Переход в лиды из разработчика — дело не простое. Нужно научиться слушать людей, видеть их сильные стороны, разбираться в мотивации и много чего еще. Сейчас я Dev Lead в Exante. Мы разрабатываем внутренние сервисы для узкого круга заказчиков. Мой путь в лиды начался с неформального лидерства и первых попыток менторства. О том, что я узнал, какие фейлы прошёл и чему научился за это время — под катом.

Первый среди равных

Мой первый шаг в управление начался с роли неформального лидера в команде, которая только запускала новый проект. Я занимался бэкендом, а два моих коллеги закрывали фронт и мобильную часть. Руководство настаивало на Agile, поэтому каждую неделю мы устраивали демо, показывали, что успели накатить, и собирали фидбек от заказчиков.

Так получилось, что именно я отвечал за большинство технических вопросов на этих встречах — обсуждал архитектуру, предлагал решения, объяснял, почему тот или иной подход лучше ложится в проект. Официально я был таким же разрабом, как и остальные, но неофициально стал точкой входа для многих вопросов — возможно, потому что бэкенд часто становится ядром системы и требует системного взгляда.

На этом проекте случился мой первый фейл: я оставил баг, который не успел закрыть перед уходом. Коллеги потом его исправили, но урок остался — лидерство — это не только про ответственность, но и про создание системы, которая работает даже без твоего контроля.

Микровывод: Неформальное лидерство — это не про должность, а про готовность брать на себя ответственность, видеть проблемы и решать их до того, как они станут критичными.

Падаваны падавана

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

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

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

Сформированная команда

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

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

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

Микровывод: Лид в сформированной команде — это способность видеть возможности для улучшения там, где другие давно смирились со статус-кво, и двигать команду вперёд, сохраняя уважение к её привычным процессам.

Между кодингом и управлением

Хотя роль лида добавляет кучу митингов, я никогда не прекращал кодить. Менеджмент забирал у меня не более 50% рабочего времени — остальное я старался разрабатывать сам, чтобы не терять связь с реальностью.

Даже если продолжаешь писать код, со временем всё равно начинаешь отставать от новых подходов. Однажды пришлось влететь в ревью сложного модуля — а команда уже вовсю использует свежие технологии. Пришлось срочно нагонять, чтобы не выглядеть гостем на собственной кухне. С тех пор завёл привычку регулярно обсуждать новинки с теми, кто глубже в ресёрче — это помогает не выпадать из технологического контекста и не скатиться в роль номинального «архитектора».

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

Кроме того, всегда смотрю на юнит-тесты — они должны покрывать не только позитивные сценарии, но и пограничные случаи. Это банально, но именно тимлид должен следить, чтобы тесты действительно проверяли, а не просто существовали. После того как мы ввели обязательные юнит- и интеграционные тесты, задачи стали заметно реже возвращаться на доработку из QA. Меньше правок — меньше фрустрации у всех.

Микровывод: Лид, который перестал писать код, со временем рискует стать «архитектором на пенсии» — таким, кто может много рассуждать, но уже не знает, как реально всё устроено внутри.

Усвоенные уроки

1. Фидбек — это нормально. Не важно, хороший он или плохой. Давайте его честно, но тактично — неприятные моменты лучше вставлять между позитивными, чтобы смягчить удар. И не забывайте самому просить фидбек на себя как лида — это помогает расти, даже если не всегда приятно.

2. Вы — мост между разрабами и бизнесом. Лид — это не просто координатор задач, а проводник между разработчиками и бизнесом. Ваша задача — замечать проблемы раньше всех, находить компромиссы и поддерживать баланс между интересами команды и компании.

3. Не всех можно замотивировать. Некоторые люди просто не выкладываются на 100%, и ты ничего с этим не сделаешь. В таких случаях важно честно сообщить руководству, что человек не подходит команде.

4. Берите на себя ответственность. Лидерство начинается с готовности принимать решения и нести за них ответственность. Иногда лучше попробовать и ошибиться, чем ждать, пока кто-то другой возьмёт инициативу.

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

6. Фейлы — часть пути. Ошибки неизбежны. Главное — понять, почему так произошло, сделать выводы и двигаться дальше. Через год любой фейл превращается в байку, которую приятно вспоминать на корпоративе.

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

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

9. Проводите встречи один-на-один.
Эти беседы важны не только для фидбека по задачам, но и для построения доверия. Иногда такие разговоры помогают увидеть скрытые проблемы и лучше понять команду.

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

11. Документируйте процессы. Плохая документация кода лучше, чем ее полное отсутствие. Записывайте ключевые моменты, команды и решения — потом скажете себе за это спасибо.

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

Эпилог

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

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

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

Лидер — это не просто менеджер, а тот, кто видит возможности там, где другие видят только проблемы, и помогает команде раскрыть свой потенциал. Если готовы к этому — дерзайте.