Главная·Витки роста·Виток 4·Блок 1. Построить operating system функции
Блок 3 из 11

Блок 1. Построить operating system функции

Почему процессы становятся главным рычагом

Контекст витка

Как перейти из lead в head: масштаб через людей и системы

Как перестать масштабировать себя и начать расти через людей, стандарты и управленческие контуры — практики перехода lead → head.

Блок 3 из 11

Если нужно снова увидеть весь маршрут, вернись к обзору витка.

Открыть обзор витка

Фокус этого блока

Почему процессы становятся главным рычагом

Раздел 1

Почему процессы становятся главным рычагом

На этом уровне вас оценивают не по личному исполнению. По предсказуемости результата всей управленческой линии.

Матрица перехода Лидер направления -> Руководитель руководителей:

АспектЛидер направленияРуководитель руководителей
Scope1-3 команды, одно направление5+ команд, несколько направлений
Горизонт решений1-3 года3-5 лет
Тип задачОпределяю, какие проблемы решатьСтрою систему, которая решает проблемы без меня
ВлияниеЧерез видение и стандартыЧерез руководителей и operating model
КоммуникацияКросс-функциональная, executiveGovernance, 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. Аудит (неделя 1-2): Опроси каждого руководителя -- как он планирует, отчитывается, эскалирует. Зафиксируй расхождения.
  2. Дизайн (неделя 3-4): Определи минимальный набор правил. Не 50 пунктов, а 5-7 ключевых.
  3. Согласование (неделя 5): Обсудите с руководителями. Дай им влиять на дизайн — вовлечённость (buy-in) критична.
  4. Пилот (месяц 2): Запустите на 1 цикл (месяц), собери обратную связь.
  5. Калибровка (месяц 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)
Кризисные (угроза бизнесу)ВыБерёте на себя, информируете наверх

Как внедрить:

  1. Составь список типичных решений за последний месяц
  2. Классифицируй по матрице выше
  3. Для каждого типа определи: кто решает, в каких границах, когда эскалирует
  4. Проговори с каждым руководителем: «Вот что вы решаете сам. Вот когда приходите ко мне»
  5. Через месяц ревью: где работает, где нет

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

Инструмент #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).


Следующий шаг

Если нужно расти через систему, руководителей и устойчивые управленческие контуры.

Следующий блок