CEO о здоровье инженерной команды (без технического жаргона)

Большинство нетехнических CEO относятся к инженерии либо как к чёрному ящику, либо как к театру. CEO-чёрный-ящик спрашивает «как дела у инженерки?» на исполкоме, принимает ответ «идём по плану» и через четыре квартала удивляется, когда уходит архитектор, а роадмап встаёт. CEO-театр становится самодеятельным инженерным менеджером — учит DORA-метрики, неправильно произносит «Kubernetes» и превращает любое обсуждение roadmap в технический спор, за которым сам не успевает.

Ни то ни другое — не про интеллект. Это про отсутствие короткого нетехнического словаря для оценки здоровья инженерии. First Round State of Startups 2023 показал, что 68% CEO-первопроходцев считают себя «скорее» или «очень» зависимыми от CTO по любым инженерным решениям — это нормально, пока CTO не уходит или не расходится с советом директоров во взглядах.

Этот гайд — минимальный словарь CEO: 6 вопросов, позволяющих проверить здоровье инженерии без попытки стать техническим.

{/* truncate */}

Что CEO действительно должен знать

Вам не нужно знать, что такое pull request. Вам нужно знать, шипит ли команда, учится ли, восстанавливается ли после ошибок и будет ли здесь через 12 месяцев. У этих четырёх вещей есть нетехнические прокси. Если CTO отвечает на них простым языком — инженерная функция, вероятно, здорова. Если ответы уклончивые или оборонительные — это сигнал.

Инженерные дашборды созданы для инженерных лидеров. На них DORA, частоты деплоев, покрытие тестами. CEO, уставившийся в такой дашборд, находится не в том режиме: вы не пытаетесь управлять инженерией, вы пытаетесь доверять инженерии. Это разные задачи.

McKinsey в Developer Velocity 2022 отследили 440 компаний и выяснили, что инженерные организации верхнего квартиля опережают нижний квартиль по росту выручки в 4-5 раз. Авторы аккуратно заметили, что измеримые драйверы — в основном культурные: удовлетворённость инструментами, скорость onboarding, ясность менеджмента. Не инфраструктурные траты. Не численность. Культура.

CEO может читать культуру. CEO обычно не может читать Kubernetes. Начинайте с силы.

6 вопросов, которые должен задавать любой CEO

Инженерный цикл CEO. Не на каждый вопрос нужен дашборд; на большинство — разговор. Данные приходят, только когда разговор теряет ясность.

1. «Мы удерживаем наших лучших инженеров или теряем?»

Самый предсказательный сигнал здоровья инженерии — удержание senior-инженеров. Не junior. Не средних. Верхние 20% команды. Это те, кто может легко уйти, глубоко знает кодовую базу, и чей уход заставляет 6-12 месяцев перестраивать институциональное знание.

Цифры, которые квартально запрашивать у CTO:

• Сколько инженеров уровня senior и выше ушли за последние 12 месяцев?
• Сколько пришло того же уровня?
• Какой медианный стаж текущих сеньоров?

Здоровая B2B SaaS-команда теряет 8-15% сеньоров в год (агрегат Stack Overflow 2024). Выше 25% — кризис, даже если дашборд CTO зелёный. Ниже 5% — тоже сигнал: либо компенсация выше рынка и вы переплачиваете, либо топ-перформеры не растут и рано или поздно уйдут кластером.

2. «Команда шипит или просто занята?»

Видимая активность — встречи, сообщения в Slack, закрытые Jira-тикеты — не равна шипу. Deloitte в исследованиях knowledge workers фиксирует различие: метрики активности слабо коррелируют с бизнес-исходами; метрики доставки — сильно.

Спрашивайте: «Что мы зашипили клиентам в этом квартале и что клиенты с этим сделали?» Хорошие ответы называют конкретные фичи и конкретные числа по использованию. Плохие — закрытые тикеты или замерженные PR. «Зашипили 127 тикетов» — vanity-метрика; «зашипили multi-currency billing, 23% платящих клиентов активировали его в первый месяц» — метрика здоровья.

Специфический для CEO тест: поймёт ли член совета директоров ответ CTO без переводчика? Если да — команда, скорее всего, шипит outcomes. Если нет — команда оптимизирует активность.

3. «Что горит, о чём вы мне не говорите?»

Единственный вопрос, который задаёт хороший CEO и избегает плохой. У инженерии всегда есть латентные кризисы — стареющие базы, зависимости, выходящие из поддержки, security-долги, ключевой подрядчик, чей контракт заканчивается через 60 дней. Ничего из этого не видно в sprint board.

Спрашивайте квартально: «Если бы я дал тебе безусловную двухнедельную паузу на инженерию, что бы ты исправил?» Ответ показывает, тихо ли абсорбирует риск CTO. Ответ «ничего срочного» обычно неверен — что-то всегда есть. Продуманный ответ с одним-двумя пунктами — признак здоровья.

Антипаттерн — длинный список. Если CTO перечисляет 8 пунктов, он перегружен и не защищал вас от списка.

4. «Где команда тратит время и где она должна?»

Держатели бюджета следят «куда идут деньги». CEO должны следить «куда идёт инженерное время», потому что для большинства B2B SaaS-компаний инженерное время — более жёсткое ограничение, чем инженерные деньги.

Три корзины стоит знать:

• Новые фичи (по роадмапу, обращённые к выручке)
• Поддержка и сопровождение (багфиксы, эскалации клиентов, keeping the lights on)
• Внутренняя платформа / техдолг (рефакторинг, инфраструктура, тулинг)

Здоровое распределение для Series A-B B2B SaaS — примерно 55% фичи, 25% поддержка, 20% платформа. На Series C+ доля фич падает, платформы растёт. Если инженерная команда тратит >40% на поддержку — у вас проблема с качеством или техдолгом. Если <10% на платформу — копите проблемы для следующего цикла CEO.

PanDev Metrics отслеживает этот сплит через IDE- и Git-телеметрию, скрещенную с типами тикетов, — сплит считается автоматически, а не по self-report. Почему автоматизация важна: self-report всегда радужнее реальности. Инженеры подстраиваются под «мы roadmap-heavy», потому что им сказали, что руководство хочет это слышать. IDE heartbeat данные рассказывают другую, более actionable историю.

5. «Сколько нужно новому инженеру, чтобы стать продуктивным?»

Время onboarding — скрытая, но несущая метрика здоровья. Она говорит две вещи сразу: сколько институционального знания не задокументировано, и сколько слаба у текущей команды на инвестиции в следующее поколение.

Бенчмарк: новый middle-инженер должен выкатить первый осмысленный merged PR в течение 2 недель и достичь 70-80% средней продуктивности команды за 8-12 недель. Команды с 16+ недель ramp-up — обычно либо недоукомплектованы, либо работают с недокументированной кодовой базой; оба — долг здоровья.

Спрашивайте CTO: «Когда мы наняли [последнего senior-инженера], сколько прошло до самостоятельной работы?» «3-4 месяца» — типичная команда. «Не знаю, он ещё онбордится шесть месяцев» — проблема, компаундящая с каждым наймом. Подробнее в статье про onboarding.

6. «Когда что-то ломается, как быстро восстанавливаемся?»

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

Спрашивайте после ближайшего продового инцидента: «Что было бы, если бы этот же баг случился через полгода? Мы бы поймали его быстрее, медленнее или так же?» Здоровая инженерная команда ускоряется со временем; post-mortem'ы порождают изменения, изменения накапливаются. Нездоровая команда получает один и тот же баг трижды в год и каждый раз объясняет его заново.

Это культурное чтение, а не числовое. Роль CEO — задать вопрос. Хорошая культура post-mortem — один из сильнейших индикаторов здоровья инженерии, доступных нетехническому лидеру.

Красные флаги: сигналы, что всё хуже, чем кажется

Следите за этим — они показывают, что с инженерией беда, даже если дашборды зелёные:

• «Мы пивотимся в AI в этом квартале», объявленное CTO без ясной связи с клиентом или выручкой. Часто — признак, что реальная velocity неотгружаема, и «AI pivot» — прикрытие.
• Senior-инженеры замолкают на встречах. Когда топ-люди затихают, они уже ментально уволились. Физическое увольнение следует в 6-9 месяцев.
• Паттерн «героя». Один инженер спасает каждый релиз. Герои — failure mode, не success mode: это значит, что процессы без них не работают, и они выгорят.
• Roadmap переигрывается чаще квартала. Иногда репланировать — нормально; постоянно — значит, вы не знаете, на что способна команда.
• «Это сложно» в каждом техническом ответе. Часть вещей сложные. Большинство — нет. CTO, говорящий «это сложно» на >50% ваших вопросов, либо прячется, либо плохо коммуницирует, либо и то и другое.

Как действовать

Немедленно (на этой неделе)

• Запланировать 30-минутный разговор с CTO. Структурировать по вопросам 1, 3, 5.
• Попросить HR данные по удержанию senior-инженеров отдельно от общего. Большинство дашбордов смешивает.

Краткосрочно (в этом квартале)

• Сделать «что горит» постоянным пунктом на 1:1 с CTO.
• Согласовать таргет распределения feature/maintenance/platform и трекать факт против таргета.
• Прочитать один инженерный post-mortem в квартал от начала до конца. Не нужно понимать всю технику; нужно понять, как команда рассуждает о сбое.

Долгосрочно (в этом году)

• Ввести в ближний круг одного технического со-основателя или советника, не CTO. Нужен второй взгляд на инженерию, независимый от отчётной линии.
• Калибровать ваше чтение здоровья, сверяясь с 2-3 peer-CEO в компаниях аналогичной стадии. Бенчмарки без peer-контекста обманчивы.

Метрики (простая версия)

Метрика	О чём говорит	Здоровый диапазон
Удержание senior-инженеров (12 мес)	Верят ли топы в компанию	85-95%
Feature / Maintenance / Platform split	Куда реально уходят часы	~55 / 25 / 20% для SaaS A-B
Onboarding до осмысленного PR	Здоровье институционального знания	Меньше 2 недель
Тренд MTTR	Учится ли команда на инцидентах	Уменьшается год к году
Каденс 1:1 senior-инженера с CTO	Раннее предупреждение	Минимум еженедельно
Частота репланирования	Предсказуемость доставки	Квартал или реже

Шесть чисел. Ни одно не требует читать дашборд. На все CTO обязан иметь ответ.

Честное ограничение

Фреймворк лучше всего работает для B2B SaaS между Series A и Series C. На более ранних стадиях слишком мало точек данных (в команде из 3 инженеров нет «senior retention rate» — это 0% или 100%). На более поздних стадиях структура такая, что «спроси CTO» не масштабируется после 200 инженеров — нужны VP-уровень и адаптация фреймворка.

Наши данные: мы видим числа по вопросам 4-6 в масштабе 100+ B2B SaaS-компаний. Вопросы 1-3 опираются на разговоры с клиентами и опубликованные исследования, а не в первую очередь на наш датасет. Если вы в стартапе 20-30 человек, относитесь к этому как к точке отсчёта, а не к scoreboard.

Контрарная точка

Каждый инженерный блог говорит CEO «выучи DORA» или «пойми deployment frequency». Я — нет. CEO, заучивший DORA без понимания «зачем», принимает худшие решения, чем тот, кто остаётся в рамке бизнес-outcome. Ваша работа как CEO — не понимать инженерию. Она — построить доверительные отношения с тем, кто понимает, и знать, когда сигнал этих отношений деградирует.

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

Похожие материалы

• Как обосновать CFO найм 5 разработчиков — CFO-ответная версия этого гайда
• CTO Dashboard — на что CTO должен смотреть еженедельно (чтобы вам не пришлось)
• 5 паттернов данных, кричащих о выгорании разработчика — ранние сигналы, которые иначе упустите
• Внешнее: McKinsey Developer Velocity Index — definitive CEO-level кейс, почему качество инженерии — бизнес-вопрос