Что такое быть Team Leader

Всем привет! Меня зовут Артур Дементьев, я бы хотел поделиться личным опытом и написать несколько статей о том, что из себя представляет менеджмент в IT. А также рассказать о том, на какие грабли наступал и каких ошибок можно было избежать. Все статьи я буду писать, основываясь на своём опыте работы в разных IT-компаниях, в которых я начинал как Team Leader (TL) команды из нескольких человек. В одной из них с нуля вырастил маленький отдел в большую IT-структуру и дорос до CTO.

Проблемы есть во многих компаниях, часто люди допускают ошибки. Именно общение с ними сподвигло меня на написание статьи. В ближайшем времени, я постараюсь продолжить публикации. Надеюсь, они будут полезны TL, CTO, руководителям департаментов или тем, кто только собирается ими стать. А начну я с рассказа о том, что такое быть Team Leader, это будет взгляд изнутри.

Тут сразу стоит сделать отступление. Есть разные компании:

  • крупные, где обычно IT — основной профиль деятельности. В иерархии есть CTO, Tech Leader, Team Leader, Architects, Project Manager, Analyst. В таких условиях TL возможно не выполняет некоторых функций, которые я буду описывать ниже;
  • бизнесы, где лишь часть компании завязана на IT. Там структура в половину проще первого варианта;
  • небольшие фирмы с маленьким IT-отделом из нескольких человек (в моём случае нас было трое). Там просто не на кого переложить все обязанности. Иногда стоит задача вырастить такую контору в компанию из первого пункта списка.

Таким образом, объём и спектр обязанностей TL во многом зависит от размера компании или IT-отдела. Чем крупнее компания и сложнее структура IT в ней, тем меньше обязанностей у TL.

Как становятся Team Leader


Есть два стандартных пути к позиции TL:

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

image

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

Перемены в деятельности


Итак, что нового появится в вашей жизни с того момента, как вы превратились из разработчика в TL? Несомненно, вы будете больше участвовать в обсуждениях и присутствовать на совещаниях. Зато вы сможете не тратить время на рутинные задачи, а делегировать их коллегам. Также придётся больше заниматься code review. Возможно на вас упадут договора и выставления счетов в бухгалтерию. Вроде бы жизнь удалась, и вы добились цели.

image

Но эйфория проходит довольно быстро, и вы практически начинаете гореть. Происходит примерно следующее: поток задач нескончаем, их надо решать или делегировать, следить, что пишет команда. Надоедливые менеджеры всё время что-то хотят и постоянно зовут на совещания. «Им заняться что ли больше нечем?» — думаете вы. Начальство же жмёт со сроками, а из команды внезапно ушёл человек, и искать замену вам. Ещё и жена звонит. В общем, вы становитесь раздражительным и близки к перегоранию. В таком режиме реально прожить максимум год.

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

Что надо понять


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

  • Вам платят деньги не за то, что вы пишите код. Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше. Ваша основная задача — создать такие условия, чтобы команда была наиболее эффективна. Программист должен писать код, а всё остальное — ваши заботы.
  • Теперь ваши коллеги пишут код лучше вас. Пройдёт полгода-год, и отсутствие практики скажется на ваших способностях. Ведь они это делают практически всё рабочее время, а вы от случая к случаю или дома по вечерам.
  • Перестаньте людей равнять на себя. Человек так устроен, что думает, что лучше него решить задачу никто не сможет. Во-первых, это не всегда так, а во-вторых, если вы будете тратить время на решение всех задач, потому что думаете, что люди не справятся, это уже не TL. Доверяйте людям.
  • Ваши главные показатели эффективности — качество всего проекта и время разработки. Здесь, пожалуй, главную роль играют ваши навыки коммуникабельности. Что-то надо делать качественно и долго, а иной раз целесообразнее быстрое решение. Сложность состоит в том, что вы должны донести это до программиста и убедить его сделать, как нужно в этот момент. А не через 2 дня обнаружить, что он только на середине, а готовое решение нужно сейчас.
  • Мотивируйте людей. Придумайте систему мотиваций, чтобы всем хотелось лучше работать. Выдать премии, если не было аврала? Нет, это ерунда. Внедряйте метрики, собирайте статистику, оценивайте работу людей. Также следите за профессиональным ростом сотрудников, кто как развивается. Всегда держите руку на пульсе.
  • Вам нужно нанимать людей. Хорошо, если у вас есть отдел кадров, который умеет нанимать IT-специалистов. Если нет — у вас появились дополнительные обязанности. Учитесь составлять вакансии, отбирать специалистов, проводить собеседования, увольнять. И если у вас не стартап с космическими инвестициями, готовьтесь находить людей в бюджете ниже рынка. Возможно даже придётся самому обзванивать кандидатов.
  • Вы отвечаете за весь проект. Если ваш сервис вдруг упал надолго или его невозможно восстановить, потому что нет бэкапов, перед руководством всегда будете виноваты вы. Работоспособность проекта в техническом плане — ваша обязанность.
  • Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.
  • Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.
  • Вы должны уметь подменять любого члена команды. Если кто-то заболел, ушёл в отпуск или уволился, и процесс разработки остановился, вся ответственность ложится на вас. Будьте готовы к этому всегда.
  • Психологический аспект. Вам необходимо общаться с командой и понимать людей, знать, какие у них могут быть проблемы, и даже помогать решать их. Большая часть программистов — интроверты, вы должны пытаться выяснять, что их не устраивает или мешает на работе. Конечно, большинство и не скажет этого, вам надо научиться это понимать. Но главное не перегибать палку и не становиться психологом вместо начальника, а то это плохо кончается.

image

Одни минусы. Есть ли плюсы?


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

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

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

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

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

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

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

image

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

Для тех, кто уже завтра идёт на собеседование


Стоит рассказать и о вакансиях на позицию TL. Как я и писал выше, компании бывают разные, в них разные задачи. На собеседовании попытайтесь понять, кто всё-таки нужен работодателю, чтобы ваши ожидания совпали с реальностью. Особенно смешно, когда в компании нет чёткой иерархии, и всё должно висеть на одном человеке. Обычно в их вакансиях есть фраза: «Придётся программировать 70–80% времени. Я бы советовал избегать таких предложений. Либо на вас хотят сэкономить, либо руководство вообще не понимает зачем им нужен TL. Конечно, каждый случай индивидуален, но всё же есть грани разумного. В конечном итоге человек перегорит и уйдёт, так как жить в стрессе всё время нельзя.

image

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

Выводы


Выбор стать TL должен быть осознанным решением, а не просто, потому что вам надоело писать код или хотите зарплату повыше. TL — это первая ступенька в IT-менеджменте. На этом этапе можно понять, нравится вам это или нет. И если нет, то всегда можно вернуться в разработчики. Но учтите, если вы долго проработаете TL, то уйти назад может быть сложно. TL не так много пишет код, мир вместе с технологиями сильно меняется, опыт теряется. Может получиться, что вы вернётесь назад, и придётся долго навёрстывать упущенное.

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

Всё описанное выше приходит с опытом. Учебники и курсы не научат вас быть TL. Но зато смогут помочь обойти немалое количество граблей.

P.S.: Спасибо, что уделили время! Прошу строго не судить, это моя первая статья на хабре. Надеюсь, она окажется кому-то полезной. Я постарался передать свой личный опыт. Буду признателен за любые мнения. Но это лишь начало, дальше я хочу углубится в детали процессов разработки и управления командой и рассказать, как я их выстраивал.
Поделиться публикацией

Комментарии 25

    0
    А в чём разница между Team Lead'ом и Tech Lead'ом?
      +2
      тимлид отвечает за всю команду. чем ей заниматься, куда расти. делает так, чтобы команда выполняла свои задачи максимально эффективным образом без ущерба для самих разработчиков. к нему же приходят всякие внешние заказчики т.е. это интерфейс команды.
      техлид отвечает за сервисы, их архитектуру и т.д.
      часто тимлид и техлид это одно лицо.
        +4
        тимлид: к нему же приходят всякие внешние заказчики т.е. это интерфейс команды.

        А чем он от PM отличается?

        техлид отвечает за сервисы, их архитектуру и т.д.

        Чем он от архитектора отличается?
          0
          Не претендую на истину в последней инстанции, однако предположу, что отличие роли Архитектора от роли Тех.Лида в том, что первый концентрируется на big picture, тогда как последний фокусируется только на своем проекте. По сути архитектор отвечает за взаимодействие проектов, тогда как тех.лид отвечает только за функционирование своего проекта. Плюс архитектор может определять стандарты и подходы, общие для разных команд, а тех.лид их может уточнять и дополнять в рамках специфики своего проекта.

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

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

      Опять статья про нетехнического проектного менеджера (PM) чьи недостатки компенсируются прокачанным лидром команды (Team Lead), по факту выполняющим функции технического менеджера проекта?

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

        Поэтому надо сто раз подумать, прежде чем идти в небольшую компанию. Как минимум четко оговорить круг обязанностей и уточнить, кто будет исполнять функции ПМ.
          +1
          Я могу признаться, что так оно и есть. И когда я туда пришел, там по факту ничего не было и пришлось все разгребать самому. Был стартап-проект, и первое время не было денег. И фактически ты человек-оркестр. Но мне кажется, это бесценный опыт, главное чтобы такой опыт был не первый и ты понимал, что делаешь и зачем. А то может быть крах. Конечно, надо понимать, на что ты идешь.
          0
          Кто такой технический менеджера проекта и чем отличается от просто менеджера проекта?
          +7
          Team Lead, как и любая роль — формальность. Функции, обязанности и ключевые факторы успеха определяются текущими потребностями бизнеса и уровня его развития.
          Я за свою карьеру был и CTO и CIO, и CEO и т.д. и т.п. и вот, сейчас TL. Так вот, лично мое мнение, что TL это не функциональная должность, а скорее избирательная. В прямом смысле, эту роль нужно заслужить у своей команды. Как, почему, рассуждать можно долго.
          Лично для меня наиболее комфортна роль TL. Потому, что только тут я могу говорить с командой не с позиции руководителя, а равного. Спорить о коде, об архитектуре. Развиваться в технологиях. Именно этого ты лишаешься с уходом в менеджмент.
            –3
            Зато вы сможете не тратить время на рутинные задачи, а делегировать их коллегам.
            — или другими словами говоря — «перекладывать ответственность»

              0
              Принимая на себя ответственность за это решение
                0
                Делегировать задачи не всегда равно делегировать ответственность, но может совпадать, но тогда получается плохой тимлид, раз за свои решения он не несет ответственность в полной мере.
                0
                "… собрать крутую команду и принести прибыль компании.." — а если компания жадная и прибылью делиться не хочет? Т.е. ни увеличения зарплаты, ни премий, ни каких либо других перспектив? На вопросы о повышении зарплаты тебе отвечают: ты и так берешь максимум?
                  0
                  Искать другую компанию.
                    0
                    Да, еще можно пересмотреть свои знания и улучшить их. Затем уйти.
                    0
                    можно сесть в углу и плакать.
                    Я не считаю, что прибыль компании имеет отношение к зарплате работника, если это не предусмотрено контрактом. Человек был нанят для исполнения определенного плана работ, которые должны привести к прибыли — иначе компания долго не протянет.

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

                    Представьте Вы берёте машину в аренду, а Вам через какое то время присылают счёт, с объяснением: за год машина ни разу не сломалась и проехала 1000 км. В связи с этим оплатите пожалуйста доп. x.000 руб
                      0
                      Насчет контракта все понятно. Но вот ситуация, запуск нового проекта, предыдущая команда бросила важный подпроект и сбежала. Вы беретесь доделываете и запускате это подпроект. Т.е. вклад можно сказать был высок, т.к. иначе вся система бы не заработала. Затем работодатель нанимает другую фирму, которая переписывает сделанный вами подпроект один к одному, т.е. не добавляя никакого ноу-хау и берет за это в 100 раз больше денег. Как относиться к компании после такого?
                        0
                        Если всё именно так, как Вы расписали, ситуация не очень.
                        Однако ход Вашей компании к фирме с вложением «в 100 раз больше» должно иметь какое то объяснение. Возможно в Вас сомневаются? Тогда и нежелание платит Вам больше — понятно.
                        Какая бы причина ни была — недоверие к Вам или «рыба гниёт с головы» — выход тут только один: искать другое место. Имхо
                          0
                          Да, я уже ищу. Заодно подгоняю упущенные технологии. Причина скорее всего в коррупции, так легче украсть деньги если договориться с внешней фирмой.
                            0
                            Ну если причина в коррупции, возможно стоит побороться? Пойти в обход этого руководителя, выше и поставить это вложение под вопрос, официально.
                            Смена компании тоже не самый лёгкий этап… я бы взвесил.
                      0
                      Из моего личного опыта. Да, повышение ЗП сотрудников было не потому что они хотели, а за реальный вклад (заслуги) в проект. Переговоры с начальством о повышении зарплаты давались нелегко, порой затягивались до 4 месяцев. Но мое личное мнение, что это задача руководителя объяснить, почему сотрудник действительно стоит этого и что он делал для компании.

                      Понятно, что если денег нет, повысить ЗП никто не сможет. А если компания жадная, насколько она будет успешна, если от нее уходят ценные кадры?

                      Есть еще один аспект, я даже читал исследования hr-агетнств. Что многие компании иногда держат сотрудников и повышают им зарплаты, просто потому что найти нового будет в 5-6 раз дороже, чем сохранить старого. Но это был не мой случай =)
                        0
                        Согласен с Вами, однако с повышением нужно быть очень аккуратным. Отсюда появляются люди, думающие что они стоят 100k, когда другие люди делающие туже работу и возможно делают её ещё лучше, получают 50к.
                        И потом, этот человек запросит 150к, и не получив их, он будет искать того, кто заплатит. Или просто будет лишён мотивации…
                        Один из сценариев развития…
                          0
                          Самый лучший способ поднять зарплату, это поменять работу, не раз убеждался.
                        +2
                        Автор описал желание менеджеров переложить ответственность с себя на единую персону ТЛ, и желательно без доступа этой персоны к финансам.
                        Мифический ТЛ все знает, все умеет и за все отвечает. Разве только чашки за всеми не моет, но думаю в некоторых конторах есть и такие опции.
                          0
                          Кстати, из личного опыта.

                          Я за более чем 20-ти летний жизненный опыт встретил только одного Team Leader, который был именно лидер. Может быть, потому, что он был альпинистом.

                          Все остальные кого встречал и встречая — просто менеджеры, со всеми вытекающими последствиями.

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

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

                          Самое читаемое