Все мы слышали о делегировании, плоских структурах и прочем прямом взаимодействии, где каждый — автономная боевая единица, все молодцы, все ответственно работают и вообще, коллектив больше похож на отряд идеологических строителей коммунизма, чем на команду разработки. В основе всех этих разговоров об автономности и «плоскости» лежит тезис, который в кратком виде можно сформулировать как «дай людям работать, не замыкай процессы на себе». То есть максимально делегируй, а что не можешь делегировать — спихивай на подчиненных с удвоенной силой! Никакого офисного рабства, только максимум самосознания! Мир! Труд! Май!
Этот миф вдвойне опасен тем, что мы не все понимаем его проблему. Считается, что делегирование проваливается в случае, если исполнитель — помидорка, которая не хочет или не может пользоваться данными ей Богом менеджером властью. Вот только чаще всего проблема провала делегирования как практики заключается в том, что менеджеры или руководители разработки просто не умеют или не хотят по-настоящему делегировать свои полномочия, а только делают вид, что позволяют подчиненным действовать самостоятельно.
Наблюдая за работой десятков разных IT-компаний из разных сегментов я с уверенностью заявляю: так называемое «делегирование полномочий» в 90% случаев — фикция и способ самоутверждения менеджера. Потому что делегирование, это двунаправленный процесс, в котором должен быть не только сильный исполнитель (что очевидно), но и умный, со стальными нервами руководитель. И сейчас объясню, почему.
Идеальное делегирование в вакууме
По какой-то причине наши менеджеры привыкли думать, что делегирование — это скинуть работу на другого, которую ты должен делать сам. Греет душу прохладная, как Чудское Озеро в апреле 1242 года, история о директорах заводов/предприятий/компаний/колхозов и прочих учреждений, которые могут уехать на полгода, а без них все отлично работает. Мол, процессы отлажены.
Что такая история рисует в воображении условного менеджера? Она рисует ему то, что у директора, по сути, нет никаких задач: все делают его подчиненные, все работает само. Ему нужно подключаться только в тех случаях, когда ему самому этого захочется. Ну не жизнь же, а сказка, да? Ходи себе, попинывай своих рабов сотрудников, время от времени устраивая выборочный контроль их деятельности. Хороших — хвали, плохих — карай.
Вот только вопрос в том, что идеальное делегирование — это сложный механизм взаимодействия сотрудника и его непосредственного руководителя, причем механизм опасный.
В основе концепции здорового жизнеспособного делегирования лежит простой и понятный тезис: любая ошибка в ходе работы над делегированным участком проекта одновременно становится ошибкой как исполнителя, так и человека, который делегировал на него этот объем работы.
Исполнитель должен иметь всю полноту власти при принятии решений, а руководитель — быть готовым в любой момент включиться в процесс, когда это необходимо.
Иначе это что угодно, но не делегирование.
То есть не бывает так, что работник накосячил — и отвечает только руководитель, или наоборот, когда в случае косяка отвечает только работник, а руководитель выходит сухим из воды, да еще и становится личным палачом для провинившегося. При этом не бывает делегирования, когда все окончательные результаты надо согласовывать с вышестоящим руководителем на обозначенных стадиях, как не бывает и полностью автономного делегирования, когда все работает само.
Модель, где крайним становится менеджер — приводит к безответственности со стороны сотрудников и утрате доверия внутри коллектива.
Модель, когда работник ничего не решает, а руководитель «не видит и не слышит» — к пассивности и параличу воли, а спущенные задачи — в мрачный кошмар.
Обе эти модели и есть те самые «протомифы» о работе делегирования.
Работают они буквально до первого серьезного «залета» одной из сторон, после чего в компании начинается такое закручивание гаек, что работать дальше становится практически невозможно.
Давайте разберем детально оба случая.
Делегирование полномочий без ответственности исполнителя
Если менеджер хочет поиграть в «доброго начальника», он расширяет границы возможностей своих подчиненных до максимума, при этом называя это «делегированием полномочий», хотя по факту он просто забивает на происходящее на его участке ответственности. В итоге DevOps и разрабы могут сами подавать данные в бухгалтерию о закупках мощностей на AWS в обход начальника, админы — сметы на закупку оборудования. Такая себе добрая анархия, где все друг другу братья. Сотрудники делают все быстро и смело, не оглядываясь по сторонам, потому что им был дан карт-бланш, со словами «я тебя прикрою».
Вот это «я прикрою» в любых вариантах — буквально игра в русскую рулетку.
Менеджеру невероятно повезет, если он скажет эти слова правильным людям, которые осознают степень ответственности и будут действовать аккуратно. Однако, как показывает опыт, ответственность люди нести не любят и первый же серьезный залет становится проблемой для менеджера; он принимает удар вышестоящего начальства на себя, вместо того, чтобы разделить его с виновниками происходящего.
«Виновато всегда начальство» — достаточно удобный тезис, который, однако, работает лишь в половине случаев. Если админы подали две одинаковые заявки на покупку оборудования, которую бухи оплатили — это ошибка, в первую очередь, администраторов. То есть тут ситуация, как с дураком и заряженным ружьем. Если дурак с ружьем в итоге покалечится, то это, в первую очередь, вина самого дурака, а только потом человека, который предложил ему взять в руки ружье.
Так и в случае с «делегированием» полномочий. Если работник не несет ответственности за свои действия на «делегированном» участке, то это не значит, что он не виноват в ошибках. Тут есть проблема менеджера, который некорректно делегировал полномочия.
И вот тут начинается территория второго мифа о делегировании, который произрастает из ошибок первого. Это когда менеджер все еще хочет «делегировать», чтобы было как в историях про директора завода, но при этом он абсолютно не доверяет подчиненным.
Делегирование без права принятия решений
Если на ситуацию выше приходится 10% случаев псевдоделегирования, то ниже мы обсудим самую частую и популярную проблему современного «эффективного» менеджмента.
Сколько раз вы сталкивались с ситуацией, когда на принятие окончательного решения по какому-либо вопросу тратится времени больше, чем на его обсуждение, планирование и разработку?
Насколько часто бывают ситуации, когда «предложение уехало наверх» и там же бесследно пропало?
Эта проблема пересекается и с вопросом некорректного менеджмента, когда решения принимаются поверхностно и неэффективно, но также она существует и в ситуации так называемого «делегирования».
В отечественной разработке и бизнесе мы чаще всего сталкиваемся именно с таких «недоделегированием», когда объем задач перекладывается на сотрудника ниже по иерархии, но при этом ему не дается права принятия даже промежуточных решений.
Самый яркий пример — это маркетинг или прочие внешние активности. «Эффективный» менеджер набирает себе команду из китайских болванчиков, на которых перекладывается не только работа по условному холодному прозвону, но и вообще все, что можно. Все это подается под соусом делегирования, якобы, руководитель должен принимать только конечные решения, а его подчиненные — выполнять черновую работу.
Подобные действия со стороны менеджмента приводят к локальному коллапсу, так как любой вопрос в ходе работы или переговоров, выходящий за пределы стандартной инструкции приводит к ответу вида:
Мне надо проконсультироваться со своим руководителем.
То есть сотрудник не способен очертить даже границы вероятностей, он просто парализован в принятии каких-либо решений и выполняет исключительно роль говорящей куклы.
Такие псевдомодели делегирования растягивают процессы, которые при должном участии всех заинтересованных лиц, длятся пару часов, на невероятные недели и месяцы. Еще хуже ситуация становится, когда менеджеру плевать на время своих подчиненных. И это проблема не только маркетинга или PR, но и в том числе аутсорс-разработки. Бесконечные митинги, согласования, созвоны разработчиков с клиентом, выезды на место и так далее, когда проектный менеджер или другое административное лицо играет в делегирование и плоскую структуру, вовлекая подчиненных в ненужные активности вместо того, чтобы позволить людям делать свою работу — тоже некорректно.
Менеджер должен быть готов в любой момент полноценно включиться в делегированный на сотрудника процесс и взять его на себя.
Этот термин можно распечатать и выдавать любому руководителю при найме. Почему-то менеджеры постоянно забывают о том, что делегированные полномочия — это все еще их полномочия. То есть, если производственная необходимость того требует, начальник должен моментально включиться в рабочий процесс вместе или даже вместо человека, которому он доверил этот фронт работ. Причем включение это должно инициироваться не только по инициативе менеджера, но в том числе и по запросу сотрудника.
Менеджмент зачастую игнорирует тот факт, что нижестоящие по иерархии сотрудники должны иметь право на принудительное подключение к вопросу вышестоящих специалистов в случае делегированной задачи.
Так как должно выглядеть идеальное делегирование
Всю эту историю можно сжать до ряда простых тезисов.
Делегирование — это передача задачи и права принятия промежуточных или окончательных решений.
Делегирование не подразумевает полное перекладывание ответственности за процесс и результат на исполнителя.
Делегирование должно подразумевать разделение ответственности за процесс в адекватных пропорциях.
Делегирование стоит рассматривать как временный процесс и быть готовым вернуть его в свою зону задач.
Не играйте в плоские структуры и делегирование там, где это не нужно. Разработчики должны писать код, а не сидеть на митингах с клиентом. Пиарщики должны пиарить, а не бегать между подрядчиком и начальником своего отдела, как гонцы.
А менеджеры должны руководить и нести ответственность, а не окидывать томным взглядом офис и думать «как же хорошо я все делегировал на других».
На правах рекламы
Мощные VDS с защитой от DDoS-атак и новейшим железом. Всё это про наши эпичные серверы. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.
Автор: Александр
