Блок 1. Построить operating system функции
Почему процессы становятся главным рычагом
Контекст витка
Как перейти из lead в head: масштаб через людей и системы
Как перестать масштабировать себя и начать расти через людей, стандарты и управленческие контуры — практики перехода lead → head.
Блок 3 из 11
Если нужно снова увидеть весь маршрут, вернись к обзору витка.
Оглавление витка
- 1Быстрый обзор
- 2Старт: что меняется на этом витке
- 3Блок 1. Построить operating system функции
- 4Блок 2. Выстроить каскад ожиданий через руководителей
- 5Блок 3. План на 12 месяцев
- 6Блок 4. Где люди чаще всего застревают
- 7Блок 5. Пример из другой сферы
- 8Блок 6. Что открыть дальше
- 9Блок 7. Шаблоны и ресурсы
- 10Блок 8. Как понять, что вы готовы
- 11Блок 9. Следующие шаги
Фокус этого блока
Почему процессы становятся главным рычагом
Почему процессы становятся главным рычагом
На этом уровне вас оценивают не по личному исполнению. По предсказуемости результата всей управленческой линии.
Матрица перехода Лидер направления -> Руководитель руководителей:
| Аспект | Лидер направления | Руководитель руководителей |
|---|---|---|
| Scope | 1-3 команды, одно направление | 5+ команд, несколько направлений |
| Горизонт решений | 1-3 года | 3-5 лет |
| Тип задач | Определяю, какие проблемы решать | Строю систему, которая решает проблемы без меня |
| Влияние | Через видение и стандарты | Через руководителей и operating model |
| Коммуникация | Кросс-функциональная, executive | Governance, board-level, системная |
| Измерение успеха | Направление движется правильно | Функция предсказуемо даёт результат через менеджеров |
Признаки, что процессов не хватает:
- каждый руководитель управляет «по-своему», без общей модели;
- статус и метрики несопоставимы между командами;
- успех держится на 1–2 сильных менеджерах;
- вы постоянно тушите межкомандные конфликты и приоритетные аварии;
- при уходе одного менеджера его команда разваливается.
Инструмент #1: Operating System функции
Проблема: Каждый руководитель управляет как считает нужным. Нет единого языка, ритма и стандартов.
Решение: Описать и внедрить минимальную operating system -- набор правил, по которым работает вся функция.
Flight Levels как рамка для проектирования operating system. Klaus Leopold (Канбан-пионер, автор «Rethinking Agile» и со-автор «Kanban Change Leadership») в модели Flight Levels формализовал три уровня улучшения: FL1 — поток внутри команды, FL2 — координация между командами, FL3 — стратегический портфель. На вашем уровне главная работа — построить FL2: общие правила, ритуалы, метрики, по которым команды двигаются предсказуемо без вашего ручного контроля. В отличие от SAFe/Scrum@Scale, Flight Levels не предписывает роли — это рамка для дизайна под контекст (см. Heuristic: H6).
Что должно быть единообразно:
- единый ритм планирования (месяц/квартал);
- единый формат управленческих апдейтов;
- единые правила эскалации рисков;
- единые критерии «зелёный/жёлтый/красный» по инициативам;
- единые правила межкомандных передач (handoff).
Что НЕ нужно унифицировать:
- тактику исполнения внутри команды (менеджер решает сам);
- способ проведения встреч один на один (1:1) с сотрудниками;
- инструменты и процессы, специфичные для одной команды.
Принцип: Единые правила на выходе (результат, сроки, качество), свобода на входе (как именно команда работает).
Как внедрить Operating System:
- Аудит (неделя 1-2): Опроси каждого руководителя -- как он планирует, отчитывается, эскалирует. Зафиксируй расхождения.
- Дизайн (неделя 3-4): Определи минимальный набор правил. Не 50 пунктов, а 5-7 ключевых.
- Согласование (неделя 5): Обсудите с руководителями. Дай им влиять на дизайн — вовлечённость (buy-in) критична.
- Пилот (месяц 2): Запустите на 1 цикл (месяц), собери обратную связь.
- Калибровка (месяц 3): Исправь, упрости, убери лишнее. Закрепите.
Инструмент #2: Cadence управленческих ритуалов
Проблема: Нет регулярного ритма. Встречи хаотичны, решения теряются.
Базовый cadence:
- Еженедельно (30 мин): Краткая операционная синхронизация (short operating sync) — только ключевые риски и блокеры. Формат: каждый менеджер — 3 минуты: что красное, что нужно решить.
- Ежемесячно (90 мин): Операционный обзор (operating review) — портфель инициатив по статусу/ресурсам/зависимостям. Формат: системные метрики, калибровка команд, решения.
- Ежеквартально (полдня): Стратегическая сверка — пересборка приоритетов, обзор зрелости руководителей, преемственность (succession planning).
Каждый ритуал должен заканчиваться решением или ясным следующим шагом (clear next step). Если решения нет — встреча бесполезна.
Антипаттерн: Ритуалы ради ритуалов. Если еженедельная синхронизация (weekly sync) не даёт ценности 3 недели подряд — переформатируй или отмени.
Инструмент #3: Системные метрики
Проблема: Много данных, но непонятно, здорова ли система.
используйте ограниченный набор метрик (5-7), который отражает здоровье системы:
Метрики предсказуемости:
- Plan vs Actual по ключевым инициативам (% выполнения в срок)
- Доля инициатив, где риски были выявлены заранее (vs. «сюрпризы»)
Метрики управленческого качества:
- Доля инициатив с прозрачным владельцем и SLA
- Скорость межфункционального согласования
- Количество эскалаций, которые можно было предотвратить на уровне менеджера
Метрики здоровья команды:
- Retention ключевых людей
- Доля руководителей, готовых к расширению scope (succession pipeline)
Если метрика не ведёт к решению — убери её. Dashboards ради dashboards — пустая трата времени.
Инструмент #4: Делегирование через правила (рамка делегирования, Delegation Framework)
Проблема: Вы не можете отпустить контроль. Каждое решение проходит через вас.
Решение: Делегирование не задач, а полномочий по чётким правилам.
Матрица делегирования:
| Тип решения | Кто принимает | Что вы делаете |
|---|---|---|
| Тактические (внутри команды) | Руководитель команды | Не вмешиваетесь, если результат в рамках |
| Межкомандные (затрагивают 2+ команды) | Руководители совместно | Модерируете, если не могут договориться |
| Стратегические (меняют направление) | Вы с вкладом (input) от руководителей | Принимаете, но с консультацией (consultation) |
| Кризисные (угроза бизнесу) | Вы | Берёте на себя, информируете наверх |
Как внедрить:
- Составь список типичных решений за последний месяц
- Классифицируй по матрице выше
- Для каждого типа определи: кто решает, в каких границах, когда эскалирует
- Проговори с каждым руководителем: «Вот что вы решаете сам. Вот когда приходите ко мне»
- Через месяц ревью: где работает, где нет
Если руководитель принял решение в рамках своих полномочий и результат не тот — это ок, это обучение. Если вы каждый раз отменяете его решения — это микроменеджмент.
Инструмент #5: Управление конфликтами между руководителями
Проблема: Руководители команд конфликтуют по ресурсам, приоритетам, зонам ответственности. Вы постоянно арбитр.
Типичные конфликты:
- «Моя команда перегружена, потому что команда X не делает свою часть»
- «Приоритеты пересекаются, мы дублируем работу»
- «Руководитель Y принимает решения, которые затрагивают мою зону»
Протокол разрешения:
Шаг 1: Руководители решают сами (48 часов)
- Обязательная встреча двух руководителей
- Формат: проблема, варианты, решение, владелец, срок
- Если договорились -- информируют вас о решении
Шаг 2: Модерация (если не договорились)
- Вы модерируете, но НЕ решаете за них
- Формат: каждый излагает позицию, вы задаёте вопросы, они находят решение
- Ваша роль: убрать эмоции, вернуть к фактам и приоритетам
Шаг 3: Арбитраж (крайний случай)
- Вы принимаете решение
- Объясняете логику
- Фиксируете правило, чтобы в следующий раз этот тип конфликта решался на шаге 1
Цель: Со временем количество конфликтов, доходящих до шага 2 и 3, должно снижаться.
Роль руководителя на этом уровне
Ваша задача — не заменить менеджеров, а усилить их управленческий контур:
- упростить правила и убрать разночтения;
- обеспечить прозрачность зависимостей;
- выровнять качество управленческих решений между руководителями;
- создать среду, в которой менеджеры растут.
На каждом следующем уровне «реальный продукт» меняется. Camille Fournier (ex-CTO Rent the Runway, автор «The Manager's Path») описывает эту цепочку: у инженера «продукт» — код; у tech lead — техническая координация; у line manager — команда; у вас на уровне «руководитель руководителей» — команды команд и культура между ними. Главная ловушка перехода — продолжать делать «продукт предыдущего уровня». Признак, что вы попали в неё: вы по-прежнему лично разбираете технические или операционные задачи, которые должны решать ваши менеджеры (см. Evidence: E19).
Следующий шаг
Если нужно расти через систему, руководителей и устойчивые управленческие контуры.