Шаблон карьерной лестницы

Грейды разработчика: шаблон карьерной лестницы

Пять уровней от Junior до Principal и шесть компетенций — от разработки и выпуска до развития команды.

Бесплатный тариф · Банковская карта не нужна

Эта карьерная лестница написана для продуктовых компаний примерно на 20–200 человек: разработчики сами доводят фичи до продакшена, команды небольшие, а отдельного HR, который выстроил бы систему грейдов, нет. В ней пять уровней — от человека в начале пути до того, кто задаёт техническое направление всей компании. Верхний уровень, Principal-инженер, относится к экспертному треку, а управление разработчиками описывает отдельная лестница руководителя разработки.

Каждый уровень описан через то, что человек делает, а не через стаж. Читайте строку матрицы компетенций слева направо, чтобы увидеть, как растёт одно ожидание, или раздел уровня — чтобы увидеть всё, что ожидается на нём. С её помощью удобно объяснять, что значит следующий уровень, проводить самооценку и чек-ины и сравнивать кандидатов на повышение между командами.

Это отправная точка, а не готовый регламент. Переименуйте уровни под свои должности, объедините или уберите компетенции, которые вам не подходят, и перепишите ожидания своими словами, прежде чем публиковать лестницу для команды.

Уровни коротко

Junior-разработчик
Осваивает кодовую базу и выполняет чётко поставленные задачи с поддержкой коллег.
Масштаб
Отдельные задачи в одной части продукта, которые обычно декомпозирует кто-то опытнее.
Middle-разработчик
Самостоятельно делает фичи и надёжен как участник команды.
Масштаб
Небольшие и средние фичи в зоне одной команды — от короткого дизайн-документа до продакшена.
Senior-разработчик
Ведёт крупные части работы и поднимает планку для всей команды.
Масштаб
Проекты на несколько сервисов или несколько человек и технические решения одной команды.
Staff-инженер
Решает задачи на стыке команд и влияет на технические решения за пределами своей.
Масштаб
Несколько команд или целое продуктовое направление, включая задачи, у которых нет владельца.
Principal-инженер
Задаёт техническое направление компании и отвечает за её техническое здоровье в долгосрочной перспективе.
Масштаб
Вся инженерная организация и техническая стратегия компании на несколько лет вперёд.

Матрица компетенций

Строки — компетенции, столбцы — уровни. Читайте строку слева направо, чтобы увидеть, как растёт ожидание.

Что означает каждая компетенция

Разработка и выпуск: Превращать требования в работающий поддерживаемый код и доводить его до пользователей.
Проектирование систем: Выбирать структуры, интерфейсы и компромиссы, которые выдержат рост продукта.
Качество и надёжность: Поддерживать продукт корректным, наблюдаемым и доступным и учиться на сбоях.
Взаимодействие и коммуникация: Эффективно работать с другими разработчиками, продуктом, дизайном и остальной компанией.
Ответственность за результат: Понимать, зачем нужна работа, и отвечать за результат, а не только за задачу.
Менторство и развитие команды: Помогать другим расти и делать команду сильнее любого её участника.

Разработчик: ожидания по компетенциям и уровням
Компетенция	Junior-разработчик	Middle-разработчик	Senior-разработчик	Staff-инженер	Principal-инженер
Разработка и выпуск	Выполняет чётко поставленные задачи читаемым кодом с тестами, просит помощи, если застрял на несколько часов, а не дней, и отрабатывает замечания ревью до мержа.	Без постоянной опеки доводит фичу от короткого дизайн-документа до продакшена, разбивает её на удобные для ревью пул-реквесты и реалистично оценивает знакомую работу.	Ведёт проекты на несколько сервисов или участников, выстраивает порядок работ так, чтобы польза выходила как можно раньше, и снимает риски до того, как они заблокируют команду.	Разблокирует выпуск там, где команды зависят друг от друга: распутывает общие зависимости, делает инструменты или проводит миграции, нужные нескольким командам, и держит межкомандные проекты в графике.	Определяет, как выпускает софт вся организация, — практики релизов, выбор платформ, инструменты сборки и деплоя, — чтобы каждая команда выпускала быстрее и безопаснее.
Проектирование систем	Следует принятым в кодовой базе паттернам и может объяснить, почему изменённый им код устроен именно так.	Проектирует компоненты внутри существующего сервиса, пишет короткий дизайн-документ для нетривиальных изменений и сравнивает хотя бы два варианта, прежде чем выбрать.	Ведёт проектирование фич, затрагивающих несколько сервисов, письменно фиксирует компромиссы для ревью и конструктивно ревьюит чужие дизайны.	Задаёт архитектуру на стыке команд — общие модели данных, контракты сервисов, решения «делать или покупать» — и предвидит, как система должна измениться в ближайшие год-два.	Отвечает за техническую стратегию компании: на какие технологии делать ставку, от каких отказываться и как архитектура должна развиваться вместе с бизнесом на несколько лет вперёд.
Качество и надёжность	Пишет тесты на свои изменения, проверяет работу перед релизом и чинит баги в коде, который трогал.	Добавляет мониторинг и алерты для своих фич, участвует в дежурствах и разбирает типовые инциденты по ранбуку.	Руководит реагированием на инциденты в системах команды, пишет постмортемы без поиска виноватых и следит, чтобы задачи по их итогам действительно выполнялись.	Находит риски надёжности и безопасности на стыке систем, задаёт стандарты — стратегию тестирования, целевые уровни сервиса (SLO) — и доводит исправления до конца в нескольких командах.	Определяет, что значат надёжность, безопасность и качество для компании, вместе с руководством балансирует их со скоростью и становится последней инстанцией в самых тяжёлых инцидентах.
Взаимодействие и коммуникация	Открыто рассказывает о прогрессе и блокерах и задаёт чёткие вопросы, если требование непонятно.	Напрямую работает с продуктом и дизайном над уточнением требований, объясняет технические ограничения простым языком и пишет понятные ревьюерам описания пул-реквестов.	Представляет команду на планировании, договаривается с продуктом об объёме и компромиссах и пишет документы, понятные людям вне разработки.	Согласует технический план между несколькими командами и функциями, разрешает разногласия между командами и объясняет технические риски руководству.	Имеет вес в решениях на уровне компании, переводит бизнес-стратегию в техническое направление и обратно и при необходимости представляет разработку перед клиентами, партнёрами или инвесторами.
Ответственность за результат	Понимает цель своих задач, проверяет, что выпущенное работает для пользователей, и доводит дело до конца.	Отвечает за фичу и после запуска: следит за использованием и ошибками, исправляет проблемы и предлагает улучшения по итогам.	Отвечает за часть продукта целиком, оспаривает требования, которые не помогают пользователям, и предлагает работу, которая двигает цели команды.	Находит самые значимые проблемы во всём продуктовом направлении — в том числе те, за которые не взялась ни одна команда, — и добивается их решения.	Связывает инвестиции в разработку с результатами компании и выступает за крупные ставки или против них, исходя из их технического и бизнес-эффекта.
Менторство и развитие команды	Просит обратную связь и действует по ней, записывает то, в чём разобрался, чтобы следующему новичку было проще.	Внимательно ревьюит код, помогает с онбордингом новых коллег и работает в паре с junior-разработчиками над незнакомыми частями кода.	Целенаправленно менторит одного–двух разработчиков, даёт обратную связь, которая помогает им дорасти до следующего уровня, и участвует в собеседованиях.	Растит senior-разработчиков в разных командах, влияет на процесс найма и инженерные практики, к нему приходят за советом.	Выстраивает техническую культуру компании — как принимаются решения и как распространяются знания — и растит следующее поколение staff-инженеров.

Прокрутите таблицу вбок, чтобы увидеть все уровни.

Скачать в CSV Открывается в Excel, Google Таблицах и Numbers.

Junior-разработчик: что ожидается

Осваивает кодовую базу и выполняет чётко поставленные задачи с поддержкой коллег. Отдельные задачи в одной части продукта, которые обычно декомпозирует кто-то опытнее.

Разработка и выпуск: Выполняет чётко поставленные задачи читаемым кодом с тестами, просит помощи, если застрял на несколько часов, а не дней, и отрабатывает замечания ревью до мержа.
Проектирование систем: Следует принятым в кодовой базе паттернам и может объяснить, почему изменённый им код устроен именно так.
Качество и надёжность: Пишет тесты на свои изменения, проверяет работу перед релизом и чинит баги в коде, который трогал.
Взаимодействие и коммуникация: Открыто рассказывает о прогрессе и блокерах и задаёт чёткие вопросы, если требование непонятно.
Ответственность за результат: Понимает цель своих задач, проверяет, что выпущенное работает для пользователей, и доводит дело до конца.
Менторство и развитие команды: Просит обратную связь и действует по ней, записывает то, в чём разобрался, чтобы следующему новичку было проще.

Middle-разработчик: что ожидается

Самостоятельно делает фичи и надёжен как участник команды. Небольшие и средние фичи в зоне одной команды — от короткого дизайн-документа до продакшена.

Разработка и выпуск: Без постоянной опеки доводит фичу от короткого дизайн-документа до продакшена, разбивает её на удобные для ревью пул-реквесты и реалистично оценивает знакомую работу.
Проектирование систем: Проектирует компоненты внутри существующего сервиса, пишет короткий дизайн-документ для нетривиальных изменений и сравнивает хотя бы два варианта, прежде чем выбрать.
Качество и надёжность: Добавляет мониторинг и алерты для своих фич, участвует в дежурствах и разбирает типовые инциденты по ранбуку.
Взаимодействие и коммуникация: Напрямую работает с продуктом и дизайном над уточнением требований, объясняет технические ограничения простым языком и пишет понятные ревьюерам описания пул-реквестов.
Ответственность за результат: Отвечает за фичу и после запуска: следит за использованием и ошибками, исправляет проблемы и предлагает улучшения по итогам.
Менторство и развитие команды: Внимательно ревьюит код, помогает с онбордингом новых коллег и работает в паре с junior-разработчиками над незнакомыми частями кода.

Senior-разработчик: что ожидается

Ведёт крупные части работы и поднимает планку для всей команды. Проекты на несколько сервисов или несколько человек и технические решения одной команды.

Разработка и выпуск: Ведёт проекты на несколько сервисов или участников, выстраивает порядок работ так, чтобы польза выходила как можно раньше, и снимает риски до того, как они заблокируют команду.
Проектирование систем: Ведёт проектирование фич, затрагивающих несколько сервисов, письменно фиксирует компромиссы для ревью и конструктивно ревьюит чужие дизайны.
Качество и надёжность: Руководит реагированием на инциденты в системах команды, пишет постмортемы без поиска виноватых и следит, чтобы задачи по их итогам действительно выполнялись.
Взаимодействие и коммуникация: Представляет команду на планировании, договаривается с продуктом об объёме и компромиссах и пишет документы, понятные людям вне разработки.
Ответственность за результат: Отвечает за часть продукта целиком, оспаривает требования, которые не помогают пользователям, и предлагает работу, которая двигает цели команды.
Менторство и развитие команды: Целенаправленно менторит одного–двух разработчиков, даёт обратную связь, которая помогает им дорасти до следующего уровня, и участвует в собеседованиях.

Staff-инженер: что ожидается

Решает задачи на стыке команд и влияет на технические решения за пределами своей. Несколько команд или целое продуктовое направление, включая задачи, у которых нет владельца.

Разработка и выпуск: Разблокирует выпуск там, где команды зависят друг от друга: распутывает общие зависимости, делает инструменты или проводит миграции, нужные нескольким командам, и держит межкомандные проекты в графике.
Проектирование систем: Задаёт архитектуру на стыке команд — общие модели данных, контракты сервисов, решения «делать или покупать» — и предвидит, как система должна измениться в ближайшие год-два.
Качество и надёжность: Находит риски надёжности и безопасности на стыке систем, задаёт стандарты — стратегию тестирования, целевые уровни сервиса (SLO) — и доводит исправления до конца в нескольких командах.
Взаимодействие и коммуникация: Согласует технический план между несколькими командами и функциями, разрешает разногласия между командами и объясняет технические риски руководству.
Ответственность за результат: Находит самые значимые проблемы во всём продуктовом направлении — в том числе те, за которые не взялась ни одна команда, — и добивается их решения.
Менторство и развитие команды: Растит senior-разработчиков в разных командах, влияет на процесс найма и инженерные практики, к нему приходят за советом.

Principal-инженер: что ожидается

Задаёт техническое направление компании и отвечает за её техническое здоровье в долгосрочной перспективе. Вся инженерная организация и техническая стратегия компании на несколько лет вперёд.

Разработка и выпуск: Определяет, как выпускает софт вся организация, — практики релизов, выбор платформ, инструменты сборки и деплоя, — чтобы каждая команда выпускала быстрее и безопаснее.
Проектирование систем: Отвечает за техническую стратегию компании: на какие технологии делать ставку, от каких отказываться и как архитектура должна развиваться вместе с бизнесом на несколько лет вперёд.
Качество и надёжность: Определяет, что значат надёжность, безопасность и качество для компании, вместе с руководством балансирует их со скоростью и становится последней инстанцией в самых тяжёлых инцидентах.
Взаимодействие и коммуникация: Имеет вес в решениях на уровне компании, переводит бизнес-стратегию в техническое направление и обратно и при необходимости представляет разработку перед клиентами, партнёрами или инвесторами.
Ответственность за результат: Связывает инвестиции в разработку с результатами компании и выступает за крупные ставки или против них, исходя из их технического и бизнес-эффекта.
Менторство и развитие команды: Выстраивает техническую культуру компании — как принимаются решения и как распространяются знания — и растит следующее поколение staff-инженеров.

Как адаптировать эту лестницу

Сопоставьте уровни со своими должностями
Если у вас должности «Разработчик I, II, III», переименуйте уровни, но оставьте по одному уровню на каждый реальный шаг в масштабе работы. Большинству компаний, где меньше 100 разработчиков, уровень Principal пока не нужен — не вводите его, пока кто-то действительно не делает эту работу.
Оставьте пять–семь компетенций
Больше семи никто не читает, а при меньше чем четырёх очень разные люди выглядят одинаково. Объедините компетенции, которые вы всегда оцениваете вместе, и добавляйте новую, только если она изменит реальное решение.
Переформулируйте ожидания так, чтобы их было видно
Для каждой ячейки спросите себя: сможет ли руководитель привести пример за последние полгода? Замените слова вроде «сильный» или «глубокий» на то, что человек делает, — например, «руководит реагированием на инциденты в сервисах команды».
Проверьте лестницу на реальных людях до публикации
Попросите двух–трёх руководителей расставить своих сотрудников по черновику. Там, где их мнения расходятся, формулировка двусмысленна: исправьте её, опубликуйте лестницу и договоритесь пересмотреть её через полгода.

Вопросы и ответы

Вопросы об этой лестнице

Сколько грейдов должно быть у разработчика?

Для компании на 20–200 человек обычно хватает четырёх–шести. Если уровней меньше, повышения становятся редкими и огромными; если больше — разницу между соседними уровнями уже не описать. В этом шаблоне пять: Junior, Middle, Senior, Staff и Principal.

Обязательно ли разработчику становиться руководителем, чтобы расти?

Нет. Это экспертный трек: staff- и principal-инженеры растут в масштабе и влиянии, не управляя людьми. Используйте его вместе с карьерной лестницей руководителя разработки — тогда переход в менеджмент будет сменой трека, а не повышением.

Как использовать лестницу при решениях о повышении?

Повышайте тех, кто уже стабильно работает на следующем уровне, а не тех, кто, возможно, справится. Попросите сотрудника и руководителя собрать конкретные примеры по каждой компетенции целевого уровня и сравнивайте все случаи по одной и той же матрице — так решения будут единообразными во всех командах.

Как лестница помогает на чек-инах и встречах один на один?

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

Как часто пересматривать карьерную лестницу?

Раз-два в год и каждый раз, когда меняется структура компании, — например, когда появляется платформенная команда или вы начинаете нанимать staff-инженеров. Переписывайте ячейку, если на ней раз за разом спотыкаются при оценке.

Соберите эту карьерную лестницу в LadderKit — бесплатно

Задайте её уровни и навыки для своей команды, оценивайте людей по ним на чек-инах и принимайте решения о повышении по единым правилам.

Начать бесплатно Посмотреть демо Без регистрации