Я долго думал, что хороший руководитель — это человек, который всё держит под контролем.

Кто что делает. Почему задача не закрыта. Когда будет готово. Кто виноват. Кого надо ускорить. Кому надо «поставить приоритет».

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

Но в IT это часто работает наоборот.

Контроль создаёт иллюзию управления

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

И в этот момент жёсткое управление сверху начинает не помогать, а тормозить.

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

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

Главная ошибка — считать людей исполнителями

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

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

Если относиться к нему как к исполнителю команд, он постепенно и начинает вести себя как исполнитель команд.

Не предлагает. Не спорит. Не берёт лишнего. Не думает за продукт. Просто делает тикеты.

А потом руководитель удивляется: «Почему у команды нет инициативы?»

Потому что инициативу долго и методично заменяли контролем.

Agile не спасает, если мышление осталось старым

Можно ввести спринты, daily, ретро, доски, груминг и демо. Но если все решения по-прежнему принимаются сверху, это не Agile.

Это старое управление в новой упаковке.

Команда стоит у доски, красиво двигает задачи, но не управляет ни процессом, ни качеством, ни решениями. Она просто отчитывается чаще, чем раньше. И это, на мой взгляд, одна из самых частых причин, почему «Agile у нас не взлетел».

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

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

Для меня это значит:

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

Хорошая команда не нуждается в постоянном надзоре. Но ей нужны ясные правила, доверие, сильный контекст и пространство для решений.

Контроль стоит заменить прозрачностью

Я не считаю, что руководитель должен «просто отпустить команду». Это другая крайность.

Но между тотальным контролем и хаосом есть нормальный вариант — прозрачность.

Когда видно, какие задачи в работе. Когда понятно, где блокеры. Когда команда сама показывает прогресс. Когда проблемы обсуждаются до того, как всё загорелось. Когда люди не боятся сказать: «Мы ошиблись» или «Так не успеем».

Прозрачность делает контроль менее нужным. А доверие делает команду взрослее.

Вывод

Старый стиль управления задаёт вопрос:

Как заставить людей выполнить план?

Современное управление должно спрашивать иначе:

Как сделать так, чтобы команда могла принимать хорошие решения и отвечать за результат?

Для меня это главное отличие. В IT выигрывает не тот руководитель, который сильнее всех контролирует. А тот, кто строит систему, где людям не нужно ждать команды сверху, чтобы двигаться вперёд.