Промо в бигтехах

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

И да, я понимаю, почему так, и сейчас буду вам объяснять, что это нормально.

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

———

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

Почему так?
Чтобы избежать или уменьшить влияние Принципа Питера — «В иерархической системе каждый индивидуум имеет тенденцию подниматься до уровня своей некомпетентности».

Проще всего объяснить это как промо за успехи на текущем грейде.

Типа, Вася самый лучший разработчик в команде. Тимлид уходит — ставим Васю тимлидом. Разберется.

Или так: Вася — хороший мидл, но что-то заскучал. Повысим его до сеньора.

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

Побочные эффекты

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

Помню, как пришел тимлидом в Авито, и старательно выискивал проявления TUL’a (руководителя юнита). Вот я цели на год составил — галочку поставил. Сейчас хихикаю, понимаю что это было как раз натягивание.

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

Роль руководителя и почему объяснение может ранить

Задача руководителя — объяснить, как матрицу для грейда Х трактуют те, кто проводит перформанс-ревью для этого грейда. И из-за того, что сотрудник склонен «натягивать», это объяснение от руководителя может считываться как обесценивание.

«Да, цели на год есть, но они чисто операционные. А где твоя персональная техническая повестка? Куда ты ведёшь юнит с точки зрения техландшафта?»

пу-пу-пу.. в матрице-то написано просто «составляет цели на год». А тут оказывается какая-то повестка требуется и техландшафт.

И таких вещей много, а матрица достаточно компактная.
Получается, нужно выпускать дополнительный «поясняющий» документ к матрице?

Слишком сложно, да и читать его никто не будет, скорее всего. Потому что людям некогда читать инструкции. Им нужно чтобы инструмент был очевидным и самодокументируемым.

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

Редкость проявлений на высоких грейдах

От сеньоров требуются проекты на квартал или полгода. Понятно, что такие проекты появляются не часто.

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

Условно, средний тимлид М2 в Авито нанимает одного-двух инженеров в год. Таким образом, техлиду М1 скорее всего потребуется год, чтобы показать, что он умеет самостоятельно нанимать, и поставить галочку в матрице тимлидов.

Средний TUL М4 нанимает тимлида раз в 2 года. Таким образом, тимлиду в шапочке aTUL нужно 2 года, чтобы закрыть компетенцию М4.

Средний кластерлид М6 нанимает TUL’a раз в 3 года. .. Ну вы поняли.

Чем выше грейд — тем больше долгоиграющих компетенций надо закрыть.

А справедливо ли это?

Выглядит как несправедливость: человек сидит «в шапочке» грейда Х+1, делает работу Х+1, но получает зарплату грейда Х. Но если это повышение нужно самому сотруднику — считаю, что это ок.

А вот если это компания приходит к сотруднику и говорит «нам надо чтобы ты работал работу грейда Х+1» — справедливо сразу дать за это компенсацию.

Проблема в том, что обычно процесс одинаковый для всех. Давайте обсудим в комментах.

P.S. Не говорю, что это идеальная система и всем срочно надо так же делать в любом стартапе. Это способ обеспечить управляемость системы, как в посте про Performance Review.
Добро пожаловать в мир корпоративных процессов и правил :)