Engineering Lead: управление технической причинностью

Курс на лида — это не “как стать приятным начальником”.
Это программа про то, как инженер перестаёт быть только исполнителем задач и начинает держать контур ответственности за систему, команду, delivery, качество решений, риски и смысл работы.

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

Чтобы говорить о границах ответственности лида, необходимо обозначить соседнюю ответственность — за продуктовую сторону решений: цель, ценность, приоритет и продуктовый scope. В этом курсе субъекта, который её удерживает, будем называть Product Owner. Название пришло из Scrum, но сегодня используется и за его пределами. Конкретное название роли и распределение полномочий зависят от организации.

1. Переход от Senior к Lead

Не “ты теперь лучше кодишь”, а:

как меняется зона ответственности;
почему лид отвечает не только за свои задачи;
чем отличается “сделал сам” от “сделал так, чтобы команда могла сделать”;
почему лид должен видеть систему целиком;
где граница между Tech Lead, Team Lead, Engineering Manager, Architect, Product Owner;
что значит “держать delivery”, а не просто “участвовать в разработке”.

Здесь важное различение:

Senior Developer:
отвечает за сложную часть работы.

Tech Lead / Team Lead:
отвечает за то, чтобы сложная работа стала выполнимой для команды.

И это огромная разница.

2. Команда как инженерная система

Команда — это не “набор людей”.
Команда — это производственная система, у которой есть:

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

Вот тут можно давать разбор:

Что команда умеет?
Где команда зависает?
Где теряется смысл?
Где задачи превращаются в болото?
Где один сильный инженер тащит всё на себе?
Где команда симулирует Agile, но фактически живёт в ручном управлении?

Сюда хорошо ложится Team Topologies: там команда рассматривается не абстрактно, а через типы команд, границы ответственности, cognitive load и режимы взаимодействия между командами. В их модели есть четыре фундаментальных типа команд и три основных режима взаимодействия: Collaboration, X-as-a-Service и Facilitation. (teamtopologies.com)

3. Delivery: как доводить работу до результата

Это прям ядро курса.

Потому что лид без delivery — это философствующий старший разработчик.
А лид с delivery — это человек, который умеет превращать мутное требование в поставленный результат.

Модуль должен включать:

декомпозицию задач;
slicing больших фич;
определение MVP;
Definition of Ready;
Definition of Done;
управление зависимостями;
оценку рисков;
работу с блокерами;
daily / planning / refinement / review / retro;
контроль прогресса без микроменеджмента;
отличие активности от продвижения;
отличие “мы что-то делали” от “мы приблизились к результату”.

DORA для измерения software delivery использует метрики, связанные со скоростью и стабильностью поставки: deployment frequency, lead time for changes, change failure rate и failed deployment recovery time. Там же delivery performance описывается не как “люди были заняты”, а как способность команды безопасно, быстро и эффективно поставлять изменения. (dora.dev)

И это очень правильный разворот:
лида надо учить не “пинать людей”, а видеть поток работы.

Где задача вошла?
Где зависла?
Почему зависла?
Кто ждёт кого?
Где недостаточно решения?
Где недостаточно контекста?
Где архитектура мешает delivery?
Где процесс имитирует движение?

4. Архитектура для лида

Не “архитектура как красивые схемы”.
А архитектура как способ не дать системе сдохнуть под изменениями.

Темы:

модульность;
границы сервисов;
bounded contexts;
API contracts;
интеграции;
синхронное и асинхронное взаимодействие;
очереди;
транзакционность;
консистентность;
observability;
масштабирование;
технический долг;
миграции;
legacy;
архитектурные компромиссы;
когда не надо строить микросервисы;
как объяснять архитектурное решение команде и бизнесу.

Отдельный блок — Architecture Decision Records. ADR — это короткий документ, который фиксирует одно архитектурное решение, его контекст и последствия; Martin Fowler отдельно подчёркивает, что ADR должен сохранять не только “что решили”, но и почему это решение появилось. (martinfowler.com)

Для лида это критично, потому что команда постоянно страдает не от отсутствия кода, а от отсутствия памяти решений.

Почему мы выбрали Kafka?
Почему не RabbitMQ?
Почему этот сервис отдельный?
Почему эта таблица такая?
Почему авторизация вынесена отдельно?
Почему нельзя просто переписать всё?

Без фиксации решений команда живёт в вечном “а кто это придумал?”.

5. Code Review: проверка инженерных решений и развитие команды

Очень важный модуль.

Code review — это не поиск запятых.
Это место, где лид формирует стандарт инженерного мышления.

Темы:

что проверять в pull request;
как отличать вкусовщину от реальной проблемы;
как не превращать review в унижение;
как защищать качество без токсичности;
как объяснять trade-offs;
как видеть архитектурный запах;
как находить скрытую сложность;
как не пропускать “работает, но потом нас убьёт”;
как учить младших через review;
как самому не становиться bottle-neck.

Пример различения:

Плохой review:
"переделай, так некрасиво".

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

Вот это уже leadership, потому что ты не просто указываешь на ошибку, а передаёшь способ видеть систему.

6. Работа с требованиями и стейкхолдерами

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

Темы:

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

Лид организует совместную работу: Product Owner принимает продуктовые решения, команда определяет техническую реализацию, владельцы предметных правил подтверждают условия в своих областях. Договорённости должны быть доступны участникам и поддерживаться в актуальном состоянии.

Отдельный навык: превратить запрос «нам нужна кнопка» в согласованное описание:

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

7. Планирование, оценки и управление неопределённостью

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

Темы:

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

8. Ответственность за живую систему: наблюдаемость и инциденты

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

Темы:

как отличать состояние кода и инфраструктуры от результата пользовательской операции;
как использовать метрики, логи и трассировки для наблюдения за операциями и проверки последствий изменений;
какие решения поддерживают health checks, dashboards и правила оповещения;
как различать SLI, SLO и SLA, задавать цели и использовать error budget;
как организовать on-call, объявление инцидента, роли и коммуникацию во время сбоя;
как уменьшать воздействие через откат, feature flags, постепенный выпуск и управляемую деградацию;
как проводить blameless postmortem, восстанавливать причинную картину и назначать проверяемые действия;
как проверять готовность сервиса к эксплуатации и поддерживать runbooks и playbooks;
как измерять воздействие инцидентов, обнаружение и восстановление без ложных выводов по средним значениям.

9. Люди: менторинг, рост и конфликты

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

Темы:

как отделять наблюдение от интерпретации и проверять причины на уровне человека, задачи, роли, команды и системы;
как описывать способности в контексте и менторить Junior, Middle и Senior;
когда передавать знание, помогать человеку построить решение, давать доступ к возможностям роста или делегировать ответственность;
как строить план роста, вести 1:1 и проверять развитие по наблюдаемым действиям;
как давать трудную и положительную обратную связь, сохраняя психологическую безопасность и требования к результату;
как определять предмет конфликта, отличать конфликт ролей от личного и проводить разговор между сторонами;
как отличать непонимание, перегруз и несогласие от устойчивого уклонения или сознательного препятствования;
как работать с сильным, но разрушительным инженером и не допускать захвата знаний, решений и доступа;
как проверять нагрузку, защищать команду от внешнего давления и проверять её собственные ошибочные решения;
как обсуждать неудовлетворительный результат, соблюдать последовательный стандарт и не сводить вклад человека к индивидуальным метрикам.

10. Найм и собеседования

Для лида это отдельная компетенция.

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

Темы:

как читать резюме;
как проводить technical screening;
как отличать реальный опыт от пересказа;
как задавать system design вопросы;
как проверять reasoning;
как проверять ownership;
как не нанять токсичного “звёздного” разработчика;
как оценивать seniority;
как давать hiring feedback;
как онбордить нового человека;
как строить probation plan.

Пример хорошего вопроса:

Не:
"Что такое Kafka?"

А:
"У вас есть сервис заказов, платёжный сервис и сервис уведомлений. Где вы будете использовать синхронный вызов, где событие, где очередь, где нужна идемпотентность, и что сломается при повторной доставке сообщения?"

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

11. AI / ML / LLM для лида

Сейчас это уже надо включать обязательно.

Но не в формате “ChatGPT ускоряет разработку в 10 раз”, а нормально:

как использовать ChatGPT / Codex / Copilot в разработке;
как давать задачу AI-инструменту;
как проверять сгенерированный код;
как не тащить hallucination в production;
как использовать AI для refactoring, тестов, документации, анализа логов;
как строить AI-assisted workflow в команде;
как фиксировать правила использования AI;
где AI помогает;
где AI создаёт иллюзию понимания;
где AI ускоряет junior, а где делает его опаснее;
как лид должен контролировать качество при AI-assisted development.

DORA в своём research-разделе уже отдельно выделяет AI как фактор, который меняет software delivery и organizational performance; при этом формулировка важная: AI усиливает существующую социотехническую систему, а не магически заменяет её. (dora.dev)

То есть для курса на лида сильная формулировка такая:

AI не заменяет leadership.
AI увеличивает последствия существующего leadership.

Если в команде есть мышление, контекст, review, тесты и архитектурная дисциплина — AI ускоряет.
Если в команде хаос — AI ускоряет производство хаоса.

12. Управление техническим долгом

Технический долг надо разбирать не как “грязный код”, а как отложенную цену решений.

Темы:

intentional debt;
accidental debt;
legacy;
refactoring strategy;
strangler pattern;
migration plan;
debt register;
как объяснять долг бизнесу;
как не превращать refactoring в бесконечное “давайте всё перепишем”;
как выбирать, какой долг платить первым;
как связывать долг с delivery risk.

Пример:

Плохая формулировка:
"код плохой, надо переписать".

Лидерская формулировка:
"из-за текущей структуры изменение тарифов занимает 5 дней вместо 1 дня, потому что бизнес-правила размазаны по трём сервисам. Предлагаю выделить pricing module в течение двух спринтов, чтобы следующие изменения тарифов проходили быстрее и безопаснее".

Вот это язык, который понимает и инженер, и бизнес.

13. Документация, знания и память команды

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

Темы:

README;
runbooks;
onboarding docs;
architecture overview;
ADR;
API contracts;
diagrams;
knowledge sharing;
bus factor;
внутренние tech talks;
как писать документацию, которую реально читают;
как не превращать Confluence в кладбище текстов.

Главный принцип:

Если знание существует только в голове лида — это не знание команды.
Это скрытая зависимость.

14. Коммуникация лида

Не “soft skills”, а точная инженерная речь.

Темы:

как формулировать проблему;
как различать факт, оценку, интерпретацию и риск;
как говорить с разработчиком;
как говорить с QA;
как говорить с Product;
как говорить с менеджером;
как говорить с заказчиком;
как эскалировать;
как писать status update;
как писать risk update;
как не прятать проблему до последнего.

Пример:

Плохо:
"У нас всё сложно, команда разбирается".

Нормально:
"Интеграция заблокирована, потому что внешний API не возвращает стабильный contract для статусов платежа. Сейчас проверяем два варианта: адаптер на нашей стороне или изменение contract со стороны партнёра. Риск: задержка релиза на 2–3 дня, если партнёр не подтвердит contract сегодня".

Это не корпоративное сглаживание. Это точная передача реальности.

15. Лид как точка сборки смысла

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

Лид должен отвечать на вопросы:

Что мы вообще делаем?
Зачем мы это делаем?
Как это связано с пользователем?
Как это связано с бизнесом?
Как это связано с архитектурой?
Как это связано с задачей конкретного разработчика?
Где здесь результат?
Где здесь имитация результата?

Потому что команда очень легко распадается на локальные действия:

один пишет endpoint;
другой чинит тест;
третий обновляет pipeline;
четвёртый спорит про naming;
пятый не понимает, зачем эта feature вообще нужна.

А лид должен собирать это обратно:

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