- Teamlead: Pros and Cons
- Введение
- Минусы
- Потеря хард-скиллов
- Играющий тренер как сидение на двух стульях
- Размытая зона ответственности и возможностей
- Сложность в смене работы
- Деньги и карьера - не то, что вы себе представляете
- Удовольствие от работы - не быстрый процесс
- Тяжелая работа с людьми
- Бесконечные созвоны
- Нет времени на рефлексию
- Интриги и дипломатия
- Свой среди чужих, чужой среди своих
- Синдром самозванца
- Итого про минусы
- Плюсы
- Итого
- Полезные ссылки
- Отдельные благодарности
Кому будет интересно/полезно прочесть данный текст? Человеку, который может дать утвердительный ответ на вопрос: хочу ли я стать тимлидом? Также это будет полезно тем людям, кто только начинает свой путь по этой стезе и лишь недавно стал тимлидом команды.
Здесь мы постараемся дать честный ответ на плюсы и минусы работы тимлидом, что ждет в ближайшем будущем вас, на что стоит обратить внимание и как потом не пожалеть о сделанном выборе.
При этом, я понимаю, что проекты и команды бывают разные, однако, я попытался усреднить и дать оценку именно некоторой абстрактной роли тимлида, той самой, о которой плюс-минус представляют, когда слышат это слово.
Во время написания статьи я опирался на большое количество материалов, список и ссылки на них я привожу в конце. Также я старался мысли и рассуждения не транслировать только как свои - а обсуждать их с другими людьми, как из этой роли, так и из других ролей. Список благодарностей я также привожу снизу.
Ну что ж, приступим.
В данном разделе я постарался собрать как свой негативный опыт, разочарования или неожиданности, так и чужой - посредством чтения материалов, конференций, общения с людьми разного грейдового состава, при этом я старался слушать не только одну сторону (тимлидов, руководителей), но и другую - членов различных команд из широкого круга предметных областей (а значит и проектов).
Одно из первых, что необходимо упомянуть - это постепенное или даже стремительное ощущение потери хард-скилла.
Происходит это потому, что если программист практически полностью нацелен на код, то тимлид распыляется на множество вещей - будь то one-to-one, планирование, процессы и так далее.
Из-за большого количества отвлекающих факторов (встречи, проблемы членов команды, инциденты, интеграции) вы будете все время переключаться между задачами. Это похоже на то, как одно ядро пытается работать с множеством потоков!
Так вот у человека такое переключение достаточно сильно влияет на фокус, что в последствии негативно сказывается на вашем навыке программирования, где глубокая фокусировка является пусть не достаточным, но необходимым фактором успеха.
В дополнении к выше сказанному, будет страдать еще и прогнозируемость завершения задачи. Вас чаще будут отвлекать (и не всегда предсказуемо), следовательно, прогноз по завершению задачи давать будет сложно. Добавим сюда еще и то, что может быть ситуация, в которой вы некоторую фичу завершили, передали в тестирование, но там был обнаружен дефект и задача возвращается на доработку/исправление. А вы уже не можете физически взять ее в работу - вы уже заняты на планировании следующего спринта, бюджетах и так далее.
Это приводит к тому, что средне-большие/большие задачи или сложные случаи багов брать не получится. Все чаще вы будете либо отказываться от идей брать фичи в работу, либо будете брать небольшие/не критичные задачи.
Конечно, можно учиться вечерами, проходить курсы, писать пет-проекты, но в таком случае будет страдать личная жизнь, хобби и прочая иная составляющая жизни, ведь времени уже не останется. Да и это, будем честны, не совсем про развитие хард-скиллов и глубину, скорее про поддержание себя в форме.
Мой личный опыт говорит о том, что навык программирования не утрачивается полностью (сказывается и то, что я стараюсь практиковаться), однако скорость и качество разработки падает, часто (особенно на простых вещах) хочется делегировать это другому. Мозг тоже часто отвлекается, ибо привык работать в ином режиме. Отсюда нужна постоянная практика и тренировки, иначе будет сложно.
Итого: надо понимать, что по части хард-скиллов скорее всего будет неизбежная просадка. Уровень этой просадки зависит от множества факторов и этот процесс можно замедлить. Однако, надо заранее готовиться к таким вещам, возможно учитывать в планировании на себя некоторые мини-таски, возможно, не критичный функционал без горящих сроков брать.
Ну и первая важная метрика: если вы очень любите писать код, то, возможно, эта ветка развития, эта роль - не для вас.
Если говорить о классической корпоративной разработке, то у тимлида будет множество задач по администрированию, коммуникациям с другими командами, мотивации собственной, планированию и так далее.
В результате, как мы отметили в пункте про хард-скиллы, на написание кода остаётся не так много времени, как иногда хотелось бы.
Но компании часто стараются экономить и считают тимлида еще одной качественной единицей в разработке, на уровне ведущего программиста (те самые М+ или Senior), зачастую такое совмещение обязанностей называется 'играющий тренер'.
А такое переключение между ролями (программист - менеджер) на самом деле не легко дается, что иногда выражается так: начал день с менеджерских задач и к их окончанию уже не способен программировать, голова не может переключиться, и в этот день может быть такое, что ни строчки кода уже не напишешь.
Это выливается в потенциальные переработки и стресс из-за сроков, страдает планирование как стратегическое, так и кратковременное из-за замыленности - вам кажется, что осталось чуть-чуть, а на деле после всех переключений приходится заново вникать в уже почти написанную задачу, а это часто тяжелее, чем сделать сразу 'с нуля'.
Итого: быть играющим тренером возможно (и я бы сказал - даже неплохо!), но необходимо четко понимать, что это не основная ваша работа и критические участки брать нельзя. Вы должны аккуратно понять рамки и выделить ту грань, где вы можете помочь в разработке, а где уже начнете мешать.
Если взять две разные компании, то почти наверняка окажется, что обязанности тимлидов в них существенно различаются.
Где-то будет упор на 'людей', где-то наоборот минимальное ваше вовлечение в это. Где-то вы будете 'играющим' тренером, а где-то вообще почти не будете писать код. Во многих компаниях вы вообще будете совмещать роль технического лидера и менеджера.
По сути своей вы отвечаете за результат и за качество проекта, команды. Однако, метрики качества крайне размыты или вовсе не сформулированы. При этом, что самое неприятное, у вас не всегда будут понятные и доступные рычаги влияния (найм, приоритеты бэклога, да даже выбор стека или увольнения не всегда могут быть под вашим контролем).
Также команду часто собирает не тимлид, а именно организация. Не всегда вы можете (да будем честны - почти никогда) собрать именно команду 'под себя': здесь мешает и долгий найм, подбор, а времени обычно уже нет, плюс зачастую внутри компании рекомендуют людей, которые выходят из других команд и вы используете этот ресурс.
Вообще, скорее всего будет что-то такое: надо сделать хорошо, потому что плохо не надо. Вот команда (нам кажется, этого достаточно, мы уверены), все молодцы, как на подбор, и мы немного торопимся по срокам. Если нужны ресурсы еще, то это надо вам как-то доказать, как - это тоже вам надо узнать.
При этом ответственность будет на вас, как на лидере. Ведь в итоге от вас будут требовать достижения бизнес-целей, а, как выше описано, возможности влиять на эти цели или команду не всегда будут доступны или банально сразу понятны.
Нередки случаи, когда вы будете 'затыкать' собой сложные места. Как результат — частый стресс и ощущение неопределённости, особенно на первых порах.
Часто из-за загруженности бывают ситуации, что вы поздно обедаете или вовсе не получается нормально поесть.
Итого: размытая область ответственности подразумевает, что необходимо быстро адаптироваться к новым требованиям, срокам и понимать свои возможности. Уметь стратегически мыслить. Так или иначе, но необходимо будет хорошо вникнуть в процессы компании, а где-то даже в интриги! Ну и уметь делегировать! И обязательно ставьте фейк-встречу, во время которой вы нормально пообедаете.
Не секрет, что вакансий тимлида или руководителя разработки в разы меньше, чем вакансий разработчика (мы рассматриваем именно ведущие вакансии разработки). Из-за размытости зоны ответственности вакансии могут сильно отличаться по требованиям и обязанностям, что сужает воронку поиска.
Однако, это не самое страшное, сложнее дело обстоит именно в части собеседований.
Собеседование на такие позиции, как тимлид, всегда включает в себя несколько этапов, в числе которых присутствует как секция менеджмента, так и техническая.
И в технической секции вас будут оценивать по хард-скиллам, а проходной балл будет не ниже М+ или Senior.
В совокупности с прошлым пунктом мы уже сейчас можем заметить явную проблему: человек, проработавший тимлидом два-три года скорее всего испытает трудности. Этот нюанс даже упоминался в утёкших методичках Яндекса, где рекомендовалось не рассматривать кандидатов-тимлидов на позиции разработчиков уровня Senior.
Еще одной проблемой в рамках смены работы может стать то, что работая в компании на стыке разработки и менеджмента (а именно там вы и окажетесь), вы станете все больше 'прирастать' к компании и ее процессам, станете менее гибкими (часть команды - часть корабля).
Например, тимлид из 'банковской' сферы скорее всего привык к более долгому найму, к большим и развесистым 'матрицам' компетенций, специфической работе с безопасниками, нескольким контурам эксплуатации и заявкам на них (все эти ЗНИ, ИФТ, ПСИ и ТУЗ-ы из Сбера). И придя в иную сферу ему будет непривычно, потребуется время на адаптацию. То же работает и наборот, когда приходят в такие компании из небольших или средних. И вот к этим ТУЗ-ам действительно прирастаешь и уже требуется время, чтобы понять и принять тот факт, что между тобой и ПРОД-ом не 4 контура стоит со своими заявками.
Положа руку на сердце - эта проблема есть и среди разработчиков, например, вы прирастаете к специфическим решениям в компании (читай - собственным 'велосипедам'), к типу задач и так далее. Но эта проблема в разработке менее остра, по той причине, что опыт в разработке с собственными решениями все же более релевантен, нежели со специфическими процессами (привет, ЗНИ!).
Еще одной сложностью при смене работы является вход в команду. Вам предстоит более сложный онбординг, так как помимо технической составляющей, придется выстраивать еще и как горизонтальные, так и вертикальные связи.
В это время могут возникать конфликты, столкновения культур и так далее. И бывают случаи, когда нанятый тимлид не может найти общий язык с командой, при том, что все остальные факторы складываются удачно.
Частично по этой причине тимлидов предпочитают 'выращивать' внутри компании, а не нанимать с рынка.
Итого: процесс смены работы для тимлида происходит болезненнее и сложнее, нежели для разработчика.
Необходимо поддерживать как хард-скиллы, так и софт-скиллы, при этом спрашивать c вас будут также как и с разработчика. Важно постоянно поддерживать свою гибкость в плане административных и управленческих навыков, в процессах, иначе велик шанс сужения и так не самой широкой воронки вакансий.
На самом деле, процесс найма и собеседований вообще больная тема, потому что будем честны - не всегда есть корреляция между тем, что спрашивают и тем с чем надо работать, реальными задачами.
Поэтому зная о проблеме и понимая ее, подходя к смене работы как правильно: что это именно прохождение собеседований, а значит и подготовка должна быть соответствующей (литкоды, вопросы, мок собесеседования).
Тимлидство редко приносит значительное увеличение зарплаты по сравнению с позицией ведущего разработчика.
Чаще всего эта разница не составляет даже и 15-20%. Добавьте сюда то, что смена работы - это для вас крайне болезненный процесс, в отличие от позиций разработчика (а зачастую значительные прибавки к зарплате связаны со сменой места работы).
Это не значит, что у вас нет шансов увеличить свои зарплатные ожидания, однако сделать это станет чуть сложнее.
Осложняет все и то, что не во всех компаниях существует плавный рост после тимлида: где-то не существует позиции юнит-лидов (или лида лидов), где-то нет выделенных архитекторов, CTO, многие верхнеуровневые позиции заняты и не планируют освобождаться, а горизонтального роста компании не хватает.
Получается, что иногда дальнейшего роста не предусмотрено, эта следующая ступенька зачастую отсутствует. Вы остаётесь линейным менеджером среднего уровня, который начал хуже писать код. И с кратно возсросшим уровнем ответственности и стресса.
Отсюда зачастую рост происходит либо в другие роли (например, Product Owner), либо горизонтальный (Technical Leader).
Итого: не стоит ожидать 'золотых' гор и резкого перехода в CTO. Карьерная составляющая присутствует, но может быть реализована через переход на другую роль, либо горизонтальным ростом.
Не все компании имеют плавные процессы для этого роста, поэтому заранее надо четко понимать границы, после которых ваш рост замедлится, а также амбиции, которые вы хотите реализовать. И, возможно, для этого потребуется сменить роль или компанию.
Разработчик может получать удовольствие от работы по разному, например, когда видит, что функционал, который он реализовал востребован, кто-то получает дофамин от красиво написанного кода или, в конце концов, зеленых тестов!
Моментов радости или получения позитивных эмоций достаточно много и они происходят часто. Чего часто нельзя сказать о тимлиде.
Тимлид реже получает позитивные эмоции, так как события, которые их дарят, происходят реже и эти события иного рода.
Чаще всего вы радуетесь, когда план сошелся и фича реализована во время, внедрение прошло без проблем, после чего вас что-то отвлекает и вы уже забываете эту радость, так как погружаетесь в новую проблему.
Грубо говоря, позитивные события - это в основном более глобальные события, а значит и происходят реже.
Как сказал один мой друг: тимлидство можно сравнить с марафоном. Это длинная дистанция, которую не все могут осилить и если ты не добежишь до конца (даже 100 метров), то удовольствия уже не получишь. Ну и надо уметь открывать у себя второе дыхание.
Важно отметить также то, что так или иначе, но вы будете вынуждены решать конфликты и участвовать в них: как внутри вашей команды, так и с внешними. Решенный конфликт редко вызывает чувство удовлетворения или радости, это скорее еще одна метрика (почему он возник, как это повлияет на вашу команду и так далее),которую надо проанализировать.
Однако, из-за более масштабных событий и чувство удовлетворения будет большим. Хорошо выстроенный, работающий процесс приносит не меньше удовольствия, чем внедренная фича, а иногда и больше.
Итого: вопреки многим комментариями в интернете, удовлетворение от работы вполне имеет место быть, однако оно немного другого формата и, возможно, испытывается не так часто. К этому надо быть готовым: если вы привыкли к частым 'радостным' событиям, то сейчас ситуация может измениться.
В целом, из самого названия роли, понятно, что работа предстоит с людьми. Однако, зачастую мало кто предполагает насколько это большая часть работы и насколько бывают разные люди.
Конфликты - это неизбежная часть взаимодействия людей друг с другом. При этом конфликты бывают как на уровне команды, так и выше. Из-за того, что тимлид - это по сути как точка входа, так и точка выхода в команду, вы оказываетесь в водовороте огромного количества людей и цепочек их взаимодействий. Не все люди будут вам приятны, не все из них будут компетентны или даже, прошу прощения, адекватны.
Все это рождает дополнительный стресс.
Итого: работа с людьми, конфликтными ситуациями и мотивацией станет неотъемлемой частью вашего дня. К этому надо себя подготовить, уметь и учиться решать конфликты, понимать мотивацию как свою, так и команды.
Если вы тяжело переживаете конфликты, то подумайте о смене роли еще раз.
Ну и вишенкой на торте нельзя не упомянуть бесконечные созвоны. Зачастую абсолютно бесполезные или сумбурные, неожиданные. Бывает также и такое, что вы понимаете, что на этой встрече вы вообще не нужны и после часа-другого простого 'сидения' на созвоне единственное, что вы говорите - это 'до свидания, коллеги' или 'всем пока'.
Это в свою очередь рождает ощущение, что тратишь время в пустую и ничего полезного не делаешь.
Итого: большое количество встреч (на многих из которых вы вообще не нужны) может как отнимать дорогое время, так и стать разочарованием в рабочем дне. Необходимо грамотно распоряжаться временем, воспитывать самостоятельность в принятии решений у сотрудников и уметь говорить 'нет'.
Несмотря на то, что работа в роли тимлида подразумевает как низкоуровневое, так и верхнеуровневое планирование, аудит процессов и так далее, этого зачастую не случается. Текучка проблем и встреч отнимает силы, фокус и время.
Выливается это в то, что вы выныриваете из созвонов и необходимо принять решение, о котором у вас просто не было достаточно времени подумать.
Из-за подобного часто копится стресс, потому что вы даже после работы можете думать - а верно ли вы вообще решили то? Также это является одной из причин, почему 'замыливается' взгляд на существующие процессы и проблемы.
Итого: Здесь может помочь только дисциплина и выстроенная команда с процессами, которые будут позволять проще принимать решения. Выделяйте себе 'золой час' на рефлексию.
Работа с людьми - это всегда дипломатия. Участие в разработке с несколькими смежными командами, и, не дай бог, вендором - это еще и интриги.
Почему так получается?
Потому что это пересечение областей, ответственности, рисков и влияния. И в такой среде зачастую (пусть и не всегда) происходит как раз перетягивание одеяла на себя, война за бюджеты (каждый хочет свой кусок и побольше), перекладка ответственности за штрафы по срокам и так далее.
Тут все как в сериалах про жизнь!
И так или иначе, но вам придется в этом участвовать. Кому-то чуть меньше, ну а кому-то побольше (ну а кто-то вообще войдет во вкус!).
И иногда это достаточно грязно, некрасиво и подло бывает.
Итого: Надо быть готовым, что хоть и не везде, хоть и не всегда, но во многих организациях вы будете участвовать в интригах, выбирать сторону и не всегда эта сторона будет победителем (ну а в вашей карьерной лестнице в таком случае будут лишние пролеты).
Вы еще не менеджер, тем более не С‑левел. Но вы уже не разработчик. У команды уже есть чатик без руководителя (то есть без вас), и они любят там общаться. Сломать этот барьер весьма сложно, и не всегда понятно, стоит ли. А если вы можете влиять на KPI, а следовательно — зарплату и премию, вы уже никогда не будете своим, и это будет чувствоваться.
Часто также встречается ситуация, когда копится тревога из-за того, что сложно быстро ответить на вопрос "что я сделал сегодня". Вроде было много дел, везде по чуть-чуть подключался, но чувства завершенности нет.
Также бывает накапливается ощущение, что вы не компетентны, ничего не делаете или то, что вы делаете не так уж и важно - ну типичный синдром самозванца.
Особенно на фоне того, что вы теряете в хард-скиллах, а результата или отдачи от тимлидства еще нет.
Итого: синдром самозванца частая история, особенно у начинающих. Бороться с ним может обратная связь от коллег, непосредственного руководителя и результат, который так или иначе придет, если стараться.
Минусы есть в любой работе и я постарался описать без приукрас то, с чем вы так или иначе, но столкнетесь.
Если для вас в работе одним из важнейших факторов является работа с кодовой базой, какая-то ее техническая часть (например, именно тестирование или эксплуатация) лучше подумать дважды о том, чтобы переходить в роль тимлида.
Также, если вы крайне тяжело переносите работу с людьми, которые вам не нравятся (по какой-то причине), тяжело переживаете конфликтные ситуации (или вообще избегаете их всеми способами) - это является дополнительным камнем в огород вашего перехода в тимлидство.
Еще одной метрикой 'против' явялется то, что вы сложно переносите размытость задач, стресс и 'бесполезных' дней, когда кажется, что день прошел 'за разговорами'.
На своем опыте я часто замечал интересный момент: есть еще так называемые 'неформальные лиды'.
Это люди, которым дали значок тимлида или лидера в какой-то области, но по факту они продолжают выполнять ту же работу, что и раньше с дополнительной ответственность. При этом зарплата если и повышается, то совсем символически. Полномочий, чтобы реально управлять командой или принимать стратегические решения, не дается (ну и официального назначения нет, все неформально). Получается, что такой человек вроде бы 'лид', но на деле — это разработчик с дополнительной нагрузкой и громким титулом, который обязывает отчитываться перед уже официальным лидом за просроченные сроки, ошибки в планировании и так далее.
При этом таких людей часто отвлекают на дополнительные созвоны, зовут на согласование сроков планирования и так далее.
Вот подобный пример может дать хороший взгляд на именно минусы в работе тимлидом.
Однако, со всеми перечисленными минусами можно работать и если не полностью нивелировать их, то как минимум купировать часть из списка.
Об этом мы поговорим чуть позднее. И все не так ужасно, как можно подумать, поэтому давайте перейдем к плюсам!
В данном разделе мы попробуем рассмотреть именно плюсы и положительные стороны в работе тимлида. Точно также как и в прошлом, я постарался собрать как свои впечатления, так и чужие.
Ну и раз мы так сгуститли краски, то давайте их разбавим?
Из-за того, что вы теперь смотрите на проект и продукт не только с точки зрения кода, вы расширяете свой кругозор. Теперь проект - это не просто кодовая база и зеленые тесты, а огромное количество составляющих: это и цена разработки, и эксплуатация, и потеря клиентов как из-за багов, так и из-за долгой разработки. С другой стороны - это и приобретение клиентов посредством частично ваших решений и где-то трейд-оффов.
Вы посмотрите на все это будто бы в стратегии реального времени (на каких-то проектах будет как пошаговая).
Придется так или иначе взглянуть на все составляющие разработки и как они строятся: тестирование, эксплуатация, документация (как внутренняя, так и внешняя). И каждая область - это действительно свой мир, со своими правилами, своими метриками и проблемами.
Сюда же можно отнести и стратегическое видение, которое так или иначе нужно будет развивать. Необходимо будет учиться работать со сроками, предсказывать выходы (и входы) в команду/из команды, придет понимание бизнес процессов как своего, так и смежного направлений - это как шахматы (или игра в кальмара).
Все это расширит кругозор (хотите вы этого или нет). И это достаточно интересно (хоть иногда и неприятно) - смотреть на мир более широко.
Например, когда я стал тимлидом, мне пришлось базово разобраться еще и во фронтенде. После этого в тестировании и автотестах, а далее и в DevOps. Пришлось в какое-то время даже с ЦОД-ом работать и делать его аудит!
И да, я, наверное, стал хуже как практик в коде, но сейчас я смотрю на все гораздо шире, банально, но при проектировании систем на собеседовании первая мысль - это про бюджет и эксплуатацию!
Как бы кто и что не говорил, но тимлидство - это иной масштаб задач. И от этого масштаба можно (и часто так и есть) получать удовольствие.
Так как теперь вы отвечаете уже за продукт и за команду - это задачи уже иного масштаба, более глобального. Частично, эту тему мы затрагивали в минусах, где проговорили, что дофамин от работы получать вы будете от иных задач и побед.
Масштаб подразумевает под собой не один сервис или кодовую базу, а уже весь цикл разработки, в котором вполне может получиться внедрить и иные практики разработки (причем в разные области), и ощущение все таки более серьезных решений (обратная сторона этого - это стресс).
Мое наблюдение показывает, что в какой-то момент многим людям уже не получается радоваться своим повседневным успехам, нужно увеличение как масштаба, так и сложности. Это как раз та самая история.
Не будем лукавить и кривить душой: есть люди, которым нравится управление и работа с людьми. Когда вы понимаете, что за вами стоит крепкая команда, уважение (а это тоже важная составляющая) коллег и знакомых.
И пусть влияние на проект и сроки не так просто дается (а где-то и вовсе невозможно), но влияние на вашу команду будет и это будет заметно.
В целом, лидер команды - это лицо команды. И во многом от вас зависит как это лицо выглядит в глазах других, а также как ваша команда функционирует. Вот это влияние - оно для многих людей является действительно большим плюсом.
Ну и скажем честно, статусная составляющая тоже может иметь место. Тимлид - это достаточно статусная роль, а для кого-то статус важнее тех же денег или других бенефитов.
Если получится собрать сильную команду, то удовольствие от работы вы будете получать от слаженности и четкости разработки.
Каждый тимлид хочет собрать команду, с которой и море по колено, но не всем это удается. Но если удается хотя бы часть из задуманного - вы будете иметь возможность наблюдать работу слаженного механизма (до первой поломки), а это действительно приятно.
Еще одним фактором является то, что так или иначе, но вы влияете на вектор развития людей. Через perfomance review или нет, это не важно. Но видеть как растут и развиваются ваши сотрудники - это тоже один из приятных моментов. Здесь, я думаю, чувство схоже с чувством преподавателя, который видит как его студенты становятся все лучше и сильнее. Тимлид получает удовольствие зачастую от роста своей команды.
При этом, секрет успеха сильной команды - это не просто набрать 'звезд' и посадить в одной комнате. Это подобрать к каждому свой 'ключик', создать условия и возможности такие, чтобы они раскрылись и работали на максимум своих возможностей.
Действительно сильные эмоции ощущаешь, когда удается 'спасти' человека: например, его хотели увольнять, были недовольны, но появляетесь вы (и ваша работа) и ситуация меняется настолько, что человека даже повышают.
В целом, каждый тимлид за свою карьеру так или иначе точно может сказать, что повлиял на вектор развития хотя бы нескольких людей.
Да, зарплата не такая, как хотелось бы, но чаще всего в рамках одной компании - это единственная ветка для ее роста.
Часто, ведущий разработчик 'упирается' в потолок по зарплате и уже почти не растет, во многих компаниях технические задачи не настолько сложны, чтобы 'пробивать' этот потолок средней зарплаты по рынку уникальной экспертизой.
И получается, что простой и понятный рост по зарплате (пусть и не сопоставимый, на мой взгляд, по уровню стресса и возросшей ответственнсости) ждет именно по этому пути. Ну или идти на вторую работу по совместительству (что для большинства тяжело как физически, так иногда и в моральном плане).
Достаточно часто ведущие разработчики через много лет разработки уже 'устают' от кода и хочется чего-то нового. И вот тимлидство - это один из вариантов (ну и одна из ступеней). При этом вы не настолько далеко уходите от разработки - вы точно также остаетесь с кодовой базой на 'ты', можете влиять на решения как технические, так и иногда бизнесовые.
А дальше - новые свершения.
Нередки случаи, когда хороший тимлид впоследствии переходил на руководящие должности более высоких грейдов, менял роль на Product Owner-а и так далее.
Это все очень интересно (особенно, если вы устали программировать): продумывать задачи, обсуждать решения, предлагать идеи, но не делать большую часть руками.
Да, не везде будет гладко, но зачастую ступенька тимлида - это необходимая роль перед переходом в более высокий менеджмент.
Здесь так или иначе придется развивать навыки, которые ранее вы либо не замечали, либо не акцентировали на них внимание. Это и найм, и взаимодействия с людьми, и стратегическое планирование, работа с рисками (особенно непредсказуемыми).
Сюда же можно записать и работу с заказчиками, взаимодействие с смежными командами, продактами и так далее.
Все это всесторонне развивает и позволяет начать мыслить по другому (наверняка же вы отмечали, что 'не технари' немного не такие?).
А без этого путь до следующих ступеней менеджмента еще более тернист и сложен (если вообще возможен).
Несмотря на множество спорных моментов, роль тимлида достаточно интересна, насыщенна и полна вызовов. Это не для всех и не всем подойдет, здесь есть очень много проблемных мест и стресса.
Я бы не рекомендовал смотреть в сторону тимлидства людям, которые видят смысл (удовольствие от) работы в коде, в различных технически сложных вызовах, а также людям, которым сложно или тяжело воспринимать конфликтные ситуации.
Это не рост 'из разработчика', это переход в совершенно иную роль со всеми вытекающими плюсами и минусами.
В этой роли очень важно понимать свою мотивацию, во время реагировать на проблемы и подводные камни, которые будут встречаться. В противном случае, вас ждет разочарование и выгорание в той или иной степени.
Если постараться привести аналогию, то эту роль можно сравнить с футбольным тренером. Вы отвечаете за результат, но часто бюджет ограничен советом правления клуба. Не всегда 'звезды' приносят результат, а иногда и молодой игрок делает разницу, но нужно всегда искать баланс между опытом и молодостью.
Надо уметь делегировать задачи, мотивировать, не все матчи будут выиграны и иногда будут обидные проигрыши, после которых будет казаться, что зря вы вообще выбрали эту работу. Но оглядываясь назад, после многих матчей, после многих людей в кого вы 'вдохнули' жизнь, после всего, вы поймете - это было не зря.
Но помните, что это будет так, если вы будете честны перед собой и четко понимаете свою мотивацию, влияние минусов роли именно на вас и на ваше отношение к работе.
В противном случае, можно действительно пожалеть о своем выборе и понять, что на самом деле все самое интересное для вас было именно в другом.
Важно понимать, что любая роль и работа имеет свои плюсы и минусы, в роли тимлида вас ждут иные вызовы, не менее интересные. Просто другие.
И минусы описаны здесь не для того, чтобы запугать, а для того, чтобы предупредить. Это как с сидячей работой, где вы понимаете риски - это набор веса, заболевания с этим связанные. И вы не бросаете с ужасом эту работу, вы просто вводите профилактику: зал, бассейн, чаще вставать и так далее.
Тимлид - крайне важная и ответственная роль. Эта роль так или иначе, но оказывает влияние на проект, бизнес и команду, людей.
Ну и напоследок: даже если у вас не получится, то в этом нет ничего стыдного. Лучше попробовать и посмотреть что будет, нежели провести кучу времени в сомнениях и метаниях, боясь неудачи. Пробуйте и дерзайте!
- Теперь я - тимлид, но почему мне так плохо? Практические советы / Евгений Кот (Wrike)
- Habr. 7 причин не становиться тимлидом
- Habr. Не нужно становиться тимлидом
- Какие задачи у тимлида? Стоит ли идти в тимлиды ради зарплаты / Евгений Антонов, Тимлид очевидность
- Гайд начинающего тимлида
- Teamlead Roadmap
- Habr. Нужны ли тимлиды?
- Habr. Неочевидные минусы позиции тимлида
- Hexlet. Ответственность за команду, много созвонов и мало кода: всем ли надо быть тимлидами?
- Канал Тимлид Очевидность
- Habr. Неочевидные минусы позиции тимлида
За обсуждение и споры!
- Владимир Долженко @dolzhenko
- Валере
- Sergey Petrelevich
- Denis Pimenov
- Viktor Koreysha
- Telegram канал Тимлид Очевидность
- Многие другие, кого я не знаю как тегнуть!