Как некорректное делегирование отравляет IT-индустрию



    Все мы слышали о делегировании, плоских структурах и прочем прямом взаимодействии, где каждый — автономная боевая единица, все молодцы, все ответственно работают и вообще, коллектив больше похож на отряд идеологических строителей коммунизма, чем на команду разработки. В основе всех этих разговоров об автономности и «плоскости» лежит тезис, который в кратком виде можно сформулировать как «дай людям работать, не замыкай процессы на себе». То есть максимально делегируй, а что не можешь делегировать — спихивай на подчиненных с удвоенной силой! Никакого офисного рабства, только максимум самосознания! Мир! Труд! Май!

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

    Наблюдая за работой десятков разных IT-компаний из разных сегментов я с уверенностью заявляю: так называемое «делегирование полномочий» в 90% случаев — фикция и способ самоутверждения менеджера. Потому что делегирование, это двунаправленный процесс, в котором должен быть не только сильный исполнитель (что очевидно), но и умный, со стальными нервами руководитель. И сейчас объясню, почему.

    Идеальное делегирование в вакууме


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

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

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

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

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

    Иначе это что угодно, но не делегирование.

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

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

    Модель, когда работник ничего не решает, а руководитель «не видит и не слышит» — к пассивности и параличу воли, а спущенные задачи — в мрачный кошмар.

    Обе эти модели и есть те самые «протомифы» о работе делегирования.

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

    Давайте разберем детально оба случая.

    Делегирование полномочий без ответственности исполнителя


    Если менеджер хочет поиграть в «доброго начальника», он расширяет границы возможностей своих подчиненных до максимума, при этом называя это «делегированием полномочий», хотя по факту он просто забивает на происходящее на его участке ответственности. В итоге DevOps и разрабы могут сами подавать данные в бухгалтерию о закупках мощностей на AWS в обход начальника, админы — сметы на закупку оборудования. Такая себе добрая анархия, где все друг другу братья. Сотрудники делают все быстро и смело, не оглядываясь по сторонам, потому что им был дан карт-бланш, со словами «я тебя прикрою».

    Вот это «я прикрою» в любых вариантах — буквально игра в русскую рулетку.

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

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

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

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

    Делегирование без права принятия решений


    Если на ситуацию выше приходится 10% случаев псевдоделегирования, то ниже мы обсудим самую частую и популярную проблему современного «эффективного» менеджмента.

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

    Насколько часто бывают ситуации, когда «предложение уехало наверх» и там же бесследно пропало?

    Эта проблема пересекается и с вопросом некорректного менеджмента, когда решения принимаются поверхностно и неэффективно, но также она существует и в ситуации так называемого «делегирования».

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

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

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

    Мне надо проконсультироваться со своим руководителем.

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

    Такие псевдомодели делегирования растягивают процессы, которые при должном участии всех заинтересованных лиц, длятся пару часов, на невероятные недели и месяцы. Еще хуже ситуация становится, когда менеджеру плевать на время своих подчиненных. И это проблема не только маркетинга или PR, но и в том числе аутсорс-разработки. Бесконечные митинги, согласования, созвоны разработчиков с клиентом, выезды на место и так далее, когда проектный менеджер или другое административное лицо играет в делегирование и плоскую структуру, вовлекая подчиненных в ненужные активности вместо того, чтобы позволить людям делать свою работу — тоже некорректно.

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

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

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

    Так как должно выглядеть идеальное делегирование


    Всю эту историю можно сжать до ряда простых тезисов.

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

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

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

    А менеджеры должны руководить и нести ответственность, а не окидывать томным взглядом офис и думать «как же хорошо я все делегировал на других».



    На правах рекламы


    Мощные VDS с защитой от DDoS-атак и новейшим железом. Всё это про наши эпичные серверы. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

    VDSina.ru хостинг серверов
    Серверы в Москве и Амстердаме

    Comments 15

      0
      это мааааленькая часть проблемы принципала-агента, из-за которой — вообще все проблемы на земле
        +2
        По какой-то причине наши менеджеры привыкли думать, что делегирование — это скинуть работу на другого, которую ты должен делать сам. Греет душу прохладная, как Чудское Озеро в апреле 1242 года, история о директорах заводов/предприятий/компаний/колхозов и прочих учреждений, которые могут уехать на полгода, а без них все отлично работает. Мол, процессы отлажены.
        Эта история не про делегирование. Она про то, что нужно задокументировать типовые решения типовых проблем на всём участке бизнес-процесса, и в дальнейшем использовать эту документацию вместо того, чтобы каждый раз придумывать решение самому или дергать непосредственного руководителя.
          0
          так как же тогда менеджеру считать себя лихим атаманом — если, вместо УРА кричать и шашкой махать ему надо бумагомарательством заниматься? ;)
            0
            Так проблема-то не в типовых. А как раз в нетипичных. Вероятно, граница тут и проходит — дозволять ли обработку хвостовых событий исполнителю, то есть по сути требуется делегирование полномочия разработки нового типа обработчика.
            +4

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

              0
              а если на всё есть инструкция и все подчиняются инструкции а не менеджеру — то как тут менеджеру считать себя главным?
              –1
              Что-то часто вижу статьи от VDSina. Хотя, один фиг статься хорошая так что норм.
                +1
                Статья хорошая. Хотелось бы еще узнать источники этих «житейских мудростей», чтобы можно было удобно сослаться в разговоре. Все понимают, что это здравый смысл, но книги и научные исследования всегда убедительней.
                  0
                  Практический опыт сотрудничества с компаниями в качестве подрядчика с 2014 года. Постоянно наблюдаю, как выстроены процессы в разных организациях и что могут и не могут люди одной и той же должности в разных организациях.
                  +4
                  Вот вам ещё один вариант:
                  За всё несёшь ответственность ты, а на твои запросы фиг клали. Ибо мы делегировали тебе работу, а не права. Ты можешь предлагать и требовать процессы, которые спасут разработку, но никто не посмотрит, так ещё и выговор влепят. А как разработка начнёт трещать по швам — ты виноват и ещё один выговор. СНГ development style.
                    0
                    Зачем работать на таких условиях, вроде вакансии в it не в дефиците
                      0

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


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

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

                      А мне казалось, что в такой ситуации как раз менеджер и должен принимать удар от вышестоящих, а потом уже самостоятельно «перетирать» с тем, кому он делегировал полномочия. Разве нет?
                        0
                        Имелось в виду, что для сотрудника все равно будут последствия, просто их озвучит сам менеджер. Немного некорректная конструкция получилась.
                        0
                        Всё верно.
                        Мне приходилось самому срочно доделывать порученную коллеге работу, потому что дольше объяснять что и как переделать. Эффективней, быстрей и дешевле оказывалось подключиться к задаче самому.

                        Only users with full accounts can post comments. Log in, please.