Резкий рост команды разработчиков — например, с 6 до 12 человек — часто превращает тимлида в узкое место: ревью копятся, встречи один на один переносятся, а сильные специалисты начинают задумываться об уходе. Ниже — семь типичных ошибок и практические шаги, как перестроить управление, пока проблемы не стали критическими.
1. Пытаться всё делать самому
Тимлид продолжает брать задачи как разработчик, плюс ревью, плюс управление. В итоге ни одна роль не выполняется качественно. Шаг: выделите чёткие зоны ответственности. Например, назначьте техлида или старшего разработчика на ревью и менторство, а сами сосредоточьтесь на планировании, найме и развитии команды. Критерий успеха: у вас в календаре есть блоки времени на управленческие задачи, а не только на код.
2. Игнорировать делегирование
При росте команды тимлид часто боится потерять контроль и делегирует только мелкие задачи. В результате команда не растёт, а тимлид тонет в операционке. Шаг: составьте список задач, которые можно передать. Начните с повторяющихся: планирование спринта, проведение ретро, приоритизация бэклога. Делегируйте не только задачи, но и полномочия — например, право принимать решения по архитектуре в рамках сервиса.
3. Не налаживать процессы ревью
Когда разработчиков становится больше, ревью превращается в бутылочное горлышко. Если тимлид — единственный ревьюер, он становится тормозом. Шаг: введите правило: каждый разработчик может ревьюить код коллег после прохождения определённого порога (например, 3 успешных ревью от старших). Настройте автоматические проверки (линтеры, тесты), чтобы ревью фокусировалось на логике, а не на стиле. Критерий: время от пуша до первого комментария — не более 4 рабочих часов.
4. Забывать про one-on-one
С ростом команды встречи один на один легко вытесняются срочными задачами. Но именно они помогают удерживать людей и вовремя замечать проблемы. Шаг: зафиксируйте регулярность: 30 минут раз в две недели с каждым разработчиком. Подготовьте три вопроса: что мешает, что получается, чего хочет. Не переносите эти встречи — это приоритет. Если команда стала слишком большой, передайте часть встреч техлиду или EM.
5. Не пересматривать структуру команды
Одна большая команда из 12 человек плохо управляема: сложнее синхронизироваться, дольше принимаются решения. Шаг: подумайте о разделении на подкоманды по 4–6 человек с собственными зонами ответственности (например, фронтенд и бэкенд, или по продуктовым направлениям). Назначьте лидов подкоманд. Это снизит нагрузку на тимлида и даст людям возможность расти.
6. Игнорировать онбординг и менторство
При быстром найме новые сотрудники остаются без поддержки, а тимлид тратит всё время на них в ущерб остальным. Шаг: создайте простой онбординг-план на первые 2–4 недели: доступы, знакомство с кодовой базой, первый несложный таск с наставником. Назначьте бадди из опытных разработчиков. Критерий: новый сотрудник выходит на продуктивность (закрывает задачи без постоянных вопросов) за 4–6 недель.
7. Не управлять ожиданиями стейкхолдеров
С ростом команды тимлид часто продолжает обещать те же сроки, что и раньше, не учитывая, что коммуникаций и накладных расходов стало больше. Шаг: прозрачно сообщайте о capacity команды: сколько времени уходит на ревью, встречи, менторство. Используйте простые метрики: например, доля времени на разработку vs на коммуникации. Согласуйте реалистичные сроки с продуктом, а не берите всё на себя.
Главное правило: если вы чувствуете, что стали узким местом, — это сигнал перестраивать процессы и делегировать. Не ждите, пока сильные специалисты начнут уходить.
