Как масштабировать команду без потери скорости

За полтора года команда разработки выросла с 6 до 25 инженеров. Это был не плавный рост, а серия скачков: раунд финансирования, новый продукт, поглощение небольшой команды подрядчика. Ниже — честный разбор того, что ломалось на каждом этапе, и решения, к которым мы пришли.

Что ломается первым: коммуникация

До восьми человек всё держится на общем чате и одном стендапе. Каждый знает, кто чем занят, код-ревью происходит «через плечо», а решения принимаются за обедом.

На двенадцати людях этот механизм умирает. Симптомы узнаваемы:

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

Что сделали мы

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

Чего делать не стоит

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

Второй разлом: найм быстрее онбординга

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

Онбординг как продукт

Помогло отношение к онбордингу как к продукту с метрикой: «время до первого продакшен-коммита». Мы сократили его с 26 дней до 9:

1. Первый день — рабочее окружение поднимается одним скриптом.
2. Первая неделя — размеченный список задач «для новичка» с растущей сложностью.
3. У каждого новичка — бадди, у бадди — освобождённые 20% времени.

Третий разлом: структура

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

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

Что я сделал бы иначе

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

Короткая шпаргалка

Размер команды	Что ломается	Что вводить
6–10	неформальные знания	ADR, владельцы сервисов
10–16	онбординг	бадди, метрика первого коммита
16–25	плоская структура	продуктовые команды, матрица

Масштабирование команды — это не про то, как нанять 20 человек. Это про то, как перестроить всё вокруг них так, чтобы скорость на человека упала как можно меньше. Совсем не упасть она не может — и честно признать это перед бизнесом тоже часть работы.