Успех тимлида — это успех команды: три ошибки тимлидов в начале пути

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

d4d652565f0df726e76e5b621348e93e.jpeg

Ошибка первая: тянуть сотрудников за уши

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

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

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

  • Команда получает негативную оценку перформанса со стороны руководителя: «Такая опытная команда, а проекты по уровню не тянете».

  • На команду сваливается проект, соответствующий её ожидаемому уровню, и она его заваливает. 

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

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

При использовании такого подхода у людей возникает «сопротивление изменениям». Это довольно распространённое явление, про которое написано много статей. Я только уточню, что на преодоление этого эффекта тратится значительное количество времени и сил.

Хорошим ответом на вопрос о развитии будет задача для тимлида:

  • Во-первых, нужно понять нужный состав команды по навыкам.

  • Во-вторых, нужно собрать пожелания от ребят про их профессиональные интересы.

Дальше есть два пути:

  • С теми, кто не дотягивает до целевой картины: поставить рамки, явно проговорить ожидания, вместе выработать план и контролировать достижение. Дальше сотрудник либо дорастает, либо мы договариваемся расстаться или ротировать его.

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

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

  1. Собираем понимание необходимого набора навыков в команде. Для этого можно обратиться к инструментам вида StarMap и подобным, они неплохо с этим справляются

  2. Собираем профессиональные интересы наших сотрудников.

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

Ошибка вторая: не понимать приоритеты работы

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

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

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

Часть 1. Собираем карту стейкхолдеров. 

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

  • Кто может меня уволить? Обычно тут не только административный руководитель, но и ключевые стейкхолдеры.

  • Кто меня может премировать? Тут иногда тоже больше одного руководителя, а иногда и нет руководителя.

Часть 2. Собираем карту реальности и ожиданий. 

Следующие вопросы я в том или ином виде задаю всем стейкхолдерам:

  • Что в моей зоне ответственности с вашей точки зрения? Чем более точная граница получится, тем лучше. Я всегда беру объединение всех получившихся ответов по максимуму.

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

  • Что от меня ожидается? Это и будет нашим фокусом на первое время.

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

Ошибка третья: не собирать требования и ожидания

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

Ситуация. Сотрудник приносит заявление и офер сторонней компании. Что попытался сделать молодой руководитель? Перекупить. Как итог — сотрудник поднимает скандал. Я вмешиваюсь.

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

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

После этого случая я всегда копаю решения и выводы тимлидов на наших встречах. Тут не пришлось ничего изобретать: есть стандартные техники, например «Пять почему» и подобные. К чему это приводит — почти мгновенному погружению в пропасть отчаяния :) . Это тоже проблема, но рассмотрение её решения тянет на отдельную статью.

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

© Habrahabr.ru