Про тимлидство

Я стал тимлидом в 24 года и по меркам тех лет это даже поздно для DL. Область была настолько молодая, что опытных инженеров было мало и лидерами команд часто становились вчерашние студенты. Главная ловушка в такой ситуации, что все молодые лиды думают мол ML/DL/программированию надо учиться, а навыки управления командой как-то да придут сами, хватит и здравого смысла для развития в этой роли.

И я так думал. А ещё думал, что я самый умный и знаю, как быть хорошим тимлидом. Считал главной задачей: сделать чтобы команде было хорошо🙌 Задачи были интересные🙌 Зарплаты были по ожиданиям🙌 Все дружили и общались🙌 Каждый человек рос в команде🙌 Слышал, что роль тимлида это “планирование, мотивация и контроль”, что “тимлид должен кодить”, и что “тимлид не должен кодить”, а еще “тимлид это не обязательно техлид” — вообще хрен разберёшься, что должен тимлид, а что не должен, слушая советы со всех сторон.

И тут я хочу дать 3 совета молодым тимлидам и тем, кто хочет ими стать (напишите в комментах, что вы бы посоветовали или почему не согласны со мной)

1️⃣ Учитесь управлению также, как учились бы программированию/разработке/DL

Хороший руководитель не забросит вас в эту роль без подготовки. Это просто абсурд, я понимаю это только спустя годы. Есть целая книга, которая от главы к главе будет унижать вас за отсутствие желания развиваться как руководитель: “Вы или вас” — Александр Фридман. Почитайте, чтобы замотивировать себя на учёбу.
В идеале вы должны обучиться до вхождения в эту роль. Но если вы стали тимлидом неожиданно, вам срочно надо на курсы. Жалко тут как в DL нельзя пройти по одной методичке/курсу и по шагам разобраться в домене. Искусство быть руководителем как быть хорошим отцом или мужем — примерно понятно что плохо, что хорошо, но когда доходит до чётких инструкций, все советы разнятся.
Сторонние курсы я проходил уже по управлению для предпринимателей (и прямо сейчас тоже учусь), поэтому рекомендовать не могу (мб вы напишите в коментах?). В крупных компаниях часто есть внутренние курсы, узнайте, есть ли у вас. Или спросите совет у руководителей и коллег по должности.

2️⃣ Постоянно спрашивайте у руководителя, что он от вас хочет

Тимлид — это крайний, с кого спросят за результат команды. Это главное, что надо понимать. Такое осознание сразу отрезвляет. Вам надо не муси-пуси с командой лишь бы все были довольны, а надо сделать так, чтобы команда перформила и перформила вдолгую (надо держать темп, но не выжимать все соки, так как бежать надо долго, а нанимать нового человека каждые полгода это дорого и неэффективно в масштабе).
Руководящая позиция часто опьяняет, даёт ощущение важности, вам становится интересно всё поменять (и чем тимлид моложе, тем ярче это выражается) — поэтому важно вспомнить, что вы всё равно линейный сотрудник для вашего руководителя и у него есть ожидания от вас. Чем прозрачнее для вас эти ожидания, тем выше шанс стать хорошим тимлидом. “Хорошесть” определяется руководителем, и от команды к команде критерии разнятся. Если вы с критериями не согласны, обсуждайте или ищите место, где будет мэтч.

3️⃣ Примите, что тимлид ≠ техлид

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

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