Совет директоров: вопросы по инженерии
Series-B презентация совету в 2023 пошла под откос, когда директор — бывшая VPE GitHub — задала CTO три вопроса подряд, к которым он не был готов. Он знал deployment frequency и размер команды. Он не знал median lead time, скорость найма против плана и долю инженерного фонда от operating burn. Совет не урезал инженерку, но добавил квартальный engineering review с другим CTO на созвоне. Встреча стала экзаменом, который команда сдала, а CTO нет.
К совету готовиться сложнее, чем к инвесторам, — у них больше контекста и меньше терпения. Это список вопросов — что реально спрашивает работающий совет, что CTO должен принести без спроса, и красные флаги, которые опытный директор ловит за 15 минут. Собрано из разговоров с CTO, которые успешно презентовали, с CTO, которые провалились, и с двумя директорами, сидящими в инженерно-тяжёлых портфелях.
{/* truncate */}
Что совету реально нужно знать
Совет — не менеджер инженерной команды. Это аудиторы плюс инвесторы инженерной организации. Три вопроса в любой момент:
- Инженерная ёмкость превращается в продукт и выручку с разумной скоростью?
- Команда достаточно хорошо устроена, чтобы уход основателя её не расплавил?
- Есть ли именованные риски (key-person, security, regulatory), которыми управляют, а не прячут?
Всё остальное вытекает из этих трёх. Deployment frequency — не board-метрика; это диагностический инструмент, если возникло подозрение, что первый вопрос проваливается. Lead time — тоже не board-метрика. Board-метрики на уровень выше и на уровень более финансовые.
Stanford, исследование эффективности советов 2023 (David Larcker, Brian Tayan): советы в среднем тратят 18% времени встреч на технологический надзор — но только 9% из этого времени реально разбирают инженерные решения. Остальное — security-апдейты и AI-стратегия. Эти 9% — окно, чтобы объяснить, что реально происходит под капотом.
Board-ревью — это пять связанных разговоров, не дамп данных. Каждый ответ зарабатывает время на следующий.
12 вопросов, которые должен задать совет — и что говорит ответ
Категория 1: Delivery health (мы вообще шипим?)
1. Какой был deployment frequency прошлый квартал, куда тренд?
- Хороший ответ: «В среднем X в неделю, +30% QoQ, потому что мы консолидировали три release trains».
- Флаг: «Я… надо свериться». CTO не знает = CTO не управляет фабрикой.
2. Какой lead time для changes — от commit до prod — и где ломается?
- Хороший: «Медиана 2.1 дня. Хвост — code review, P90 4.8 дня, из-за двух ревьюеров, зажатых в merger-integration rebuild».
- Флаг: нет медианы, нет P90, нет названного bottleneck. Бэйзлайн — в нашем гайде по внедрению DORA.
3. Какой change failure rate и MTTR?
- Хороший: «CFR 8% (ниже индустриальных 15% по DORA 2024). MTTR 42 минуты. Скользящий квартал».
- Флаг: «Мы пока не трекаем инциденты по severity».
Категория 2: Team capacity (хорошо ли тратим людей?)
4. Какая доля инженерии в operating burn, куда тренд?
- Хороший: «62% burn, держим флэт QoQ, output-метрики при этом +18%».
- Флаг: «Надо уточнить у финансов». Связка инженерии и финансов — базовый маркер зрелости.
5. План найма vs факт — какой close rate по оферам?
- Хороший: «Планировали 14 хайров, закрыли 11. Acceptance упал с 68% до 52% — связано с отставанием comp-band, предложение в работе».
- Флаг: числа найма без acceptance rate и time-to-fill.
6. Какая инженерная утилизация — billable / feature vs platform vs support vs KTLO?
- Хороший: «58% feature, 22% platform, 12% support, 8% KTLO. KTLO был 14% прошлый квартал, снизили, убив два legacy сервиса».
- Флаг: одна цифра («мы на 90% продуктивны»). Эта цифра всегда неверна.
Категория 3: Risk register
7. Какая концентрация key-person риска?
- Хороший: «Три системы имеют bus factor 1. Миграция-план на Q3. Задокументирован в onboarding».
- Флаг: «Все могут заменить всех» — всегда враньё.
8. Топ-3 security-риска, которые вы трекаете, — не те, что в новостях?
- Хороший: конкретные CVE, конкретные third-party зависимости, конкретные pending pentests с известными findings.
- Флаг: экскурсия по контролям SOC 2. Это product security разговор, не инженерный risk-разговор.
9. Паттерн инцидентов за 12 месяцев — severity, кластеры корневых причин?
- Хороший: «7 Sev-1, 4 из-за database hot-spot, который мы уже починили, 2 из-за third-party outages, добавили fallback, 1 человеческая ошибка в деплое, которая привела к policy freeze-window».
- Флаг: количество инцидентов без распознавания паттернов.
Категория 4: Инвестиции и стратегия
10. Дам вам 3 сеньорных инженера сегодня — куда пойдут и что будем мерить через 90 дней?
- Хороший: конкретная команда, конкретная проблема, конкретная метрика (например, «reliability engineering, уменьшить database hot-spots, MTTR с 42 до <30 мин»).
- Флаг: «Распределю по командам». Это не план, это размещение.
11. Какой у вас engineering "stop doing" список?
- Хороший: два legacy сервиса на депрекейшн, один внутренний инструмент на убийство, одна framework-миграция, которую мы поставили на паузу.
- Флаг: такого списка нет. Инженерные организации без stop-doing списка накапливают работу.
12. Что команда сделала бы по-другому, если бы компания была ×3 по размеру?
- Хороший: честный ответ, показывающий, что CTO думает на два шага вперёд («централизовать SRE; сейчас у каждой продуктовой команды part-time SRE, не масштабируется»).
- Флаг: «Мы готовы к масштабу». Нет, не готовы. Никто не готов.
5 слайдов, которые зарабатывают больше времени
Слайд 1: Единственное число, суммирующее инженерный output (выбор ваш — deployment frequency, lead time, roadmap % hit) тренд за 4 квартала.
Слайд 2: Delivery scorecard — DORA-метрики с однострочным комментарием на каждую.
Слайд 3: Таблица ёмкости — headcount по командам, % на feature vs platform vs support, план найма vs факт.
Слайд 4: Risk register — топ-5 рисков, владелец, митигация, дедлайн. Включите один риск, который пока не можете митигировать, — выглядите честнее.
Слайд 5: Запрос. Одно конкретное, что вам нужно от совета в этом квартале (хайр, исключение, санкция политики). Если запроса нет — вы не используете совет.
Не превышайте 5 слайдов. Каждый лишний разбавляет внимание. Время совета — дефицитнее любого бюджета.
Красные флаги, которые опытный директор ловит за 15 минут
| Сигнал | Что означает |
|---|---|
| CTO говорит «мы вот-вот начнём трекать X» | Об этом спрашивали и в прошлом квартале |
| Инженерный headcount +40% YoY, output флэт | Классическая ловушка масштабирования (закон Брукса) |
| Каждый инцидент — внешняя причина | Команда не владеет своей reliability |
| Продуктивность измеряется в коммитах, PR, LoC | CTO меряет активность, а не output |
| Нет явного stop-doing списка | Организация добавляет работу, не вычитая |
| В инженерной roadmap нет «platform» доли | Feature-debt накапливается, будущее замедление |
Как CTO готовиться
За 2-3 дня до встречи:
- Каждая DORA-цифра в двух формах: медиана и P90. Директора с инженерным бэкграундом спрашивают хвост. Без бэкграунда — примут медиану.
- Подготовьте одну честную слабость. «Область, куда инвестировал бы больше» или «риск, в котором меньше всего уверен». Обезоруживает директора, ищущего слепые пятна.
- Тренируйтесь на 30-секундной версии каждого ответа. Советы терпят 90 секунд, нетерпеливы после. 3 минуты ответа = вы не усвоили.
- Принесите один конкретный запрос. Совет существует, чтобы санкционировать то, что менеджмент сам не санкционирует — comp-bands, реорганизации, крупные хайры, стратегические пивоты. Не тратьте встречу.
Как PanDev Metrics вписывается в подготовку
Два прямых применения:
Еженедельный CTO-дашборд. Наш CTO-дашборд сводит delivery, team health и cost в одностраничный вид без аналитика. Это становится слайдом 2 без недели раскопок. Несколько наших enterprise-клиентов открывают дашборд прямо на board-созвоне.
Cost-per-feature для слайда ёмкости. Совет хочет видеть доллары. Наш расчёт cost-per-feature (из tracked time × hourly rate по 100+ B2B-клиентам) превращает «мы зашипили фичу X» в «зашипили фичу X за $48k против средних $61k прошлого квартала». С таким числом совет уже может работать.
Мы не единственный способ это сделать, но один из немногих, кто собирает это из IDE-телеметрии, а не из self-report. Числа сопротивляются инфляции, потому что разработчики не заполняют тайм-шиты; данные идут из редактора.
Честный лимит
Наш датасет смещён к организациям 50-500 инженеров в KZ, UZ, RU, US, SG, EU. Советы публичных компаний работают иначе — формальные audit committees, SEC-расписания, паттерны governance, которые эта статья не покрывает. 12 вопросов выше — от приватных советов на стадиях Seed до late-Growth. Если готовитесь к FAANG-adjacent публичному совету, механика похожа, формальность — нет.
Самый жёсткий тезис
Инженерные советы проваливаются в подготовке, а не на встрече. CTO, способный ответить на любой из 12 вопросов за 60 секунд, уже сделал организационную работу, чтобы заслужить ответ. CTO, скребущий числа накануне, признаётся, что операционный ритм не работает. Совет не заботят ваши метрики; их заботит, знаете ли вы свои метрики.
По теме
- CTO Dashboard: что показывать на еженедельном — еженедельный feed, который делает подготовку к совету простой
- Внедрение DORA за 2 недели — базовые числа, которые ожидает совет
- Размер команды и продуктивность: закон Брукса — для вопроса «почему output флэт при +40% headcount»
- Ramp-up онбординга разработчика — история митигации key-person риска
- Внешнее: Stanford Rock Center on Board Effectiveness — исследования Larcker/Tayan по tech oversight