Почему став тимлидом бывает плохо

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

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

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

“Быть тимлидом круто!” – думает большинство разработчиков особенно джуниор и миддл уровней, ведь “Я буду решать очень важные вопросы”. Оказавшись в долгожданной роли они наверняка испытают горькое чувство от того, что на стендапе о сделанных фичах и исправленных ошибках сказать им нечего. Вроде как ничего и не делал: на митинги ходил, на почту отвечал, по телефону общался. Ну и прямым в голову становится фраза подчиненного “Ты код вообще не пишешь, только делаешь вид, что проводишь code review.”.

Существует три классических типа тим-лидов: Волшебник, Воин, Бард.

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

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

Бард: всегда лицом повернут к бизнесу. Ответственность на себя не берет, но не знает кто за что отвечает и вобще смутно понимает что творится в команде.

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

Не стоит делать из хорошего программиста плохого менеджера. (Лучше поступите наоборот!)

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

И тут многие скажут – “Используй делегирование, че тут сложного-то”. Поймите, что распихать задачи в менеджере задач – не делегирование. Делегирование – это про передачу ответственности. Например – проводить ревью будет кто-нибудь из команды.

Второй полезный совет:

Заведите асинхронный канал для входящей связи

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

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

Не лишним будет вспомнить о философии Икигаи и встать на путь поиска и никогда на этом пути не быть несчастным.

Оригинал: Теперь я тимлид, но почему мне так плохо? Практические советы