Какую картину мы наблюдаем прямо сейчас: Meta уволила 11 000 человек, Google — 12 000. Amazon объявил о ликвидации целых управленческих прослоек. На первый взгляд — антикризисные меры. На деле — симптом куда более глубокого процесса, который меняет саму логику построения IT-команд.
Компании убирают не разработчиков. Они убирают уровни принятия решений. И это принципиальная разница.
Глобальный тренд: дело не в кризисе
Последние десять лет технологические компании росли в условиях дешёвого капитала. Это позволяло выстраивать сложные организационные конструкции — с менеджерами, которые управляют другими менеджерами, с координационными ролями, которые не создают прямой ценности для продукта.
Когда многие процессы удалось упростить и автоматизировать, оказалось, что значительная часть управленческого штата не производит результата. Сокращения
Данные подтверждают: в крупных tech-компаниях на одного разработчика приходилось до 0,7 менеджера. Это не норма и не патология — это следствие масштаба, который рос быстрее, чем компании успевали выстраивать процессы. Когда менеджер координирует другого менеджера, а не помогает команде создавать продукт, структура начинает работать против себя.
Главный риск автоматизации — внедрять изменения ради самих изменений, на «хайпе» ИИ или иной технологии, без понимания бизнес-цели и себестоимости. Это усложняет процессы и увеличивает затраты без реальной отдачи. Фактическую ценность можно отследить только в конкретных метриках: скорость работы, стоимость, удержание клиента, снижение рисков. Всё остальное — временный фарс рынка.
Плоские структуры: где работает, где разрушает
Valve, Basecamp, Spotify с их squad-моделью — это не миф для конференций. Это рабочая история, у которой есть четкие условия применимости.
Плоская структура работает там, где компания небольшая, продукт понятный, команда автономная. Как только появляются высокая регуляторная нагрузка, десятки команд или сложная инфраструктура — полностью отказаться от управления невозможно. Большинство успешных компаний находятся посередине: они убирают лишние уровни, а не менеджмент как класс как таковой.
Российский рынок: другая задача
На Западе компании избавляются от последствий гиперроста. В России во многих случаях проблема обратная — нехватка сильных менеджеров и перегруженные технические лидеры, которые вынуждены совмещать разработку с операционным управлением.
После 2022 года часть команд релоцировалась, часть перешла в распределённый формат. Удалённая работа сначала увеличила потребность в менеджерах — выросли издержки на коммуникацию. Затем компании начали выстраивать процессы и автоматизировать взаимодействие. Сейчас рынок движется в другую сторону: растёт спрос не на количество менеджеров, а на качество управления.
Самая частая ошибка российского рынка
Компании пытаются решить проблему неэффективности наймом новых людей, хотя проблема находится в процессах и зонах ответственности. В результате появляются перегруженные команды и размытые роли — при том, что управленческих должностей становится больше.
Санкционные ограничения добавили новые роли: DevOps, информационная безопасность, эксплуатация, международные расчёты. Часть административных функций была автоматизирована или объединена. Цепочка принятия решений стала короче — не по идеологическим соображениям, а по необходимости.
Сколько людей нужно: рабочая формула
Универсальной формулы нет — но есть рабочие ориентиры, которые позволяют избежать двух крайностей: управленческого раздутия и хаоса без координации.
| Размер команды | Соотношение | Признак | Главный риск |
|---|---|---|---|
| до 5 чел. | Отдельный менеджер не нужен | Тимлид совмещает роли | Сильный технический лидер |
| |
1 тимлид на команду | Начало разделения ролей | Рост коммуникационных издержек |
| ~30 чел. | Разделение тех. лидерства и опер. управления | Первые менеджерские прослойки | Риск размытия ответственности |
| 80+ чел. | Промежуточные уровни управления оправданы | Законы орг. сложности | Критична прозрачность процессов |
Есть ситуации, где менеджер на каждые 3 разработчика оправдан: финтех, госзаказ, крупные корпоративные внедрения. Там стоимость ошибки значительно выше стоимости дополнительного управления. И есть ситуации, где один тимлид на 15 человек работает лучше: зрелые продуктовые команды с сильными инженерами и понятными процессами. Если сотрудники автономны и понимают цели бизнеса, избыточный менеджмент начинает только замедлять работу.
Как считать экономику менеджерского слоя
Правильный вопрос — не «сколько стоит менеджер», а «как этот менеджер влияет на скорость принятия решений и стоимость ошибок».
Если управленец сокращает время вывода продукта на рынок или предотвращает дорогостоящие сбои — он окупается многократно. Если его функции можно заменить процессом или инструментом — возникает вопрос о необходимости роли.
Пример из практики
Автоматизация части координационных функций через Jira, Linear и CI/CD-пайплайны убрала значительную долю статусных встреч и ручного контроля задач. Там, где раньше нужен был отдельный менеджер для сбора информации между командами, теперь достаточно настроенного процесса. Это не означает, что менеджер исчез — его роль сместилась в сторону принятия решений и устранения организационных препятствий.
Где сокращения работают, а где разрушают
Ошибка большинства собственников — видеть в менеджерском слое только расходы. Это верно ровно до тех пор, пока менеджер не отвечает ни за что критическое.
| Сектор | Менеджмент | Почему |
|---|---|---|
| Финтех | Критически важен | Регулятор + цена ошибки = штраф или потеря лицензии |
| Медтех | Критически важен | Ошибка может стоить жизни или судебного иска |
| Госзаказ | Критически важен | Прозрачность процессов — требование контракта |
| Стартап до 15 чел. | Чаще балласт | Скорость важнее координации |
| E-commerce / SaaS | Контекстуально | Зависит от масштаба и числа интеграций |
Когда собственник говорит «давайте уберём лишних менеджеров и сэкономим» — это умное решение, если менеджер не влияет на результат и выполняет исключительно координационную функцию. Если же он отвечает за снижение рисков, взаимодействие между командами и выполнение обязательств перед клиентами, его сокращение обойдется компании значительно дороже его зарплаты.
Слепые зоны собственника
Большая часть работы разработчиков невидима. Пользователь видит функцию, но не видит архитектурных решений, устранения технического долга и обеспечения стабильности. Из-за этого возникает иллюзия, что команда делает меньше, чем на самом деле.
Собственник чаще всего недооценивает сложность интеграций и тестирования. Большинство задержек возникает не при написании кода, а при взаимодействии разных систем и устранении побочных эффектов изменений. Это невидимая работа — и она составляет значительную часть инженерного времени.
Почему «поставить разработчика на место менеджера» не работает
Разработка и управление — разные компетенции. Хороший инженер не обязательно станет хорошим руководителем. В таком сценарии компания рискует потерять сильного разработчика и не получить сильного менеджера — оба результата хуже исходного.
Перед любым решением о реструктуризации стоит задать один вопрос: какую проблему я пытаюсь решить? Если цель — просто сократить расходы, эффект будет краткосрочным. Если цель — ускорить принятие решений и повысить эффективность, тогда изменения имеют смысл.
Что отделяет менеджера, которого уволят, от того, кого не тронут
Это вопрос не только для собственников, но и для самих менеджеров. Оптимизация продолжится — и тех, кто не может объяснить свою ценность через цифры, она коснется в первую очередь.
Менеджер, которого уволят первым, выполняет координационные функции, которые уже закрывают инструменты. Он собирает статусы, передает информацию между командами, контролирует задачи вручную. То, что раньше требовало человека, сегодня автоматизировано.
Менеджер, которого не тронут, умеет связывать технические решения с бизнес-результатом. Его вклад виден в цифрах: скорость разработки, качество продукта, снижение рисков, выручка. Такие люди редко оказываются первыми кандидатами на сокращение — потому что их сокращение сразу видно в финансовых показателях.
Навыки, которые защищают позицию:
-
Умение читать экономику продукта и переводить технические решения в бизнес-метрики
-
Работа с рисками: не просто фиксировать проблемы, а предотвращать дорогостоящие сбои
-
Понимание технических ограничений — разговор с инженерами на одном языке
-
Измеримый вклад: сроки, выручка, качество, снижение затрат
Если вас только что сократили
Сначала — честный анализ: какую измеримую ценность вы создавали для бизнеса? Если ответ неочевиден, это и есть причина сокращения — и точка роста.
Рынок сегодня особенно востребует людей, которые работают на стыке технологий, процессов и экономики продукта. Это не узкая специализация — это новый стандарт для IT-менеджера.
Главное заблуждение, которое стоит убрать
И у собственников, и у специалистов — одно общее заблуждение: что эффективность команды определяется количеством людей.
На практике решающее значение имеют качество коммуникации, скорость принятия решений и ясность ответственности. Именно эти факторы чаще всего определяют успех или провал технологических проектов — независимо от того, сколько человек в команде.
Итог: три вопроса перед любым решением о структуре команды
- Какую проблему я решаю — и измеримо ли она влияет на деньги?
- Чья ценность видна в цифрах, а чья — только в процессе?
- Что произойдет с результатом, если этой роли не станет завтра?
Там, где есть человек, который отвечает за результат, есть понятные метрики и готовность дорабатывать решение — управление начинает влиять на цифры в бизнесе. Всё остальное — организационный шум.
Источник: Владимир Кондаков, эксперт по IT-архитектуре и кибербезопасности
