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

Привет, Хабр! Меня зовут Анна Жаркова, я — Lead Mobile Developer в Usetech. Пишу нативные приложения под iOS и Android и кросс-платформенные приложения на Xamarin, Xamarin.Forms и Kotlin Multiplatform. Эксперт Skillbox по мобильной разработке. Автор на «Хабре» —  @anioutka, и Medium. Пишу статьи, выступаю на конференциях и митапах. Член программного комитета Mobius, CodeFest, «Стачка». Увлекаюсь живописью и участвую в выставках. Для закрытого комьюнити Skillbox Code Experts рассказала о том, каково это быть тимлидом и с какими проблемами можно столкнуться в пути.

Кто такой тимлид или проблема разночтений

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

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

• решать сложные технические задачи и контролировать их решение у команды;

• быть наставником;

• выстраивать процессы и распределять задачи;

• представлять команду на уровне менеджмента;

На практике чаще всего тимлид — это смесь всех этих функций, а акцент зависит от компании, руководства и конкретного проекта.

Когда работала мидлом в аутстаффинговой компании из Барнаула на московском проекте, первый раз столкнулась с настоящим тимлидом, вернее, тем, кто значился на этой роли. У нас была кросс-функциональная команда: Android, iOS и backend-разработчики. Тимлидом тогда был старший бэкендер, который параллельно выполнял свои технические задачи и присматривал за проектом.

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

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

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

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

Такой специалист помогает решать насущные вопросы. В какой-то мере он связующее звено (делегат) между командой и ПМ/ПО. Хотя важно помнить, что не всегда тот, кто дольше проработал в компании или на проекте обладает самыми сильными навыками или опытом. Например, если роль лида проекта выполняет джун/миддл, то при подключении, например, сеньора может возникнуть конфликт из-за несовпадения видения процессов, решений. Либо если на проекте все сеньоры, то может возникнуть острая конкуренция.

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

Распределяет задачи. Совместно с product owner занимается декомпозицией задач, распределяет их внутри команды и следит за сроками выполнения.

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

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

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

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

Какими бывают тимлиды — сфера задач

Из тех спецов, с кем я встречалась на практике, могу выделить следующие типы и роли лидов:

Тимлид-менеджер. Может быть менеджером, работающим с кодом и совмещать технические задачи с управлением. Я таких называю тим/техлид или просто лид. А может быть менеджером без кода и фокусироваться исключительно на процессах и людях. Последние лет 5 компании их выращивали из джунов и миддлов, переводя их в управленцы.

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

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

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

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

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

Можно еще выделить следующие типы лидо по карьерному пути:

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

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

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

Тимлид, выращенный из джуна. Распространённая практика в компаниях, особенно на «галерах» (аутсорс и аутстафф-компании). Человека с минимальным опытом (полтора-два года) начинают обучать навыкам менеджмента. Проблем у такого подхода много: недостаток технических знаний, трудности в общении с более опытными разработчиками. Чаще всего такие тимлиды становятся проджект-менеджерами, так как не справляются с техническими задачами.

Head of Mobile и другие глобальные лиды. Это не просто тимлид проекта, а руководитель целого направления, например, мобильной разработки. Они занимаются стратегией, процессами и взаимодействием с другими отделами. Это своего рода вершина карьерной лестницы для лидеров в разработке.

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

Часто рассказы о работе Head of Mobile звучат как истории о безупречной карьере. Однако на практике не всё так гладко. Без реальных полномочий, даже находясь на высокой позиции, невозможно реализовать амбициозные проекты и задачи. Успех всегда зависит от поддержки руководства, готового инвестировать в развитие направления. С этим могут столкнуться и лиды помладше. Например, с нехваткой административного ресурса для решения проблем.

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

Какие навыки важны для тимлида

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

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

Делегирование

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

Коммуникация

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

Работа с джунами, мидлами и синьорами требует гибкости, терпения и умения адаптироваться к уровню каждого. Общение с руководством не менее важно. И это не про лесть, а про грамотные коммуникации: нужно уметь доносить свои мысли, аккуратно подсвечивать риски и предлагать решения. Руководство делегирует техническому специалисту экспертизу по решению технических вопросов. Оно не обязано разбираться во всех тонкостях и нюансах каждого направления. Специалисты должны в свою очередь уметь ясно, чётко и корректно донести обратно результат. Надо общаться иногда и с заказчиками, которые могут быть не специалистами в IT, но представлять только конечный результат. Некоторые могут иметь свое видение решений, которое не всегда может иметь отношение к реальности, быть правильным и/или реализуемым. Надо иметь терпение и такт, уметь аккуратно донести риски, проблемы и предложить решение взамен.

Техническая экспертиза (по необходимости)

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

Менторство

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

Менторство джунов. Джуны бывают разными, в том числе и:

• «Неумехи», которым нужна помощь на каждом этапе.

• «Торопыжки», стремящиеся сделать всё сразу и бездумно.

• «Я сам», уверенные в своих силах, но часто допускающие ошибки.

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

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

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

Тимлид в реальном мире: проблемы, вызовы и выгорание

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

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

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

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

Избыточное количество созвонов. Тимлидам приходится участвовать в бесконечных встречах: дэйли, созвоны с руководством, one-to-one и других. Большинство созвонов могут быть бесполезными, но требуют присутствия тимлида просто «на всякий случай». Многие тимлиды из-за этого вынуждены перерабатывать, т.к другие задачи и сроки по ним никто не отменял.

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

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

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

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

Почему выгорают тимлиды и как этого избежать

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

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

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

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

Конфликты с руководством. Если руководство давит или предъявляет необоснованные претензии, это, разумеется,  усиливает стресс.Постоянный контроль и требования «делать лучше» без конкретной обратной связи — ещё больше демотивируют.

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

Могу дать несколько рекомендаций, как остаться в должности тимлида и не выгореть в угли.

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

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

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

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

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

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

А, главное, помните: тимлид — не супергерой! Искать поддержку, перепоручать задачи и беречь своё здоровье — не слабость, а залог успешной работы и долгосрочной карьеры. Следуйте своему пути и не сдавайтесь!