Путь развития руководителя разработки

Карьера началась с ожидания, что после технического образования получится заниматься наукой. На третьем курсе появилась первая работа junior-разработчиком в небольшой компании без зрелых инженерных процессов. Несовпадение университетского computer science с реальной промышленной разработкой заставило самостоятельно изучать code review, тестирование, сборку и правила поддержки больших систем. Затем была попытка перейти в аналитику, возвращение в разработку, рост до middle и senior и первая развилка: углубляться в технику или искать больший масштаб влияния.

Следующим шагом стала роль тимлида: сначала запуск новой версии продукта в издательском доме, затем ещё несколько команд, стартап и, наконец, Tinkoff.ru. В привлечении техническая команда выросла примерно с десяти до ста человек. В ретроспективе первые годы можно было пройти быстрее — не уходить надолго в аналитику и раньше попасть в сильную среду. Но эти отклонения дали широкий взгляд на бизнес, архитектуру и процессы. Осознанность не исключает эксперименты; она помогает понимать, зачем нужен каждый из них.

Junior и middle наращивают инженерную базу и самостоятельность. На уровне senior появляется ответственность за крупные части системы, но влияние всё ещё ограничено личной производительностью. Переход в team lead меняет профессию: результат теперь создаётся через людей и процесс. Нужно выстраивать правила работы, развивать специалистов, делегировать и отвечать за общий результат команды, а не за количество написанного собственными руками кода.

Руководитель нескольких команд снова меняет масштаб. Он работает через тимлидов, распределяет ресурсы между направлениями, согласует приоритеты и сроки, распространяет удачные практики и проводит изменения. На уровне технического руководителя мерилом становится бизнес-результат. Нужно начинать с цели бизнеса, выбирать архитектуру, способную выдержать рост, собирать подходящие команды, организовывать их работу — а затем отходить в сторону, помогая отстающим и усиливая тех, у кого получается.

Особенно важна первая рабочая среда. Junior без предыдущего опыта принимает местные правила за норму, поэтому ему нужны и понятные обязанности, и полный инженерный контур: code review, тесты, CI/CD, воспроизводимая инфраструктура и прозрачный процесс поставки. В хаосе сильный специалист ещё может самостоятельно восстановить правила игры, а начинающий чаще закрепляет случайные практики и тратит годы на их переосмысление.

Практики между командами лучше переносить не приказом сверху, а через общую проблему и эксперимент. Сначала нужно показать, что похожая команда уже прошла путь от исходного состояния к результату, затем предложить попробовать подход и проверить эффект. У руководителя разработки горизонт обратной связи измеряется месяцами: изменение, о котором договорились сегодня, может заработать только через полгода. Нетерпение на этом уровне легко принять за отсутствие прогресса.