Микроменеджмент глазами бывшего программиста

Что такое микроменеджмент простыми словами

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

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

Откуда берётся тяга контролировать

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

История с пивом за три часа

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

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

Проекция вместо контроля

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

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

Программы и люди

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

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

Контейнирование эмоций вместо микроменеджмента

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

Делегирование задач через цель, а не через алгоритм

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

Как это выглядит на практике

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

Расписать всё самому быстрее, экономия часа-двух. Только потом этот план придётся тащить на себе и контролировать каждый пункт.

Закрыть глаза, но знать результат

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

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

Встречи один на один вместо ежедневных проверок

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

С менеджерами такие разговоры идут легко. С разработчиками сложнее: на вопрос «как дела» звучит «нормально», и тему приходится вытягивать. Но даже такая встреча раз в неделю даёт больше, чем ежедневные вопросы «ну что, сделал?». Для меня это ещё и способ проверить себя. Если за неделю мне захотелось влезть в задачу сотрудника три раза, значит, мы плохо договорились о результате, и на встрече нужно обсуждать именно это, а не сами правки. Чаще всего проблема оказывается в формулировке цели, а не в человеке.

Об этом опыте я рассказывал на CrossConf 2022 в докладе о том, как за семь лет прошёл путь от разработчика до CEO. Отучиться от тотального контроля оказалось одним из самых сложных шагов на этом пути.