Бич профессии — превращать самого опытного разработчика в плохого менеджера. Я видел ситуации, когда синьор перерастает команду и ему предлагают должность руководителя. Многие соглашались и становились несчастными. И ладно бы только они: страдает-то в итоге команда и компания.

Зачем они соглашаются? Во-первых, потому что они росли всегда и останавливаться страшно. Во-вторых — это часто единственная возможность повышения.

Что мы поменяли у себя в разработке Газпромбанка:

• Явно обозначили, что инженер, получающий больше своего руководителя, — обычная ситуация.
• Дали возможность расти инженерам дальше после синьора, не меняя свою работу, то есть не становясь руководителями.

Куда можно расти? В хеда профессии — эксперта, к которому может обратиться каждый в компании. Это как Стив Возняк в Apple.

Как это ни странно, в развитой инженерной культуре такие «эксперты выше синьора» — норма. В России я встречал мало компаний с такими фичами, поэтому хочу поделиться практическим опытом того, что это даёт.

Кто такой хед профессии?

Это суперквалифицированный инженер, который не хочет управлять другими людьми. Если хочет, рост понятный — вперёд до CTO, привыкшего управлять стейкхолдерами, ресурсами и работать с бизнесом. А вот если человеку интересны только технические аспекты работы, наступает интересная ситуация. Сначала в команде становится тесно. Потому что хочется чего-то большего, а команда этого предложить не может. Потом становится скучно. Можно, конечно, сменить проект — но через 2–3 месяца скучно станет с новой силой. Обычно дальше сотрудник развлекается увольнением или в качестве хобби идёт разводить пчёл в деревне.

Что ему можно предложить?

Во-первых, нам нужны люди с очень глубокой экспертизой, чтобы к ним можно было обратиться за советом.

Во-вторых, эти люди нужны для того, чтобы развивать подходы к работе. Например, эксперт по Java, вышедший за рамки синьорства, — может развивать подходы к написанию кода, создавать корпоративные стандарты и транслировать их на всех. Это важно, потому что даже в кровавом энтерпрайзе часто при одинаковом стеке три разных команды сделают три разных по структуре и стилю продукта и поженить их потом будет очень сложно. Мы стремимся к тому, чтобы подходы написания кода были едины — и как раз эту функцию очень хорошо поддерживает хед профессии. Он не занимается менеджментом, он унифицирует стандарты и подходы. Он определяет базовый набор инструментов на уровне организации и должен замотивировать инженеров этим подходам следовать.

В-третьих, эти подходы можно выносить на комьюнити. Эксперт может выходить на мероприятия и рассказывать про опыт разработки и производства, полученный в компании. Для компании это развитие технобренда, для специалиста — возможность менять стандарты всей сферы.

И при этом хед профессии остаётся в команде и действует как разработчик. Мы строим организацию так, чтобы хеды профессии были частью команды, а не выделялись.

Мы используем Engineering Ladder Framework. Инженер по хардам оценивается по 7 уровням этой лестницы. Это инженер разработки, старший инженер разработки, ведущий инженер разработки, главный инженер разработки, эксперт разработки, ведущий эксперт разработки, главный эксперт разработки. На уровнях 6 и 7 быть хедом уже одно из требований компетенции.

Чем лидер отличается от руководителя?

Приведу цитату Гарольда Ливитта (из «Сверху вниз»):

«Менеджер администрирует — Лидер обновляет.
Менеджер поддерживает — Лидер развивает.
Менеджер сосредоточен на системах и структуре — Лидер сосредоточен на людях.
Менеджер полагается на контроль — Лидер внушает доверие.
Менеджер спрашивает, как и когда — Лидер спрашивает, что и почему.
Менеджер смотрит на прибыль — Лидер смотрит в будущее.
Менеджер делает вещи правильно — Лидер делает правильные вещи».

Откуда у него берётся время?

Разработчик пишет код 2–3 часа в день. Остальное время он читает, обсуждает, думает, смотрит ковёр, ревьюит, ест и переживает глубокую травму от неидеальности кода. Хед профессии достиг опыта во всём этом (кроме еды) и обычно делает то же самое быстрее. Образуется 1–2 часа на то, что ему интересно.

Например, эксперты часто дают окна в расписании HR-отделу (1–2 часа в неделю) на собеседования и внутренние ассесменты (при повышениях). Они часто разрабатывают сам дизайн технического интервью, проектируют тестовые задания, выходят непосредственно к ключевым кандидатам и так далее.

Им не сложно поработать над стандартом написания кода — это хорошее переключение. И так далее.

Предполагается, что эти люди выросли до того, что они — полноценные зрелые инженеры, которые умеют управлять временем и могут самоорганизоваться и распределить делегирование. Если не удаётся — вступает хед хедов.

Один хед — одна профессия?

Нет. В нашей системе хедов может быть сколько угодно.

Примерно начиная с уровня развитого мидла мы смотрим на то, к чему человек более склонен — к управлению людьми или к управлению техническими стандартами и развитию технологии. Если второе — то постепенно предлагаем некоторые функции хеда профессии до тех пор, пока после синьорства он таковым не станет.

То есть хедов может быть сколько угодно, и они друг другу не противоречат, а составляют некий совет или гильдию.

Сейчас у нас 7 центров компетенций, этих самых «гильдий»:

• Центр экспертизы архитектуры решений.
• Центр экспертизы качества программного обеспечения.
• Центр экспертизы разработки баз данных.
• Центр экспертизы разработки и сопровождения систем.
• Центр экспертизы разработки приложений.
• Центр экспертизы разработки фронтальных систем.
• Центр экспертизы системного анализа.

Очень важно, что когда хед становится хедом официально, это означает, что у него появляется новый функционал, но при этом не прибавляется полномочий. То есть он не может прийти и сказать: «Так, теперь мы все переписываем миллион строк Java на Go, я так сказал, исполняйте!!». Сначала ему нужно убедить других хедов своей профессии, что это разумно. Затем они все убеждают техлидов команд, те своих инженеров — и только затем это становится стандартом. Иногда бывает так, что решение неконсенсусное, но полезное — тогда можно убедить CTO или руководителя центра компетенций в том, что нужно ввести новый стандарт (регламент) принудительно, но это крайние случаи. В любой ситуации хед профессии имеет много фильтров перед имплементацией решений. То есть сначала обычно хорошая практика обкатывается в своей команде, потом на подразделении, потом через центр компетенций — на весь банк.

Если джун пошлёт хеда на три буквы, то останется только убеждать. Но обычно у хеда уже есть очень большой авторитет в сфере, и такая ситуация просто не возникает.

Хеды уже взрослые люди и достаточно опытны, чтобы делить между собой задачи. Например, если кто-то любит выступать, а кто-то второй не любит, они способны договориться между собой о перераспределении этой работы.

Хеды разных профессий собираются на регулярные стратегические встречи, где прорабатывается вектор развития стратегии и приоритезируются вещи, которые прямо горят.

Что формально прописано в должностных обязанностях?

Роль Head of Profession

Техническое лидерство. Быть ведущим экспертом, евангелистом и мыслителем, представляющим выбранную профессию и её возможности.

Развитие технологий. Формировать предложения на тактическом и стратегическом уровне по развитию представляемой профессии в соответствии с бизнес-целями.

Кадровое планирование. Формировать рекомендации по подбору людей в профессию, команды. Организовывать поддержку лидеров стримов в планировании необходимых уровней кадров, компетенций в рамках профессии.

Планирование карьеры. Обеспечить лидерство в развитии навыков карьерного роста и обучении инженеров по профессии.

Управление знаниями. Отстаивать развитие технических компетенций, организовывать процессы обмена знаниями, включая преемственность, наставничество. Организовывать программы обучения и подготовку молодых инженеров.

Процессы и политики. Создавать и поддерживать стандарты и процессы, развивающие профессию.

Развитие технобренда. Принимать участие в профильных сообществах и мероприятиях внутренних и внешних в качестве спикера, контентмейкера, продвигая и развивая технобренд банка. Развивать внутренние профессиональные сообщества и их процессы.

Обратите внимание, что никакое управление нигде не прописано — даже в должностных (мы же банк, у нас всё это важно) нет ни слова про это.

Что мы получили

Мы избавили разработчиков от того, чтобы руководить тогда, когда они этого не хотят — но и при этом избавили от стагнации, когда синьор не стал руководителем.

Мы решили энтерпрайзную проблему с тем, что формально можно записать инженера руководителем ради грейда, но не давать ему обязанности менеджера. Такое часто случается, но заканчивается печально. Инженер с формальной должностью «руководитель» сначала решает один маленький вопрос, потом из-за чувства ответственности другой, потом кто-то из другой части структуры обращается к нему как к руководителю с вопросом — и вот у нас новый менеджер, который никогда этого не хотел. У нас по должности можно чётко понять, с чем приходить, а с чем нет.

Мы построили меритократию в миниатюре. Хеды управляют стандартами, а через стандарты мы управляем разработкой. Хеды помогают в создании поля знаний, которое очень важно. В предыдущих постах серии «Отстаньте от разработчиков» про это есть: вот первый, вот второй .

Мы знаем про риск того, что хеды будут рождать всё более и более мейнстримовые вещи, потому что в сильных решениях нужно убеждать всех. Если софтов не хватает, могут и не убедить. Тем не менее пока такой проблемы не замечено. У нас сейчас скорее Дикий Запад, и мы только определяем правила игры. Все предложения хедов — они базис, вещи, без которых просто нельзя. Возможно, когда-то позже, когда можно будет расслабиться, мы будем аристократами, пить шампанское на встречах и загнивать. Пока до этого далеко.

Точно могу сказать, что хеды сами по себе как институт невозможны без определённой культуры организации, склонной как раз к меритократии. В другой модели организации хедов не будет. Длинной лестницы для инженеров не будет. Есть компании, где ИТ-директора и исполнительные директора для самого ИТ-блока — дятлы, которые не секут в технологиях и их надо очаровать или убрать с дороги. В нашей ситуации руководство ИТ-блоком — это скорее Светлый Совет магов, а не корпорация. Ну, насколько это вообще возможно в банке.

Так что, думаю, у нас получилось кое-что важное. А теперь разнесите наш опыт, пожалуйста )