Переход в лиды из разработчика — дело не простое. Нужно научиться слушать людей, видеть их сильные стороны, разбираться в мотивации и много чего еще. Сейчас я Dev Lead в Exante. Мы разрабатываем внутренние сервисы для узкого круга заказчиков. Мой путь в лиды начался с неформального лидерства и первых попыток менторства. О том, что я узнал, какие фейлы прошёл и чему научился за это время — под катом.
Первый среди равных
Мой первый шаг в управление начался с роли неформального лидера в команде, которая только запускала новый проект. Я занимался бэкендом, а два моих коллеги закрывали фронт и мобильную часть. Руководство настаивало на Agile, поэтому каждую неделю мы устраивали демо, показывали, что успели накатить, и собирали фидбек от заказчиков.
Так получилось, что именно я отвечал за большинство технических вопросов на этих встречах — обсуждал архитектуру, предлагал решения, объяснял, почему тот или иной подход лучше ложится в проект. Официально я был таким же разрабом, как и остальные, но неофициально стал точкой входа для многих вопросов — возможно, потому что бэкенд часто становится ядром системы и требует системного взгляда.
На этом проекте случился мой первый фейл: я оставил баг, который не успел закрыть перед уходом. Коллеги потом его исправили, но урок остался — лидерство — это не только про ответственность, но и про создание системы, которая работает даже без твоего контроля.
Микровывод: Неформальное лидерство — это не про должность, а про готовность брать на себя ответственность, видеть проблемы и решать их до того, как они станут критичными.
Падаваны падавана
В другой компании я сам предложил свою кандидатуру на роль лида, но там просто так менеджерами не становились, даже при явной нехватке кадров. Мне предложили взять под крыло двух новичков — показать процессы, помочь с первыми тасками, научить проводить код-ревью и one-to-one. Я согласился — любой опыт был мне нужен.
Один из моих падаванов не прошёл испытательный срок, второй перешёл в соседнюю команду. Оба были не особо вовлечены: инициативы — минимум, интереса — тоже. Я пытался их расшевелить, дать больше свободы, но особого эффекта это не принесло. Тогда и пришло первое менторское прозрение: ты не вытащишь человека туда, куда он сам идти не хочет. Иногда лучший вклад — помочь ему осознать, в чём он действительно силён, и отпустить.
Микровывод: Менторство — это не только передача знаний, но и умение понять, кто действительно готов учиться, а кто просто плывёт по течению.
Сформированная команда
В следующей компании я снова начинал разрабом. Но вскоре мне предложили перейти на позицию лида в уже сформированную команду — их старый лидер как раз увольнялся. Все согласования прошли быстро, и я начал вникать в процессы. Первые недели были непростыми: команда уже устоявшаяся, со своими привычками и внутренними договорённостями, которые мне ещё предстояло понять.
Сразу заметил процессы, которые можно было улучшить. Вместо резких перемен решил начать с небольших шагов — понять, что для команды действительно важно, а потом постепенно предлагать изменения. Один из удачных кейсов — пересмотр процесса ревью, который помог сократить время на обсуждение кода и повысить качество выпускаемых фич.
В сложившейся команде нельзя сразу начинать с радикальных изменений. Люди привыкли к процессам и технологиям, если начать резко что то менять можно вызвать раздражение у коллег. Постепенные шаги, вовлечение команды и уважение к уже принятым практикам — более эффективная стратегия.
Микровывод: Лид в сформированной команде — это способность видеть возможности для улучшения там, где другие давно смирились со статус-кво, и двигать команду вперёд, сохраняя уважение к её привычным процессам.
Между кодингом и управлением
Хотя роль лида добавляет кучу митингов, я никогда не прекращал кодить. Менеджмент забирал у меня не более 50% рабочего времени — остальное я старался разрабатывать сам, чтобы не терять связь с реальностью.
Даже если продолжаешь писать код, со временем всё равно начинаешь отставать от новых подходов. Однажды пришлось влететь в ревью сложного модуля — а команда уже вовсю использует свежие технологии. Пришлось срочно нагонять, чтобы не выглядеть гостем на собственной кухне. С тех пор завёл привычку регулярно обсуждать новинки с теми, кто глубже в ресёрче — это помогает не выпадать из технологического контекста и не скатиться в роль номинального «архитектора».
Ревью кода — важная часть работы лида. Здесь важно не только проверять корректность выполнения, но и следить за читаемостью и лаконичностью. Часто свежий, незамыленный взгляд помогает поймать корнер-кейсы и неочевидные сценарии, которые легко ускользают в потоке задач. Такие находки экономят время QA и сокращают число доработок, а заодно повышают доверие команды к тебе как к технарю.
Кроме того, всегда смотрю на юнит-тесты — они должны покрывать не только позитивные сценарии, но и пограничные случаи. Это банально, но именно тимлид должен следить, чтобы тесты действительно проверяли, а не просто существовали. После того как мы ввели обязательные юнит- и интеграционные тесты, задачи стали заметно реже возвращаться на доработку из QA. Меньше правок — меньше фрустрации у всех.
Микровывод: Лид, который перестал писать код, со временем рискует стать «архитектором на пенсии» — таким, кто может много рассуждать, но уже не знает, как реально всё устроено внутри.
Усвоенные уроки
1. Фидбек — это нормально. Не важно, хороший он или плохой. Давайте его честно, но тактично — неприятные моменты лучше вставлять между позитивными, чтобы смягчить удар. И не забывайте самому просить фидбек на себя как лида — это помогает расти, даже если не всегда приятно.
2. Вы — мост между разрабами и бизнесом. Лид — это не просто координатор задач, а проводник между разработчиками и бизнесом. Ваша задача — замечать проблемы раньше всех, находить компромиссы и поддерживать баланс между интересами команды и компании.
3. Не всех можно замотивировать. Некоторые люди просто не выкладываются на 100%, и ты ничего с этим не сделаешь. В таких случаях важно честно сообщить руководству, что человек не подходит команде.
4. Берите на себя ответственность. Лидерство начинается с готовности принимать решения и нести за них ответственность. Иногда лучше попробовать и ошибиться, чем ждать, пока кто-то другой возьмёт инициативу.
5. Тяните за собой команду. Если кто-то буксует — помогайте. Иногда это значит просто подсказать, иногда — сходить в соседний отдел и спросить, как коллеги решали похожие задачи. Вместе вы сможете двигаться быстрее.
6. Фейлы — часть пути. Ошибки неизбежны. Главное — понять, почему так произошло, сделать выводы и двигаться дальше. Через год любой фейл превращается в байку, которую приятно вспоминать на корпоративе.
7. Делегируйте, но держите руку на пульсе. Не пытайтесь завязать всё на себе. Дайте команде проявить себя, но не отпускай задачи полность��. Контролируйте ключевые точки, чтобы вовремя заметить, если что-то идёт не так.
8. Предлагайте идеи, но будь готов к отказу.
Даже самые крутые идеи могут не сработать из-за специфики проекта. Учитесь слушать команду, находить причины отказа и адаптировать свои предложения.
9. Проводите встречи один-на-один.
Эти беседы важны не только для фидбека по задачам, но и для построения доверия. Иногда такие разговоры помогают увидеть скрытые проблемы и лучше понять команду.
10. Не выносите фейлы на общие собрания. Ошибки лучше разбирать на личных встречах — это снижает стресс и позволяет обсуждать промахи честно и открыто. Общие митинги лучше использовать для обсуждения успехов и планов.
11. Документируйте процессы. Плохая документация кода лучше, чем ее полное отсутствие. Записывайте ключевые моменты, команды и решения — потом скажете себе за это спасибо.
12. Гибкость — ключ к успеху. Люди разные, и то, что работает с одним, может оказаться бесполезным с другим. Лидер должен быть готов менять подходы, адаптироваться и искать индивидуальные решения.
Эпилог
Лидерство — это не только про задачи, но и про понимание людей. Иногда важно слышать, что говорят между строк, и замечать, когда «всё нормально» — это просто привычная фраза.
Чтобы лучше понимать людей, я начал искать нестандартные подходы. Например, DnD оказался неожиданно полезным инструментом. Во время всей игры приходится быстро находить общий язык с командой, учитывать интересы всех участников и принимать решения под давлением.
Хакатоны тоже стали отличной школой лидерства. В условиях жёстких дедлайнов и ограниченных ресурсов люди проявляют себя иначе. Нужно быстро выявлять приоритеты, предлагать решения и сохранять спокойствие, когда команда на грани выгорания.
Лидер — это не просто менеджер, а тот, кто видит возможности там, где другие видят только проблемы, и помогает команде раскрыть свой потенциал. Если готовы к этому — дерзайте.