Грейды и competency matrix

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

19 апреля 2026

Справочник

Грейды описывают ожидаемую работу, ответственность и масштаб влияния инженеров. Competency matrix помогает обсуждать найм, развитие и оценку по общим критериям. В статье разбираю, как составлять такую матрицу и использовать ее в разговоре о конкретных решениях. Обратная связь коллег может дополнять эту оценку, но не заменяет ясных ожиданий от роли.

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

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

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

С ростом грейда обычно меняются самостоятельность, сложность решений и масштаб ответственности. Это не сводится к скорости написания кода. Конкретные ожидания от middle, senior и staff нужно описывать для своей организации.

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

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

Антипаттерн: грейд как синоним стажа. «Работает 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 - рутинная часть автоматизируется. Ценность инженера смещается к способности увидеть продуктовый контекст, принять решения с учетом бизнеса, довести до результата. Отказ от продуктовой ответственности - уход с траектории ценности, не «спокойная техническая ниша».

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

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

360 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

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

Типичная ошибка - взять готовую матрицу (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-агентов:

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

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

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

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

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