Всем привет! Меня зовут Денис Ульянов, и я продолжаю серию статей «От разработчика к руководителю». В предыдущих статьях я рассказал, почему управлять людьми сложнее, чем писать код и как мы создали собственную методологию разработки. Сегодня поговорим о фазовом переходе, который происходит с инженером, когда он становится руководителем.
Типичная история
Как часто это происходит? Есть в команде отличный разработчик Вася. Он делает больше задач за спринт, чем вся команда вместе взятая. Инициативный, амбициозный, систему знает как свои пять пальцев — не он строился вокруг сервисов, а сервисы вокруг него. И вот приходит момент повышения — технический директор говорит: «Теперь, Вася, ты менеджер. Руководитель команды». Вася воодушевлен и идёт управлять.
Но что значит «управлять»? Обычно такие Васи берут на себя самые сложные задачи, не доверяют команде и начинают жить по принципу «8 часов на код и 8 часов на менеджерские задачи». Днём он пишет код, консультирует коллег и ревьюит задачи, а по ночам пытается заниматься менеджментом.
Активность Васи в GitLab выше, чем у всей команды, и он этим гордится. Возможно, Вася даже читал статьи о делегировании и пытается «раскидать» карточки по команде. Но по факту каждую задачу он проверяет лично и контролирует вплоть до деплоя в production.
Ещё у Васи есть страшный и непонятный people management. Когда им заниматься, совершенно не ясно.
Почему так происходит?
Вернёмся назад и посмотрим, как инженеры обычно растут по карьерной лестнице. Они были джунами, затем стали мидлами, после начали замахиваться на архитектуру и стали сеньорами. Упрощённо — примерно так. И тут появляется «Принцип Питера»:
В иерархической системе каждый индивидуум имеет тенденцию подниматься до уровня своей некомпетентности.
Переходя на позицию руководителя, инженер часто оказывается неэффективным, хотя был блестящим разработчиком. Почему так происходит? Ответ прост: не надо делать из хороших инженеров плохих менеджеров. Роль руководителя — не следующая ступень карьеры инженера, а совершенно иная профессия. Нас не учат управлять людьми, и после повышения мы делаем то, что умеем лучше всего: пишем код.
Что с этим делать?
Задача новоиспеченного руководителя проста и сложна одновременно — как можно быстрее пройти трансформацию от инженера к руководителю. И тут главный парадокс: технический опыт, который помогал нам раньше, теперь становится главной помехой. Очень сложно отказаться от соблазна вмешиваться в код, ревью и архитектуру, ведь ты делаешь это лучше всех.
Я советую радикальное решение — запретить себе писать код, не трогать pull requests и не вмешиваться в архитектурные дискуссии. Это будет больно, примерно как резко бросить курить. Но это единственный эффективный путь.
Ещё один совет: обязательно прочитайте «Джедайские техники» Максима Дорофеева. Если вы ещё не читали, бросайте статью и бегите читать эту книгу. Это первая книга, которая нужна вам как руководителю.
Также крайне полезно забронировать время на обед в своём календаре. Как ни смешно это звучит, но иначе вы рискуете проводить целый день на бесконечных встречах без возможности передохнуть.
Чем же заниматься руководителю?
Теперь ваша главная задача — работа с людьми. Вдохновлять, развивать, мотивировать команду, держать её в фокусе на достижение результата. Говорить с людьми теперь ваша обязанность. Учитесь доверять команде и перестаньте быть самым сильным разработчиком в ней.
Вам нужно завоевать авторитет не за счёт хард-скиллов, а за счёт качества вашего руководства. Как конкретно это делать — зависит от вашего стиля управления, и здесь не будет универсального рецепта. Но важно понять одно: теперь всё будет иначе, чем раньше. Вас ждёт фазовый переход, который может пройти быстро или долго, а может, вы и вовсе поймёте, что менеджмент не для вас.
Помните: быть руководителем — это не про власть и не про статус. Это ответственность перед командой и людьми, которые вам доверились. Готовьтесь учиться заново, готовьтесь ошибаться и расти. Главное — не пытайтесь быть лучшим инженером. Теперь ваша задача — стать лучшим руководителем.
Как же понять, что ты уже хороший руководитель?
Почему это сложно?
На первый взгляд, проверить себя кажется легко: достаточно собрать вертикальный фидбек (от своей команды и руководителя) и горизонтальный (от коллег из других команд). Но на деле это не так просто и не всегда объективно.
Команда и коллеги могут не знать, какие именно задачи перед вами стоят, и не понимать истинных причин ваших решений. Например, вы можете быть жёстким и требовательным не потому, что вам это нравится, а потому, что проект действительно сложный и требует напряжения. Ситуации, когда рынок меняется и работа последних месяцев уходит на свалку, неизбежны. Чем сложнее проект, тем чаще такое происходит.
Ваш руководитель, наоборот, может не знать, как именно выстраиваются ваши отношения с командой, насколько сотрудники выгорели или готовы к увольнению. Кроме того, горизонт планирования руководителя достаточно велик: многие решения проявят свои результаты только через несколько месяцев, а значит, моментальная оценка не даст правильного понимания.
Критерии самооценки руководителя
При отсутствии идеального способа оценки мы можем использовать несколько субъективных критериев, которые, тем не менее, дают достаточно ясную картину:
Ваш руководитель доволен результатами вашей команды.
В вашей команде нет текучки кадров, то есть люди готовы с вами работать. Они могут быть недовольны, но главное продолжают работать с вами.
Вы можете спокойно уйти в отпуск на несколько недель и не подключаться к работе. Важно не просто отдохнуть, но и убедиться, что команда работает в вашем отсутствии так же эффективно, как и при вас. Если же она работает даже лучше — поздравляю, вы были «саботажником» собственной команды.
Кажется, пунктов немного? Да, но именно эти критерии показывают ваш результат как руководителя, уровень вашей вовлеченности (или микроменеджмента) и стабильность команды.
Саморефлексия и взгляд со стороны
Для руководителя крайне важна саморефлексия. Умение останавливаться и задумываться о том, правильно ли вы поступили в той или иной ситуации, поможет вам постоянно расти и улучшаться.
Найдите коллегу или ментора, с которым сможете откровенно обсуждать рабочие вопросы. Это позволит взглянуть на свои действия под другим углом и, возможно, избежать ошибок в будущем.
Что почитать и послушать?
Наконец, поделюсь книгами и ресурсами, которые в своё время оказались для меня крайне полезными:
Элияху Голдратт «Цель» (The Goal) — о том, как эффективно управлять процессами и видеть главное.
Том ДеМарко «Deadline. Роман об управлении проектами» — помогает понять, как управление проектами и людьми работает на самом деле.
Максим Дорофеев «Джедайские техники» — о том, как правильно работать с задачами и сохранять продуктивность.
Подкаст «Podlodka» — там часто разбирают ситуации, с которыми сталкиваются руководители IT-команд.
Как говорится, умный учится на чужих ошибках, и я советую вам именно такой подход. Надеюсь, эта статья поможет вам лучше понять себя и даст отправную точку для дальнейшего роста в роли руководителя.
Разборы, новости, экспертиза наших разработчиков и вакансии — в телеграм-канале, подписывайтесь!