Как хорошему разработчику не стать плохим менеджером

История про ответственность

На одном моем новом проекте подошли ко мне лиды двух команд, Вася и Наталья. Судя по их виду, разговор предстоял серьёзный.

– Константин, нам нужно принять серьёзное решение, – сразу перешла к делу Наталья.

– Отлично, я люблю принимать решения. В чём дело?

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

Вася и Наталья выжидающе глядели на меня. Я в ответ тоже глядел выжидающе:

– И какое решение нужно принять-то? – я пока не мог задать более осмысленного вопроса.

– Решение о переписывании модуля на новую архитектуру! – Вася и Наталья были удивительно единодушны.

– Мы можем его не переписывать?

– Нет, не можем. В том и дело. Мы не можем реализовать нужные заказчику задачи без этого.

– Так а какая альтернатива есть?

– Никакой альтернативы! В том и дело! Мы просто вынуждены его переписать!

– Тогда решения никакого принимать не нужно. Вы сами уже приняли решение переписать модуль и просто хотите, чтобы я донёс это решение до заказчика, так?

– Нет. Ты должен принять решение!

– Так даже альтернативы никакой нет! Значит, решение вы уже приняли. В чём проблема-то?

– Э, не. Кто принимает решение, тот и ответственность несёт. А мы на себя ответственность такую брать не будем! Мы лидами уже давно работаем. С такими решениями всегда проблемы. Потом разборки начинаются, крайних ищут. И мы такими крайними быть не хотим.

Наконец-то я понял, чего от меня хотят.

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

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

Воздействия и результат

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

Чтобы пояснить, что я имею в виду, я хотел бы привести пример из замечательной книги Даниэля Канемана “Думай медленно… Решай быстро”.

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

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

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

В менеджменте такое происходит постоянно. В моей практике был очень забавный пример, как одни и те же результаты интерпретировались по-разному. Я тогда работал в очень большой IT-компании, где группе из примерно 30 менеджеров поставили задачу увеличить производительность их команд. Разработчики выполняли некоторые задачи, каждая из которых фиксировалась тикетом в Jira. Количество зафиксированных (созданных и закрытых) тикетов и определяло производительность.

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

На общем собрании один из менеджеров, очень активный парень по имени Пётр, так прокомментировал наблюдаемое: “Уважаемый менеджмент, поглядите, как здорово мы выполнили ваше задание. Вы попросили увеличить производительность, и мы всего за пару недель производительность фактически удвоили”.

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

Через неделю график производительность обзавёлся очередным скачком:

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

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

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

Со мной периодически кто-нибудь спорит:

– Константин, твои методы слишком сложные. Любую проблемную ситуацию в команде можно решить, просто пригрозив увольнением. Вот жалуется человек на что-то. А я ему говорю: “Увольняйся!” – и сразу все претензии пропадают.

– Но ведь так никакой команды не построить! – в шоке возмущаюсь я.

– Зато люди делают то, что им сказано. А больше ничего не надо. Это эффективно.

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

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

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

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

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

История про неожиданные выводы

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

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

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

Мне подобная политика не нравилась. Я считал её губительной уже в средней перспективе и на своих проектах разработчикам разрешал переходы. У меня даже получалось договариваться со всеми заинтересованными сторонами и оставлять разработчиков после повышения на моих проектах. Повышение зарплаты составляло обычно 60%-100%, так что разработчики были заинтересованы договариваться со мной о завершении текущих дел перед переходом на новую должность. Так что я даже извлекал пользу от этого своего отхода от принятой практики.

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

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

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

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

– Константин, а ты ведь не верил, что я пройду тест!

– Почему? У тебя же есть опыт. Ты вполне мог пройти, – удивился я.

– А, понятно. Значит, ты меня просто не ценишь и тебе пофигу, работаю я у тебя и уволюсь!

Тут у меня слов не нашлось, и я просто завис, а Игорь продолжил:

– Ну, вот другие менеджеры ценят своих сотрудников, поэтому никуда их не отпускают. Все менеджеры так делают. А раз ты меня отпустил, то не ценишь.

Я, конечно, попытался объяснить свою позицию, но до сих пор сомневаюсь, что Игорь понял меня правильно. Уж очень у нас разный подход к делу оказался. А я тогда долго удивлялся, что мне в реальном проекте пришлось работать с традиционным домостроевским подходом “Бьёт – значит любит”.

Раздел 2. Мотивация и командообразование

Главное правило мотивации

В IT тема мотивации чрезвычайно популярна. Менеджерам рассказывают о важности мотивации разработчиков, и во многих компаниях много усилий вкладывается в мотивацию5. Каждый год строятся планы развития, где выясняются желания человека. Потом к этим желания подгоняются планы, соответствующие целям компании. Человек видит, как компания работает над исполнением его желаний.

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

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

Секрет очень прост: начать работу с мотивацией надо с того, чтобы исключить демотивацию. Дело в том, что мотивация – это очень хрупкий объект. Чтобы человек думал о всеобщем благе, стремился к самосовершенствованию и делал больше, чем необходимо, надо, чтобы у него было всё хорошо.

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

Очень большая ошибка считать мотивацию и демотивацию некими величинами, которые просто складываются. Такая арифметика не работает в реальной жизни.

Например, знаю одного менеджера (очень опытного, кстати), который так говорит про свою работу: “Это я делаю все свои проекты, а не команда. Да, я использую разработчиков и тестировщиков в своей работе, но это просто инструменты для реализации проекта”. Он может это мнение своей команде никогда и не озвучивает, но оно прекрасно считывается. Этот менеджер говорит, что его проекты скучные и с них народ очень часто увольняется. Но сам он остаётся работать, поэтому проекты успешно функционируют.

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

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

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

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

История про мотивирующие речи

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

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

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