Principal Engineer: как измерить реальный impact
Principal-инженер в финтехе на 200 человек за Q3 написала 180 строк кода. Её команда за тот же период отгрузила 340 000 строк. Когда CTO посмотрел дашборды coding-time для performance review, её едва не пометили как отстающую. Что реально произошло в Q3: она переписала спецификацию сверки платежей, разблокировав две команды, менторила трёх senior-инженеров в tech-lead, и закрыла полугодовой проект, который отгрузил бы то, что рынку не нужно. Её измеримый output был крошечный. Её impact — крупнейшим среди всех инженеров компании за квартал.
Это парадокс измерения principal-инженера. Каждый staff-plus-фреймворк (Will Larson, книга Tanya Reilly The Staff Engineer's Path, внутренняя лестница Google) это признаёт: principal-инженерам платят за суждение и умножение силы, а не за throughput. Но большинство инженерных организаций меряют их как senior-инженеров с большим титулом. Эта статья — о том, как честно измерять principal-impact, и как самому principal мерить свой impact к моменту review.
{/* truncate */}
Что реально делают principal-инженеры
Путаница начинается с описания роли. "Principal" обычно означает одну из трёх очень разных ролей:
Архетип 1 — Глубокий специалист. Эксперт домена. Principal по распределённым системам, который владеет кодом консенсуса. Principal по БД, владеющий оптимизацией запросов. Impact — в корректности и масштабе: их системы не падают так, как это важно.
Архетип 2 — Tech lead на масштабе. Кросс-командный force multiplier. Задаёт архитектуру на 5-10 команд, ревьюит самые сложные PR, пишет RFC, разблокирующие инициативы. Impact — в том, что шипят эти команды, а не в личных коммитах.
Архетип 3 — Решатель. Человек, которому дают самые тяжёлые проблемы. Ротируется между командами, приземляется на критический пожар, пишет 800 строк, разблокирующих 80 000. Impact — в предотвращённых катастрофах.
Книга Tanya Reilly The Staff Engineer's Path (2022, на интервью с 50+ principal/staff-инженерами от стартапов до Google) явно выделяет эти три архетипа и отмечает: попытка мерить principal метриками смежного архетипа всегда искажает сигнал. Специалист, меряемый throughput, выглядит плохо. Решатель, меряемый retention, — плохо. Tech lead на масштабе, меряемый личным объёмом кода, — плохо. Каждый раз.
Цепочка principal-impact. "Измеримый исход" — последний шаг, не первый. Большинство метрик пытаются мерить напрямую и в итоге меряют активность.
5 вопросов, которые должен задавать principal
1. Чью работу я разблокировал в этом квартале?
Чистейший сигнал. Principal, который не может назвать 3-5 людей или команд, чью работу разблокировал, либо невидим, либо реально не множит силу. Спрашивать ежемесячно. Вести список.
Опрос Microsoft Research 2023 (4000+ senior-инженеров) показал: умножение силы (через peer-review вклада в разблокировку) коррелирует с решениями о повышении в principal лучше, чем любая метрика по коду. Это сигнал, реально двигающий карьеру в верхней полосе.
2. Какие решения я принял, с которыми организация будет жить через 2 года?
Principal-инженеры принимают архитектурные решения, переживающие их собственный срок в компании. Трекать явно: principal, принявший ноль долгоиграющих решений за год, делает senior-работу, не principal.
Примеры долгоиграющих решений:
- Выбор БД для новой продуктовой линейки
- Форма API платформы, которую теперь используют 4 команды
- Закрытие сервиса, съедавшего $80k/год
- RFC, сформировавший философию on-call
3. Скольких людей я сделал заметно лучше в их работе?
Не "подчинённых" (у principal их обычно нет). Менти, соавторы, студенты code review. Если три senior-инженера показывают на вас и говорят "она научила меня думать о распределённых транзакциях" — это измеримый impact на capability организации.
Will Larson в Staff Engineer называет это "developing other engineers" и отмечает: это самый трудно-квантифицируемый тип impact в review — поэтому principal, пренебрегающие этим, получают повышения медленнее и увольняются быстрее во время реорганизаций.
4. Что я остановил?
Негативный impact — тоже реальный impact. Закрытые проекты, которые не должны были шипнуться. Архитектуры, которых не построили. Несделанные покупки компаний. Этого нет ни на одном дашборде.
Один principal, которого мы интервьюировали в продуктовом research, сформулировал резко: "Мой главный Q2-вклад — закрытая миграция на 6 месяцев, которая стоила бы $400k и не принесла бы ничего. Jira-тикета за это не существует." Impact реальный. Проблема измерения в том, что нужны показания пиров или явный трекинг.
5. Что сломается, если я завтра уйду?
Principal, уход которого едва неудобен организации, — либо не на той роли, либо чрезмерно абстрагировал свою работу. Здоровый ответ — не "всё сломается" (bus factor = 1, вы провалили умножение силы), а "три конкретных инициативы теряют лучшего адвоката и уезжают на 6-8 недель".
Метрики, которые principal-инженер должен трекать сам
Практический набор. Трекать поквартально — не для дашборда, а чтобы иметь данные к моменту review.
| Метрика | Что меряет | Здоровое направление |
|---|---|---|
| Вклад в кросс-командные RFC (автор или главный ревьюер) | Архитектурное влияние | 3-8 за квартал |
| Инженеры, которых явно менторили | Умножение силы | 3-5 одновременно |
| Code review-комментарии на чужих PR | Техническое лидерство | 20-40% от вашей code-активности |
| Проекты, закрытые или урезанные по вашей рекомендации | Ценность суждения | 1-3 в год |
| Junior/mid-инженеры, повышенные после вашего менторства | Рост capability организации | 2-4 в год |
| Внешняя видимость (доклады, open-source, публикации) | Сигнал рынку | 1-3 в год |
Principal, высоко набирающий только по личным coding-time метрикам и низко по всем шести — делает senior-работу с большим титулом. Это реальная проблема и для инженера (застопорившаяся карьера), и для компании (переплата за throughput).
Что PanDev Metrics может и чего не может измерить
Наши IDE-данные ловят coding-активность на рабочей станции инженера — сколько времени в какой кодовой базе, какие языки, какие файлы. Для principal это обманчивый первичный сигнал, и мы это прямо говорим. Principal с низкими coding-часами, но высокими code-review сигналами и высоким touch-ом кросс-командных коммитов, скорее всего хорошо множит силу. Principal с высокими coding-часами и низкой кросс-командной активностью может делать senior-работу, которую стоит делегировать.
Где наши данные помогают principal: детектировать, когда их тащат в тактическую работу, которой у них быть не должно. Если IDE-время principal на одном проекте превышает 60% за полный квартал, они фактически сведены к senior-инженеру на этом проекте. Этот паттерн видим и исправим.
Где данные не помогают: измерить решения, закрытые проекты, глубину менторства, внешнее влияние. Это требует peer-сигналов (360, структурированные свидетельства, документированные артефакты). Мы честно: умножение силы тяжело измерить только из телеметрии, и любой вендор, обещающий решить это одной метрикой, продаёт историю.
Красные флаги для principal (самодиагностика)
- Только вы понимаете критическую систему. Вы создали bus factor, а не построили умножение силы. Задокументируйте и делегируйте до review.
- Хайлайты квартала — только ваш личный шиппинг. Вы делаете senior-работу. Спросите менеджера, почему force-multiplication-возможности не приходят на ваш стол.
- Никто не приходит к вам за архитектурным ревью. Либо вы недостаточно видимы, либо организация обошла вас стороной. И то, и другое требует разговора.
- Ваши менти застыли. Если трое, которых вы менторили, не выросли за год — менторство не работает, меняйте подход или менти.
Красные флаги для менеджеров principal
- Вы не можете перечислить 3 вещи, которые ваш principal сделал за квартал, без просмотра коммитов. Вы не видите их реальной работы.
- Ваш principal каждое утро на стендапе с командой. Его используют как senior. Исправьте аллокацию.
- Ревьюеры не могут согласиться, в чём сильна ваш principal. Провал ясности роли. Явно назначьте архетип.
Контринтуитивный тезис
Principal-инженеры — самая мис-измеряемая роль в инженерных организациях. Предвзятость структурная: throughput измерять легко, суждение — трудно. Каждая организация, меряющая principal теми же дашбордами, что и senior, системно недооценивает force-multipliers и переоценивает high-output специалистов. За 3-5 лет это кумулятивно приводит к повышению не тех людей в staff+ и потере нужных.
Честный лимит: у нас нет данных о том, что это "фиксит". Команды, которые мы видим делающими principal-impact правильно, используют 360-style peer-свидетельства, структурированные квартальные ревью артефактов и явное назначение архетипа при найме. Это процессные фиксы, не метрические. Телеметрия может подсветить "этого principal используют не так", но не может одна измерить "principal делает всё правильно".
Что почитать
- Performance Review на данных: шаблоны и антипаттерны
- Миф 10x-разработчика: что реально показывают данные
- VP of Engineering: первые 90 дней на данных
Если вы principal, и ваш review читается как senior-review с большей цифрой — что-то не так с тем, как видят ваш impact.