Руководство направлением: как управлять 50-100 инженерами

← назад к разделу

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

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

От тимлида к руководителю руководителейспросят на собеседовании

Что меняется по сути, а не по названию должности.

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

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

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

Оргдизайн: четыре типа команд и три режима взаимодействияспросят на собеседовании

Как резать одну команду на несколько, по продукту, а не по слою, разобрано в статье про структуру команд и владение. На уровне направления вопрос другой: какие типы команд вам нужны и как они должны взаимодействовать. Самый ясный язык для этого дают Мэтью Скелтон и Мануэль Пайс в книге Team Topologies (IT Revolution, 2019, второе издание 2025).

Четыре типа команд по первоисточнику:

И три режима взаимодействия:

• Collaboration (совместная работа): две команды работают вместе ограниченное время, чтобы открыть новое: API, практику, технологию.
• X-as-a-Service (как сервис): одна команда предоставляет, другая потребляет, с минимумом согласований.
• Facilitating (содействие): одна команда помогает другой и обучает её.

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

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

Шаблон разбора направления, который стоит сделать в первые два месяца: таблица «команда, тип, что владеет, с кем взаимодействует и в каком режиме, сколько доменов на команду». Пустые клетки и команды с тремя доменами покажут, куда смотреть.

Встречи через уровеньспросят на собеседовании

Встреча через уровень (skip-level) это разговор руководителя направления с инженером из команды его тимлида. Её цель не контроль тимлида, а второй канал правды: информация через одного руководителя неизбежно фильтруется, даже без злого умысла.

Как проводить, чтобы не сломать доверие:

• Тимлид знает заранее и понимает зачем. Скажите прямо: «я хочу слышать команду не только через тебя, это не про проверку».
• Регулярно и по кругу, а не по поводу. Встреча, назначенная только когда что-то горит, читается как расследование. На 80 человек реалистично: каждый инженер раз в полгода индивидуально или групповые встречи по 4-6 человек раз в квартал.
• Вопросы о системе, а не о людях. «Что мешает делать работу быстрее?», «О чём ты узнал последним?», «Что бы ты поменял, будь ты на моём месте?», «Понятно ли, зачем команда делает то, что делает?»
• Не решать проблемы через голову тимлида. Услышали жалобу: обсуждаете её с тимлидом как тему, без имени источника, если человек не разрешил.
• Закрывать петлю. Через месяц инженер должен увидеть, что сказанное к чему-то привело, иначе на третьей встрече он будет говорить «всё хорошо».

Найм и ввод в работу на масштабе

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

Что делает поток управляемым:

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

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

Коммуникации: письменно, регулярно, одним источником

На сто человек устная передача ломается: к третьему пересказу решение искажается до неузнаваемости. Работают три канала с разными задачами.

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

Общее собрание (all-hands) раз в месяц или квартал, 45-60 минут. Не отчёт о проделанной работе по командам, а три вещи: куда идём и почему, что поменялось, ответы на вопросы. Вопросы собирают заранее, в том числе анонимно, и на неудобные отвечают первыми: пропущенный острый вопрос люди замечают сильнее, чем любой слайд.

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

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

Буфер: защита от шума и где начинается изоляцияспросят на собеседовании

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

Что разумно забирать на себя:

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

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

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

Делегирование решений: двери и пиццыспросят на собеседовании

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

Полезная рамка из письма акционерам Amazon за 2015 год: решения бывают двух типов. Тип 1 это «двери в одну сторону», последствия необратимы или почти необратимы, и решать их надо методично и медленно. Тип 2 это «двери в обе стороны», их можно отыграть назад, и они должны приниматься быстро людьми с хорошим суждением или небольшими группами. Там же названа болезнь растущих организаций: тяжёлый процесс для решений типа 1 начинают применять почти ко всему, включая решения типа 2, и результат это медлительность и нежелание экспериментировать.

Для направления это превращается в короткую таблицу: какие решения ваши (найм руководителей, структура команд, выбор основной СУБД или облака, бюджет), а какие принимают команды без согласования (библиотеки, внутренние API, порядок задач в пределах квартальных целей). Всё, чего нет в первом списке, по умолчанию решают команды.

Второй принцип, который часто цитируют неточно: «команда на две пиццы». По словам Безоса, которые приводит AWS: «мы стараемся создавать команды не больше, чем можно накормить двумя пиццами». В описании на сайте AWS суть шире размера: в идеале меньше 10 человек, у команды единоличное владение конкретным продуктом или сервисом, внутри все нужные роли (разработка, тестирование, продукт, эксплуатация), а руководитель обязан сохранять её автономию. Если взять только размер и не дать владения и полномочий, получатся просто маленькие команды, которые ждут друг друга.

Методологии на масштабе

Когда команд пять-десять над одним продуктом, встаёт вопрос общего ритма. Подробный разбор SAFe, LeSS и гибридов в статье про масштабирование методологий; здесь ориентиры для руководителя направления.

• SAFe рассчитан на «поезд» из 50-125 человек, то есть ровно на ваш масштаб, и даёт единый календарь планирования и бюджетный цикл. Цена: роли, церемонии и двухдневное планирование.
• LeSS рассчитан на до восьми команд по восемь человек над одним продуктом с одним списком работ. Легче по весу, но требует, чтобы команды действительно были взаимозаменяемы по продукту.
• Гибрид, который часто встречается в банковских и государственных проектах: снаружи вехи и документы для заказчика, внутри спринты или Kanban по выбору команды, сверху общее квартальное планирование зависимостей.

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

Типичные ошибкиспросят на собеседовании

• Остаться главным инженером. Вы на всех ревью архитектуры и решаете за тимлидов. Тимлиды не растут, вы узкое место.
• Реорганизация каждые полгода. Команде нужны месяцы, чтобы сработаться, и частая перестройка не даёт ей дожить до результата. Меняйте структуру, когда есть конкретная проблема в потоке, а не новая модная схема.
• Тимлиды без управленческой подготовки. Лучшего инженера назначили руководителем и оставили. Через полгода у вас минус сильный инженер и плюс несчастный руководитель.
• Информация только сверху вниз. Нет встреч через уровень и анонимных вопросов: вы узнаёте о проблеме из заявлений об уходе.
• Метрики для контроля, а не для разговора. Сравнение команд по скорости в баллах рушит доверие и учит команды подгонять цифры.
• Буфер, ставший стеной. Команды не знают бизнес-контекста, вы незаменимы, и уход в отпуск парализует направление.
• Масштабирование процесса вместо структуры. Внедрили фреймворк, не разобрав зависимости и владение.

Глубже: закон Конвея как инструмент руководителярасширенное

Мелвин Конвей сформулировал это в статье «How Do Committees Invent?» в журнале Datamation, апрель 1968 года: организации, проектирующие системы, вынуждены создавать проекты, копирующие их собственные структуры коммуникаций. Там же он делает вывод, который руководители часто пропускают: первый проект редко бывает лучшим, поэтому организация должна оставаться гибкой, чтобы проектировать эффективно.

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

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

Глубже: шаблоны документов направлениярасширенное

Три документа, без которых направление на 50+ человек держится на памяти руководителя.

Карта направления (одна страница, обновляется раз в квартал):

Команда | Тип (поток/платформа/помогающая/подсистема) | Тимлид | Человек
Чем владеет (сервисы, домены) | Ключевые взаимодействия и режим
Цели квартала (1-3) | Главный риск

Матрица решений (одна страница, пересматривается раз в полгода):

Решение                         | Кто решает      | С кем советуется | Где записано
Найм и увольнение тимлида       | руководитель    | HR, команда      | кадровая система
Структура и границы команд      | руководитель    | тимлиды, архитектор | записка + ADR
Выбор СУБД, облака, языка       | архитектор      | тимлиды          | ADR
Внутренний API и библиотеки     | команда         | соседние команды | ADR команды
Порядок задач внутри квартала   | команда         | продукт          | трекер

Рассылка направления (раз в две недели): «Главное за две недели» (три пункта), «Что меняется и почему», «Люди» (пришли, ушли, сменили роль), «Инциденты и выводы», «Вопросы, на которые отвечу на собрании».

Коротко

• На масштабе вы управляете системой, которая делает работу: структурой, правилами решений, каналами информации и руководителями команд.
• Оргдизайн по Team Topologies: четыре типа команд (поток, платформа, помогающая, сложная подсистема) и три режима взаимодействия (совместная работа, как сервис, содействие), большинство команд это команды потока.
• Закон Конвея: система копирует структуру коммуникаций, поэтому структура команд это архитектурное решение.
• Встречи через уровень дают второй канал правды, если они регулярные, согласованы с тимлидом и закрывают петлю.
• Найм на масштабе это поток с единой шкалой, калибровкой интервьюеров и цифрами воронки.
• Коммуникации: регулярная рассылка, общее собрание с ответами на неудобные вопросы, решения в документах.
• Буфер фильтрует шум, но не контекст: команды должны знать причины своей работы.
• Решения типа 2 (обратимые) отдают командам; «две пиццы» это про владение и автономию, а не только про размер.
• Сначала убрать зависимости оргдизайном, потом выбирать SAFe, LeSS или гибрид.

Что почитать дальше

• Структура команды и владение системами - как резать команды и раздать владение.
• Делегирование, встречи один на один и рост инженеров - уровни передачи решения и один на один.
• Масштабирование Agile: SAFe и LeSS - подробный разбор фреймворков и обратный манёвр Конвея.
• Найм инженеров и ввод в работу - отбор и первые тридцать дней.
• Стейкхолдеры: как управлять ожиданиями - единая точка входа и статус для бизнеса.
• Метрики команды - что меряют на уровне команды и направления.