Career Ladders

«Вырастешь — посмотрим». Эту фразу я регулярно слышу в командах, у которых нет документированной career ladder, и дальше всё идёт по одному сценарию. Инженер не понимает, чего от него ждут. Руководитель читает слово «senior» по-своему, поэтому калибровка между командами невозможна в принципе, а промоушн через два года приходит вместе с обратной связью, которая ни разу не прозвучала на 1:1. Career ladder — это организационный артефакт: явный список компетенций на каждом уровне, конкретные сигналы для промоушна, калибровочная встреча ради общего толкования. Соседний лист к SRE Onboarding под L1 Organisational Capability Development.

Что должен уметь

Главный навык на уровне L5 — формулировать конкретные поведенческие ожидания, а не «должен иметь impact». Расплывчатое «у senior должен быть large impact» не разворачивается в проверяемое действие: оценивающий понимает по-своему, инженер не знает, что закрывать. Рабочие ladders формулируют через поведение: «доводит фичу до конца сам, в условиях неопределённости», «ведёт как минимум N младших инженеров», «отвечает за надёжность одного критичного сервиса», «участвует в архитектурных решениях через ADR». Измеримо, сравнимо, отстаиваемо на калибровке.

Знает, где лежит документ с ladder; находит свой текущий уровень и читает ожидания следующего.
Регулярно (минимум раз в квартал) перечитывает ladder, чтобы понять, где он сейчас: что закрывает, что нет, в чём разрыв.

Использует ladder в разговорах на 1:1: конкретно формулирует вопросы о росте («вот ожидания L5, такие пункты я закрываю через X / Y / Z, эти — нет»).
Даёт обратную связь коллегам со ссылкой на ladder («это решение уже по масштабу L5», «здесь не хватает того, что в L5 названо влиянием за пределами своей команды»).

Сверяет собственную самооценку с командной нормой на калибровочной встрече (полугодие — норма).
Если играет роль руководителя / tech lead: использует ladder для решений о промоушне, документирует промоушн как явный кейс с доказательствами (артефакты, проекты, поведение).
Пишет promotion case на одну страницу: для какого уровня, какие ожидания закрыты конкретными примерами, какие открытые вопросы; ревьюится кросс-командно.

L6+

Проектирует и обновляет ladder для своей области в организации: балансирует специалиста и универсала, инженерный трек и управленческий.
Поддерживает ladder во времени. Сдвиги индустрии (эпоха AI, эпоха platform engineering) приходят за ожиданиями, ladder меняется, а уже выданные обещания остаются в силе.

Материалы

Книги

Will Larson — Staff Engineer (2021). Путь staff/principal для инженера, который не уходит в руководители: четыре архетипа (tech lead, architect, solver, right-hand) и стратегии выхода на этот масштаб. Помогает понять, как формулируются ожидания за пределами senior.
Camille Fournier — The Manager’s Path (O’Reilly, 2017). Главы про performance review, калибровку и решения о промоушне — сторона руководителя в работе с ladder.
Lara Hogan — Resilient Management (A Book Apart, 2019). Описание уровней, честная обратная связь, калибровка без перекосов.

Статьи и фреймворки

Progression.fyi. Публичная коллекция из 75 с лишним карьерных лестниц разных компаний (CircleCI, Medium, Monzo, Rent The Runway, GOV.UK и др.). По моим наблюдениям, главный практический ресурс перед написанием собственной: сюда идут за структурой и языком формулировок.
SFIA — Skills Framework for the Information Age. Канонический международный фреймворк с семью уровнями ответственности. Подходит как основание для собственной ladder в IT-командах.

Инструменты

Markdown в общем репозитории инженерии (или Notion / wiki) — по моим наблюдениям, чаще всего берут именно его, потому что это самый дешёвый вариант: один документ, секции по уровням, поведенческие ожидания и примеры доказательств. Правки идут через PR, документ открыт всей инженерии.
Шаблон калибровки — структурированный документ для калибровочной встречи: список инженеров под рассмотрение, рекомендуемый уровень от руководителя, ссылки на доказательства, заметки комитета. Версионируется ради возможности потом поднять историю.
Лист самооценки — формат для инженера перед performance review: ожидания уровень за уровнем, самооценка «закрываю / частично / пока нет» с конкретными артефактами. Реже, чем два предыдущих, и обычно появляется, когда компания уже дошла до регулярного цикла ревью.

Best practices

Я регулярно вижу команды, в которых ladder написан, опубликован — и никто его не открывает между промоушнами. Это не ladder, это документ-альбатрос. По моим наблюдениям, рабочая ladder отличается одним признаком: за год к ней возвращаются на каждом 1:1 хотя бы раз. Правило «никаких сюрпризов на ревью» не магия, а побочный эффект того, что ladder используется как общий словарь, а не открывается раз в двенадцать месяцев.

Первое — вынести ladder из головы руководителя в документ, открытый всей инженерии. Дальше начинается язык. Формулировка «у senior должен быть large impact» не работает никак: инженер не знает, что закрывать, а оценивающий каждый раз читает фразу заново. «Доводит фичу до конца сам, в условиях неопределённости» или «отвечает за надёжность одного критичного сервиса» читаются одинаково двумя разными людьми — этого достаточно, чтобы спор на калибровке был про факты, а не про интерпретацию.

Дальше — два трека, инженерный и управленческий. Если единственный путь наверх идёт через управление, сильные инженеры либо уходят в менеджмент, где они плохи, либо уходят совсем. Зрелая ladder ветвится на L5/L6: staff / principal / distinguished с одной стороны, руководитель с другой.

Уровни не привязаны к компенсации напрямую (или привязаны явно, через вилки). «Каждый уровень автоматически = прибавка» ломает разговор о росте: вместо «куда я расту» получается «как получить деньги», руководители боятся повышать, потому что вопрос компенсации не решён, а обоснование промоушна пишется под зарплату, а не под зону ответственности. Вилки к уровням привязывать нормально, но именно как объявленные вилки на уровне организации, не «один уровень — одна цифра».

Разговор про ladder — ежеквартальный, а не однократный перед ревью. Документ, который открывают раз в год, не используется. Инженер не понимает, как он прогрессирует, руководитель приходит к решению без доказательств. Каждое 1:1 — повод сослаться на ladder, каждый квартальный чек-ин — короткая самопроверка. По моим наблюдениям, разница между командами, у которых ladder работает, и теми, у кого нет, именно в частоте обращения к документу, а не в качестве формулировок.

Калибровка регулярная, а не «как руководитель понял». Каждый руководитель толкует ladder по-своему, и через полгода в команде A и в команде B живут два разных «L5»: несовместимые ожидания, несправедливые повышения, поехавшие вилки. На калибровочной встрече руководители вместе разбирают свои рекомендации, спорят и договариваются об общем толковании. Если расхождение структурное — правят сам документ.

Promotion case пишется и ревьюится кросс-командно, а не «по личному знанию руководителя». Когда обоснование не видит никто за пределами команды, повышения начинают случаться по личным отношениям, заметности и удачным проектам. Небольшой комитет из руководителей и старших инженеров с других команд даёт независимый взгляд — этого обычно хватает.

Связанные листья

SRE Onboarding — программа обучения обычно ложится на переход L3 → L4 в первый год; без ladder у onboarding нет понятной финишной черты.
One-on-Ones — ритуал, в котором ladder живёт: разговор о росте на 1:1 — основной способ обсуждать прогресс между формальными циклами ревью.
Personal Growth Plan — личный артефакт: цель в нём обычно формулируется как «закрыть ожидания L5», и ladder служит для него исходником.
Dev Team Partnership — в моделях embedded SRE и консультирующей SRE уровни расставляются по-разному.
Team Topologies — путь инженера часто проходит через разные типы команд (embedded → платформенная → enabling); без понимания топологии ladder читается плоско.
Stakeholder Management — критерий L5+ в большинстве вменяемых ladder; трек staff/principal прямо требует влияния за пределами своей команды. Без него верхние уровни лестницы схлопываются в один.
Calibration Meeting — ритуал, в котором ladder тестируется на конкретных людях; без calibration ladder остаётся документом-альбатросом, который читается каждой командой по-своему.
Mentoring as Practice — «ведёт как минимум N младших инженеров» — типичное ожидание уровня L5+ в публичных ladder; менторство и есть один из способов передать опыт вверх по лестнице.

Открытые вопросы

Главный пробел — полный цикл performance review: ритуал с рейтингом и разговором о компенсации целиком. Механика калибровки вынесена в отдельный лист Calibration Meeting, а всё остальное пока TBD. Рядом стоит связь ladder с зарплатными вилками — тема уровня организации и скорее со стороны HR, шире, чем этот лист.

Мельче, но тоже не закрыто: форматы promotion case (одностраничник, ссылки на доказательства, отзывы коллег) и управление изменениями самой ladder. По второму пункту у меня нет хорошего ответа: кто именно обновляет документ и как не устроить чехарду из частых правок.