Введение

Кому будет интересно/полезно прочесть данный текст? Человеку, который может дать утвердительный ответ на вопрос: хочу ли я стать тимлидом?

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

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

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

Ну что ж, приступим.

Минусы

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

Потеря хард-скиллов

Одно из первых, что необходимо упомянуть — это постепенное или даже стремительное ощущение потери хард‑скилла.

Происходит это потому, что если программист практически полностью нацелен на код, то тимлид распыляется на множество вещей — будь то 1-to-1, планирование, процессы и так далее.

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

В дополнении к выше сказанному, будет страдать еще и прогнозируемость завершения задачи. Вас чаще будут отвлекать (и не всегда предсказуемо), следовательно, прогноз по завершению задачи давать будет сложно. Добавим сюда еще и то, что может быть ситуация, в которой вы некоторую фичу завершили, передали в тестирование, но там был обнаружен дефект и задача возвращается на доработку/исправление. А вы уже не можете физически взять ее в работу - вы уже заняты на планировании следующего спринта, бюджетах и так далее.

Это приводит к тому, что средне-большие/большие задачи или сложные случаи багов брать не получится. Все чаще вы будете либо отказываться от идей брать фичи в работу, либо будете брать небольшие/не критичные задачи.

Конечно, можно учиться вечерами, проходить курсы, писать пет-проекты, но в таком случае будет страдать личная жизнь, хобби и прочая иная составляющая жизни, ведь времени уже не останется.

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

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

Ну и первая важная метрика: если вы очень любите писать код, то, возможно, эта ветка развития, эта роль - не для вас.

Играющий тренер как сидение на двух стульях

Если говорить о классической корпоративной разработке, то у тимлида будет множество задач по администрированию, коммуникациям с другими командами, мотивации собственной, планированию и так далее.

В результате, как мы отметили в пункте про хард-скиллы, на написание кода остаётся совсем немного времени.

Но компании часто стараются экономить и считают тимлида еще одной качественной единицей в разработке, на уровне ведущего программиста (те самые М+ или Senior), зачастую такое совмещение обязанностей называется 'играющий тренер'.

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

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

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

Сложность в смене работы

Не секрет, что вакансий тимлида или руководителя разработки в разы меньше, чем вакансий разработчика (мы рассматриваем именно ведущие вакансии разработки).

Однако, это не самое страшное, сложнее дело обстоит именно в части собеседований.

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

И в технической секции вас будут оценивать по хард-скиллам, а проходной балл будет не ниже М+ или Senior.

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

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

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

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

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

Частично по этой причине тимлидов предпочитают 'выращивать' внутри компании, а не нанимать с рынка.

Итого: процесс смены работы для тимлида происходит болезненнее и сложнее, нежели для разработчика.

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

Размытая зона ответственности и возможностей

Если взять две разные компании, то почти наверняка окажется, что обязанности тимлидов в них существенно различаются.

Где-то будет упор на 'людей', где-то наоборот минимальное ваше вовлечение в это. Где-то вы будете 'играющим' тренером, а где-то вообще почти не будете писать код. Во многих компаниях вы вообще будете совмещать роль технического лидера и менеджера.

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

Также команду часто собирает не тимлид, а организация.

Скорее всего будет что-то такое: надо сделать хорошо, потому что плохо не надо. Вот команда (нам кажется, этого достаточно, мы уверены), все молодцы, как на подбор, и мы немного торопимся по срокам. Если нужны ресурсы еще, то это надо вам как-то доказать, как - это тоже вам надо узнать.

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

Это приводит к тому, что голова буквально 'плавится' от необходимости следить за множеством дел сразу. Нередки случаи, когда вы будете 'затыкать' собой сложные места. Как результат — частый стресс и ощущение неопределённости, особенно на первых порах.

Часто из-за загруженности бывают ситуации, что вы поздно обедаете или вовсе не получается нормально поесть.

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

Деньги и карьера - не то, что вы себе представляете

Тимлидство редко приносит значительное увеличение зарплаты по сравнению с позицией ведущего разработчика.

Чаще всего эта разница не составляет даже и 15-20%. Добавьте сюда то, что смена работы - это для вас крайне болезненный процесс, в отличие от позиций разработчика (а зачастую значительные прибавки к зарплате связаны со сменой места работы).

Это не значит, что у вас нет шансов увеличить свои зарплатные ожидания, однако сделать это станет чуть сложнее.

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

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

Отсюда зачастую рост происходит либо в другие роли (например, Product Owner), либо горизонтальный (Technical Leader).

Итого: не стоит ожидать 'золотых' гор и резкого перехода в CTO. Карьерная составляющая присутствует, но может быть реализована через переход на другую роль, либо горизонтальным ростом.

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

Удовольствие от работы - не быстрый процесс

Разработчик может получать удовольствие от работы по разному, например, когда видит, что функционал, который он реализовал востребован, кто-то получает дофамин от красиво написанного кода или, в конце концов, зеленых тестов!

Моментов радости или получения позитивных эмоций достаточно много и они происходят часто. Чего часто нельзя сказать о тимлиде.

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

Чаще всего вы радуетесь, когда план сошелся и фича реализована во время, внедрение прошло без проблем, после чего вас что-то отвлекает и вы уже забываете эту радость, так как погружаетесь в новую проблему.

Грубо говоря, позитивные события - это в основном более глобальные события, а значит и происходят реже.

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

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

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

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

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

Тяжелая работа с людьми

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

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

Все это рождает дополнительный стресс.

Итого: работа с людьми, конфликтными ситуациями и мотивацией станет неотъемлемой частью вашего дня. К этому надо себя подготовить, уметь и учиться решать конфликты, понимать мотивацию как свою, так и команды.

Если вы тяжело переживаете конфликты, то подумайте о смене роли еще раз.

Бесконечные созвоны

Ну и вишенкой на торте нельзя не упомянуть бесконечные созвоны. Зачастую абсолютно бесполезные или сумбурные, неожиданные. Бывает также и такое, что вы понимаете, что на этой встрече вы вообще не нужны и после часа-другого простого 'сидения' на созвоне единственное, что вы говорите - это 'до свидания, коллеги' или 'всем пока'.

Это в свою очередь рождает ощущение, что тратишь время в пустую и ничего полезного не делаешь.

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

Итого про минусы

Минусы есть в любой работе и я постарался описать без приукрас то, с чем вы так или иначе, но столкнетесь.

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

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

Еще одной метрикой 'против' явялется то, что вы сложно переносите размытость задач, стресса и 'бесполезных' дней, когда кажется, что день прошел 'за разговорами'.

На своем опыте я часто замечал интересный момент: есть еще так называемые 'неформальные лиды'.

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

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

Вот подобный пример может дать хороший взгляд на именно минусы в работе тимлидом.

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

Об этом мы поговорим чуть позднее. И все не так ужасно, как можно подумать, поэтому давайте перейдем к плюсам!

Плюсы

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

Ну и раз мы так сгустили краски, то давайте их развеем?

Кругозор

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

Вы посмотрите на все это будто бы в стратегии реального времени (на каких-то проектах будет как пошаговая).

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

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

Все это расширит кругозор (хотите вы этого или нет). И это достаточно интересно (хоть иногда и неприятно) - смотреть на мир более широко.

Масштаб

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

Так как теперь вы отвечаете уже за продукт и за команду - это задачи уже иного масштаба, более глобального. Частично, эту тему мы затрагивали в минусах, где проговорили, что дофамин от работы получать вы будете от иных задач и побед.

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

Влияние

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

И пусть влияние на проект и сроки не так просто дается (а где-то и вовсе невозможно), но влияние на вашу команду будет и это будет заметно.

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

Ну и скажем честно, статусная составляющая тоже может иметь место Тимлид — это достаточно статусная роль, а для кого‑то статус важнее тех же денег или других бенефитов.

Команда и люди

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

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

Еще одним фактором является то, что так или иначе, но вы влияете на вектор развития людей. Через perfomance review или нет, это не важно. Но видеть как растут и развиваются ваши сотрудники — это тоже один из приятных моментов. Здесь, я думаю, чувство схоже с чувством преподавателя, который видит как его студенты становятся все лучше и сильнее. Тимлид получает удовольствие зачастую от роста своей команды.

При этом, секрет успеха сильной команды — это не просто набрать 'звезд' и посадить в одной комнате. Это подобрать к каждому свой 'ключик', создать условия и возможности такие, чтобы они раскрылись и работали на максимум своих возможностей.

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

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

Зарплата (опять!)

Да, зарплата не такая, как хотелось бы, но чаще всего в рамках одной компании - это единственная ветка для ее роста.

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

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

Уход от кода, но не из разработки

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

А дальше - новые свершения.

Нередки случаи, когда хороший тимлид впоследствии переходил на руководящие должности более высоких грейдов, менял роль на Product Owner-а и так далее.

Это все очень интересно (особенно, если вы устали программировать): продумывать задачи, обсуждать решения, предлагать идеи, но не делать большую часть руками.

Итого

Несмотря на множество спорных моментов, роль тимлида достаточно интересна, насыщенна и полна вызовов. Это не для всех и не всем подойдет, здесь есть очень много проблемных мест и стресса.

Я бы не рекомендовал смотреть в сторону тимлидства людям, которые видят смысл (удовольствие от) работы в коде, в различных технически сложных вызовах, а также людям, которым сложно или тяжело воспринимать конфликтные ситуации.

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

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

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

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

Но помните, что это будет так, если вы будете честны перед собой и четко понимаете свою мотивацию, влияние минусов роли именно на вас и на ваше отношение к работе.

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