Отстаньте от разработчиков: не надо делать их руководителями просто ради грейда
Бич профессии — превращать самого опытного разработчика в плохого менеджера. Я видел ситуации, когда синьор перерастает команду и ему предлагают должность руководителя. Многие соглашались и становились несчастными. И ладно бы только они: страдает-то в итоге команда и компания.
Зачем они соглашаются? Во-первых, потому что они росли всегда и останавливаться страшно. Во-вторых — это часто единственная возможность повышения.
Что мы поменяли у себя в разработке Газпромбанка:
- Явно обозначили, что инженер, получающий больше своего руководителя, — обычная ситуация.
- Дали возможность расти инженерам дальше после синьора, не меняя свою работу, то есть не становясь руководителями.
Куда можно расти? В хеда профессии — эксперта, к которому может обратиться каждый в компании. Это как Стив Возняк в 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
Техническое лидерство. Быть ведущим экспертом, евангелистом и мыслителем, представляющим выбранную профессию и её возможности.
Развитие технологий. Формировать предложения на тактическом и стратегическом уровне по развитию представляемой профессии в соответствии с бизнес-целями.
Кадровое планирование. Формировать рекомендации по подбору людей в профессию, команды. Организовывать поддержку лидеров стримов в планировании необходимых уровней кадров, компетенций в рамках профессии.
Планирование карьеры. Обеспечить лидерство в развитии навыков карьерного роста и обучении инженеров по профессии.
Управление знаниями. Отстаивать развитие технических компетенций, организовывать процессы обмена знаниями, включая преемственность, наставничество. Организовывать программы обучения и подготовку молодых инженеров.
Процессы и политики. Создавать и поддерживать стандарты и процессы, развивающие профессию.
Развитие технобренда. Принимать участие в профильных сообществах и мероприятиях внутренних и внешних в качестве спикера, контентмейкера, продвигая и развивая технобренд банка. Развивать внутренние профессиональные сообщества и их процессы.
Обратите внимание, что никакое управление нигде не прописано — даже в должностных (мы же банк, у нас всё это важно) нет ни слова про это.
Что мы получили
Мы избавили разработчиков от того, чтобы руководить тогда, когда они этого не хотят —, но и при этом избавили от стагнации, когда синьор не стал руководителем.
Мы решили энтерпрайзную проблему с тем, что формально можно записать инженера руководителем ради грейда, но не давать ему обязанности менеджера. Такое часто случается, но заканчивается печально. Инженер с формальной должностью «руководитель» сначала решает один маленький вопрос, потом из-за чувства ответственности другой, потом кто-то из другой части структуры обращается к нему как к руководителю с вопросом — и вот у нас новый менеджер, который никогда этого не хотел. У нас по должности можно чётко понять, с чем приходить, а с чем нет.
Мы построили меритократию в миниатюре. Хеды управляют стандартами, а через стандарты мы управляем разработкой. Хеды помогают в создании поля знаний, которое очень важно. В предыдущих постах серии «Отстаньте от разработчиков» про это есть: вот первый, вот второй.
Мы знаем про риск того, что хеды будут рождать всё более и более мейнстримовые вещи, потому что в сильных решениях нужно убеждать всех. Если софтов не хватает, могут и не убедить. Тем не менее пока такой проблемы не замечено. У нас сейчас скорее Дикий Запад, и мы только определяем правила игры. Все предложения хедов — они базис, вещи, без которых просто нельзя. Возможно, когда-то позже, когда можно будет расслабиться, мы будем аристократами, пить шампанское на встречах и загнивать. Пока до этого далеко.
Точно могу сказать, что хеды сами по себе как институт невозможны без определённой культуры организации, склонной как раз к меритократии. В другой модели организации хедов не будет. Длинной лестницы для инженеров не будет. Есть компании, где ИТ-директора и исполнительные директора для самого ИТ-блока — дятлы, которые не секут в технологиях и их надо очаровать или убрать с дороги. В нашей ситуации руководство ИТ-блоком — это скорее Светлый Совет магов, а не корпорация. Ну, насколько это вообще возможно в банке.
Так что, думаю, у нас получилось кое-что важное. А теперь разнесите наш опыт, пожалуйста)
