Успех тимлида — это успех команды: три ошибки тимлидов в начале пути
За свою карьеру я вырастил многих тимлидов как руководитель и ментор. За это время собрал обширную коллекцию возникающих во время работы проблем. Собрал список тех, которые встречались мне чаще всего.
Ошибка первая: тянуть сотрудников за уши
Успех тимлида — это успех команды, а команде для успеха нужны сильные сотрудники. Значит моя задача — вырастить всех, кого смогу.
Подобное утверждение я слышу довольно часто. Эти благие намерения часто ведут тимлида в ад. Прикрываясь этим, тимлид начинает уговаривать своих сотрудников расти, а в запущенных случаях пытается имитировать рост перед окружающими. Объясню, почему это плохо.
Начнём с очевидного: если тимлид приукрашивает навыки сотрудников, команда со стороны выглядит более сильной. Далее возможны два варианта развития событий:
Команда получает негативную оценку перформанса со стороны руководителя: «Такая опытная команда, а проекты по уровню не тянете».
На команду сваливается проект, соответствующий её ожидаемому уровню, и она его заваливает.
Оба варианта приведут к тому, что к тимлиду придут выяснять, в чём дело — он не тянет или команда. Выйти из этой ситуации даже опытному менеджеру сложно. В любом случае, оценка его работы на перфревью будет ниже среднего.
Почему не стоит уговаривать или заставлять сотрудников расти не так очевидно. Добиться роста сотрудников так получится, но времени и сил на такое развитие тимлид потратит столько, что на его собственную работу времени не останется, а фокусироваться надо именно на ней.
При использовании такого подхода у людей возникает «сопротивление изменениям». Это довольно распространённое явление, про которое написано много статей. Я только уточню, что на преодоление этого эффекта тратится значительное количество времени и сил.
Хорошим ответом на вопрос о развитии будет задача для тимлида:
Во-первых, нужно понять нужный состав команды по навыкам.
Во-вторых, нужно собрать пожелания от ребят про их профессиональные интересы.
Дальше есть два пути:
С теми, кто не дотягивает до целевой картины: поставить рамки, явно проговорить ожидания, вместе выработать план и контролировать достижение. Дальше сотрудник либо дорастает, либо мы договариваемся расстаться или ротировать его.
Для тех, кто уже достаточно прокачан, подобрать интересные и полезные векторы развития внутри проекта и помогать по запросу сотрудника на пути развития.
Для того, чтобы избежать подобной проблемы можно использовать следующий алгоритм, который создаст правильный фундамент для решения подобных задач
Собираем понимание необходимого набора навыков в команде. Для этого можно обратиться к инструментам вида StarMap и подобным, они неплохо с этим справляются
Собираем профессиональные интересы наших сотрудников.
Приступаем к созданию индивидуальных планов развития. Делаем это так, чтобы в итоге получить максимальное покрытие первых двух пунктов.
Ошибка вторая: не понимать приоритеты работы
Эта ошибка тянет на отдельную статью: тут во многом бывает упущение и руководителя тимлида, и его самого. Побочный эффект этой проблемы очевиден — тимлид делает не то, что от него ожидают и, как следствие, там, где нужен результат, его не будет.
Начинающие тимлиды часто слишком много внимания уделяют инженерной работе в ущерб менеджерским обязанностям. Она проще, понятней и виден результат, больше удовлетворение от работы. На месте руководителя такого тимлида надо много и регулярно работать с образом мышления, научить видеть результат менеджерской работы. Для этого есть много обучающих материалов, и фреймворков. Сам тимлид из такой ловушки обычно выбирается долго и больно, потому что приходится менять привычные приоритеты и паттерны мышления, а объективно оценить результат можно только со стороны.
Опытные тимлиды попадают в эту ловушку реже, но проблем она приносит больше. Они редко уходят в инженерную историю, а просто делают «не то», работу, которая в новой компании должна закрываться другими специалистами — например, менеджером проекта. Часто такое случается на новом месте работы, так как на предыдущем ожидания и приоритеты отличались. Я собрал для себя мини-фреймворк, который позволяет выбраться из неё без особой боли.
Часть 1. Собираем карту стейкхолдеров.
Это нужно, для того чтобы понять над решением чьих задач мы работаем и кто в конечном итоге будет оценивать нашу работу. Для формирования этой карты я отвечаю для себя на следующие вопросы:
Кто может меня уволить? Обычно тут не только административный руководитель, но и ключевые стейкхолдеры.
Кто меня может премировать? Тут иногда тоже больше одного руководителя, а иногда и нет руководителя.
Часть 2. Собираем карту реальности и ожиданий.
Следующие вопросы я в том или ином виде задаю всем стейкхолдерам:
Что в моей зоне ответственности с вашей точки зрения? Чем более точная граница получится, тем лучше. Я всегда беру объединение всех получившихся ответов по максимуму.
Кто в моей зоне ответственности и как я могу на них влиять? Иногда будут сотрудники, иногда будет возможность влиять на зарплаты или бюджет, иногда проекты.
Что от меня ожидается? Это и будет нашим фокусом на первое время.
Этот фреймворк позволяет правильно расставить приоритеты в работе, а также позволяет увидеть есть ли ответственность за то, на что нет возможности влиять. Как с этим быть, каждый решает по-своему.
Ошибка третья: не собирать требования и ожидания
Многие из нас знакомы с эффектом Даннинга-Крюгера. В эту ловушку часто попадают и молодые тимлиды. Когда всё кажется понятным, очень сложно найти в себе силы не побежать сразу делать, а потратить время на изучение проблемы. Если проблему не изучить, то результат почти всегда оказывается непредсказуемым, так как от нашего внимания могут ускользнуть значительные нюансы. В лучшем случае, ситуация не становится хуже, но иногда возникают курьёзные случаи. Например, я разбирал следующий кейс.
Ситуация. Сотрудник приносит заявление и офер сторонней компании. Что попытался сделать молодой руководитель? Перекупить. Как итог — сотрудник поднимает скандал. Я вмешиваюсь.
Что тут не так. Тимлид не разобрался в причине того, почему сотрудник решил уйти, а сразу бросился чинить. К счастью, в тот раз мне удалось вмешаться, сохранить сотрудника в компании и преподать небольшой урок тимлиду.
Как можно было этого избежать. Уточнить причины. Сотрудник был замкнут и явно не обозначил такие потребности, а руководитель был молод и не смог докопаться в силу недостатка опыта.
После этого случая я всегда копаю решения и выводы тимлидов на наших встречах. Тут не пришлось ничего изобретать: есть стандартные техники, например «Пять почему» и подобные. К чему это приводит — почти мгновенному погружению в пропасть отчаяния :) . Это тоже проблема, но рассмотрение её решения тянет на отдельную статью.
На этом я закончу с описанием ошибок, хотя их список можно ещё долго вести. Часто молодой тимлид не в состоянии справиться с ростом давления, новой информации и задач. Так что их наставникам не стоит расслабляться и надо быть всегда наготове, чтобы подстелить соломку и поддержать.
