Мотивация разработчиков: чек-лист для тимлида

Привет! Я Александр Субботин, руководитель отдела разработки Content AI.

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

Спойлер: в 90% случаев проблема была не в мотивации ^[1].

В этой статье я собрал кейсы из практики по мотивации ^[2] на всех этапах и один простой вопрос, который изменил мой подход к управлению командой.

Для начала буквально пара уточнений по терминологии. Руководители обычно понимают под мотивацией ^[3] разработчиков внешнюю часть: деньги, бонусы, KPI, формальные стимулы. Но есть и внутренняя мотивация ^[4]: интерес ^[5] к задаче, чувство смысла, профессиональные амбиции, автономность. И как минимум последние пять лет ключевыми факторами значимости для разработчиков остаются качество, суть и смысл разрабатываемого продукта, приносимая им польза. То есть то, что усилит их профессиональную идентичность.

Как научиться видеть истинную мотивацию уже на собеседовании

Я провел десяток собеседований, пока не понял одну простую вещь. Попытки оценить человека по хард-скиллам, опыту ^[6], тестовому работают далеко не всегда. Случалось, все эти этапы проходили вполне достойно, человек выходил, а через пару месяцев становилось понятно, что дело не идет. И проблема была не в косяках, а в том, что человек работает формально. То есть задачи закрывает, но видно, что это не его ни по ценностям, ни по интересу, ни по подходу к работе. Он не задает вопросы, не предлагает улучшений, не интересуется, зачем вообще мы это делаем.

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

Совпадение по ценностям видно уже на собеседовании: одним нужна стабильность, другим — вызов и нагрузка; кто-то расцветает в мягкой структуре, кто-то мобилизуется в директивной «красной» модели. Эти вещи важно выяснять сразу, а не пытаться «чинить мотивацию» постфактум (все равно не получится).

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

Как KPI и обратная связь могут все сломать

Классические KPI плохо подходят для разработчиков. Работа из страха перед метриками или в погоне за ними ограничивает пространство для поиска оптимальных решений. Люди стремятся не сделать лучше, а минимизировать риск ошибки ^[7]. Или еще хуже — тренируются закрывать тикеты и оптимизировать нужные метрики вместо решения реальных задач по продукту.

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

Честный разговор, даже с негативной обратной связью, не демотивирует. Демотивируют неясность, размытые формулировки и прочие увиливания от сути. Я за честность и открытость в коммуникациях, даже если хочется покритиковать. Структурированные форматы обратной связи типа SBI могут помогать, но главное не потерять за ними суть и нормальный диалог с человеком. Разработчики не дураки и со второго раза прекрасно видят, когда им упаковывают информацию в определенном «красивом» формате.

Что скрывается за запросом «Давайте мотивировать разработчиков»

Я много раз слышал от CEO и CTO запросы вроде «Надо как-то замотивировать разработчиков / вовлечь». Со временем, поняв, как заканчиваются такие разговоры, начал сразу заходить со встречных вопросов о том, что именно беспокоит, что на самом деле хотят изменить руководители. Обычно выясняется что-то очень конкретное: фичи едут медленнее, чем хочется, техдолг растет, разработчики не проявляют инициативу, на встречах отмалчиваются и т.д.

И тут не нужны какие-то дополнительные мотивирующие активности, а нужно чинить то, что сломано. Команде в этот момент не нужны бонусы за выполнение новых KPI, это только добавит стресса ^[8] и заставит гнаться за достижением метрик вместо решения реальных задач.

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

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

Мотивация людей в команде

Людей мотивируют разные вещи в работе, чаще встречаются такие типы:

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

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

• Третьи хотят роста влияния. Им важна вертикальная карьера, управление, ответственность за решения.

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

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

Простой управленческий вопрос как волшебный инструмент мотивации

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

Задайте  разработчику или лиду простой вопрос: «Представь, что у меня была бы волшебная палочка и я бы мог пофиксить одну вещь, которая тебя больше всего бесит — что бы это было?»

Фраза может звучать наивно, но сам смысл ее в том, чтобы снять с человека ответственность за ее достижение. 

Каково было мое удивление, когда вместо процессов, целей и давления по срокам самой большой проблемой для одного из тилидов однажды оказалось неудобное кресло, которое реально бесило человека, но он все никак не мог этим заняться. Был и случай, когда после такого вопроса половине команды поставили мощные SSD и добавили оперативную память ^[9].

Контроль и микроменеджмент любят притворяться мотивацией

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

Как проблемы в коммуникациях снижают мотивацию

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

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

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

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

Почему премии и геймификация не работают

Первое, что приходит в голову при разговоре о мотивации — бонусы и игровые механики. На первый взгляд, все логично ^[10]: людям нужно платить платить за результат и делать работу увлекательнее.

Премии коварны тем, что могут смещать фокус внимания ^[11] с работы в целом на достижение конкретного показателя. Например, разработчик будет думать не о том, чтобы хорошо сделать модуль, а начнет стремиться закрывать тикеты максимально быстро. С появлением новых инструментов вроде Cursor очень заманчивым видится следить за количеством PR в день или за Time to Market/Cycle Time всех фич. 

Но если контролировать только это, что будет с техдолгом? Разработчики будут тотально MVP-шить каждую фичу, делая ее все меньше и меньше, но будет ли это реально хорошо работать? Разработчики — умные ребята и всегда найдут, как взломать метрики.

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

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

Почему геймификация разрушает команду

Геймификация звучит весело и, на первый взгляд, работает хорошо — люди включаются в гонку за баллами и  ачивками. Но в этом кроется катастрофа. Чтобы ощутить, как это работает, вы можете поиграть в донатную мобильную игру, которая будет выдавать вам много звезд и наград, требуя взамен много денег. В итоге вы наверняка почувствуете больше тревоги и стресса ^[12].

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

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

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

Стрессовать сотрудников доской почета классно во «Вкусно и точка», но так ли это нужно для разработчиков?

Как обойтись без бонусов и баллов

Мотивировать людей в целом вообще не надо. Достаточно создать нормальные условия, в которых им будет интересно работать:

• Давать задачи, в которых есть смысл

• Объяснять контекст и важность

• Убирать препятствия (технические, процессные, коммуникационные)

• Помогать расти профессионально

• Давать денег)))

Тогда дополнительные костыли мотивации просто не понадобятся.

Чек-лист: 

1. Задайте вопросы себе:

• Что ответит команда, если спросить ее о наших целях?

• Когда в последний раз я объяснял бизнес-контекст?

• Что с техническим долгом и инфраструктурой?

• Какой честной обратной связи я избегаю и к руководителю, и к команде?

• Верю ли я сам стратегию и надо ли мне что-то с ней сделать?

2. Спросите каждого в команде:

• Что тебя больше всего бесит — и что я могу поменять?

3. Оцените процессы:

• Задачи приходят с контекстом или просто как список тикетов?

• Приоритеты меняются каждый месяц или есть стабильность?

• Люди знают, почему принимаются решения  или только выполняют команды?

В 90% случаев проблема вскроется в каком-то из пунктов этого списка. А вера в достижимость результатов — тоже часть стратегии.

Есть вещи, с которыми ничего нельзя сделать

Есть ситуации в которых имеет смысл быстро признать поражение:

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

• не удастся помочь человеку, который выгорел и потерял интерес к разработке в принципе (мы не психологи)

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

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

А что в вашей практике чаще всего оказывалось реальной причиной демотивации команды? И главное, что помогло это исправить? 

Мне, например, очень весело каждый раз объяснять, как разработчики взломают тут или иную метрику. А еще помню случай, когда в предыдущей компании команда HR для увеличения вовлеченности сделала обязательный ежемесячный пульс-опрос, на который потом никак не реагировали =