Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.

Проверим, а не микроменеджер ли вы.

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

  1. Один из худших программистов спрашивает “Могу ли я поработать сегодня из дому?”. Ваш ответ:

    • Конечно нет!
    • Да, но пообещай мне….
    • Конечно да, почему ты вообще спрашиваешь?

  2. Вы заметили, что кто-то из команды смотрит youtube-видео, несмотря на приближающийся дэдлайн. Ваши действия:

    • Спросить “Что ты делаешь?”
    • Поговорить с ним позже
    • Присоединиться и вместе посмотреть видео

  3. Вы назначаете митинг, но дизайнер говорит, что у него нет времени и он не придет на встречу. Ваши действия:

    • Сказать “Ты обязан присоединиться в любом случае”
    • Сказать “Мы обсудим твое отношение позже”
    • Сказать “Как насчет 50$ за участие?”

  4. Новый разработчик в команде фэйлит два дэдлайна подряд без уважительной причины. Ваши действия:

    • Попросить о более частых репортах о своей работе
    • Уволить ее (Егор использует именно местоимение “она”)
    • Дать ей повышение

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

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

  6. DevOps-ер жалуется, что его зарплата меньше, чем зарплата разработчика. Ваши действия:

    • Пообещать ему повышение
    • Дать ему повышение
    • Предложить ему стать разработчиком

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

  • 4 балла: 1b, 2a, 3b, 4a, 5b, 6a.
  • 1 балл: 1a, 2b, 3a, 4b, 5a, 6b.
  • 0 баллов: 1c, 2c, 3c, 4c, 5c, 6c.

И после этого Егор говорит, что с радостью бы нанял тех, у кого получилось 0 баллов. А если менеджер набрал более 8 баллов, то он может смело назвать себя микроменеджером. У а тем, кто набрал более 16 баллов, вообще не место в менеджменте, считает Егор.

Разница между хорошим менеджером и микроменеджером в том, что микроменеджер говорит как делать что-то, а менеджер - что нужно достичь. В пример Егор приводит фото рецепта, где полностью описана инструкция сырников: что смешивать, сколько, в каких пропорциях и сколько времени запекать. Егор говорит, что дай этот рецепт шеф-повару, то он просто откажется работать по нему и скажет “Дай мне просто сделать тебе сырники так, как я умею”. Если же шеф-повар сделает сырники по данному рецепту и сырники получатся невкусными, то вины шеф-повара в этом нет - ведь это вы дали повару рецепт и указали следовать строго инструкции. Это и есть микроменеджмент.

Специалист лучше знает как ему работать, где ему работать и во сколько ему работать. Такому специалисту нужно только лишь поставить цель.

А теперь разберем ответы.

1. Один из худших программистов спрашивает “Могу ли я поработать сегодня из дому?”

  • Конечно нет!
  • Да, но пообещай мне….
  • Конечно да, почему ты вообще спрашиваешь?

Первый ответ - очевидный пример микроменеджмента. Не сделать худшего разработчика лучшим только лишь запретив работать ему из дому, так что такой ответ точно не приведет к повышению эффективности. Более того, он “убьет” мотивацию этого разработчика развиваться.

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

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

2. Вы заметили, что кто-то из команды смотрит youtube-видео, несмотря на приближающийся дэдлайн

  • Спросить “Что ты делаешь?”
  • Поговорить с ним позже
  • Присоединиться и вместе посмотреть видео

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

Второй вариант получше, но это - “затаить обиду”, как говорит Егор. Менеджер как будто запоминает ситуацию и собирается поднять этот вопрос на следующем митинге. Если так будет, то разработчики будут подстраивать свою работу не под цели проекта, а под конкретного менеджера. Это - одна из классических ошибок менеджмента, когда сотрудники работают исключительно на него. Цель проекта - закрыть N тикетов за месяц, а не сделать счастливым конкретного менеджера. Проект - это начальник разработчика, а не конкретный менеджер.

Роль тимлида заключается в трех вещах:

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

Если вы выбрали третий вариант, то вас трудно назвать микроменеджером. Почему бы и не посмотреть видео с ним, если у вас есть время. У разработчика свои правила игры, у вас - свои. Если разработчик считает, что для достижения его цели нужно посмотреть видео, то пусть смотрит. Наказание не минует его, если правила игры нарушены будут (а правило “не смотреть ютьюб ни при каких обстоятельствах” - очень странное), и награда так же будет дана разработчику, если цель будет достигнута.

3. Вы назначаете митинг, но дизайнер говорит, что у него нет времени и он не придет на встречу. Ваши действия:

  • Сказать “Ты обязан присоединиться в любом случае”
  • Сказать “Мы обсудим твое отношение позже”
  • Сказать “Как насчет 50$ за участие?”

Чаще всего митинг нужен менеджеру. Если дизайнер говорит, что ему митинг не нужен, значит он и вправду так считает: он знает свои цели, он знает правила игры, он знает о системе наказания и награждения, и если он говорит, что митинг ему не нужен, значит так оно и есть. Если же менеджеру нужно, чтобы дизайнер присутствовал на митинге, значит менеджер и должен как-то замотивировать дизайнера на участие в нем (пример с 50$ был дан ради шутки). Сотрудников нужно не микроменеджерить, а уважительно с ними общаться и договариваться на принципах торговых отношений. Если дизайнер говорит, что участие в митинге для него - трата времени в обмен на ничто, значит менеджеру нужно уравнять сделку.

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

4. Новый разработчик в команде фэйлит два дэдлайна подряд без уважительной причины. Ваши действия:

  • Попросить о более частых репортах о своей работе
  • Уволить ее (Егор использует именно местоимение “она”)
  • Дать ей повышение

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

Пример с повышением зарплаты так же дан утрировано, однако Егор считает, что менеджеру нужно спросить новичка “А что тебе нужно дать, чтобы ты не провалил третий дэдлайн? Может тебе чего-то не хватает?”. Может быть разработчику нужны бонусы или зарплата повыше. Увольнение - тоже не самый хороший способ. Увольняя людей, вы не научитесь сами и не научите команду правилам игры. Более того, Егор считает, что

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

Ведь менеджер нанимал этого человека, общался с ним, доносил установленные правила игры до него. И если по итогу работы в течение некоторого периода менеджер вынужден увольнять человека, значит либо правила игры не были построены верно, либо они не соблюдаются. Когда новичок уходит сам, то это прекрасно, считает Егор. Разработчик, придя в команду, увидел установленные законы, попробовал поработать в их рамках, но спустя время понял, что ему они не подходят. Разработчик сам видит, что не вписывается в ваши правила и уходит. Егор считает, что это - признак факта, что правила игры достаточно строгие, чтобы удерживать лучших сотрудников под текущие условия (не худших или лучших, а наиболее подходящих, считает Егор).

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

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

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

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

Двуначалие категорически не приветствуется. Егор считает, что правилами должно быть установлено, что брать задачи от других команд нельзя. Егор не верит в flat-организации, где якобы нет начальников и где каждый “просит” другого что-то доя него сделать. У каждого сотрудника должен быть один начальник, считает Егор. Начальник может меняться, но источником информации, что нужно делать сотруднику, и правил игры должен быть один менеджер для него.

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

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

6. DevOps-ер жалуется, что его зарплата меньше, чем зарплата разработчика. Ваши действия:

  • Пообещать ему повышение
  • Дать ему повышение
  • Предложить ему стать разработчиком

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

Если у людей разные квалификации и разные задачи, значит и вопроса “почему товарищ получает больше” возникать не должно. Если же он возникает, то это - вина менеджера. Для сотрудников непрозрачна система мотивации и зарплат, и именно отсюда и возникает вопрос о компенсациях.

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

Вопросы из зала

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

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

“Если я менеджер, то я отвечаю за результат. И когда ко мне придет мой менеджер и спросит, почему я провалил проект, то что мне ему ответить?”

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

В каких условиях или ситуациях микроменеджмент оправдан?

Есть такие ситуации, например6 когда упал продакшн-сервер, и у вас есть три минуты, чтобы его поднять. Тогда-то и нужно забыть все о том, о чем Егор говорил в докладе, и сказать кому-то из разработчиков “ты, сел сюда, включил компьютер и поднял этот сервер, а ты - сядь рядом и посмотри, как первый это сделает”. И они оба сделать должны это здесь и сейчас7 Это - экстремальный режим, считает Егор, и включаться он должен редко и только в критических ситуациях. Вы просто используете своих людей для решения своих задач. Однако чем больше таких критических ситуаций, тем вы хуже менеджер.

Какими полномочиями менеджер должен обладать, чтобы работать по таким правилам?

Менеджер должен обладать максимальными полномочиями. Егор считает, что выснить, обладаете ли вы теми самыми максимальными полномочиями, можно вопросом:

“А могу ли я завтра уволить всех и нанять новых?”. Если в ответ вы слышите “нет”, то вы - не менеджер. Вы координатор, надсмотрщик, да кто угодно, но не менеджер.

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

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

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

Как надо наказывать?

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

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

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

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

Значит руководство не поддерживает ваш принцип менеджмента. Значит руководство считает, что они будут платить среднюю зарплату и не более. Это частоая история, говорит Егор. Менеджмент просто не хочет слушать идеи о дополнительных мотивациях. В таких условиях вы как менеджер можете геймифицировать процесс. Часто людям важнее увидеть асбтрактные 5 звездочек на открытой доске на стене, когда все имеют 4, чем получить премию, хотя Егор считает это странным. Но, тем не менее, он работает.

Какое соотношение между мужчинами и женщинами в вашем проекте?

Егор не знает, так как работает только с аккаунтами на гитхабе. Он прицнипально не хочет знать, кто там за аккаунтом. Егор считает, что правила игры вообще не должны зависеть от состава сотрудников по половому признаку.

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

Значит перед командами неверно поставлены цели проекта. Нужно именно интеграцию поставить целью сотрудников команд, и тогда правила игры будут работать на менеджера. Если предложить футболистам и баскетболистам вместе начать сажать деревья, то можно долго упрашивать их, говорить воодушевляющие речи о том, как это здорово - заботиться об экологии. Работа при такой системе мотивации врядли сдвинется с места, ибо футболистам и баскетболистам больше хочется продолжить играть в свои игры. Однако если предложить платить за каждое посаженное дерево по 10$, то обе команды бросят свои игры и начнут сажать деревья с радостью. Вы меняете правила игры и даете им иную систему мотивации, которая работает.

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

Чем ближе вы свяжете личные цели сотрудников с целями компании, тем более эффективных сотрудников вы получите.

Связать - это искусство, это тяжело. Хороший менеджер это умеет.

Если взять макроменеджмент. Все люди делают свою работу, и ты вроде как и не нужен. Что вы об этом думаете?

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

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

Что делать такому менеджеру - работать над правилами игры. Идеального варианта никогда не будет, и менеджер смотрит на обстановку, экспериментирует, меняет правила, если это необходимо.

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