От джуна до сеньора: критерии промоушена на данных

Инженер с 3,5-летним стажем в 120-человеческом скейлапе, с которым я работал в прошлом году, был «очевидно сеньор» — по интуиции всех. Её данные Git и IDE говорили другое: она шипила больше фич, чем любой сеньор команды, но не ревьюила PR за пределами своего сквада, никогда не вела system-design-proposal от начала до конца, а её коммиты кучковались в узкой области из 2 компонентов. Гут её менеджера говорил «сеньор». Поведенческие данные говорили: готова через 6-9 месяцев, не сегодня. Ревизит через 6 месяцев подтвердил: она дошла, и промоушен зашёл сильнее, чем зашёл бы интуитивный.

Решения о промоушене ошибаются в двух направлениях. Promote-too-early производит недоподдержанных сеньоров, тихо недорабатывающих и иногда уходящих. Promote-too-late теряет ваших лучших инженеров в пользу конкурентов, первыми увидевших готовность. Исследование First Round Review 2023 по инженерным карьерам обнаружило: крупнейший драйвер сожаления senior-инженеров — «повысили до того, как был готов», отмечено 41% респондентов. Критерии на данных снижают обе ошибки.

{/* truncate */}

Проблема интуитивного промоушена

Менеджеры ловят pattern-match на ярких моментах — отличный incident response, красивый demo, одна архитектурная дека — и сильно взвешивают их при решении. Эти моменты — реальный сигнал, но страдают от трёх смещений:

• Recency — последний квартал весит больше предыдущих 18 месяцев
• Visibility — инженер, презентующий на all-hands, виднее того, кто делает платформенную работу
• Similarity — менеджеры оценивают «инженеров похожих на себя» выше

Статья Microsoft Research 2019 по справедливости промоушена зафиксировала до 2x разницы во времени до промоушена между демографически похожими и разными подчинёнными одного менеджера — при контроле output. Критерии на данных не убирают интуицию — они её якорят.

Что senior значит поведенчески (а не по званию)

Четыре гейта между mid и senior. Один стаж ни одного не проходит.

Промоушен mid → senior означает, что инженер прошёл четыре поведенческих гейта, каждый — независимо наблюдаемый в Git, PR и IDE-данных:

Гейт	Как выглядит в данных	Порог
Independent delivery на ambiguous-работе	PR, где задачу создал сам инженер, а не была назначена	≥ 30% PR за последние 6 месяцев
Cross-team влияние	Ревью PR вне своей основной команды	≥ 20% ревью за последний квартал
Владение system design	Инженер автор ≥ 1 design doc, приведшего к зашипленной системе, с участием multi-contributor	≥ 1 за 6 месяцев
Ментор-output	PR, которые инженер ревьюил, автором которых был джун	≥ 15% ревью за последний квартал

Ни один гейт сам по себе недостаточен. Mid, обжигающий independent delivery, но не ревьюящий вне команды — не senior, это high-output IC. Mid, ревьюящий широко, но не владеющий design doc — не senior, это полезный reviewer.

Все четыре, удерживаемые ≥ 6 месяцев — это сигнал к промоушену.

Четыре сигнала подробнее

1. Independent delivery на ambiguous-работе

Сеньоры начинают проекты. Джуны и mid — завершают назначенные. Самый чистый прокси: кто открыл исходную задачу/тикет?

Выгрузите Jira/ClickUp/Linear-данные и проверьте, кто создал задачу, приведшую к каждому смёрженному PR за 6 месяцев:

Роль	Типичный % PR из своих созданных задач
Junior	0-10%
Mid	10-25%
Senior	25-50%
Staff+	40-70%

Инженер, сидящий на 15% 18 месяцев — mid, а не early-senior. Инженер, поднимающийся с 12% до 32% за 9 месяцев — показывает сигнал готовности.

2. Cross-team влияние через ревью PR

Senior-инженеры ревьюят код за пределами своей feature-команды. Причина простая: им доверяют мейнтейнеры больше чем одной кодбазы, и их ревью даёт ценность на нескольких поверхностях.

Меряем: из ревью PR, закрытых этим инженером за квартал, какой % — ревью PR авторов, чья основная команда ≠ команда ревьюера?

• Mid: 5-15%
• Early senior: 15-25%
• Senior+: 25-40%

Следите за патологиями: инженер с 60%+ cross-team-ревью и низким own-delivery может быть review-героем, избегающим своей shipped-работы. Senior — баланс, а не крайности.

3. Владение system design

Написание design doc, которое реализуется — самый сложно-подделываемый senior-сигнал. Реализация — тест: многие пишут доки; сеньоры пишут доки, которые превращаются в системы.

Отслеживаем:

• Написал ли инженер ≥ 1 design doc за 6 месяцев?
• Прокомментировали ли его 3+ других инженера (не авторов)?
• Зашипилась ли получившаяся система?
• Остался ли инженер в топ-3 коммиттеров получившейся кодбазы ≥ 30 дней после launch?

Четыре «да» = гейт владения design полностью пройден. Меньше = частичный зачёт, отметьте специально, чего не хватает.

4. Ментор-output

Сеньоры множат команду. Простейшая измеряемая форма: ревью PR от джунов, с содержательными комментариями (не просто approvals).

Сигнал: из всех ревью PR, сделанных этим инженером, какой % — PR от инженеров со стажем < 18 месяцев? И из них — какой % содержит хотя бы один inline-комментарий с предложением/вопросом?

• Mid: 5-10% junior-ревью, 20-30% с содержательными комментами
• Senior: 15-25% junior-ревью, 50%+ содержательных
• Staff: 10-20% junior-ревью (Staff менторит больше через design, меньше через review), 70%+ содержательных

Инженер, ревьюящий 25% junior-PR, но штампующий их (все «LGTM» без inline) — не менторит, а быстро пропускает через гейт. Коэффициент содержательных комментов — это фильтр качества.

Количественный дашборд

Сигнал	Измерение	Mid-диапазон	Senior-порог
Own-task PR ratio	Автор задачи == автор PR / всего PR	10-25%	≥ 30%
Cross-team reviews	Cross-team ревью / всего ревью	5-15%	≥ 20%
Design docs (6мес)	Количество merged-design-doc-PR	0-1	≥ 1 с реализацией
Junior-ментор ratio	Junior-PR-ревью / всего ревью	5-10%	≥ 15%
Удерживаемый период	Месяцев все 4 выше порога	< 3	≥ 6

Разговоры о промоушене начинаются, когда инженер удерживает все 5 строк 6 месяцев. До этого разговор — «к чему расти», а не «когда повышать».

Что НЕ коррелирует с готовностью к senior

Некоторые метрики звучат так, как будто должны предсказывать готовность к senior, но не предсказывают — а ранжирование людей по ним ломает команды.

• Строки кода в неделю. Mid-инженеры в наших данных пишут больше LOC, чем сеньоры, а не меньше. Сеньоры больше ревьюят и проектируют. Данные IDE heartbeat подтверждают: доля coding-time падает с 68% на mid до 52% на senior.
• Количество коммитов. Та же проблема — сеньоры коммитят реже, большими логическими блоками.
• Количество PR. Коррелирует с mid-output, слабо — с senior.
• Время говорения на standup. Нулевая корреляция. Экстраверты переобжирают.
• GitHub stars на pet-проектах. Нулевая корреляция с on-job senior-поведением.

Если ваш процесс промоушена взвешивает любое из этого — вы отбираете по объёму output, а не по senior-зрелости. Ждите promote-too-early ошибок.

Использование IDE + Git данных в разговорах о промоушене

Поверхность engineering-intelligence PanDev Metrics (IDE heartbeat + Git-события + связи с task-tracker) делает четыре сигнала queryable без ручного аудита. CTO-дашборд добавляет не «readiness score» — мы намеренно его не считаем — а возможность ответить «Покажи cross-team review ratio этого инженера за 6 месяцев, квартал за кварталом» за 10 секунд вместо 2 часов PR-археологии.

Поведение, которое мы видим у клиентов: менеджеры приходят на разговор о промоушене с предзаполненными гейтами и используют разговор, чтобы обсудить то, чего не видит data (domain-экспертиза, customer impact, инцидент-response). Data не заменяет суждение — она освобождает суждение от счёта.

Типичные ошибки

• Промоушен по стажу. 4 года в кресле ≠ senior. Стаж — необходимое, но не достаточное.
• Квартал данных. Все четыре сигнала шумные квартал-к-кварталу. 6 месяцев минимум.
• Взвешивание visibility выше evidence. Инженер, презентующий на all-hands, не обязательно дальше того, кто рефакторит deploy-pipeline.
• Игнорирование отрицательных сигналов. Инженер, прошедший все 4 гейта, но имеющий 3 инцидента, прослеженных до review-less-мёржей, показывает риск, который счёт гейтов пропускает.
• Промоушен «иначе уйдёт». Так создаются посредственные senior. Retention — отдельная проблема, решаемая scope и оплатой, а не инфляцией звания.

Контр-тезис

Большинство инженерных организаций повышают слишком поздно, а не слишком рано, и цена «слишком поздно» больше. Нарратив: «мы повышаем слишком рано, так что поднимем планку». Данные по customer-ам, за которыми мы наблюдали, говорят обратное: инженеры, прошедшие все 4 гейта за 6 месяцев до реального промоушена, либо ушли (40%), либо провели эти 6 месяцев, делая senior-работу за mid-зарплату. Фреймворк гейтов — не только про подъём планки, он про то, чтобы сделать «они готовы прямо сейчас» так же видимым, как «ещё не готовы». Обе ошибки стоят; скорость детекции важна одинаково.

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

Наш датасет — 100+ B2B-компаний, ~1000 отслеживаемых человек. Этого достаточно, чтобы валидировать направление 4 сигналов, но не хватит на публикацию жёстких порогов для конкретной индустрии (у gaming, fintech, e-commerce разные нормы design-doc). Пороги выше — медианы по нашим данным, не универсальные истины. Калибруйтесь по своей организации: постройте распределение текущих сеньоров по 4 метрикам и установите свои гейты на 15-20% ниже медианы senior.

Мы также не можем зафиксировать cultural fit, customer empathy, stakeholder management из IDE+Git-данных. Это реальные senior-поведения. Четыре гейта — необходимый поведенческий пол, а не достаточный потолок.

Дополнительное чтение

• Performance Reviews на данных: шаблоны и анти-паттерны — более широкий процесс оценки, в который встраивается промоушен
• Onboarding разработчика: метрики ramp-up до полной продуктивности — кривая, заканчивающаяся там, где начинается эта статья
• 10x Developer: что данные говорят на самом деле — почему мифы об individual output искажают promotion-суждение
• External: First Round Review: Engineering Career Ladders — качественное исследование сожаления о промоушене