5 антипаттернов тимлида: как эффективно демотивировать свою команду

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

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

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

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

Антипаттерн №1: «Серый кардинал»

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

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

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

Как чинить: 

• Используйте в работе инструменты визуализации процесса принятия решений, например RACI/DACI матрицы. Это поможет всем понимать, кто и за что отвечает, кто принимает окончательное решение, а кому важно просто рассказать об итоговых результатах, не привлекая активно к задаче.
• Проводите встречи для совместного принятия решений, где команда будет обсуждать ключевые моменты, которые касаются команды.
• В продолжение пункта про встречи совместного принятия решений можно применить «Освобождающие структуры» для обсуждения задач. Особенно я рекомендую  технику «1-2-4-All». Она помогает получить разнообразные мнения, избежать доминирования отдельных участников и создать более структурированное обсуждение.

Антипаттерн №2: «Министерство ненужных дел»

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

К чему приводит:

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

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

Как чинить: 

• Используйте User Story Mapping для приоритизации бэклога с учетом потребностей пользователя.
• Устраивайте встречи «бизнес-контекста», где тимлид или тимлид и продакт команды объясняют, как новая фича вписывается в продуктовую стратегию, какие бизнес-цели она поддерживает и на какие метрики влияет.

Антипаттерн №3: «Синдром контроллера»

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

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

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

Как чинить: Здесь также можно использовать и RACI матрицу, но, на мой взгляд, эффективнее Покера Делегирования из Management 3.0 пока ничего не придумали. Инструмент предоставляет 7 уровней делегирования, которые помогут вам настроить с командой детали взаимодействий и совместное принятие решений.

Антипаттерн №4: «Девять кругов дисфункций»

Проблема: Команда работает вместе несколько спринтов, но, кажется, что все как будто идут в разные стороны. Один или пара разработчиков взяли на себя роль негласных лидеров, принимая решения за других или постоянно выясняя, кто круче/умнее/опытнее. В этот же момент несколько членов команды чувствуют себя «на обочине» и не понимают, как их работа влияет на общий результат. Цели и задачи проекта/продукта размыты: каждый сосредоточен только на своих собственных задачах, не думая о конечном продукте. Тимлид пытается всё координировать, но ему постоянно приходится «тушить пожары» и решать мелкие конфликты, проблемы, блокеры. Одним словом в команде хаос и непонятно за что хвататься, а упорядочить весь этот бардак очень хочется.

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

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

Как чинить: 

• Для организации работы команды можно использовать шаблон Team Canvas, который поможет выделить роли и зоны ответственности в команде, а также правила взаимодействия внутри команды и цели.
• Также существует Team Charter — это документ, который определяет цели, роли, ценности и ожидания для работы команды. Он служит основой для совместной работы и помогает всем участникам оставаться на одной волне относительно задач и процессов.

Антипаттерн №5: «Капитан чужого корабля»

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

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

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

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

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

Как чинить: Здесь у меня нет какого-то инструмента, но есть несколько советов, которые помогут вам внедрить изменения без попытки «сломать команду об колено».

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

2. Оценка текущего состояния. Вместо того чтобы сразу ломать процессы, проведите диагностику. Определите, что реально работает, а что требует изменений.  Используйте инструменты анализа текущего состояния команды, например ретроспективы, SWOT-анализ, оцените команду при помощи инструмента Team Maturity Model или же поработайте с командой над Value Stream Map, чтобы увидеть, как создается ценность вашей командой и где есть неэффективные процессы и/или потери времени. 

3. Постепенное внедрение изменений. Вносите изменения шаг за шагом, экспериментируя и собирая обратную связь от команды. Это позволит вовлечь команду в процесс изменений, снизить сопротивление и адаптироваться на ходу. В качестве подхода внедрения изменений можно использовать HADI-цикл. 4. Прозрачное принятие решений. Вовлекайте команду в процесс обсуждения и принятия решений. Дайте людям возможность высказаться и поделиться своими опасениями или предложениями. Это повысит уровень доверия и ответственность за внедренные изменения. Здесь мне также хочется сослаться на Покер Делегирования и RACI матрицу, которую описывала ранее.

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

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

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

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

— разберем модель Ситуационного лидерства (4 модели поведения руководителя в зависимости от уровня зрелости команд), 

— покажем, как построить прозрачную систему задач и метрик,

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