💭 Почему некоторые разработчиков никогда не станут тимлидами

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

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

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

И это действительно полезно. Но когда появляется возможность назначить нового лида, очень редко выбор делается между человеком, который знает Kafka на 8 из 10, и человеком, который знает ее на 10 из 10. Гораздо чаще выбор происходит между сильными инженерами, один из которых умеет влиять на людей, брать ответственность и вести проекты вперед, а другой концентрируется исключительно на коде. И в большинстве случаев лидом становится первый.

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

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

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

Кто я | Навигация | Спасибо