Я профессиональный проходитель performance review. И может показаться, что это шуточная статья, но я вообще не шучу.

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

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

Если что, это статья не о том, как обманывать систему — не хочется закрывать себе дорогу обратно в бигтех. Это статья про то, как система реально работает, даже если мы делаем вид, что всё иначе.

Performance review — это не про работу

Performance review — это про то, какое впечатление ты производишь, как ты выглядишь в глазах коллег и твоего начальника.

Можно пахать весь год и получить «соответствует ожиданиям». А можно сделать пару правильных вещей в правильное время — и внезапно «сильно превысить ожидания».

Дальше разберём, какие действия для этого нужны.

Нужно вовремя активизироваться

Главная ошибка новичка — быть стабильно хорошим весь квартал или полгода, в зависимости от периодичности performance review.

Это никому не интересно.

Правильный тайминг — последний месяц перед review. Именно в этот момент менеджер:

  • начинает собирать фидбек

  • вспоминает, кто что делал

  • формирует общую картину

И тут ты внезапно оживаешь и перформишь. Ты начинаешь писать апдейты, задавать вопросы, приносить идеи, аккуратно напоминать о себе.

Со стороны это выглядит как рост, вовлечённость и зрелость.

А последнее свежее впечатление — очень важное. Просто представьте, если делать наоборот: в начале перформить, а потом стухнуть… вот и думайте.

Не будьте мудаками — про важность вежливости

Есть миф, что в IT ценят прямоту, жёсткость и «говорить как есть». Это неправда. Ценят тех, с кем комфортно работать.

У меня была коллега в прошлой команде — QA-инженер. И с ней было суперкомфортно работать. Она с каким-то необычным рвением помогала разобраться с требованиями или протестировать корнер-кейсы. Всегда быстро отвечала и будто бы была искренне рада любой коммуникации по, казалось бы, скучным задачам. У неё не было суперглубоких технических знаний, она ещё не писала автотесты и тогда была ручным тестировщиком. Но я всегда ставил ей максимально высокие оценки и искренне расписывал, какая она крутая, во время performance review. Потому что с ней просто было комфортно работать, и мне было всё равно, сколько задач она закрыла за последний цикл.

Если ты:

  • не закатываешь глаза

  • не обесцениваешь идеи

  • не начинаешь каждое обсуждение с «на самом деле всё не так»

То ты уже в топ-20% команды и как минимум получишь хорошие оценки от коллег.

Performance review — это всегда субъективщина. И субъективно приятный человек выигрывает у субъективно неприятного, даже если второй технически сильнее.

Реши проблему за пределами своих обязанностей

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

Но важно не только сделать, а потом ещё и расписать это в красках. Обязательно нужно указать, что это был вклад за пределами команды. Это будет одним из зелёных флажков для повышения. У менеджеров есть такие условные чеклисты, по которым можно дать повышение грейда или ЗП. Если ты внес импакт за пределами команды, то менеджеру будет легче продать твоё повышение уже своему менеджеру.

Слабые стороны — это козырь в рукаве

Нужно всегда находить свои слабые стороны и пробовать их решить в рамках цикла. Как минимум — откопать один такой пункт. А ещё лучше — подготовить почву заранее.

В одном из циклов можно прямо явно подсветить свои слабости. Например, написать, что вы хотите больше вовлекаться в продуктовые требования. А потом в следующем цикле реально один раз взять ответственность за фичу и дотащить её в соло.

Здесь может быть много кейсов:

  • молчите и не участвуете в обсуждениях — начните вовлекаться и предлагать идеи

  • никогда не участвовали в код-ревью — начните это делать

Ну вы поняли. Обязательно нужна какая-то маленькая победа над собой.

Self-review — это не отчёт, а реклама

Если в компании есть этап самооценки — это вообще подарок.

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

Каждый пункт — мини-кейс: проблема → действие → результат.

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

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

Сам скажи, что ты превосходишь ожидания

Не нужно бояться сказать, что ты себя оцениваешь выше среднего.

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

Менеджеру проще согласиться, чем доказывать обратное. Особенно если ты дал ему готовую аргументацию. Ну и ещё полезно посмотреть, как это выглядит в глазах менеджера.

Как выглядит игра со стороны менеджера

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

Если человек поставил себе средние оценки — «соответствует ожиданиям», то с вероятностью 99% менеджер просто скажет ОК и подкинет на сухарики вместо повышения. Потому что есть лимиты, и есть люди, которые прямо кр��чат о том, что они круто работают и повышения ждут. И они, если что, даже могут обидеться, если их проигнорировать.

А тут он смотрит на self-review с высокой самооценкой: достижения расписаны, человек и то сделал, и это. Да ещё и от команды хорошие оценки. Как с таким не согласиться? Другое дело, если есть резонанс — например, плохие оценки от коллег и высокая самооценка. Вот тогда может и не прокатить. Поэтому и нужно выполнять все пункты из статьи.

Performance review — это не про честность. Это про формулировки и видимость. И один правильно выбранный героический поступок. Можно быть сильным инженером и стабильно недополучать, а можно быть просто умным игроком. И, честно говоря, если система такая — грех не научиться в неё играть.

Приглашаю в свой тг-канал «Из найма в продукт». Пишу как совмещаю работу в найме с развитием своего приложения.