Всем привет, меня зовут Сергей Прощаев, я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

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

Знакомая картина. Соседнюю команду расформировали, её руководитель ушёл, а людей «временно» передали вам. Было шесть человек, стало двенадцать.

Формально ничего не изменилось: тот же спринт, те же стендапы, тот же вы. Через месяц пулл‑реквесты ждут вашего ревью по три дня, встречи один на один переносятся через раз, а решения по архитектуре принимаются в коридоре без вас.

Через квартал двое сильных разработчиков уходят, и о причинах вы узнаёте на выходном интервью.

Проблема здесь не в том, что вы плохой руководитель. Число подчинённых выросло, а способ работы остался рассчитанным на шесть человек.

Почему это происходит сейчас

В январе 2026 года Gallup опубликовал данные: среднее число подчинённых у руководителя в США выросло с 10,9 в 2024 году до 12,1 в 2025-м. С 2013 года, когда Gallup начал это измерять, средний размер команды вырос почти на 50%.

Медиана при этом шесть человек, то есть средний показатель тянет вверх меньшинство очень больших команд. Некоторые наблюдатели называют эту тенденцию «Великим сплющиванием»: компании убирают средний уровень менеджмента и раздают людей оставшимся руководителям.

Самый громкий пример дал Google. В августе 2025 года CNBC со ссылкой на запись общего собрания сообщил, что за год в компании стало на 35% меньше менеджеров с маленькими командами. По словам источника издания, речь о руководителях, у которых было меньше трёх подчинённых, и многие из них остались в компании в ролях без подчинённых.

Для сравнения — модель McKinsey, построенная на управленческой работе вообще, а не на разработке. Там руководителей делят на пять архетипов по характеру работы и сразу оговаривают, что единого правильного числа подчинённых не существует. У «играющего тренера», который сам делает значимую часть работы, а подчинённые растут годами, типичный охват три‑пять человек.

У «тренера» шесть‑семь, у «супервизора» восемь‑десять. Одиннадцать‑пятнадцать и больше встречаются там, где работа стандартизирована и новичок выходит на самостоятельность за месяц‑два.

Разработка на такую работу не похожа. Если перенести её на разработку как аналогию, двенадцать человек плохо сочетаются с ролью играющего тренера, особенно если он продолжает много писать код сам.

Сразу о терминах.

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

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

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

Ошибка 1. Сохранить прежнюю долю своей инженерной работы

Симптом. Вы по‑прежнему берёте в спринт задачи из роадмапа, потому что «я же всегда так делал». Писать код получается только вечером, днём вас разрывают вопросы.

Почему возникает. Привычка и страх потерять технический уровень. Плюс никто сверху не сказал, что ожидания к вам поменялись.

Чем грозит. У Gallup медианная доля времени руководителя на индивидуальную работу вне управления — 40%. Вовлечённость самих руководителей, которые тратят на неё не больше 40%, держится на 37% при любом размере команды. У тех, кто тратит больше, она падает с ростом команды: от 36% при команде меньше пяти человек до 32% при 25 и больше. Это не норматив для тимлида, а сигнал проверить, не съедает ли индивидуальная работа управленческую часть роли.

Как исправить. Мне нравится правило, которое описал на LeadDev Ферит Топчу, руководитель разработки в Zenjob. Мелкую внеплановую работу (баг, обращение поддержки) берёт себе. Сложную внеплановую сначала исследует и решает, кому её отдать. Плановая работа принадлежит команде. В команде из двенадцати я бы договорился с руководителем о явном бюджете на свой код, например один день в неделю, и не брал ни одной задачи на критическом пути релиза.

Ошибка 2. Остаться единственным ревьюером и точкой финального решения

Симптом. Очередь пулл‑реквестов на вас растёт быстрее, чем вы её разбираете. В чате постоянно звучит «ждём апрув тимлида».

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

Чем грозит. Время до слияния растёт, разработчики переключаются между задачами, пока ждут. Вы становитесь узким местом процесса и единственным человеком, который знает всю систему целиком. Сильные инженеры часто воспринимают это как недоверие.

Как исправить. Разделить зоны владения и закрепить их в репозитории. CODEOWNERS здесь работает как маршрутизация ревью: он назначает владельцев, а обязательным их одобрение делает защита ветки (branch protection в GitHub, Code Owner approval в GitLab).

# CODEOWNERS, пример для GitHub (в GitLab синтаксис секций и настройки отличаются)
/billing/              @dev-anna @dev-oleg
/catalog/              @dev-ivan @dev-maria
/infra/terraform/      @dev-pavel @dev-anna
/.github/CODEOWNERS    @teamlead @dev-pavel

При обязательном одобрении в GitHub достаточно одного из перечисленных владельцев, поэтому на каждую зону нужны двое: отпуск одного не должен останавливать слияние.

Сам файл CODEOWNERS стоит закрепить за двумя‑тремя ответственными за репозиторий, чтобы правила ревью не менялись незаметно.

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

Ошибка 3. Сохранить встречи один на один в прежнем виде или отменить их

Симптом. Вариант первый: у вас двенадцать получасовых встреч в неделю плюс подготовка, это семь‑восемь часов, и половина переносится. Вариант второй: встречи «временно» отменены, «и так всё обсуждаем на стендапе».

Почему возникает. Формат встреч не пересчитали под новое число людей.

Чем грозит. Здесь у Gallup самая сильная цифра. Если сотрудник твёрдо согласен, что за последнюю неделю получил от руководителя содержательную обратную связь, вовлечены около 70% сотрудников, при любом размере команды. Если нет, вовлечён примерно каждый четвёртый.

Это уже вовлечённость подчинённых, а не самих руководителей. При этом лишь 16% из почти 15 тысяч опрошенных назвали последний разговор с руководителем очень содержательным. Отменяя регулярные встречи, вы лишаете себя одного из главных каналов такой обратной связи.

Я сам однажды на месяц «временно» отменил такие встречи в разросшейся команде и о том, что один из разработчиков ищет работу, узнал последним.

Как исправить. Gallup пишет, что достаточно 15–30 минут, но регулярно. Мой вариант для двенадцати человек: еженедельная 15-минутная сверка с каждым, без статусов, только «что мешает» и «что было хорошо». Раз в месяц полноценная встреча на 45 минут о развитии и обратной связи. Это около пяти часов в неделю: меньше, чем двенадцать получасовых с подготовкой, и нагрузка предсказуема, поэтому встречи реже переносятся.

Ошибка 4. Назначить лидов без полномочий

Симптом. Пара старших разработчиков «как бы» ведёт свои направления, но любое их решение всё равно переспрашивают у вас.

Почему возникает. Неформальное лидерство удобно руководителю: ответственность распределена, а контроль остался у него.

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

Как исправить. Найти две‑три устойчивые границы ответственности: продуктовые направления или самостоятельные части системы со своим владельцем (дальше — поток). Назвать в каждой лида потока и записать, что именно ему передаётся. Подчинённые при этом остаются у вас: лид потока ведёт поток и принимает решения в своей зоне, но людей в подчинение не получает.

На Рис. 2 показано, как меняется поток решений.

Главная мысль схемы: структура подчинения не меняется, меняется маршрут решений. Встречи один на один и оценка всех двенадцати остаются за тимлидом, а ежедневные решения и ревью уходят к лидам потоков. Это и отличает делегирование от отстранения.

Ошибка 5. Оставить одну большую команду с одним стендапом

Симптом. Стендап на тринадцать человек длится полчаса и превращается в очередь отчётов тимлиду. Доска одна, и в ней невозможно разобраться.

Почему возникает. Кажется, что разделение команды — это бюрократия, а «мы же одна команда».

Чем грозит. Тринадцать человек по полчаса каждый день — это шесть с половиной человеко‑часов, большая часть которых уходит на чужие статусы. Число возможных пар растёт с 15 в команде из шести до 66 в команде из двенадцати. Это не мера затрат на согласования, но хорошо показывает, почему с ростом команды явные границы ответственности становятся важнее.

Как исправить. Делить стоит, только если в работе есть устойчивые независимые потоки: свои цели, бэклог, сервисы и дежурства. Если обе половины всё равно правят один монолит, две команды добавят согласований, а не уберут их. Нарезать — по продуктовым целям, а не по технологическим слоям. Это соответствует идее потоковых команд из Team Topologies: команда строится вокруг потока ценности и не должна нести когнитивную нагрузку всей системы. У каждого потока свой короткий стендап и своя доска, а общая встреча нужна, только пока между потоками есть зависимости.

Ошибка 6. Оценивать результаты по памяти раз в полгода

Симптом. Перед ревью результатов вы смотрите на список из двенадцати фамилий и понимаете, что про треть людей помните только последний месяц.

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

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

Как исправить. Рабочий журнал: после каждой короткой встречи две‑три строки по сотруднику. Только наблюдаемое поведение, договорённости, примеры результата и темы развития, без ярлыков вроде «слабый» и без личной информации. Хранить такие записи — по правилам компании. Это пара минут после разговора, около получаса в неделю на всю команду, а через полгода у вас есть наблюдаемые примеры по каждому.

2026-09-14 | Анна | взяла разбор инцидента в биллинге без просьбы, довела до ретро
2026-09-14 | Олег | второй раз просит больше архитектурных задач — обсудить на встрече о развитии
2026-09-21 | Иван | четыре дня не поднимал блокер по интеграции — договорились сигналить, если блок дольше суток

Ошибка 7. Не пересогласовать ожидания со своим руководителем

Симптом. Команда стала вдвое больше, а от вас ждут того же: свой код, все ревью, отчёты, найм, участие в архитектурном комитете. И сроки команды пересчитали линейно: людей вдвое больше, значит фич вдвое больше.

Почему возникает. Реорганизацию проводили как перенос людей, а не как изменение ролей. Разговор «что я перестаю делать» никто не начал.

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

Как исправить. В первые две недели принести руководителю список «перестаю делать»: что передаю лидам потоков, от каких встреч ухожу, что откладываю. И договориться о переходном периоде, у меня он обычно занимает 6–12 недель, когда часть управленческого времени уходит на перестройку и ожидания по скорости команды пересогласованы заранее.

На Рис. 3 показано, как я раскладываю, кто принимает решение после перестройки.

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

Локальные решения остаются в потоке, а тимлид узнаёт о них постфактум. Если по этой схеме к вам по‑прежнему идёт большинство вопросов, значит, у лидов нет реальных прав, и вы вернулись к ошибке 4.

Сводная таблица

Чек‑лист на первые две недели

1. Посчитать долю времени на индивидуальную работу и согласовать с руководителем бюджет на неё. Задачи с критического пути отдать команде.

2. Завести или обновить CODEOWNERS, включить обязательное одобрение владельцев и убрать себя из обязательных ревьюеров обычных зон. Для сквозных изменений договориться об отдельном архитектурном ревью.

3. Перевести встречи один на один на формат «15 минут еженедельно плюс 45 раз в месяц».

4. Найти границы потоков, назвать лидов и записать их права на одной странице.

5. Разделить стендап и доску по потокам.

6. Завести рабочий журнал по каждому сотруднику.

7. Принести своему руководителю список «перестаю делать» и договориться о переходном периоде.

Вывод

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

Когда людей становится двенадцать, это перестаёт быть стилем руководства и становится пределом пропускной способности.

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

А у вас команда за последний год выросла или сжалась? И сколько человек, по‑вашему, тимлид может вести без лидов потоков? Буду рад обсудить в комментариях.

Когда команда растёт, руководителю приходится пересматривать привычные подходы к управлению: делегировать решения, распределять ответственность и выстраивать процессы, которые работают без постоянного контроля.

Продолжить разбираться в этих вопросах можно на бесплатных открытых уроках OTUS:

• 20 октября, 19:00 — «Стабильность команды и взаимозаменяемость людей». Записаться
  _{Обсудим, как делегировать задачи, развивать будущих лидеров и сохранять устойчивость команды при изменениях.}

• 9 ноября, 20:00 — «Качество без микроменеджмента: что должен контролировать CTO». Записаться
  _{Поговорим о том, как выстраивать контроль качества, не замыкая все решения на руководителе.}

Больше вебинаров для IT‑специалистов и руководителей — в октябрьском дайджесте OTUS.