Перезагрузка команды — увольнение 90% персонала и сбор команды 3.0

Что произошло

В июле 2024 года я уволил около 90% команды и за несколько месяцев собрал новый состав — команду 3.0. Это было одно из самых тяжёлых управленческих решений года и, как показало время, одно из самых правильных.

Почему пришлось это делать

Причина была не в людях, а в моих управленческих ошибках. Я сам выстроил конфигурацию, которая не могла работать долго.

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

Дальше пошли классические симптомы:

• Проблемы с субординацией. Просьбы начали восприниматься как пожелания
• Сроки и договорённости размывались
• Замечания по работе принимались на личный счёт, а не как часть процесса
• Важные решения приходилось постоянно «продавать» команде, а не просто озвучивать

Оказалось, что часть людей воспринимает такую атмосферу не как желание руководителя дать комфорт и рост, а как слабость — и использует это соответствующим образом.

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

Почему я не стал «чинить» на ходу

Я не пытался разговаривать, переубеждать или перераспределять роли. В какой-то момент я просто честно сказал себе: свернул не туда. Значит, надо вернуться и начать сначала.

Это было трудное решение, но другого варианта я не видел. И главное — у меня был фундамент, на который можно было опереться:

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

В такой конфигурации перезагрузка быстрее и честнее, чем бесконечные попытки «договориться». И она сработала.

Команда 3.0 — что изменил в подходе

Третий состав я собирал уже с полным пониманием прошлых ошибок. Главные изменения:

• Отбор по софт-скиллам на входе — обучаемость, ответственность, зрелость в коммуникации
• Чёткая субординация с первого дня, без переводов «в друзья»
• Актуальные регламенты, накопленные за почти два года работы компании
• Рабочая внутренняя система, которая к тому моменту уже была отлажена и снимала львиную долю организационной нагрузки

В результате замена команды прошла буквально за несколько месяцев — без слома бизнеса и без операционных провалов.

Клиенты не заметили

Самое неочевидное и, на мой взгляд, показательное: клиенты ничего не поняли.

• Задачи продолжали приниматься и закрываться в срок
• Никаких «у нас сейчас ротация, подождите, пожалуйста»
• Коммуникация не провисала

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

Что получили после перезагрузки

Новая команда оказалась на две головы выше прошлой по всем параметрам:

• Качество выполнения задач выросло кратно
• Компетенции в командах сильнее — пришли более ответственные и осознанные люди
• Коммуникация с клиентами стала предсказуемой и деловой
• Внутри команды — рабочая культура без демонстративного панибратства

Что я забрал из этой истории

Это был болезненный, но очень точный урок:

• Атмосфера поддержки не равна отсутствию субординации
• Границы в команде должен держать руководитель — их никто не будет держать за него
• Системные управленческие ошибки нельзя чинить косметикой, иногда проще и честнее перезагрузиться
• Хорошо описанные процессы позволяют сменить 90% состава без потери клиентов — и это сам по себе сильный актив компании

Именно этот опыт во многом определил стратегию на конец 2024-го и весь 2025-й — сначала фильтрацию клиентов после истории с токсиком, а потом разворот в сторону полноценной IT-разработки.