Как расти: план развития, обратная связь, performance review, менторство

Самая распространённая модель роста в голове у начинающего разработчика примерно такая: работаешь хорошо → тебя замечают → повышают. Модель не то чтобы неверная, она просто неполная настолько, что перестаёт работать примерно на второй год.

В реальности между «работаешь хорошо» и «повысили» стоят: чьё-то представление о том, что вы сделали; чьё-то представление о том, что от вас ожидалось; бюджет; календарь; и человек, который на встрече с другими руководителями должен вслух за вас поручиться. Каждое из этих звеньев можно понять и на каждое можно повлиять — но сначала надо узнать, что они существуют.

Эта статья — про механику. Не «как стать лучше» (мотивационных текстов на эту тему достаточно), а из каких конкретных процессов состоит рост: как выглядит рабочий план развития, как просить и давать обратную связь, что происходит внутри performance review и калибровки, как устроено менторство и почему опыт иногда перестаёт превращаться в развитие. Про то, что вообще отличает грейды, — в предыдущей статье; здесь про то, как между ними двигаться.

Три разных вещи, которые называют одним словом «рост»

Если не развести их, план развития превращается в список курсов, который никуда не ведёт.

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

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

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

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

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

Плато: почему пятый год иногда равен первому

Рост никогда не идёт равномерно. Он идёт ступенями: рывок при смене контекста, потом плато, где вы шлифуете то, что уже умеете. Плато само по себе нормально — на нём вы превращаете сырое умение в надёжное. Проблема, когда плато становится постоянным местом жительства.

Признаки, что вы застряли (честно проверьте на себе):

• За последние полгода вы не сделали ничего, что вначале казалось «я не уверен, что справлюсь».
• Вы не можете назвать конкретный технический вопрос, который вы стали понимать глубже.
• Вас не просят ревьюить чужие решения на этапе замысла, только код после факта.
• Задачи приходят к вам полностью сформулированными и в том же размере, что год назад.
• Вы объясняете задержки словом «неинтересно», а не словом «сложно».

Плато пробивают четыре вещи, и ни одна из них не «работать усерднее»:

1. Задача на полразмера больше вас. Не «в два раза» — тогда вы утонете и решите, что не тянете. Полразмера — это когда 70% понятно, а 30% придётся выяснить.
2. Честная обратная связь от того, кто уже там. Своими силами вы не увидите, чего у вас нет: слепое пятно на то и слепое.
3. Смена контекста. Другой домен, другой стек, другая роль, другая компания. Смена не обязана быть радикальной: переход из продуктовой команды в платформенную внутри той же компании меняет почти всё.
4. Обязательство объяснить другим. Ничто так не обнажает дыры в понимании, как необходимость провести внутренний доклад или отревьюить чужой дизайн-документ.

Индивидуальный план развития, который не мёртв через месяц

В компаниях с HR-процессом вас попросят завести IDP (individual development plan). Обычно это заканчивается таблицей вида «изучить Kubernetes — Q3 — статус: в процессе», которую никто не открывает до следующего ревью.

Мёртвый план узнаётся по трём признакам: цель сформулирована как активность, а не как способность; нет способа проверить, достигнута ли она; нет привязки к реальной рабочей задаче, а значит, на неё никогда не будет времени.

Живой пункт плана состоит из пяти частей:

Ключевой пункт — опора на реальную задачу. План развития, который живёт отдельно от бэклога, конкурирует с бэклогом за ваше время и всегда проигрывает. План, вшитый в бэклог («я беру именно эту задачу, потому что она развивает именно это»), выполняется сам собой.

Пример рабочего IDP на полгода, как он реально выглядит в заметках:

# IDP, H2. Правило: не больше 3 пунктов. Четвёртый = ни одного.
период: "июль — декабрь"
контекст: "хочу дорасти до самостоятельного ведения фич целиком (см. грейд-матрицу, п. 2.3)"

цели:
  - способность: "проектирую интеграции с внешними API так, что деградация партнёра не роняет наш сервис"
    доказательство: "дизайн двух интеграций принят без переделок; в постмортеме инцидента с партнёром наш контур выстоял"
    действие:
      - "взять задачу PAY-330 (интеграция эквайринга) целиком, от требований до мониторинга"
      - "прочитать Release It! гл. про Circuit Breaker и Bulkhead, применить"
      - "попросить Аню отревьюить дизайн ДО написания кода"
    опора: "Аня (владелец платёжного домена)"
    сверка: "1:1 в середине сентября"

  - способность: "мои дизайн-документы читают и понимают люди из смежных команд"
    доказательство: "два документа прошли обсуждение, правки — по сути, а не 'непонятно, что тут написано'"
    действие:
      - "писать по шаблону команды, приносить черновик на ревью Косте"
      - "провести один внутренний доклад по итогам PAY-330"
    опора: "Костя"
    сверка: "октябрь"

  - способность: "не завишу от других при разборе продовых проблем"
    доказательство: "две смены дежурства без эскалации по вопросам 'а где это смотреть'"
    действие:
      - "пройти два прошлых инцидента по постмортемам и повторить разбор самому"
      - "завести себе шпаргалку по дашбордам, отдать команде"
    опора: "SRE-чат, Дима"
    сверка: "ноябрь"

не_делаю_в_этом_полугодии:
  - "фронтенд (интересно, но не двигает грейд сейчас)"
  - "сертификация по облаку (не спрашивают ни здесь, ни на рынке в моём сегменте)"

Секция не_делаю — не декоративная. План развития без явных отказов превращается в список желаний. Три цели — практический потолок для полугодия у человека с полной загрузкой; четыре означают, что не будет выполнена ни одна.

Как выбрать, что качать

Соблазн — качать то, что интереснее. Иногда это правильный ответ (интерес — топливо, без него ничего не выйдет), но решение стоит принимать осознанно, по трём осям: нужно команде сейчас, дефицитно на рынке, интересно вам.

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

Отдельно про знание домена. Начинающие его систематически недооценивают: кажется, что «предметная область» — это скучно, а расти надо в технологиях. На практике инженер, понимающий, как устроен бизнес компании, принимает решения, которые технически более сильный, но доменно слепой коллега принять не может. Это один из самых недооценённых рычагов роста, и он бесплатный: надо просто ходить на встречи с аналитиками и задавать вопросы. Как задачи вообще рождаются из бизнес-потребности — разбиралось в статье про требования.

Обратная связь: как получать, как принимать, как давать

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

Как просить, чтобы получить не «всё хорошо»

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

• «Я вёл вчерашнее обсуждение архитектуры. Что бы ты на моём месте сделал иначе?»
• «Что мне мешает брать задачи такого размера, как у Ани, — чего ты пока во мне не видишь?»
• «Если бы тебе сейчас надо было назвать одну вещь, которую мне стоит изменить в работе, что бы это было?»
• «Мои ревью полезные или занудные? Спрашиваю серьёзно, хочу калибровку.»

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

Просить обратную связь стоит не только у руководителя: у тестировщика, с которым вы работаете (он видит вашу аккуратность), у аналитика (он видит, насколько вы понимаете задачу), у того, кто ревьюит ваш код. Роли и их взгляд на вас разбирались в статье про команду.

Как принимать, не разрушая канал

Обратная связь — хрупкая вещь: один спор в ответ, и человек больше её не даст, потому что дешевле промолчать. Практическое правило: в момент получения — только уточнять, не оценивать.

Плохая реакция (даже когда вы правы по фактам): «Нет, там была другая ситуация, меня заблокировал соседний сервис». Хорошая: «Понял. А по каким признакам это было видно снаружи? Хочу понять, как это выглядело с твоей стороны». Свою версию можно изложить позже, отдельным сообщением, когда эмоция улеглась, — и часто выясняется, что она уже не нужна.

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

Как давать: SBI и почему «ты неаккуратный» не работает

Стандартная и реально работающая схема — SBI (Situation — Behavior — Impact), из Center for Creative Leadership:

• Ситуация: когда и где. «Вчера на демо, когда показывали корзину».
• Поведение: что конкретно человек сделал. Наблюдаемое действие, не оценка и не предположение о мотивах. «Ты трижды перебил Аню на середине фразы».
• Влияние: что из этого вышло. «Продакт не дослушал про ограничение по срокам и ушёл с встречи с неверным ожиданием».

Сравните с «ты вечно всех перебиваешь и не даёшь никому сказать». Второе — ярлык: его нельзя проверить, с ним можно только согласиться или обидеться. SBI даёт человеку то, что он может изменить завтра.

Три ошибки, которые превращают обратную связь в конфликт:

1. Сэндвич («похвалил — поругал — похвалил»). Все давно распознают конструкцию, и похвала обесценивается, а критика воспринимается как формальность перед плохим. Лучше: отдельно хвалить (часто и конкретно), отдельно говорить о проблемах (прямо и наедине).
2. Обратная связь про личность вместо поведения. «Ты безответственный» неисправимо. «Ты не предупредил, что не успеешь, и я узнал об этом в день релиза» исправимо.
3. Накопление. Полгода молчать, а потом вывалить всё на ревью. К этому моменту у человека нет ни шанса исправиться, ни доверия к вам.

Обратная связь вверх (руководителю) — отдельный навык и вполне легальная вещь. Формула та же, только с явным запросом: «На последних трёх задачах приоритет менялся уже после того, как я начинал. Я теряю на переключении примерно день. Можем фиксировать приоритет хотя бы на неделю?». Это не жалоба, это конкретная просьба с обоснованием — с такими работают.

Performance review: что это и что там реально происходит

Performance review — регулярная процедура, где компания фиксирует, как вы работали за период, и принимает решения: рейтинг, пересмотр вознаграждения, повышение грейда. Она есть почти во всех средних и крупных компаниях и почти отсутствует в маленьких стартапах (там её заменяет разговор с фаундером — быстрее, но менее предсказуемо).

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

Годовой цикл

Практические выводы из этой картинки, которые не пишут в HR-рассылке:

• Решение принимается на калибровке, а не на встрече с вами. К моменту, когда вам озвучивают результат, он уже принят, согласован и вписан в бюджет. Влиять надо за месяцы до, а не в момент разговора.
• Промежуточная сверка — самая ценная точка цикла. Это единственный момент, когда ещё можно узнать, что вы не дотягиваете, и успеть что-то сделать. Если её нет в процессе — организуйте себе сами, попросив у руководителя честную предварительную оценку в середине периода.
• Цели, поставленные в январе, к декабрю почти всегда неактуальны. Реорганизация, смена приоритетов, отменённый проект. Это нормально, но требует явного пересмотра: цель, которую отменила компания, не должна висеть на вас как невыполненная. Проговорите это письменно в момент смены приоритетов, а не в декабре.

Кто с кем разговаривает

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

Последствия для вас, из которых следует всё практическое поведение:

• Ваш менеджер на этой встрече — ваш адвокат. Ему нужны аргументы, которые он сможет произнести вслух перед скептиками. «Он хорошо работает» не аргумент. «Он вытащил интеграцию с эквайрингом, которая полгода стояла, и сам нашёл дыру в ретраях до того, как она стрельнула в проде» — аргумент.
• Вас сравнивают не с вами прошлогодним, а с другими людьми того же уровня. Это бывает неприятно, но это прямое следствие того, что бюджет конечен.
• Работа, о которой знает только ваш менеджер, слабее работы, о которой независимо скажет менеджер соседней команды. Отсюда ценность задач, пересекающих границу команды.

Затухание сигнала

Из этой картинки следует конкретная привычка, которую стоит завести на первой же работе, — журнал достижений (в англоязычной среде его называют brag document; лучшее описание — у Джулии Эванс, jvns.ca/blog/brag-documents).

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

## 2026-09, неделя 3

- **PAY-330, интеграция эквайринга.** Довёл до прода. Сам заметил, что у партнёра
  нет идемпотентности на ретраях, добавил ключи запроса — иначе получили бы двойные
  списания. Подтверждение: комментарий Ани в PR #4412, обсуждение в #payments 12.09.
- **Дежурство.** Разобрал инцидент с ростом latency отчётов без эскалации (первый раз
  сам). Причина — отсутствующий индекс, PR #4430. p95 отчётов: 4.2 с → 0.7 с.
- **Помощь.** Онбордил Мишу: собрал шпаргалку по локальному запуску, он поднял
  окружение за день вместо трёх (по его словам).
- **Незакрытое.** Дизайн-документ по нотификациям завис — жду ответа от смежников
  с 04.09. Написал напоминание, если не ответят до 20-го, эскалирую.

Обратите внимание на структуру: не список задач, а действие → результат → подтверждение. Подтверждение (ссылка, метрика, чужое слово) превращает утверждение в факт, который менеджер может процитировать на калибровке, не рискуя репутацией.

Как писать self-review

Самооценка — это не отчёт о проделанной работе и не место для скромности. Это черновик аргументов для вашего адвоката. Три правила:

1. Impact-first, а не activity-first. Не «участвовал в проекте миграции», а «перевёл отчёты на новое хранилище, время построения упало с 40 до 12 минут, служба поддержки перестала получать жалобы на зависшие выгрузки (было ~15 в месяц)». Если метрики нет — назовите наблюдаемое следствие. Если и его нет — возможно, работа действительно не дала эффекта, и честнее это признать.
2. Не присваивайте чужое и не растворяйте своё. «Мы командой сделали» — типичная ошибка добросовестных людей: вклад размывается. Пишите «команда сделала X, моя часть — Y и Z». Это одновременно честно и информативно.
3. Проговорите провалы сами. Провал, названный вами с выводом («переоценил срок миграции вдвое, потому что не проверил объём легаси-данных заранее; теперь всегда начинаю с замера»), работает на вас: это демонстрация зрелости. Тот же провал, вскрытый менеджером, работает против.

Отдельно: не занижайте себя из вежливости. В системах, где самооценка идёт рядом с оценкой менеджера, заниженная самооценка часто становится якорем. Скромность здесь не добродетель, а потеря информации.

Повышение: как решение принимается на самом деле

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

Что из этого следует практически:

• Просите пробу заранее. «Хочу вести следующую фичу целиком, от требований до мониторинга. Готов, чтобы ты подстраховывал» — нормальный разговор на 1:1, а не наглость. Без пробы состояние Устойчивое_поведение недостижимо в принципе.
• Одного раза мало. Одна удачная фича — это может быть везение. Два-три — это уже поведение, за которое можно поручиться.
• Спрашивайте про критерии до, а не после. «Что должно быть в моём списке за полгода, чтобы разговор о следующем уровне был реалистичным?» — вопрос, который экономит год. Если у компании есть грейд-матрица, разберите её вместе по пунктам, честно отмечая, где вы «делаю», где «делаю с поддержкой», где «не делаю».
• Отказ бывает не про вас. Заморозка бюджета, свежая реорганизация, вы полгода как в команде. Это не повод обижаться, но повод спросить прямо: «это про мой уровень или про обстоятельства?». Ответ определяет, ждать или искать.

Когда честнее уйти

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

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

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

Менторство: четыре разные роли, которые путают

Слово «ментор» в русскоязычном IT используют для всего подряд. Разделим:

Разница между ментором и спонсором — самая важная и самая неочевидная. Ментор помогает вам стать лучше. Спонсор тратит на вас свой политический капитал: предлагает вас на проект, защищает на калибровке, рекомендует. Ментора можно попросить. Спонсорство просят редко и обычно косвенно — его зарабатывают тем, что человек, поручившийся за вас, не пожалел. Формулировка Лары Хоган об этом различии — классика темы, larahogan.me/blog/what-sponsorship-looks-like.

Как найти ментора и не потратить его время зря

Ошибка новичков — просить «менторство» абстрактно: «будешь моим ментором?». Это запрос на бессрочное обязательство неизвестного объёма, на который здоровый человек отвечает уклончиво.

Работает узкий и ограниченный запрос: «Ты много работал с событийными системами. Можно я раз в две недели по полчаса приношу тебе свои решения на разбор? Месяца три, дальше посмотрим». Конкретная тема, конкретный формат, конкретный срок, лёгкий выход. Отношения продлеваются сами, если обеим сторонам полезно.

Как не сжечь ресурс:

• Приходите с домашней работой. Не «расскажи про Kafka», а «вот моя схема ретраев, вот два варианта, вот чем я склоняюсь ко второму, где я не прав?».
• Ведите повестку вы, а не он. Ментор не обязан помнить, о чём вы говорили в прошлый раз, и придумывать вам программу.
• Отчитывайтесь о результате. «Сделал по второму варианту, вот что вышло, вот где ты был прав» — единственная валюта, которой можно заплатить ментору. Люди продолжают вкладываться в тех, у кого их вклад даёт видимый эффект.

Ментор не обязан работать в вашей компании и не обязан быть сильно старше. Иногда лучший ментор — коллега на полгрейда выше, который прошёл ровно ваш путь недавно и помнит детали, которые сеньор с десятью годами опыта давно забыл.

Быть ментором — самый недооценённый способ вырасти самому

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

Объяснение обнажает дыры в собственном понимании быстрее любого курса: вы обнаруживаете, что не можете внятно ответить на «а почему именно так», и это ваша граница знания. Кроме того, менторство — самая доступная демонстрация поведения следующего грейда: переход от «я делаю» к «через меня делают другие» — ровно то, что отличает сеньора от мидла и лида от сеньора.

Ошибки начинающих менторов:

• Решать за подопечного. Быстрее показать свой ответ, чем ждать, пока он найдёт свой. Экономит час сегодня, стоит месяцев роста человеку. Правило: если у него есть рабочий, пусть и неидеальный вариант, — дайте сделать по-своему, кроме случаев, когда цена ошибки высока.
• Забыть про калибровку сложности. Задача «на полразмера больше» — искусство: слишком лёгкая не растит, слишком тяжёлая ломает уверенность. Ориентир — человек должен буксовать, но не тонуть, и знать, где вы, чтобы спросить.
• Молчать про проблемы. Ментор, который полгода говорит «всё отлично», а потом подопечный получает низкую оценку на ревью, — плохой ментор.
• Путать менторство с делегированием мусора. Отдавать новичку только рутину — не менторство, а использование.

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

Как это выглядит в энтерпрайзе и в стартапе

Ни один вариант не лучше — они дают разное, и полезно понимать, что именно.

В энтерпрайзе (подробно — в отдельной статье) процесс формализован: есть грейд-матрица, календарь ревью, промо-комитеты, требования к «промо-пакету» иногда на несколько страниц. Плюсы: правила написаны и их можно прочитать; рост слабо зависит от личных симпатий одного человека; при смене руководителя ваша история не обнуляется. Минусы: медленно (окно повышения раз в полгода-год, а то и реже), много работы «на бумагу», реальный вклад может проиграть умению его оформить. Стратегия здесь — читать матрицу буквально, собирать доказательства по её пунктам, заранее выяснять, кто ещё голосует за вас.

В стартапе (см. статью про стартапы) формального процесса обычно нет вовсе. Плюсы: радиус влияния расширяется мгновенно — если вы единственный, кто разобрался в биллинге, вы владелец биллинга уже завтра, безо всяких комитетов; рост в ответственности может обогнать рост в грейде на годы. Минусы: полная непредсказуемость. Титул может отставать от реальной работы; «повышение» иногда означает просто, что вам добавили обязанностей; а при найме сильного человека сверху вы можете внезапно потерять область, которую считали своей. Стратегия — фиксировать договорённости письменно (в стартапе память людей стирается вместе с пивотами) и не путать «мне доверяют» с «за это мне платят».

Отдельно про аутсорс и аутстафф (типы проектов): там рост часто привязан к внутренней сетке компании-подрядчика, а не к проекту клиента, и вы можете вести критичную для заказчика систему, оставаясь по документам мидлом. Смотрите, кто именно принимает решение о вашем уровне, — это не всегда тот, с кем вы работаете каждый день.

Антипаттерны роста

Собрано из наблюдений, а не из книг. Каждый выглядит как усердие и каждый ведёт в тупик.

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

Вечный перфекционист. Не отдаёт задачу, пока не идеально; переписывает то, что работает. Выглядит как высокая планка, читается снаружи как «не умеет доводить до конца» и «не чувствует приоритетов».

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

Ждун. «Я хорошо работаю, меня заметят». Не заметят: см. картинку про затухание сигнала. Это не про несправедливость мира, а про пропускную способность внимания других людей.

Технический сноб. Меряет рост чистотой кода и модностью стека, презирает «скучный бизнес». Упирается в потолок ровно там, где начинается работа с неопределённостью, компромиссами и людьми.

Тот, кто путает занятость с ростом. Работает по двенадцать часов, закрывает вдвое больше тикетов, чем все. Через год — то же самое, только больше. Радиус не изменился ни на миллиметр. Больше того же самого не двигает вас никуда. Про управление собственным временем и энергией есть отдельный трек time-management.

Мини-итог и чеклист

Рост — это три параллельных процесса (компетенция, радиус, видимость), а не один. Он идёт ступенями, плато нормально, застревание — нет. План развития работает только когда привязан к реальным задачам и сформулирован как способность с доказательством. Обратная связь не приходит сама, её надо запрашивать узкими вопросами. Performance review решается на калибровке, где вас нет, и ваш менеджер там — адвокат, которому нужны цитируемые факты. Повышение — признание уже происходящего, а не аванс. Менторство растит ментора не меньше, чем подопечного.

Что можно сделать на этой неделе:

• Завести файл-журнал достижений и внести туда всё, что вспомните за последний месяц.
• Найти грейд-матрицу своей компании (если есть) и честно разметить: делаю / делаю с поддержкой / не делаю.
• На ближайшем 1:1 задать один узкий вопрос: «чего ты во мне пока не видишь для следующего уровня?».
• Выписать три цели полугодия в формате «способность → доказательство → действие → опора → срок».
• Назвать одну задачу «на полразмера больше» и попросить её.
• Если вы уже не самый неопытный — предложить помощь новичку и вести с ним встречи по его повестке.

Источники и что почитать

• Camille Fournier, The Manager’s Path — лучшая книга о том, как выглядят уровни инженерной карьеры с обеих сторон стола; главы про менторство и tech lead полезны задолго до менеджмента.
• Tanya Reilly, The Staff Engineer’s Path и её сайт noidea.dog/staff — что происходит с ростом выше сеньора; полезно читать заранее, чтобы понимать вектор.
• Will Larson, StaffEng и блог lethain.com — в частности, разборы промо-пакетов и того, как устроены решения о повышении.
• Julia Evans, Brag documents — практика журнала достижений, из которой выросло полкультуры self-review.
• Lara Hogan, What sponsorship looks like и её же материалы про 1:1 и обратную связь.
• Center for Creative Leadership, модель SBI — первоисточник схемы обратной связи.
• Публичные инженерные лестницы: progression.fyi — коллекция реальных грейд-матриц разных компаний; полезно сравнить со своей и понять, что в вашей компании считается уровнем, а что — местной особенностью.
• Google re:Work, раздел про performance management — как крупная компания объясняет собственную механику ревью и калибровки.

Что дальше

Рост рано или поздно упирается в разговор про деньги — и это отдельная дисциплина со своей механикой: оклад, бонусы, опционы, грейдовые вилки, индексация и способы понять, сколько вы стоите на рынке, не гадая.

Зарплата и своя цена: как устроено вознаграждение и как исследовать рынок