почему став тимлидом бывает плохо
Мысли вслух Разработка

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

-
26 мая, 2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал: <a href="https://habr.com/ru/company/oleg-bunin/blog/420059/" target="_blank" rel="noreferrer noopener">Теперь я тимлид, но почему мне так плохо? Практические советы</a>
Code language: HTML, XML (xml)

ТЕГИ

Добавить комментарий

Николай Сарры
Харьков, Украина

Меня зовут Николай, я руководитель проектов по внедрению Битрикс24 и его долгосрочному сопровождению. Лофт с заметками, статьями, идеями и мыслями по управлению проектами, использованию гибких методологий разработки. Здесь собраны мои мысли, решения, заметки и статьи. В основном по управлению проектами, PHP-разработке и используемым инструментам, обзоры прочитанных статей, тезисы посещенных конференций.