Грейд без магии

Примерно два месяца назад мы поняли, что у нас есть проблема с грейдами.

Hard skills мы умеем проверять достаточно объективно: технические знания, практические навыки, тесты, оценка техлида.

А дальше часто начинается зона субъективности: «сильный специалист» «давно пора повышать» «уже почти Senior» «команда им довольна»

То есть формально грейд есть, но не всегда понятно, что именно за ним стоит.

Мы решили это поменять. Вместе с техническим директором Банка начали описывать в репозитории, что ожидаем от каждой роли и каждого уровня.

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

Около месяца собирали первую версию. Потом ещё примерно месяц обсуждали её с CTO, лидами, техлидами, тимлидами и HR.

В итоге разделили оценку на две части.

Hard skills и актуальность технических знаний остаются у техлида и тестов.

А дальше смотрим уже не только на знания, а на масштаб, на котором человек способен стабильно работать: — насколько самостоятельно принимает решения; — умеет ли находить проблему, а не только выполнять поставленную задачу; — как работает с неопределённостью; — насколько отвечает за результат, а не только за свою часть; — влияет ли на команду и систему вокруг себя.

Для меня в этом и есть смысл грейда.

Грейд — это не награда за прошлые заслуги. Это описание масштаба задач, которые человек способен стабильно решать сегодня.

Сам ассессмент выглядит довольно просто.

На встречу приходят сотрудник, его руководитель и техлид или тимлид.

Я заранее готовлю несколько вопросов по базовым полям фреймворка.

Причём не в стиле: «Ты умеешь работать самостоятельно?» А через реальные ситуации.

Например: — когда тебе приходит задача уже в виде готового решения, как ты понимаешь, что нужно реализовывать именно его? — какую проблему ты сам нашёл и принёс команде или бизнесу? — когда в последний раз ты не согласился с предложенным решением и предложил другое? — какой результат изменился благодаря твоей работе?

Мы разговариваем 40–60 минут и фиксируем ответы.

После этого LLM, которая знает наш grade framework, критерии и цели, помогает разложить ответы по компетенциям, найти разрывы и сформировать предварительную оценку.

Но решение модели мы не отдаём. Я остаюсь human in the loop: проверяю выводы, корректирую их и только после этого отправляю результат всем участникам встречи.

Причём итогом становится не просто «твой грейд такой-то».

Мы фиксируем конкретные зоны роста и цели на ближайший период.

Недавно я перешёл в другой трайб.

И почти сразу ко мне пришёл руководитель с запросом пересмотреть уровень аналитика и поднять зарплату примерно на 30%.

Hard skills техлид подтвердил. Формально сотрудник был Middle, а ожидание было, что он уже близок к Senior.

Назначили встречу.

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

И вот здесь для меня произошла самая важная часть.

Никто не воспринял это как наказание.

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

Руководитель после встречи написал, что упражнение оказалось полезным и часть разрывов он раньше просто не замечал.

Техлид получил модель оценки, которую дальше сможет применять уже сам.

Именно поэтому мне нравится такой подход.

Не потому, что он позволяет «точнее разложить людей по уровням».

А потому что убирает магию из карьерного роста.

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

Тогда грейд становится не инструментом торга за зарплату. А нормальной инженерной системой развития.

В тг канале выложил часть вопросов, которые использую на таких встречах.

Возможно, кому-то пригодится как основа для собственного ассессмента.