«Раньше у нас была классная команда, все друг друга знали, задачи решали быстро. А теперь — процессы, согласования, и непонятно, кто за что отвечает. Кстати, напомните — как зовут нашего дизайнера?».
Узнаете? Это голос руководителя, который перерос свои старые методы.
Вы прошли путь от 5 до 50 человек. Или от одной команды до целого отдела. Вместо драйва — усталость. Вместо скорости — бюрократия.
Но дело не в том, что вы плохой руководитель. Дело в том, что методы, которые работали для 10 человек, перестали работать и начали вредить.
Статья написана для руководителей и лидов команд, которые недавно выросли или находятся в процессе масштабирования.
«Просто» нанять тимлидов — не сработает
Частая ошибка при росте — взять лучшего разработчика/менеджера и сделать его тимлидом. А когда этот закончится=выгорит — взять следующего (а еще лучше — нанять со стороны «знающего» и «эффективного» менеджера).
А так не работает.
• Масштабирование начинается не с найма людей. Оно начинается с проектирования системы.
• Зоны ответственности размыты. Непонятно, кто за какой участок отвечает и кто принимает решения.
• Нет единых правил игры. Каждый тимлид делает «как умеет» — и в итоге хаос.
Три уровня масштабирования
Как и всё хорошее в жизни, работающая модель масштабирования требует не многотомных регламентов, а вашего внимания. Принципы, приведённые ниже, можно использовать полностью или частично как приёмы, упрощающие построение системы.
Уровень 1. От команды к нескольким командам (10–30 человек)
Что меняется: Вы уже не можете знать все детали. Нужны промежуточные звенья.
Что делать:
1. Разделить на устойчивые группы. По продуктам, функциям или проектам. Главное — у каждой группы есть понятная цель и понятная зона ответственности.
2. Назначить лидеров групп. Не лучших «технарей», а тех, кто умеет выстраивать коммуникацию, ставить задачи и снимать блокеры.
3. Ввести единый ритм синхронизации. Например, ежедневный дейли в группе, еженедельная синхронизация лидеров (30 минут), ежемесячная общая встреча (1 час). Не чаще, иначе вы утоните во встречах.
4. Зафиксировать «правила игры» на один лист А4. Не 50 страниц регламентов. Только самое важное: как ставим задачи, как фиксируем договорённости, как эскалируем проблемы.
Главная опасность: начать контролировать всё, вместо того чтобы делегировать. Ваша задача на этом уровне — научить лидеров управлять, а не подменять их.
Уровень 2. От нескольких команд к направлению (30–100 человек)
Что меняется: Появляются руководители руководителей. Вы управляете уже не людьми, а связками «лидер + его зона».
Что делать:
1. Определить ключевые метрики для каждой группы. Не «как дела», а цифры: скорость, качество, загрузка. Только так вы сможете управлять, не вникая в детали.
2. Ввести регулярную проверку «пульса». Например, короткий опрос по стрессу и удовлетворённости. Это помогает видеть риски до того, как они превратятся в выгорание или увольнение.
В идеале: здоровье системы — такой же KPI, как и скорость разработки. Текучка, выгорание, удовлетворённость замеряются регулярно.
3. Создать внутренний рынок экспертизы. Если в одной команде появилось сильное решение, сделайте так, чтобы другие команды могли его использовать (воркшоп, документация, чат поддержки). Это снижает «изобретение велосипедов».
4. Делегировать полномочия по найму и бюджету. Руководители групп должны сами понимать, кто им нужен и сколько это стоит. Ваша задача — утверждать стратегию, а не каждую заявку.
Главная опасность: скатиться в микроменеджмент через метрики (гонка за цифрами вместо результата). Ваша задача — смотреть на тренды, а не на каждый шаг.
Уровень 3. От направления к департаменту (100+ человек)
Что меняется: Вы управляете системой систем. Ваш главный инструмент — культура и стратегия.
Что делать:
1. Сформулировать принципы управления, а не правила. Не «сдавать отчёт по пятницам», а «мы ценим прозрачность, поэтому важные данные доступны всем». Принципы работают там, где правил слишком много.
2. Инвестировать в горизонтальные связи. Когда людей много, они перестают знать друг друга. Организуйте кросс‑командные воркшопы, обмен опытом, совместные ретроспективы.
3. Автоматизировать рутину. Отчёты, дашборды, согласования. Всё, что можно автоматизировать, — автоматизируйте.
В эту сторону сейчас хорошо работают AI‑инструменты для синхронизации (например, дашборды, которые сами собирают статусы).
4. Измерять здоровье системы. Текучка, скорость онбординга, индекс лояльности, «барометр» стресса. Без цифр вы будете управлять догадками.
Главная опасность: создать «фабрику по производству отчётов». Ваша задача — убирать барьеры, а не добавлять их.
Чек‑лист: готовы ли вы к масштабированию?
• У нас есть не больше 5–7 человек в одной группе (правило «двух пицц»).
• Каждая группа имеет понятную цель и зону ответственности.
• Лидеры групп умеют ставить задачи и снимать блокеры (я их этому научил).
• Есть единый ритм синхронизации, но не больше 2–3 часов в неделю на уровне руководителей.
• Правила игры умещаются на один лист А4.
• Я управляю по метрикам и трендам, а не по каждому отчёту.
• Я трачу не больше 20% времени на «тушение пожаров» (остальное — на развитие системы).
Если «нет» на 3 и более — вы ещё не масштабировались, а просто выросли в размере. Это не одно и то же.
Вместо заключения
Не стоит воспринимать масштабирование как «сделаем также, но больше». Нужно сделать по‑другому.
Вы не сможете контролировать всё так же, как раньше. Но вы можете построить систему, которая будет работать и в которой люди не будут задыхаться от бюрократии.
Как минимум, надо захотеть растить бизнес, не теряя людей и не выгорая самому.
ссылка на оригинал статьи https://habr.com/ru/articles/1040546/