Привет, Хабр! Меня зовут Дима Соломонов, я руковожу командой разработчиков продуктового направления в бэкенде Яндекс Диска. 11 лет работаю разработчиком, из них 3 года управляю командами от 3 до 10 человек. Кроме того, 6 лет я преподавал программирование начинающим IT-специалистам и был ментором, поэтому опыт в управлении командой накопился немалый. 

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


Кто такой тимлид 

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

Тимлид — человек, который руководит командой в проекте или продукте. 

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

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

Разберёмся, из какого карьерного трека вырастают тимлиды. Я встречал два варианта: 

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

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

Почему быть тимлидом действительно сложно  

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

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

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

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

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

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

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

  • Отстаивать интересы команды перед стейкхолдерами. Это не только про занятость и проекты, но и, например, про возможность получить повышение для сотрудника или организовать выездной тимбилдинг для команды, сказать «мы эту задачу делать не будем» и так далее.

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

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

Типы тимлидов 

Классификация основана на моем опыте работе с разными командами и руководителями. Посмотрим, какими могут быть тимлиды: 

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

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

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

  • Бизнес-менеджер. Разбирается в методологиях гибкого управления, знает цели бизнеса и может объяснить их каждому. Agile-специалист, scrum-мастер. Погружается в продукт, отлично разбирается в технологиях, выстраивает процессы и помогает, когда команда теряет фокус. Часто непонятно, над каким продуктом он работает, но сроки соблюдаются. 

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

    Совет: Если вы вдруг замечаете, что становитесь чайка-менеджером слишком часто, подумайте — доверяете ли вы своей команде? Почему стремитесь контролировать каждую мелочь? Это основная проблема, с котором нужно справиться, чтобы выстроить комфортные отношения с командой. 

С типами разобрались. Какой же вариант — правильный? 

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

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

Как стать тимлидом?

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

На рисунке изображена пирамида скилов тимлида, как я её представляю. Верхние уровни наиболее значимы, внизу менее приоритетные. Получается такая перевёрнутая пирамида Маслоу для роста тимлида.

Вот такие я выделяю компоненты пирамиды.
Вот такие я выделяю компоненты пирамиды.
  • Изучите основы управления проектами. Освойте гибкие методологии, фреймворки разработки, описания процессов, графический язык для визуализации процессов UML, язык моделирования бизнес-процессов BPMN и другие. Очень советую делать это с разведкой. Например, если вы хотите стать тимлидом в какой-то конкретной компании, изучите описания бизнес-процессов, которые там используются. Не забывайте, что методик много, они разные, поэтому учить стоит какую-то одну, а об остальных знать на поверхностном уровне.

    Полезные материалы: 

    • «Herding Cats: A Primer for Programmers Who Lead Programmers» by J. Hank Rainwater, «Мама, я тимлид! Практические советы по руководству Т-командой» Марина Перескокова — помогут погрузиться в профессию. 

    • «Scrum: The Art of Doing Twice The Work in Hald the Time» by Jeff Sutherland — хорошая книга для понимания суть гибкой разработки.

  • Развивайте навыки коммуникации. Учитесь общаться с коллегами, командой, клиентами. 

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

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

  • Обучайтесь управлению временем. Когда становишься тимлидом, появляется больше встреч и коммуникаций. У кого-то могут возникнуть сложности: одновременные синки, сбитый рабочий график или ощущение, что постоянно ничего не успеваешь.  Мой любимый совет — начните с маленького проекта для управления временем. Возьмите pet-проект, стройку дома или занятие в университете и распланируйте время. Начните его придерживаться, и вы поймете, что задача занимает все отведенные на нее часы.

    Полезные материалы: 

    • «The Deadline: A Novel About Project Management» by Tom DeMarco — интересная книга про управление временем.  

    • «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» Максим Дорофеев — рекомендую послушать аудиоверсию, которую озвучивал сам автор! Это одна из моих любимых книг по содержанию, дает понимание, как строить свою интеллектуальную жизнь и почему иногда мы быстро выдыхаемся.

  • Изучайте методы мотивации. Создавайте благоприятную рабочую атмосферу для команды, признавайте достижения. Проводите встречи 1:1, где человек получит качественную обратную связь. Может быть, даже отрицательную, но иногда она важнее, чем положительная. Умный человек поймёт, насколько трудно рассказать о косяках коллеге, с которым долго работаешь, или своему чаду, которого ты с джуна вырастил до сеньора. 

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

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

А теперь к конкретным шагам

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

Скажите начальству, что хотите стать тимлидом. Не все руководители знают или догадываются о том, что вы что-то хотите. Часто лидера можно увидеть сразу, но если он не расскажет о своём желании, процесс затянется. Рассказать о своих карьерных целях можно на 1:1. Хороший руководитель услышит желание и поможет выстроить трек развития. 

Станьте тимлидом «на замену»: на время отпуска или болезни вашего руководителя. Понятный пункт, отмечу только, что с руководителем важно заранее договориться о такой замене. Скорее всего, он будет рад и спокоен, что с командой всё в порядке.

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

Если вы выросли в тимлида — поздравляю, всё получилось. Далее нужно не пропустить этап самоонбординга, даже если вы продолжаете работать со своей командой. Собрал чек-лист, чтобы не пропустить важные шаги, — пользуйтесь. 

Что делать, если стать тимлидом не получается

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

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

  • Старший разработчик / Senior Software Developer 

  • Менеджер по разработке / Engineering Manager

  • Технический руководитель / Tech Lead 

Если понравилось, но не получилось, возможно, вы что-то не доделали: не подготовились до конца, не прошли самоонбординг, не сделали какие-то предыдущие шаги или просто не сошлись с командой. Не бойтесь продолжать пробовать.

В завершение хочу выделить основные мысли о работе тимлида: 

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

  2. Часто умение вести за собой команду в нужном направлении важнее хардовых скилов. 

  3. Быть тимлидом нужно не всем. Есть много интересных и достаточно высокооплачиваемых профессий, в которых не так важно лидерство и понимание других людей. 

  4. Быть лидом очень интересно. Руководитель влияет на процесс не меньше, а зачастую и больше, чем разработчик.

Расскажите, а вы когда-то хотели или пробовали стать тимлидом? Поделитесь своим опытом в комментариях.

Комментарии (21)


  1. DMGarikk
    22.07.2024 13:57
    +4

    Помните, что вы не выкидываете человека с обрыва, а расстаетесь, потому мэтча с командой или проектом не случилось.

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

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

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

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


    1. gleb_l
      22.07.2024 13:57
      +2

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

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


    1. Araa9977
      22.07.2024 13:57
      +1

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


  1. Batalmv
    22.07.2024 13:57
    +1

    Хорошая статья, но вот это я не понял

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

    Как так то? Поясню

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

    Но лид для меня - как минимум очень сильный разраб, иначе - а на кой он вообще?

    К примеру:

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

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

    Остальное - да, у лида много менеджерских функций, но ...


    1. DmitriySolomonov Автор
      22.07.2024 13:57

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


      1. Batalmv
        22.07.2024 13:57

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

        Еще один пример - технический дизайн. Кто?


        1. vlaubenshtein
          22.07.2024 13:57

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


          1. DMGarikk
            22.07.2024 13:57

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

            и да и нет одновременно

            мне тут досталось четыре проекта которые несколько лет делал человек с таким подходом....я конечно преклоняюсь перед такими людьми он реально сделал титаническую работу, с нуля писал и поддерживал четые проекта такого масштаба что там нужно было как минимум двое на каждый.... но там блин такое....иногда гляжу в этот код и одна мысль "зощто!!?? почемуу?? зачем так??" там блин такая дичь попадается что уши в трубочку заворачиваются...человек видимо в рамках саморазвития умудрился наваять собственный оркестратор докера в рамках проекта по моделированию производства....тысячи строк кода управления контейнерами, пререзапуска, ha, управлению сетями....*опа какаято...сотни человекочасов в помойку...


  1. inzagher
    22.07.2024 13:57

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


    1. vlaubenshtein
      22.07.2024 13:57

      Я считаю, это оправдано. Тем более, если ты сам не специалист, а именно менеджер. За что тебе платить больше синьора ? Если ты не принимаешь каких-то весомых решений, которые влияют на ключевые метрики. Time to market, ФОТ, прибыль и многие другие.


      1. DMGarikk
        22.07.2024 13:57

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

        вообще это опять чтоли вечная история что начальство не нужно и рядовые работяги сами все сделают?


        1. vlaubenshtein
          22.07.2024 13:57

          Начальство нужно, но хорошее )


    1. DMGarikk
      22.07.2024 13:57

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


  1. duke_alba
    22.07.2024 13:57

    По мне - тимлид, это самая тяжёлая ступенька в карьерном росте. Прошёл это дважды, и больше не хочу!


    1. vlaubenshtein
      22.07.2024 13:57

      Кто там дальше по карьерной лестнице ?


      1. DMGarikk
        22.07.2024 13:57

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


      1. duke_alba
        22.07.2024 13:57

        Это куда пойти. Или дальше в управленцы, или в архитекторы/идеологи.


  1. vlaubenshtein
    22.07.2024 13:57

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


  1. fixik_21
    22.07.2024 13:57

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


  1. bobnatural
    22.07.2024 13:57

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


  1. DestOny
    22.07.2024 13:57

    Я бы был лучшим увольняющим тимлидом. Вообще не понимаю в чем проблема подобрать слова типа давай останемся друзьями до свидания.

    Повезло вам, что мне вообще не интересно управлять командами. А променять монотонную писанину уютную с чашкой чая/кофе/водой на делегирование и распределение задач... Я пришел интровертить в IT, а не управлять там кем-то.

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

    Путь евангелиста или архитектора - наше всё.