VP of Engineering: плейбук первых 90 дней
Новый VP of Engineering попадает под микроскоп по трём осям: что он режет, кого оставляет и как быстро анонсирует план. Ошибка в порядке — и доверие улетает к 4-й неделе: организация решает, что вы либо реорганизатор, либо lame duck, ещё до того, как вы разобрались в кодовой базе. The First 90 Days Майкла Уоткинса — базовая книга, но она написана для руководителей вообще. У инженерных организаций есть специфические ловушки.
Контринтуитивный ход: в первые 30 дней анонсируйте меньше, чем вам кажется правильным. Не театр "listening tour" — реальная измеренная пауза, пока вы читаете календарь организации, историю инцидентов и deploy-пайплайн.
{/* truncate */}
Что VPE реально должен знать
VPE — не супер-senior IC. Работа в основном — системное проектирование, применённое к людям, не к коду. Три вещи, которые этот роль владеет эксклюзивно:
- Span of control — кто кому подчиняется, где неравномерная нагрузка, где single points of failure
- Delivery cadence — может ли организация шипать предсказуемо, без героизма
- Talent density — не headcount, а соотношение senior/mid/junior по командам
Опрос First Round Review (2024, 83 инженерных руководителя) показал: VP, которые были успешны долгосрочно, диагностировали проблему talent density в месяцы 1-2 и действовали в месяцы 3-4. Те, кто провалились — либо диагностировали слишком поздно, либо действовали без диагноза.
90-дневный план по фазам
Делите 90 дней на три 30-дневные фазы. Не пропускайте — VP, который начинает резать на второй неделе, не заработал данных, на которых можно резать.
Три фазы, одна работа в каждой. Смешивание — диагностировать пока слушаешь, коммититься пока диагностируешь — самый частый фейл.
Дни 1-30 — слушать (и молча мерять)
Цель: собрать датасет для диагноза. Результаты пока не публикуйте.
| Активность | Частота | Вывод |
|---|---|---|
| 1:1 с каждым direct report | Еженедельно | Файл заметок на человека |
| 1:1 с каждым skip-level EM | Дважды за месяц | Заметки + trust score 1-5 |
| Shadow 2-3 on-call дежурств | В неделю | Что ломается + как реагирует команда |
| Присутствовать на всех recurring eng-встречах | Первые 2 недели | Kill-list (встречи на вынос) |
| Прочитать последние 10 post-mortem | Неделя 1 | Список повторяющихся корневых причин |
| Прочитать последние 90 дней деплоев | Неделя 2 | Deploy cadence на команду |
Вопросы, которые вы задаёте в каждом 1:1 (одни и те же, всем):
- Какая самая сложная проблема сейчас?
- Что бы вы изменили, если бы была волшебная палочка?
- У кого из команды вы учитесь больше всего?
- О чём я не спросил, хотя должен был?
Вопрос 3 — тот, что важен. Одни и те же 3-4 имени всплывут в 20+ 1:1. Это ваши talent nodes — люди, чей уход ломает команды. Вам нужен их честный взгляд, прежде чем что-то публиковать.
Вопрос Друкера ("Если бы мы не делали X, начали бы?") применённый к каждой повторяющейся встрече, каждому status report, каждому дашборду, который вы унаследовали. Самый быстрый способ найти legacy-долг в management-слое. Обычно 30-40% унаследованного не проходит этот вопрос.
Дни 31-60 — диагностировать (и делиться осторожно)
Цель: построить тезис о том, что работает, что сломано, что неизвестно. Делиться приватно, прежде чем публиковать.
К дню 45 у вас должны быть ответы на:
| Вопрос | Ваш ответ |
|---|---|
| DORA-базлайн команды? | Deployment freq, lead time, MTTR, CFR |
| Какая команда — узкое место? | Обычно 1-2 команды гейтят всё |
| Кто те 3 человека, что держат организацию? | Если кто-то уйдёт, что ломается? |
| Главная неизвестная? | То, по чему у вас ещё нет данных |
| 2-летняя архитектурная ставка? | Мы делаем правильную? |
Поделитесь тезисом — не выводами — с 3 группами: вашим CEO/CTO, direct reports, 2-3 skip-level IC, которым доверяете. Используйте язык "вот как я сейчас это вижу, что я упускаю?" Сигнала получите больше как тезиса, чем как анонсированного плана.
Исследование Harvard Business Review 2023 по переходам executive (Watkins et al., n=215) показало: лидеры, которые делились диагнозом до плана, удерживали direct reports на 2 года на 40% лучше, чем те, кто приходил с планом. Listen-then-plan даёт накопительный эффект.
Дни 61-90 — коммититься (3 ставки, не 10)
Цель: опубликовать 12-месячный план. 3 ставки, не 10.
90-дневный план VPE с 10 приоритетами = 0 приоритетов. Выбирайте три. Пример от VPE из Series B fintech:
| Ставка | Обязательство | Измеримо к месяцу |
|---|---|---|
| Сократить deploy lead time на 40% | Инвестиции в CI + staging parity | 6 |
| Починить talent density в Platform | Нанять 2 senior, повысить 1, перевести 1 | 9 |
| Удалить strangler монорепо | Архив 4 legacy-сервиса, поглощение 2 | 12 |
Три ставки. Каждое 1:1, каждый квартальный review, каждый дашборд — на них. Всё остальное — шум или future planning.
Red flags в первые 90 дней
- Каждая встреча начинается с вас — вы узкое место, а не лидер. К 6-й неделе большинство встреч должно быть теми, которые вы можете пропустить.
- Вы знаете, что нужно менять, к 2-й неделе — не знаете. Знаете, что звучит неправильно. Подождите.
- Одно и то же имя всплывает как "difficult" — либо он скрытая стоимость, либо это человек, который называет реальную проблему, которую никто не хочет называть. Разберитесь.
- CEO давит "сделай изменения быстро" — спокойно пушбэкните. Объясните 30-30-30. CEO, который понимает инженерию, уважит это. CEO, который не понимает — это отдельный red flag.
- Вы рисуете реорг на 1-м месяце — реорг на 1-м месяце всегда преждевременен. Org design — последнее вмешательство, не первое.
Как действовать — конкретные инструменты
Четыре артефакта, которые новый VPE должен производить и поддерживать:
1. Person Doc
Один файл на direct report. Что его волнует, в чём силён, чему хочет учиться, что говорил в 1:1, что вы ему обещали. 12 direct reports в голове не удержать. VPE, которые пытаются, забывают обещания. Невыполненные обещания в месяцы 3-6 убивают доверие.
2. Team Health Matrix
Оценивать каждую команду (1-5) по пяти измерениям: delivery, talent, tech debt, team mood, leadership. Обновлять ежемесячно. Всё 2 и ниже получает management attention. Не даёт пропустить команду, которая катится боком, пока вы тушите самый громкий пожар.
3. 90-Day Doc
Ваш живой документ диагноза. Обновляется еженедельно. CEO в месяц 2 спрашивает "что видишь?" — открываете документ, не импровизируете.
4. First-Year Plan
Результат дня 90. Одна страница. 3 ставки. Как выглядит успех через 12 месяцев. Распространяется широко — так организация понимает, что вы приземлились.
Мерьте по ходу — метрики для вас
Четыре метрики собственной performance как VPE:
| Метрика | Месяц 3 | Месяц 6 | Месяц 12 |
|---|---|---|---|
| Время в 1:1 | 30-40% | 20-30% | 15-20% |
| Promise-keeping score direct reports | ≥ 4/5 | ≥ 4.2/5 | ≥ 4.5/5 |
| Свой календарь: unscheduled/thinking time | 10-15% | 20% | 25% |
| % решений, которые команды развернули за 30 дней | ≤ 20% | ≤ 15% | ≤ 10% |
Последняя строка — тихая: VPE, чьи решения откатывают, принимал их слишком быстро или с недостатком org buy-in.
PanDev Metrics даёт новому VPE базовый снимок организации в первую неделю — deploy cadence по командам, DORA, распределение coding time, кто чей код ревьюит. Мы видели, как входящие VPE через AI Assistant задают "кто делает больше всего PR reviews для команды X?" и быстрее, чем через 20 1:1, приземляются на скрытого несущего инженера. См. пост CTO Weekly Dashboard про leader-view.
Наш датасет смещён в компании 25-500 инженеров. Для VPE в орг 1000+ плейбук растягивается — больше времени на skip-level менеджеров, меньше на отдельных IC. Фазинг 30-30-30 держится, но активности внутри масштабируются иначе.
Ошибка первых 90 дней, которую никто не отмечает
Один fail-mode убивает VPE чаще других: считать онбординг линейным.
Реальный онбординг — три вложенных цикла. Ежедневные 1:1 кормят недельные наблюдения за командой, они кормят месячный тезис по организации. VPE, который идёт линейно — "неделя 1 — учусь, неделя 12 — делаю" — теряет накопление. Накопление — это и есть работа.
На 90-й день вы не "закончили онбординг". Вы установили цикл, который будете крутить 3 года.