Как не задушить команду контролем

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

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

Это ловушка. Чем лучше руководитель справляется с такими вопросами, тем сильнее команда привыкает к его участию. По данным исследования South HUB, 41% ИТ-руководителей в кризисных ситуациях полностью погружались в решение проблем вместе с командой. Делегировать задачи, сохраняя управленческую дистанцию, старались 36%. На коротком отрезке погружение руководителя помогает. Вопрос в том, что происходит потом. Если это остается самым быстрым способом решить любую проблему, команда перестает наращивать собственную управленческую емкость.

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

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

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

Поэтому сначала стоит посмотреть, какие решения человек вообще имеет право принимать самостоятельно.

Для руководителей отделов и подразделений я предлагаю разделять решения на четыре уровня.

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

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

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

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

Эта схема нужна не ради пустой классификации. Она отвечает на практический вопрос: когда руководителю действительно нужно подключаться? Если ответа нет, руководитель вынужден каждый раз определять это заново. Команда тоже.

Есть распространенная ошибка: руководитель передает сотруднику задачу, но оставляет у себя все решения внутри этой задачи. Формально ответственность делегирована, фактически человек продолжает работать с разрешения руководителя.

При передаче задачи важно заранее договориться о нескольких вещах. Что должно получиться и как выглядит приемлемый результат. Какие есть ограничения по срокам, бюджету, качеству и зависимостям от других команд. Что сотрудник может решить самостоятельно, а что обязательно нужно приносить руководителю. И наконец, конкретная точка контроля — без классического «пиши мне по любому вопросу».

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

Но делегировать задачу — не значит перестать контролировать вообще. Бесконтрольно делегировать нельзя. Другой вопрос, что контроль не должен превращаться в проверку каждого шага и каждого решения.

Главная сложность как раз в этой дельте: где заканчивается тотальный контроль над каждой мелочью и начинается полное доверие? Многие растущие руководители не могут найти эту грань.

Кто-то говорит: “Я вырос, теперь делегирую”. И действительно перестает вмешиваться. А через полгода выясняется, что команда бежала не туда, потратила в четыре раза больше денег и пришла не к тому результату. Поэтому следующий уровень контроля при делегировании — это цели и метрики. Желательно оцифрованные, сформулированные по SMART.

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

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

В исследовании South HUB руководители сами называют перестройку процессов и повышение прозрачности одной из наиболее эффективных мер снижения нагрузки: такой ответ дали 55% участников. Еще 39% говорили о перераспределении задач и найме, 38% — об отказе от части проектов и более жесткой приоритизации. Когда руководитель перегружен, стоит посмотреть на то, почему столько решений вообще доходит так высоко.

Для ИТ-команд это особенно заметно на уровне тимлидов. Когда сильного специалиста назначают руководителем, ему часто не дают четкого понимания, какие решения теперь находятся в его зоне ответственности. Получается странная конструкция: человек отвечает за результат, но существенную часть решений продолжает согласовывать со своим руководителем. Так тимлид превращается просто в дополнительное звено согласования.

Для меня развитие тимлидов — один из главных показателей зрелости управления. В 2025 году hh.ru проводил исследование требований к руководителям в ИТ. 83% работодателей назвали лидерство и способность вдохновлять команду, 78% — стратегическое мышление, 65% — умение работать в условиях неопределенности. Все эти навыки требуют практики. Человек не научится принимать управленческие решения, если руководитель будет делать это за него.

Эти симптомы обычно заметны, если присмотреться.

• Сотрудники приходят с вопросом, но не предлагают вариантов. “Что будем делать?” — нормальный вопрос для человека, который столкнулся с новой ситуацией. Но если так выглядит большинство рабочих обсуждений, стоит посмотреть, как устроено принятие решений в команде. Я бы попросил сотрудника сначала сформулировать свою позицию: какие есть варианты, что он предлагает и почему. Даже если итоговое решение будет другим, человек получит практику анализа.
• Без руководителя решения останавливаются. Если во время отпуска начальника несколько процессов фактически замирают, проблема уже системная. Руководитель должен иметь возможность ненадолго выйти из операционной работы без остановки команды.
• Тимлиды приносят наверх операционные вопросы. Это особенно показательный сигнал. Руководитель первого уровня должен постепенно забирать часть решений на себя. Если этого не происходит, нужно выяснять причину: человеку не хватает компетенций, полномочий или он понимает, что за самостоятельное решение его могут наказать.
• Календарь заполнен согласованиями. Можно провести простой эксперимент: посмотреть встречи и переписку за последние две недели и отметить, сколько времени ушло на вопросы, которые теоретически мог решить кто-то другой. Подсчет обычно быстро показывает масштаб проблемы.
• Сотрудники заранее стараются угадать, что хочет руководитель. Это самый неприятный симптом. Команда начинает оптимизировать решения под личные предпочтения начальника. В результате люди меньше думают о результате задачи и больше о том, как избежать повторной правки.

Для меня здесь есть еще один важный эффект. Руководитель, который постоянно принимает решения за свою команду, постепенно лишает ее возможности расти. Специалисту сложно стать руководителем, если он годами выполняет только задачи по чужому алгоритму.

В результате компания может получить парадоксальную ситуацию: сильных специалистов достаточно, а людей, готовых взять на себя управление, мало. По данным hh.ru, 59% ИТ-компаний считают наём одной из главных кадровых проблем, 61% — удержание сотрудников, 41% — переобучение текущего штата. Развитие самостоятельности здесь становится частью работы с кадровым резервом.

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

Я не считаю, что большая команда должна работать без контроля. Руководитель отвечает за результат и риски, поэтому контроль остается частью его работы. Меняется уровень. Вместо десятков мелких проверок появляются понятные метрики, которые объективно измеряют происходящее, заранее определенные правила и понимание того, где именно сейчас находится риск.

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

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