[5/10] Как построить команду, которой вы не нужны

Примерно 2500 лет назад китайский мудрец Лао-цзы написал:

Плохого начальника люди ругают

Хорошего начальника люди почитают

А о выдающемся начальнике люди говорят: «Мы справились сами»

За две с половиной тысячи лет эта мысль успела стать почти управленческим клише, ведь про самостоятельные команды, делегирование и руководителей, без которых всё должно само собой работать, написаны сотни статей. И несмотря на то, что вопрос явно не новый (раз уж цитате 2500 лет), я всё-таки решил написать ещё одну статью на эту тему, но немного с другим фокусом: как заметить, где организация всё ещё зависит лично от руководителя, и постепенно эту зависимость убрать. При этом сделать это не громадной реорганизацией, а, скорее, через вполне приземлённые вещи, которые можно «начать с понедельника»

Я сам во многом повторил типовой путь и шаблонные ошибки.

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

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

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

Тем не менее, во время кризиса идея стать незаменимым может выглядеть вполне привлекательно: ведь такого сотрудника точно не уволят!

Но представим довольно типичную ситуацию. В компании было два отдела с двумя руководителями. Решили сократить численность на 30%, отделы объединить, а одного руководителя уволить. Незаменимого оставили — ведь без него работа остановится.

Только теперь у него два направления, новая команда со своими проблемами, а старые обязанности никто не отменял. И если он с прежним объёмом работы справлялся с трудом, то как теперь управлять объединённым подразделением? Когда заниматься перестройкой процессов, перераспределением ответственности, новыми приоритетами? И главное, как самому не оказаться следующим кандидатом на увольнение, если с новой задачей он не справится?

Возвращаясь к собственной истории, урок я тогда всё-таки вынес и решил: если уж одна и та же ручная работа повторяется постоянно (решение проблем), то, возможно, её нужно автоматизировать — то есть сделать так, чтобы она решалась без моего участия. И тогда я стал искать, собственно, такие задачи — а что же именно мне нужно автоматизировать в работе моей команды?

Почтовый ящик как DLQ, или телеметрия организации.

Первым источником данных оказался собственный inbox. В какой-то момент я получал от 150 до 250 писем в день — и это без роботов и уведомлений из Confluence, которые тоже полагалось читать, а иногда ещё и одобрять.

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

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

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

Через некоторое время эта таблица превратилась в backlog изменений. Для найма появились более явные критерии. Повторяющиеся технические споры привели к архитектурному совету. Где-то сама частота эскалаций показала, что проблема лежит глубже переписки — в том, как устроено взаимодействие между подразделениями.

Входящий поток постепенно снизился до 70–80 писем в день, плюс тогда же вышла статья (McKinsey, 2012) о том, что менеджеры тратят 28% своего рабочего времени на почту, а у меня где-то так и получалось, поэтому острота вопроса спала.

Но идея использовать мой Inbox как аналог Dead Letter Queue (то есть заранее исходить из того, что любое письмо в моём Inbox — это, возможно, сигнал о проблемах в организации) мне понравилась, и я стал применять её регулярно и в других компаниях и проектах.

Сейчас я, скорее всего, начал бы с AI. Если политика компании позволяет и есть техническая возможность подключить модель к почте или мессенджерам (например, через MCP), то буквально за несколько запросов можно собрать повторяющиеся типы обращений и посмотреть, что постоянно доходит до руководителя.

Практический вывод № 1: Входящие письма к руководителю вполне можно использовать как диагностический элемент/телеметрию работы всей организации: если нужна аналогия для разработчиков — смотрите это как на количество 500-х ошибок на дашборде.

Экстремальное делегирование.

У Кента Бека в Extreme Programming была интересная идея: взять полезную инженерную практику и посмотреть, что получится, если использовать её намного интенсивнее, чем принято — на экстремальном уровне. Code review полезен — можно превратить его в постоянную совместную работу двух разработчиков, чтобы он происходил ещё в момент написания кода. Тестирование полезно — можно начинать разработку с теста, чтобы программа тестировала сама себя.

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

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

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

О том, как это сделать, тоже написаны десятки книг (я бы рекомендовал «Разверните ваш корабль» от Дэвида Марке — во многом я вдохновлялся ею).

Но практический вывод № 2, который я хотел бы донести в этой главе: делегирование — это не просто best practice, которая позволяет разгрузить руководителя. Это и есть практический способ выстраивания системы, в которой она работает самостоятельно, и поэтому работа руководителя заключается именно в создании такой системы.

1:1 как термометр команды, или самостоятельность требует поддержки.

С экстремальным делегированием легко переборщить и прийти к формуле «я всё отдал, теперь разбирайтесь сами», но это скорее уже не делегирование, а уход от ответственности.

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

Лучшее место для такого разговора — 1:1. Статус задач можно получить из трекера или на общей встрече. А при личном разговоре один на один гораздо проще услышать то, что в общий чат обычно не пишут: «я не понимаю, что делать», «кажется, я не вытягиваю», «боюсь ошибиться», «у меня конфликт», «мне нужна помощь».

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

Практический вывод № 3: я смотрю на 1:1 как на две вещи одновременно. Это термометр, который показывает, что реально происходит «на полях», и одновременно место, где сотрудник может попросить поддержки, не возвращая работу руководителю. Поэтому я совсем не удивлюсь, если у руководителя большой организации такие встречи займут до половины календаря. У меня было чуть меньше 🙂

Процессы: повторяющееся решение должно перестать быть решением, а должно отложиться в памяти организации

У многих разработчиков есть сотни скриптов, которые автоматизируют их работу.

Как уже выяснили в главе про Inbox, такие повторяющиеся задачи в организации тоже нужно автоматизировать. Возникает вопрос: а как именно это нужно сделать?

В моём понимании это и есть бизнес-процессы. Не как схемы из прямоугольников и стрелочек и другие атрибуты из BPMN-диаграммы, а скорее как организационные скрипты, которые любую повторяющуюся работу выполняют с предсказуемым результатом:

• Разобрались, по каким критериям нанимаем людей, — фиксируем критерии.
• Несколько раз столкнулись со спорным архитектурным выбором — договариваемся, где такие решения принимаются.
• Каждый релиз спотыкается об одинаковые проверки — превращаем накопленный опыт в checklist или автоматизацию.

Про бизнес-процессы тоже написаны десятки книг (и если уж с чего-то начинать, я бы рекомендовал книжки Эдвардса Деминга «Выход из кризиса» и Элияху Голдратта «Цель» как основу), но вывод, который я сделал для себя: описание бизнес-процессов моего отдела — это и есть одна из моих ключевых задач. И делаю я это не только для аудиторов по ISO 9000, если вдруг спросят, а в первую очередь для своей команды: чтобы каждый мог понять, как мы принимаем решения в той или иной ситуации.

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

Поэтому практический вывод № 4: задайте себе вопрос, какое наследие и какая организационная память останутся в этой команде после вашего ухода? Будут ли помнить, как решать сложные вопросы? Или все останется только в духе «если что, то спросим у начальника»?

Bus factor: ищем остальные точки отказа

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

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

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

В ИТ для этого есть термин «bus factor»: сколько людей должно выпасть из команды, чтобы работа серьёзно пострадала. Худший bus factor равен единице.

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

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

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

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

Практический вывод № 5: если убрали зависимость от руководителя, это хорошо. Но нужно проверить, чтобы в команде не осталось и других критических зависимостей, где bus factor = 1.

Что можно сделать за 30 дней

Для начала достаточно одной таблицы и одного месяца.

Завтра я бы взял 20–30 последних обращений к себе и выбрал три-пять повторяющихся. Для каждого — два вопроса: почему это дошло до меня и что нужно изменить, чтобы следующий такой случай прошёл без моего участия?

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

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

Чтобы было удобнее провести такую проверку, я подготовил шаблон

Когда руководитель становится лишним

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

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

Сначала вопрос меня задел: типа как так-то, команда, что ли, сама себя построила? Потом я подумал, что если вынести за скобки несколько лет, за которые эта система строилась, в нём есть доля правды: действительно, в результате собственных действий я построил систему, где не был необходимым звеном.

Тут приходит в голову аналогия со строительством. Одни компании строят здания, другие потом их эксплуатируют. И то и другое требует профессионализма, но это разная работа. С руководителями ситуация похожа: кто-то особенно силён в эксплуатации работающей системы, а кому-то интереснее прийти туда, где всё держится на героях, построить систему и идти строить следующую.

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

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

А теперь небольшой мысленный эксперимент. Представьте, что завтра у вас случится долгожданный отпуск, да не просто отпуск, а фантастически захватывающее приключение на месяц (например, экспедиция в Сахару или, наоборот, в Арктику или Антарктику) и у вас на месяц не будет связи. Что остановится? Какие знания исчезнут вместе с вами? Какие вопросы никто не сможет решить?

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

И тут повод вспомнить ещё раз Лао-цзы, который сказал короче: когда работа сделана хорошо, люди говорят — «мы сделали это сами».

Александр Апазиди

Тренер Стратоплана, автор телеграм-канала Апазиди АйТи: про IT, разработку и менеджмент, ИТ-директор с 30-летним опытом, ex-CIO СИБУР, Volvo, Metro.