Stakeholder Management

«Я просто хочу делать SRE-работу, не хочу заниматься политикой» — эту фразу я регулярно слышу от старших SRE. Обычно она означает, что в следующем квартале команда упрётся в нехватку headcount, в отсутствие поддержки руководства на вложения в надёжность или в freeze, который наверху никто не принял всерьёз. Stakeholder Management — это не «политика». Это работа с не-инженерными людьми, от которых зависят решения о надёжности: product management, executives, finance, legal, customer success, sales. Граница с Dev Team Partnership явная: тот лист — инженеры с инженерами (общие ритуалы, embedded SRE, общая ответственность за код); этот — инженеры с не-инженерами (объяснить error budget продакт-менеджеру, обосновать сокращение расходов на $200k перед финансами, договориться с юристами о публикации постмортема).

Главный навык внутри этой компетенции — перевод. Нарушение SLO → $X потерянной выручки; toil 60% → три инженеро-недели в месяц, уходящие в никуда; вложение в надёжность → окупаемость за полтора года на несостоявшихся инцидентах. Без перевода SRE-команда остаётся «теми, кто говорит на непонятном языке», и её приоритеты проигрывают на планировании всему, что сформулировано понятнее. С переводом она становится голосом, который слышат, и надёжность получает устойчивые вложения. Я считаю это самым недооценённым навыком старшего SRE: выглядит как soft skill, а без него техническое мастерство не выходит за пределы одной команды.

Что должен уметь

Главный навык на уровне L5 — переводить технические показатели в числа, значимые для бизнеса, так, чтобы стейкхолдер мог принять решение. Не «у нас burn rate 14×» (стейкхолдер не знает, что это), а «текущее ухудшение означает потерю SLO к концу квартала, это примерно $200k потерянной выручки, если объявляем freeze, и около $50k, если нагоняем на следующем спринте». Не «toil 70%», а «команда тратит 28 engineer-weeks в год на ручную работу, которую можно автоматизировать за 4». Я регулярно вижу старших SRE, которые приходят к руководству с техническими цифрами и удивляются, что решение не принимается — потому что цифры нерелевантны для уровня этого стейкхолдера.

Идентифицирует стейкхолдеров для своего сервиса / проекта: product manager, exec sponsor, finance owner, customer success contact. Знает, кто принимает решения о приоритетах, бюджете, доступе.
Переводит технические показатели своего сервиса на язык бизнеса: SLO → влияние на клиента, простой → потерянная выручка, toil → упущенное время инженеров. Не использует SRE-жаргон без объяснения.
Готовит короткую сводку для встречи с продуктом или руководством: 2-3 цифры + что они означают + какое решение он просит. Не презентация на 20 слайдов; не «всё хорошо / всё плохо» без контекста.

Проектирует карту стейкхолдеров для своей SRE-функции: кто, в какой роли, с какой периодичностью общаемся, что запускает эскалацию. Не «у меня в голове»; явный документ, который можно показать новому инженеру.
Держит регулярный ритм с теми, кто есть на карте: раз в неделю с продуктом, раз в месяц с руководством, раз в квартал с советом директоров (где он есть). У каждой встречи повестка, точки решения и follow-up.
Говорит «нет» с данными: «эта фича требует X недель работы над надёжностью перед запуском; иначе вероятность SEV1 в первом квартале — N%, историческая цена — $Y». Без данных «нет» — это запрет; с данными — переговоры.
Аргументирует вложения в надёжность (люди, инструменты, инфраструктура) в логике бизнеса: срок окупаемости, несостоявшиеся инциденты × их цена, удержание клиентов. Не «нам нужно больше».

L6+

Управляет SRE-функцией как продуктом перед руководством: дорожная карта, OKR, бюджет, планирование найма, метрики успеха. Ведёт квартальный обзор функции для бизнеса.
Ведёт переговоры о надёжности с C-level и советом директоров: обязательства по SLA для крупных клиентов, вложения под требования регулятора, оценка надёжности при слияниях, стратегия публичных сообщений об авариях.

Материалы

Книги

Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018). SRE-специфика разговора со стейкхолдерами разбросана по главам про SLO и про внедрение SRE в организации: чьи SLO обсуждаются с кем, как договариваться о целях надёжности с продуктом и руководством.
Camille Fournier — The Manager’s Path (O’Reilly, 2017), главы про tech lead и engineering manager. Не про SRE, но разбирает разговор с не-инженерами на уровне tech lead, и старшему SRE это переносится один в один.
Will Larson — Staff Engineer (2021). Главы «Writing an engineering strategy» и «Staying technical»: как старший инженер влияет на решения через тексты и доказательства, не уходя в руководители.

Статьи и доклады

Charity Majors — Reasons Not to Be a Manager (charity.wtf). Не про stakeholder management напрямую, но про то, на каких языках говорят разные роли в организации и почему инженеру не стоит путать влияние с должностью. Главное: разные стейкхолдеры решают разные вопросы, одно и то же сообщение работает по-разному.
Larson, Daniel & Donskoi — Engineering Strategy (lethain.com). Серия статей о том, как формулировать инженерную стратегию для руководства. SRE-функция — частный случай.
Mathias Lafeldt — Communicating SRE: Influence Without Authority. Один из немногих публичных текстов, где работа SRE со стейкхолдерами описана осознанно, а не по касательной. Полезен как ориентир направления, не как методичка.
Мой разбор — Надёжность строится в диалоге с бизнесом (jtprog.ru, май 2026). Ровно про перевод, которому посвящён этот лист: как переводить девятки в деньги, что отвечать на «бизнесу нужно 100% доступности» и какие метрики SRE-команды осмысленно показывать руководству, когда продуктов много. Пять кейсов разобраны репликами, а не тезисами, — это ближе к тому, как разговор идёт на самом деле.

Инструменты

Карта стейкхолдеров / матрица RACI — одна таблица: стейкхолдер × зона ответственности (по каким решениям он Responsible / Accountable / Consulted / Informed). По моим наблюдениям, самый дешёвый артефакт практики и одновременно самый ценный. Висит на видном месте у команды, обновляется при смене ролей или структуры организации.
Шаблон квартального обзора (QBR) — документ для квартальной встречи с руководством: показатели (SLO, MTTR, доля toil, частота деплоев), что улучшилось, что ухудшилось, ключевые риски, запросы (люди, бюджет, решения). Не презентация, а связный текст с цифрами. Формат Amazon 6-pager хорошо ложится как основа.
Шаблон ежемесячной сводки — одна страница для продукта и руководства: что произошло, что из этого важно, какое решение открыто. Раз в месяц на каждое имя из карты. Без шаблона сводки пишутся от случая к случаю и теряют сигнал.
Внутренняя шпаргалка по переводу — короткий документ: SRE-метрика ↔ её перевод на язык бизнеса для типовых ситуаций. Нарушение SLO → $X (если известна выручка в минуту), доля toil → инженеро-недели за квартал, MTTR → часы, которые клиент провёл в проблеме. Полезна младшим инженерам и для быстрой подготовки сводок.

Best practices

Главный публичный кейс, который полезно прочитать рядом с книгой — эволюция Google SRE от технической команды к функции, встроенной в бизнес, описанная в SRE Workbook гл. 32. На раннем этапе Google SRE общался с product engineering — это покрывалось Dev Team Partnership. По мере роста (десятки сервисов, многомиллионная инфраструктура, внимание регуляторов) потребовалась постоянная работа с не-инженерными стейкхолдерами: VP Engineering, финансы (разбор затрат), юристы (реакция на инциденты), регуляторы. SRE Workbook кодифицирует эту эволюцию через концепцию «multiple SLO audiences» — customer SLOs (для customer success / sales), internal SLOs (для product), infrastructure SLOs (для тех, кто живёт на платформе). Не «один SLO для всех», а разные представления одних и тех же данных для разных стейкхолдеров. Это и есть Stakeholder Management в SRE-контексте.

Короткие правила:

«Нет» без данных — запрет, «нет» с данными — переговоры. Фраза «эту фичу нельзя запустить, она ломает надёжность» читается на той стороне стола как «SRE мешает работать». Та же мысль с числами звучит иначе: «запустить можно через четыре недели работы над надёжностью; если катим сейчас, исторически в N% случаев мы получаем SEV1 в первом квартале, средняя цена — $X. Какой вариант берём?». Дальше разговор идёт про размен, а не про запрет.
Stakeholder map — явный документ, не «в голове». Пока карта контактов живёт в голове у каждого старшего инженера отдельно, младшие не знают, к кому идти, а ротация команды стирает эти знания за год. Матрица RACI на одну страницу, обновляемая при изменениях в организации, стоит дёшево и снимает вопрос.

Перевод я считаю не опциональным умением, а частью работы. Позиция «я инженер, я говорю метриками, пусть руководство разбирается» звучит честно и проигрывает на первом же планировании: там выигрывает тот, чьи аргументы уже сформулированы на языке принимающего решение. Значит, метрика переводится до встречи, а не по запросу на встрече. Это десять минут подготовки против квартала недофинансирования.

Подробнее:

Перевод — самый недооценённый навык старшего SRE. Я регулярно вижу инженеров с глубокой технической экспертизой, чьё влияние в организации застряло, и объясняют они это тем, что «не любят политику». Дело не в политике. Дело в том, что человек приходит к стейкхолдеру с цифрами, которые тот физически не может превратить в решение. SLO 99.9% для финансового директора не значит ничего. «$50k ожидаемых потерь в следующем квартале при текущем burn rate» — значит, и решение принимается прямо на встрече. Умение звучит как soft skill, а на деле это скучное упражнение: для каждой метрики команды заранее держать готовый перевод на язык бизнеса.

Регулярность важнее одной удачной встречи. Я наблюдаю устойчивый паттерн: команды, которые видятся с продуктом и руководством по расписанию (раз в неделю с одними, раз в месяц с другими), получают ресурсы без драмы и нормальный разговор о приоритетах. Те, кто приходит наверх только когда горит, получают реакцию по факту и недополучают вложения. Регулярность копит доверие. Стейкхолдер привыкает, что SRE приносит внятную сводку, и в момент, когда решение нужно срочно, у него уже есть и доверие, и контекст. Без этого каждый срочный разговор начинается с нуля.

Карта стейкхолдеров у инженеров разного уровня разная, и дело не в том, что младшим чего-то нельзя. Младший инженер работает с продуктовой командой своего сервиса. Старший — ещё и с финансами по затратам, с юристами по внешней коммуникации об инцидентах, с customer success по разговорам об SLA. На уровне staff добавляются C-level и совет директоров. Это разделение труда по уровню решений, и путаница в нём ломается в обе стороны: либо младший пытается влиять на решения, до которых у него нет ни полномочий, ни контекста; либо staff вручную разбирает обсуждения уровня продуктовой команды. Карта, где напротив роли выписан её стейкхолдер, снимает вопрос.

Отказ с данными сохраняет отношения лучше, чем согласие без них. Распространённое опасение звучит так: скажу «нет» — перестанут уважать и звать. Я устойчиво наблюдаю обратное. Инженеры, которые систематически отвечают «да, сделаем» на то, что вытянуть не могут, выгорают за год-два и оставляют за собой невыполненные обещания. Команды, которые приучили стейкхолдеров к «нет» с конкретным обоснованием и альтернативой, через два-три года весят на планировании заметно больше, потому что их «да» означает реальное обязательство. Это не негативизм, а трезвое обращение со своим ресурсом.

Отдельная история — перевод в деньги. Я регулярно вижу старших SRE, которые не могут ответить, во сколько компании обходится минута простоя и за какой срок окупится $200k, вложенные в платформенные инструменты. Сами по себе эти числа не появляются. Их считают: выручка в минуту от финансов плюс отток клиентов на LTV для простоя, сэкономленные инженеро-недели на полную стоимость инженера для инструментов. Один раз сев за эту арифметику вместе с финансами, инженер получает словарь на все будущие разговоры. Без него вложения в надёжность выглядят как расходы без понятного возврата, и запрос на бюджет уезжает в конец очереди.

Связанные листья

Dev Team Partnership — работа с инженерами — частный случай той же практики; здесь охват шире, потому что добавляются не-инженеры. Разделение простое: там инженеры с инженерами, здесь инженеры с остальными.
SLO / Budget Review — основной регулярный ритуал, где перевод с инженерного на язык бизнеса происходит на практике; по составу участников и качеству этой встречи видно, как в команде устроена работа со стейкхолдерами.
DORA Metrics — DORA-числа — один из лучших источников метрик, которые легко переводятся на язык бизнеса; частоту деплоев и время до продакшена руководство понимает легче, чем p99 latency.
Cloud Cost Control — перевод в деньги — отдельная её часть; финансы — та сторона, к разговору с которой готовятся отдельно.
DR Policy & Stakeholders — карта стейкхолдеров для DR-сценариев — частный случай: управление по заранее описанному сценарию в момент аварии. Здесь — про постоянную работу, там — про кризис.
Customer Communications — customer success, продажи и внешняя аудитория — стейкхолдеры внешней коммуникации; внутренняя работа с ними определяет качество внешней.
Career Ladders — работа со стейкхолдерами — критерий L5+ в большинстве вменяемых лестниц; трек staff/principal прямо требует влияния за пределами своей команды. Без этого критерия лестница становится плоской.
Team Topologies — режим взаимодействия (collaboration / X-as-a-Service / facilitating) определяет, с кем и как часто общаться; у платформенной команды карта стейкхолдеров другая, чем у embedded SRE.

Открытые вопросы

Стартап против крупной компании — в стартапе SRE часто говорит напрямую с CEO, в корпорации — через несколько уровней. Я не уверен, что здесь возможна универсальная практика: и ритм встреч, и способ перевода в этих контекстах разные. Если есть рабочая модель — расскажите PR’ом.
Текст против встречи — формат Amazon 6-pager хорошо работает там, где решения принимают на встречах; там, где работа асинхронная (GitLab и подобные), тот же контент живёт как страница handbook или RFC. Какой формат когда выбирать — отдельная подтема.
Продавать надёжность — отдельный навык — не перевод в деньги, а рассказ: как объяснить руководству, что вложение в надёжность — это вложение в продукт. Charity Majors и Larson писали об этом, но цельной публичной практики я не вижу. Возможно, отдельный лист «Reliability Storytelling» в будущем.