Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а ещё преподаю на курсах по разработке и архитектуре в OTUS. В этой статье я расскажу про то, как управлять тимлидами — и почему это совершенно не то же самое, что управлять разработчиками.
Когда я работал на руководящей позиции в розничном банковском бизнесе и впервые столкнулся с необходимостью руководить сразу несколькими тимлидами, мне казалось: «Ну что там сложного, это же опытные ребята, сами всё знают». Через два месяца я поймал себя на том, что я превратился в бутылочное горлышко: все решения замыкались на мне, инициатива угасала, а в кулуарах начали шептаться про микроменеджмент.
Потом я осознал: тимлид — это не «супер‑разработчик, которому добавили немного управленческих задач». Это отдельная роль со своей мотивацией, болями и принципиально другой моделью управления. И если подходить к нему как к линейному сотруднику, вы либо убьёте его автономию, либо потеряете его из компании.
Сегодня разберём, как выстроить работу с тимлидами системно: без тотального контроля, но с прозрачностью; без размытых ожиданий, но с понятными рамками. Поговорим о роли Delivery Manager и лучших практиках команд, которые уже научились это делать.
Почему тимлид — это не просто «старший разработчик»
Представьте себе двух людей: разработчик Петя и тимлид Лена. Оба технически сильны. Но Петя отвечает за качество своего кода и своей задачи, а Лена — за то, чтобы вся команда выдала результат в срок, с нужным качеством и без выгорания. Разница колоссальная.
Тимлид находится в постоянном конфликте ролей:
С одной стороны, он ещё пишет код (или хотя бы делает ревью).
С другой — планирует, разрешает конфликты, синхронизируется с другими командами и защищает интересы разработчиков перед бизнесом.
Если вы, как руководитель тимлидов, не учитываете эту двойственность, вы рискуете нагрузить их нереалистичными ожиданиями. Например, сказать: «Лена, почему у тебя упал персональный спринтовый velocity?» При этом Лена три дня разгребала последствия интеграции с соседним сервисом, чтобы команда вообще могла работать.
Главное правило, которое я вывел для себя: тимлиду нужно управлять не объёмом его личного кода, а здоровьем команды и потоком доставки ценности.
Три ошибки, которые я совершал сам (и видел у других)
1. Контроль вместо доверия
Первое время я пытался быть в курсе каждой мелочи. Просил отчёты, лез в детали задач, дёргал тимлидов по три раза на дню. Результат: они перестали принимать самостоятельные решения. «А давайте спросим Сергея» стало дефолтной фразой на всех митингах.
Тимлиды — это лидеры на местах. Если вы не доверяете им, зачем они вообще нужны? Контроль должен быть смещён с процесса на результат. Вместо «расскажи, что ты сегодня делал» — «какой прогресс по целям квартала и что мешает двигаться быстрее».
2. Слабое делегирование полномочий
Ещё одна классика: вы делегируете задачу, но оставляете за собой право вето на каждое микро‑решение. Формально тимлид отвечает за архитектуру, но если он не может выбрать брокер сообщений без вашего одобрения, какая это автономия?
Лучше определить рамки. Например: «Технические решения до бюджета X и в рамках утверждённого стека принимаете сами. Всё, что выходит за эти границы, — синхронизируемся».
3. Отсутствие прозрачности в целях
Когда тимлиды не понимают, куда движется вся организация и как их команда вписывается в эту картину, они варятся в собственном соку. Возникает эффект «локальной оптимизации»: команда прекрасно делает свою часть, но общий продукт страдает.
В одном проекте у нас было три тимлида, каждый тянул одеяло на себя. Один форсил рефакторинг, второй — новый фичи, третий — стабилизацию. Конфликты на синхронизациях были жёсткими. Проблема решилась только тогда, когда мы явно прописали общие квартальные OKR и сделали их видимыми для всех. Тимлиды начали договариваться сами, потому что поняли: их успех зависит не от того, кто громче кричит, а от того, достигнем ли мы общих целей.
Как выстраивать прозрачность и доверие в командах
Я не особо верю в «доверие по умолчанию». Доверие — это результат прозрачности и предсказуемости. Вот несколько инструментов, которые помогают мне его строить:
Регулярные one‑on‑one не о статусах, а о людях. Я всегда спрашиваю: «Что тебя сейчас больше всего беспокоит в работе команды?» или «Где ты чувствуешь себя заблокированным?». Это даёт гораздо больше информации, чем отчёт по Jira.
Данные, доступные всем. У нас в командах есть дашборды с DORA‑метриками (время выполнения, частота развёртываний, процент отказов). Тимлиды сами видят, где проседает поток. Моя задача — помочь устранить системные препятствия, а не тыкать пальцем в плохие цифры.
Культура «разбора полётов» без поиска виноватых. Если случился инцидент, мы не ищем крайнего, а разбираем, почему процесс позволил этому случиться. Тимлиды перестают бояться сообщать о проблемах, когда знают, что за это не «прилетит».
Управление через цели, рамки и метрики вместо задач
Переход от управления задачами к управлению целями — это, пожалуй, самый сложный ментальный сдвиг. Тимлид получает от вас не список из 20 тикетов на неделю, а чёткий outcome, которого нужно достичь.
Например, не «сделай рефакторинг модуля авторизации», а «снизь количество инцидентов, связанных с авторизацией, на 50% в течение квартала». Как именно тимлид этого добьётся — рефакторингом, улучшением мониторинга или добавлением кэширования — его зона ответственности.
Для этого отлично подходит формат OKR (Objectives and Key Results). На уровне компании или продукта формулируются глобальные цели, а тимлиды вместе со своими командами предлагают, какой вклад они могут внести. Дальше — регулярные проверки: не «сколько задач закрыто», а «какой прогресс по ключевым результатам».
Важно: метрики должны быть не карательными, а диагностическими. Если KR не достигается, мы не наказываем тимлида, а садимся и анализируем: цель была нереалистичной? Вмешались внешние факторы? Не хватило ресурсов?
Вот как это может выглядеть на схеме (рис. 1):
На схеме представлен замкнутый цикл работы с целями, который помогает выстроить управление тимлидами без микроменеджмента и директивных поручений.
Стартовая точка — глобальные цели компании. От них отталкиваются цели на уровне продукта или направления. Дальше — ключевой этап: OKR команды разрабатываются совместно с тимлидом. Это не спущенные сверху KPI, а договорённость о том, какой измеримый вклад команда внесёт в общий результат в ближайшем цикле.
Затем следует регулярный обзор прогресса.
Если ключевые результаты достигаются — команда продолжает двигаться в том же направлении, масштабируя успешные практики.
Если фиксируется отклонение — система не наказывает тимлида или команду. Вместо этого запускается анализ причин без обвинений (blameless review): что помешало? Нереалистичная цель? Внешние блокеры? Нехватка ресурсов?
На основе этого анализа происходит корректировка плана или ресурсов, после чего цикл обзора повторяется. Такой подход смещает фокус с контроля исполнителей на управление системными условиями, в которых тимлиды и команды могут автономно достигать результатов.
Роль Delivery Manager как системного лидера, а не контролёра
Здесь мы подходим к ключевому моменту. Вопрос: кто должен заниматься всей этой оркестрацией? Традиционный Project Manager часто скатывается в контроль сроков и микроменеджмент. Scrum Master фокусируется на процессах внутри команды. А кто смотрит на поток создания ценности целиком, помогает тимлидам синхронизироваться и убирает системные препятствия?
Вот тут и появляется роль Delivery Manager. В OTUS мы как раз готовим таких специалистов на курсе «Менеджер поставки ИТ‑решений».
Delivery Manager — это не тот, кто спрашивает «когда будет готово?». Это тот, кто создаёт условия, в которых тимлиды могут эффективно работать. Он управляет системой доставки, а не людьми. Его инструменты:
Визуализация потока (Kanban, value stream mapping).
Управление зависимостями между командами.
Выстраивание метрик, которые помогают, а не демотивируют.
Фасилитация стратегических сессий, где тимлиды договариваются о приоритетах.
Хороший Delivery Manager делает так, что тимлиды сами знают, что и зачем делать, а не ждут указаний сверху. Это системное лидерство, а не административный контроль.
Best practices от команд, которые умеют работать с тимлидами
Один из самых известных примеров — модель Spotify с их Squad, Tribe, Chapter и Guild. Не буду пересказывать всю схему, но ключевой момент: у них есть разделение между менеджером по персоналу (Chapter Lead) и лидером продукта (Product Owner). Chapter Lead отвечает за рост и развитие людей в рамках своей компетенции (например, все бэкенд‑разработчики), но не управляет их ежедневными задачами. Это позволяет тимлидам (которые могут быть и Chapter Lead, и Squad Lead в одном лице) сосредоточиться на доставке ценности, имея при этом поддержку в развитии людей.
Другой пример — культура свободы и ответственности в Netflix. Там нет детальных инструкций для тимлидов, но есть чёткий контекст и высокие ожидания. Тимлидам говорят: «Вот наша стратегия, вот границы (бюджет, compliance, архитектурные принципы). Действуй». И они действуют, потому что знают: их не накажут за ошибку, если решение было принято осознанно и с учётом имеющейся информации.
Что объединяет эти практики:
Высокий уровень автономии при ясных границах.
Фокус на outcome, а не на output.
Инвестиции в развитие лидерских навыков тимлидов.
Маленькая история из жизни
Некоторое время назад в нашем финтех‑проекте мы запускали большой проект по миграции на новую платёжную систему. Два тимлида, условно Андрей и Максим, отвечали за смежные сервисы. Формально всё было согласовано: контракты API, сроки. Но в процессе выяснилось, что Андрей, опасаясь за стабильность своего сервиса, добавил дополнительный слой валидации, который ломал ожидания команды Максима.
Мы узнали об этом за две недели до планируемого релиза. Классическая ситуация: тимлиды не договорились о нефункциональных требованиях, потому что каждый оптимизировал свою часть. Вместо того чтобы разбираться, кто виноват, мы собрали совместную сессию с белой доской в Miro и проработали контракты заново. Но самое главное — мы договорились о правиле: любые изменения, влияющие на контракты смежных сервисов, должны быть зафиксированы в общем пространстве (у нас это был внутренний реестр API в Confluence) и проговорены на еженедельной синхронизации тимлидов.
С тех пор таких сюрпризов не случалось. Этот случай научил меня, что даже самые автономные и ответственные тимлиды нуждаются в прозрачной среде для коммуникации. И задача руководителя — такую среду построить и поддерживать.
Как выглядит управление тимлидами на практике
Давайте подведём итог в виде простой схемы, которая отражает сдвиг мышления от традиционного управления к системному лидерству (рис. 2).
На схеме наглядно показаны два принципиально разных способа управления тимлидами и командами разработки.
Верхняя часть — Системный подход (роль Delivery Manager).
Delivery Manager не раздаёт задачи, а задаёт цели и рамки (например, через OKR и стратегические приоритеты). Он обеспечивает прозрачность процессов (метрики, визуализация потока) и убирает системные препятствия, мешающие команде. Тимлид в этой модели — полноценный лидер: он сам определяет, как команда достигнет результата, и ведёт её к цели. Команда, в свою очередь, получает понятный контекст и пространство для самостоятельных решений.Нижняя часть — Традиционный подход.
Руководитель напрямую ставит задачи тимлиду, контролирует детали его работы и регулярно запрашивает отчёты. Тимлид в этой модели выступает скорее как «транслятор» поручений и старший исполнитель. Автономия команды снижена, инициатива подавлена, а руководитель становится бутылочным горлышком для принятия решений.Главное отличие: в традиционной модели руководитель управляет людьми и задачами, а в системной — Delivery Manager управляет средой и потоком доставки, доверяя тимлиду и команде право выбора способа достижения цели.
Управлять тимлидами — значит создавать среду
Управление тимлидами — это не про то, чтобы раздавать поручения и проверять сроки. Это про создание среды, в которой сильные технические лидеры могут проявить себя и привести команды к выдающимся результатам. Это требует доверия, прозрачности и готовности отказаться от иллюзии полного контроля.
Если вы чувствуете, что пора переходить от интуитивных действий к системной работе с потоком доставки и лидерством, приглашаю вас на открытые уроки курса «Менеджер поставки ИТ‑решений» в OTUS. Мы разберём реальные кейсы, обсудим метрики и инструменты, которые помогают выстроить эффективную систему управления доставкой, не скатываясь в микроменеджмент.
30 апреля в 20:00. «Как управлять тимлидами?»
[Записаться]20 мая в 20:00. «Системная диагностика команды и группы команд»
[Записаться]
Проверьте, насколько вы готовы к системному управлению командами, тимлидами и delivery-процессами. ➡
[Пройти бесплатное вступительное тестирование]
Пройдите тест и получите скидку 15% на курс. Предложение действует до 30 апреля.
Dhwtj