Грейды и competency matrix

Общий язык о росте, найме и калибровке

19 апреля 2026

Грейды - разные типы работы, не «то же, только лучше». Staff engineer делает другую работу, чем senior, не «тот же код, только лучше написанный». Competency matrix - общий язык команды, одинаково полезный для трёх целей: найма (правильное соответствие роли, а не просто «хороший инженер»), развития (предметный разговор о росте), калибровки (единое представление в компании, что такое каждый грейд). 360 review - основной инструмент калибровки; без него грейды разъезжаются между командами.

Грейд - тип работы, не «тот же, только лучше» Competency matrix как общий язык Найм под грейд: правильное соответствие, не «хороший инженер» Ловушки жёстких и мягких матриц Грейд как уровень влияния (scope of impact) 360 review как practice калибровки Практика: как вводить матрицу в компании AI-native эра: что значит senior, когда код пишет агент Частые ошибки Источники и смежные статьи

Грейд - тип работы, не «тот же, только лучше»

Распространённое представление: junior умеет писать простой код, middle сложнее, senior ещё сложнее, staff - «ну очень сложный код». Это неверная модель.

Грейды - это разные типы работы с разной ответственностью и scope. Senior не делает ту же работу, что middle, но быстрее. Staff не делает ту же работу, что senior, но глубже. Переход между грейдами - смена характера деятельности.

Примеры для разных уровней:

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

Антипаттерн: грейд как синоним стажа. «Работает 5 лет - senior, 8 лет - staff». Стаж коррелирует с грейдом, но не определяет его. Инженер с 10 годами опыта может осознанно оставаться на senior-уровне - ему нравится писать код, не ведёт cross-team работу. Это валидный выбор, не «не дорос до staff».

Второй антипаттерн - грейд как зарплатная категория. Компенсация обычно привязана к грейду, но грейд описывает работу, не платёж. Путаница приводит к абсурдным ситуациям: «мне нужна staff-зарплата, поэтому повысьте» при отсутствии staff-работы.

Это не значит, что компенсация на высоких грейдах случайна. Staff/principal получают больше, потому что рычаг их влияния на компанию больше - как и ответственность за последствия. Архитектурное решение staff-инженера отражается на нескольких командах на годы вперёд; ошибка principal в выборе технической стратегии может стоить организации полного переписывания через два года. С другой стороны, успешные решения мультиплицируются: правильно выбранная платформа экономит сотни человеко-месяцев и ускоряет каждую следующую фичу. Более высокая компенсация - отражение этого рычага, не «награда за стаж». Когда работа соответствует грейду, мультипликатор оправдывает оплату; когда не соответствует - компания переплачивает за риск, который никто не принимает.

Competency matrix как общий язык

Без матрицы разговор о грейде - субъективный: «он кажется senior» или «не тянет на staff». Это приводит к неконсистентным решениям, фаворитизму, сложности обосновать промо.

Matrix даёт структурированный словарь. Типичные измерения (оси):

Для каждой оси - описания уровней по грейдам. Пример для Scope of impact:

Матрица - не checklist. Не список «сделай эти 10 вещей, получишь staff». Это framework для суждения: когда обсуждается промо или обратная связь, матрица даёт словарь и критерии, а не автоматический результат.

Подтверждение компетенций в работе, не в экзамене

Матрица описывает ожидаемое поведение на каждом грейде, но подтверждение компетенций происходит не через сертификации, тестовые задания или промо-экзамены. Компетенция подтверждается реальной работой: решёнными задачами, проведёнными архитектурными решениями, успешно завершёнными cross-team инициативами. «Я умею X» без evidence в production-работе не засчитывается.

Это принципиально по нескольким причинам. Экзамен проверяет абстрактное знание, отделённое от контекста. В реальной работе компетенция проявляется в принятии решений под давлением сроков, при неполной информации, при конфликтующих требованиях, при смешанной квалификации команды. Способность написать идеальный агрегат на листе бумаги не равна способности спроектировать агрегат для биллинг-системы с 5 годами legacy и 3 командами-стейкхолдерами. Только второе засчитывается как staff-level competency.

Рост через зону ближайшего развития

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

Для грейда это значит: если сотрудник претендует на senior, менеджер подбирает senior-level задачу (где-то между middle и senior по сложности), наблюдает справляется ли сотрудник. Справился - это подтверждение competency по этой оси. Не справился - ещё не senior, нужна дополнительная работа на уровне middle.

Важный нюанс: задача не должна быть «синтетическим тестом». Она должна приносить реальную пользу команде или продукту. Синтетические промо-задачи - «сделай что-то ненужное, чтобы показать senior-уровень» - демотивируют, искажают работу команды, и создают лицемерие в процессе роста. Свидетельства должны собираться из работы, которую всё равно нужно сделать для бизнеса.

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

Найм под грейд: правильное соответствие, не «хороший инженер»

Частая ошибка - нанимать «хорошего инженера», не проверяя, соответствует ли он конкретному грейду роли. Это даёт два класса проблем.

Underqualified. Нанимают senior на staff-роль - быстро понимают, что кандидат не делает cross-team работу, не ведёт technical direction, фокусируется на коде своей команды. Через 6 месяцев - либо промо до real-staff ожиданий (если есть способности к росту), либо разочарование с обеих сторон.

Overqualified. Нанимают staff на senior-роль «про запас». Через несколько месяцев кандидат выгорает или уходит: работа не соответствует профессиональному уровню, нет cross-team влияния, нет интересных архитектурных решений. Переплатили compensation, получили текучку.

Матрица помогает оценить соответствие, не максимум по всем осям. Staff-кандидат на staff-роль должен демонстрировать staff-level impact, communication, leadership. Не нужен с 10-летней глубиной в одной технологии, если роль требует широты.

Практические шаги найма с матрицей

  1. Для каждой открытой роли - фиксированный набор ожиданий по матрице (обычно не все оси на top-level, а комбинация, характерная для конкретного грейда и специализации).
  2. Интервью-сценарии, явно проверяющие каждую ось.
  3. Scorecard после интервью: оценки по осям, сигналы, свидетельства.
  4. Debrief-митинг: сравнение оценок, calibration между интервьюерами, итоговое решение.
  5. Hiring manager - owner решения о найме (делать offer или нет), не утверждения грейда.

Без матрицы найм сводится к «понравился / не понравился», что даёт высокую вариативность между интервьюерами и неконсистентные решения между циклами найма.

Кто утверждает грейд при найме

Утверждение грейда при найме - не прерогатива hiring manager. Если человек, закрывающий позицию, же утверждает грейд, возникает естественный конфликт: давление закрыть вакансию быстрее сдвигает оценку вверх («сделаем оффер на senior - кандидат согласится быстрее»). Это десинхронизирует грейды: внешние hires оказываются на более высоких позициях, чем internal инженеры с тем же impact, что подрывает доверие к системе.

Решение - отделить grade approval от hiring decision. Grade approval делает calibration committee, engineering leadership или VP Engineering - люди, которые не несут ответственности за скорость закрытия позиции. Hiring manager говорит: «мы хотим этого кандидата». Grade approver говорит: «на основе свидетельств из интервью соответствует такому-то грейду». Две разные роли с разными incentives.

Ловушки жёстких и мягких матриц

Два противоположных failure mode.

Жёсткая матрица = checklist. Каждая ось разбита на numeric levels, конкретные поведенческие маркеры, чёткие критерии «на этом уровне». Промо = passing всех checklist items.

Проблемы:

Мягкая матрица = вкусовщина. Описания общие («делает значимый impact»), уровни размытые, решения на суждении менеджера.

Проблемы:

Рабочий баланс: structured framework + суждение с явным процессом. Матрица задаёт словарь и критерии, но не автоматизирует решение. Процесс (calibration meetings, 360 review, документированные решения) обеспечивает последовательность суждений между менеджерами.

Субъективность полностью не убирается даже при лучшей матрице и процессе. Одно и то же поведение разные менеджеры интерпретируют по-разному; объективной метрики «staff-ли этот инженер» не существует. Задача - не устранить субъективность, а постоянно её выравнивать: через 360 review с конкретными примерами подтверждающих задач, обсуждение качества и скорости работы по ним, регулярные calibration meetings. Консистентность приходит от пересечения мнений на конкретных случаях, не от формул в матрице.

Грейд как уровень влияния (scope of impact)

Для высоких грейдов (staff+) scope of impact - главная ось. Техническая глубина и широта важны, но не определяют переход от senior к staff. Определяет изменение масштаба влияния.

Шкала scope of impact:

Junior обычно работает на Self уровне. Middle - Self + Team (косвенно). Senior - Team. Staff - Multi-team. Principal - Organization. Distinguished/Fellow - Industry.

IC track vs management track

Оба растут по scope. Разница - механизм влияния. IC-track (staff, principal) влияет через технические решения, архитектуру, mentoring, документы. Management-track (manager, director) - через людей и организационные решения. Но scope-шкала одна: director и principal на одинаковом scope-уровне (organization), просто действуют разными инструментами.

Career ladder для IC проходит не через «глубже в технике», а через «шире по scope». Инженер, желающий остаться senior и становиться техническим глубже - валидный выбор. Инженер, который хочет влиять за пределы команды, растёт в staff не через «ещё лучше пишу код», а через развитие навыков работы со scope.

После повышения: стандарт грейда и право на выбор

После промо сотрудник и менеджер должны одинаково понимать: задачи нового грейда теперь становятся стандартными, и калибровка идёт по ним, не по предыдущим. Если после повышения на staff инженер продолжает работать как senior - фокус на командную зону, редкие cross-team решения - это не «осваиваю роль медленно», это несоответствие грейду. Новый грейд не прибавляет «кое-чего иногда сверху» к старой работе; он меняет её в целом.

Из этого следует важное право сотрудника - давать обратную связь «не готов к следующему грейду» или «не хочу его». Это не признак неудачи. Это осознанное решение о карьерной траектории. Особенно значимо при переходе senior → staff, где объём изменений по всем шкалам (scope of impact, leadership, communication, decision-making) значителен - staff-работа это фактически другая профессия относительно senior. Не все senior хотят и могут делать её.

Похожая развилка встречается и на middle → senior: инженер хочет продолжать активно контрибьютить в технологию, глубоко решать технические задачи, но избегает ответственности за законченный продуктовый инкремент. Исторически это была нормальная траектория «технического специалиста без полноценной product ownership».

В эпоху AI-агентов такое позиционирование становится опасным. Тренд агентской разработки смещает все инженерные роли к ответственности за продуктовый результат: агент пишет код, собирает тесты, гоняет CI - рутинная часть автоматизируется. Ценность инженера смещается к способности увидеть продуктовый контекст, принять решения с учётом бизнеса, довести до результата. Отказ от продуктовой ответственности - уход с траектории ценности, не «спокойная техническая ниша».

Практическое следствие. Middle, предпочитающий остаться «техническим специалистом без продуктовой ответственности», рискует оказаться на обочине в течение нескольких лет. Senior с фокусом «пишу качественный код, продукт - не моя забота» - такой же риск. Грейд определяет не только сложность технической работы, но и широту ответственности за результат; это изменение в природе роли, а не просто «больше работы».

360 review как practice калибровки

360 review часто путают с performance review. Это разные инструменты с разными целями.

Performance review: оценка работы сотрудника за период, база для compensation, promo, PIP. Оценка «сверху» - менеджер на основе всех сигналов.

360 review: сбор feedback от peers, подчинённых (если есть), руководителя, cross-team коллег - о работе инженера. Цель - multi-angle картина, калибровка субъективных впечатлений через множество источников.

Главное назначение 360 в контексте грейдов - калибровка единого понимания «что такое senior / staff / principal в нашей компании». Без 360 каждый менеджер имеет свою картину, грейды разъезжаются между командами: senior в команде A работает как middle в команде B, принципиально разные люди формально на одном грейде.

Как делается

Calibration meetings

После сбора 360-feedback менеджеры одного уровня (или engineering leadership) встречаются и обсуждают их сотрудников: сравнивают оценки, обсуждают граничные случаи, выравнивают понимание. Цель - итоговые оценки консистентны в масштабе компании, не только в масштабе команды.

Результат правильно поставленного 360 + calibration: senior в любой команде - это senior в смысле, который все менеджеры понимают одинаково. Промо принимаются на основе cross-team калиброванной картины, не single-manager-мнения.

Антипаттерны 360

Практика: как вводить матрицу в компании

Типичная ошибка - взять готовую матрицу (Levels.fyi, StaffEng, Netflix career ladder) и объявить её стандартом. Шаблоны хороши как идея, но каждая компания имеет свои специфические ожидания, ценности, domain.

Рабочий процесс внедрения

  1. Описание as-is. Собрать существующих сотрудников, документировать что каждый реально делает. Получить картину «кто какой работой занят» до любой формализации.
  2. Выделение архетипов. Из as-is видны паттерны: тип работы senior в команде X, staff на платформе Y. Архетипы - основа для матрицы.
  3. Итеративная разработка матрицы. Junior, middle, senior, staff обычно выделяются относительно просто - архетипы работы на этих уровнях заметно различаются и большинство команд интуитивно их уже различают. Точки напряжения обычно в принципиальных переходах (middle → senior, senior → staff) и в верхних редких грейдах (principal, distinguished) - на них уходит больше итераций. Начинать можно с тех грейдов, где у компании больше людей сейчас, постепенно дорабатывая остальные.
  4. Пилотная калибровка. Небольшая группа менеджеров применяет матрицу на текущих сотрудниках, обсуждает разногласия, уточняет формулировки.
  5. Сверка с текущей зарплатой и план выравнивания. При калибровке неизбежно обнаруживаются несоответствия: кто-то получает ниже своего реального грейда (недоплата), кто-то выше (заработал на предыдущей позиции или был нанят с переплатой). Внедрение матрицы без плана выравнивания подрывает доверие. План состоит из двух частей. Для получающих ниже грейда - бюджет на корректировку зарплат, обычно за несколько циклов ревизии. Для получающих выше - явные ожидания роста до соответствующего грейда с планом развития и разумными сроками. Без такого плана матрица превращается в формализм, а люди теряют мотивацию работать по новым критериям.
  6. Коммуникация в команду. Матрица публична, каждый инженер может видеть ожидания. Это снижает политику («тайные правила») и даёт инструмент для самостоятельного роста.
  7. Owner матрицы. Явный человек (обычно VP Engineering / CTO) ответственен за evolution матрицы. Без owner матрица устаревает за полгода.

Источники идей

Все эти источники - отправные точки, не шаблоны для копирования. Матрица должна отражать, что конкретно делает компания и какую работу она ценит.

AI-native эра: что значит senior, когда код пишет агент

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

Что сдвигается

Новые оси в матрице

В статье «Наём AI-native инженеров» разобраны шесть измерений Augment Code, которые сейчас формируют рамку найма AI-native ролей. Эти измерения органично ложатся в competency matrix как новые оси или как updated descriptions существующих.

Практический эффект. В компании, adopt-ирующей AI-агентов:

Частые ошибки

Источники и смежные статьи

Первоисточники

Связанные темы

Смежные статьи блога