Тимлидство — роль, которая может стать ловушкой для разработчика, а может дать огромные возможности для создания ПО

Вернёмся года на два назад, когда я был разработчиком. Что я думал? «Хочу стать тимлидом. Это круто, он решает все вопросы, получает больше денег, им становятся после сеньора». Тогда не было никого, кто сказал бы мне: это вообще про другое. Пришлось учиться на своих ошибках.

Я дважды становился тимлидом

У меня есть такая черта: стараться во всем наводить идеальный порядок, систематизировать, выстраивать процессы. Поэтому меня всегда тянуло брать на себя больше, чем просто написание кода. В моём первом стартапе, назовем его «T», был полный хаос в процессах разработки.

Сейчас бы я вряд ли стал там работать, но тогда это было очень атмосферно. Только представьте. Много параллельных заказчиков. Руководитель ходил напрямую (и точечно) к разработчикам. Мы часто не укладывались в озвученные сроки и сидели допоздна. Помню, как однажды шеф позвонил в 20 часов и попросил приехать на работу, чтобы докрутить фичу для заказчика, — потому что «озвучил срок завтрашним утром». Но в «Т» мы были «семьей».



А еще делали все сами — как умели. Помню, как ставил Ubuntu на рэковый сервер, который отдал нам один из инвесторов. Когда я включал его, он издавал звук взлетающего вертолета!

Там я дорос до статуса техдира и работал с командой из 10 человек. По сути, первый, по наитию, опыт тимлидства случился там.

В «D», куда я пришел разработчиком, все было иначе — особенно в том, что касалось процессов.

В компании был реализован классический Scrum: четкие спринты, burndown chart’ы, демо, планирование, стори поинты, груминги для подготовки будущего спринта. Я был поражен качеством процесса, тихонечко писал код и наблюдал, как все работало. Затем подружился со скрам-мастером и стал закидывать его вопросами. Он охотно отвечал и делился крутыми книгами.


Особенно запомнилась «Scrum и XP: заметки с передовой» от Хенрика Книберга. Процесс в «D» был выстроен близко к этой методологии: в результате весь менеджмент и продавцы отлично понимали, когда будет результат.

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

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

Так Петя меня раскусил и узнал про опыт руководства командой в «T» и заочном обучении скраму в «D».

В какой-то момент он предложил мне провести стендап.


Операция «преемник» в моем случае выглядела вот так и заняла 6 минут)

А через неделю выяснилось, что в компании открывается новое направление, и Петя с частью команды отправляется на тот проект. Оставшимся ребятам нужен новый лид.

Все происходит само собой, будто в сторону тимлидства тебя толкает невидимый Закон Притяжения.

Когда у компании появляется нужда в тимлиде и все думают «Где его взять?», то часто берут из ребят, которые:

• лучше организованы,
• быстро вовлекаются в процессы и идеи команды,
• мотивированы и приобретают авторитет в глазах коллег-разработчиков.

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

Тут надо пояснить, кто такой тимлид в нашем случае

Это обязательно отличный программист, который хорошо разбирается в коде проекта и может при необходимости самостоятельно писать код (например, если кто-то из ребят заболел или в отпуске, а нужно срочно). Но по функционалу ты больше менеджер: общаешься с бизнесом и другими командами, выстраиваешь процессы внутри своей и почти не пишешь код. Позиции техлидов у нас тоже есть, но только на крупных проектах.

Вот как выглядел примерный круг обязанностей тимлида в Skyeng на момент начала истории:

Но одно дело взять на себя задачи тимлида, и совсем другое — справиться с ними.

Что поменялось и как я с этим боролся

Первые несколько дней ты живешь с ощущением эйфории, триумфа и восторга. Ещё бы: ты у руля целой команды, на тебя сделана ставка, у тебя больше возможностей и ответственности! С момента ухода из «Т» прошло несколько лет, я набрался опыта, проанализировал свои ошибки, увидел продвинутые процессы и методологии и поработал по ним. Все это давало мне силы и уверенность для второго захода в тимлидство.

Однако со временем чувство эйфории прошло, наступили будни. Вот что я заметил за собой.

Нужно быть морально готовым расстаться с «ежевечерним дзеном»... и подружиться с «ежеквартальным». Результат работы тимлида обычно не увидеть за один день или даже неделю. Это одновременно и плюс, и минус.

В своём докладе «Ломка и отходняки при переходе из инженера в тимлиды» Артем Каличкин бьёт прямо в точку, говоря, что «программисты — одни из самых счастливых людей на свете».

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

Тимлиду же редко есть чем поделиться на стендапе: потому что вчера ты “занимался планированием, был на созвонах, читал почту и добавлял задачи в бэклог”. Такие результаты, как новый раздел на сайте или большая фича в приложении складываются из маленьких шагов, которые вы с командой проходите каждый день. За это время ты можешь не написать ни строчки кода, однако в целом вы затащите такой объем работы, который ты бы никогда не осилил за это время.

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



Тот самый раздел в приложении.

Можно оценить количество экранов и механик одного занятия на гифке: ход ускорен

Во многом это история про делегирование. Нужно бороться с привычкой делать все своими руками. По сути, чтобы стать настоящим тимлидом, ты должен научиться программировать руками разработчиков своей команды.

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

Ты рискуешь превратится в «оператора колл-центра» — и если не остановить это, выгорание гарантированно в течении одного-двух месяцев.

Тут я хочу передать привет сказать искреннее спасибо своему продакту. Увидев эту проблему, он отправил меня читать «Джедайские техники» Дорофеева, «Тайм-менеджмент» Архангельского, а также изучать каналы и чаты для тимлидов, записи с конференций и так далее.

Практики, которые я почерпнул, помогли устранить расфокусировку. Я предупредил всех, что буду проверять входящие 1-2 раза в день, стал устраивать дни без встреч и созвонов, планировал свой рабочий день в письменной форме (даже пытался ввести эту практику в команде, но разработчики такое не любят). Приоритеты менял, только если случилось что-то реально критичное. В результате те дела, которые я запланировал, перестали откладываться.

В общем, пришлось ломать свои привычки и экстренно осваивать кучу полезных техник.

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

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

Разумеется, сами навыки можно развить. Но нужно быть готовым, что это приведет к определенной трансформации личности.

Больше не тимлид: как не потерять себя и найти снова

Два года назад я считал, что тимлид — это следующая ступень в эволюции программиста. Теперь думаю, что это другая, параллельная ветвь развития. Результат перехода сильно зависит от каждого конкретного человека — и ты не узнаешь, пока не попробуешь.

Эту роль нужно протестировать. И не месяц, не не два. Думаю, минимум шесть. Еще лучше — годик-два. Есть большая вероятность, что будет сложно, будет хотеться вернуться назад, не достигнув результата. Посоветую поставить себе срок и сказать: «Я не делаю промежуточных выводов до конца этого срока. Потестирую, а в конце приму решение, моё это или нет». Лично я так и сделал.

Проработав на позиции лида полтора года (с сентября 2018 по февраль 2020), я осознанно решил оставить эту роль и вернулся в разработку. За это же время тимлид, канал которого я читал, дорос CTO в моей компании.



Мы всегда на удаленке, основная коммуникация в Slack: так что «все ходы записаны». Всё сложилось так, как на картинке: коллега, которого я предложил, пробует себя в роли тимлида, а я радуюсь «вечернему дзену» в рамках другой команды.

А этим летом мы с еще парой ребят, прошедших подобный путь, сделали внутренний митап о своем опыте. И самый главный вопрос, который возник у слушателей: ок, а как понять, когда думаешь, куда развиваться дальше, роль тимлида — это твоё или нет?

Так пришла идея обсудить его в публичном формате с:

• Егором Толстым (подкаст и курсы Podlodka) — он сделал выбор в пользу управления продуктом и расскажет о моменте, когда понял, что устал от руководства разработкой,
• Вадимом Мартыновым (Контур и сообщество RndTech) — он вернулся в разработчики и расскажет, как переучивался писать код и как все это сказалось на финансах,
• и Евгением Котом (Wrike и тот самый доклад о болях тимлида) — в качестве ведущего.

Все пройдет онлайн в ближайшую среду (2 сентября) в 19 часов по Москве/Киеву/Минску на ютубе: для зрителей будет чат и простая возможность включиться голосом. А если у вас останутся силы — пообщаемся в зуме.

Здесь можно поставить напоминалку в календарь.

Подключайтесь дискуссии «БольшеНеТимлид» или смотрите ее в записи. Надеюсь, наш опыт будет вам полезен, ведь два года назад я тоже думал, что…