Тимлид: чем занимается, какие навыки нужны и как им становятся

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

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

Где проходят границы роли

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

Чаще всего роль путают с тремя соседними. Техлид отвечает за технические решения: выбор библиотек, архитектуру сервиса, стандарты кода. Людьми он, как правило, не управляет, и в некоторых командах техлид и тимлид — разные люди, которые работают в паре. Менеджер проектов отвечает за сроки, бюджет и договорённости с заказчиком, часто сразу по нескольким командам, но в код не погружается. Руководитель отдела разработки управляет уже несколькими тимлидами, бюджетом подразделения и штатным расписанием.

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

Из чего состоит рабочая неделя

Встреча один на один (в IT её называют «one-on-one» или «1:1») — регулярный разговор с каждым сотрудником, обычно раз в неделю или раз в две недели по полчаса. Это не отчёт о задачах: статус виден на доске. На такой встрече обсуждают, что мешает работать, чему человек хочет научиться, как он воспринимает решения команды. Здесь тимлид раньше других узнаёт, что сотрудник выгорает или ищет новую работу.

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

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

Найм — требования к вакансии, технические собеседования, решение о кандидате и затем адаптация нового сотрудника.

Оценка работы (performance review) — разговор о результатах сотрудника за полгода или год. От неё часто зависят повышение грейда и пересмотр зарплаты. Честная оценка требует записей в течение всего периода: по памяти тимлид вспомнит только последний месяц.

Учебный пример: команда, которая держится на одном человеке

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

Для такой ситуации в разработке есть термин bus factor — число людей, потеря которых остановит проект. Здесь он равен единице.

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

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

Как становятся тимлидами и что стоит знать о переводе

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

Первые управленческие шаги обычно делают ещё в роли разработчика: берут в наставничество стажёра, ведут онбординг новичков, отвечают за код-ревью в своём модуле, заменяют тимлида в отпуске. Такие задачи показывают, нравится ли вам работать с людьми, раньше, чем вы сменили должность. Системно разобрать сам переход помогает, например, онлайн-курс Skillbox «Управление командами»: он рассчитан на два месяца, включает 68 видеоматериалов и десять практических работ, а первый блок посвящён переходу от исполнителя к руководителю. Программа общеуправленческая, без IT-специфики, зато практические задания можно выполнять на своей команде, а итоговая работа — стратегия её развития.

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

Многие работодатели хотели бы назначить нового тимлида «с испытательным сроком». Но ст. 70 ТК РФ связывает испытание с заключением трудового договора, и Минтруд в апреле 2025 года прямо разъяснил: при переводе внутри организации испытательный срок установить нельзя. Если тимлид не справился, работодатель не может уволить его «как не прошедшего испытание» и не может вернуть на прежнюю должность без его согласия — нужно новое соглашение.

Поэтому пробный период на практике оформляют иначе. Первый вариант — временный перевод по соглашению сторон на срок до одного года (ч. 1 ст. 72.2 ТК РФ). У него есть подвох: если по окончании срока прежнюю работу не предоставили, а сотрудник не потребовал её вернуть и продолжает работать тимлидом, перевод становится постоянным. Второй вариант — совмещение по ст. 60.2 ТК РФ: разработчик остаётся в своей должности, а обязанности руководителя группы выполняет дополнительно, с письменного согласия и за доплату. Каждая сторона может досрочно отказаться от совмещения, предупредив другую письменно не позднее чем за три рабочих дня.

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

Что придётся освоить

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

Отдельный навык — вести записи. Решения по архитектуре, договорённости с соседними командами, заметки после встреч один на один и наблюдения для оценки работы — всё это тимлид фиксирует письменно, иначе к performance review у него останутся только впечатления.

Эти темы разбирают на онлайн-курсе Eduson Academy «TeamLead в IT»: три месяца самостоятельного обучения с наставником, модули об обратной связи, оценке и развитии сотрудников, о планировании, рисках, делегировании и приёмке задач, об Agile, Scrum и Kanban, о сложных коммуникациях. В практике есть кейс о переносе сроков. Программа рассчитана на разработчиков перед повышением и начинающих тимлидов, техническая база предполагается заранее. По окончании выдают удостоверение о повышении квалификации.

Что может оказаться трудным

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

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

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

Сколько зарабатывает тимлид

Надёжной статистики именно по тимлидам в открытых источниках мало. В исследовании «Хабр Карьеры» за первое полугодие 2026 года, построенном на 45 226 зарплатах, которые IT-специалисты анонимно указали в калькуляторе, отдельной строки для тимлидов нет. Есть категория «менеджеры в IT»: их медианная зарплата — 260 000 ₽ в Москве, 200 000 ₽ в Санкт-Петербурге и 152 000 ₽ в регионах. Для сравнения, медиана разработчиков в том же исследовании — 270 000, 247 000 и 200 000 ₽ соответственно (Хабр Карьера, июль 2026). Обе категории широкие: в «менеджеров» попадают и менеджеры проектов, и продакты, а тимлид в калькуляторе может указать себя и разработчиком с квалификацией Lead.

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

Чтобы посмотреть актуальные цифры самостоятельно, откройте зарплатный калькулятор «Хабр Карьеры» и выберите свою специализацию с квалификацией Lead, а в вакансиях на агрегаторах отфильтруйте предложения по региону и опыту от трёх лет. Смотрите на медиану, а не на среднее, и помните, что вакансии показывают ожидания работодателей, а калькулятор — то, что люди получают фактически.

Как выбрать обучение

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

Пример второго типа — программа МИПО «Тимлид в ИТ». Несмотря на название, в опубликованном перечне из 14 модулей нет ни код-ревью, ни планирования спринтов: это основы менеджмента, управление конфликтами и стрессом, формирование команды, делегирование, мотивация, коммуникации и принятие решений. Зато программа большая — пять месяцев и 520 академических часов, а по итогам выдают диплом о профессиональной переподготовке. Подробную программу и актуальную цену лучше уточнить у школы.

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

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

С чего начать

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

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