β
Войти Регистрация

Мой менеджер не продвигает меня. Что делать?

Советы инженерного менеджера из Amazon, Meta и Microsoft

Мой менеджер не продвигает меня: карьерный рост в Amazon, Meta и Microsoft
Три кита повышения и реальные истории инженеров, которые застряли на уровне

English briefing for the international IT‑Career‑Gym site (itcareergym.tech). This is not a mirror of the Russian edition: the notes map the same interview topic onto global hiring loops — FAANG-style mocks, onsite loops and remote-first screens — rather than the CIS job board.

Введение

На протяжении всей моей инженерной карьеры я постоянно слышал один и тот же вопрос: «Как мне расти, чтобы получить повышение?» Я работал инженерным менеджером в Amazon, Meta и Microsoft, участвовал во множестве комиссий по продвижению сотрудников и хочу поделиться своим взглядом на то, что на самом деле нужно для роста.

Три кита повышения

Чтобы вас повысили, необходимо совпадение трёх ключевых факторов:

Готовность

Вы действительно готовы к новой должности? Работаете ли вы стабильно на следующем уровне достаточно долгое время?

Восприятие

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

Бизнес-потребность

Если в команде нет объективной необходимости в сотруднике более высокого грейда — повышения не будет.

В этой статье я сосредоточусь на пункте 1 (оценка готовности). О том, как управлять восприятием, расскажу в следующем материале.

Две реальные истории (имена изменены)

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

Сэм

Блестящий инженер, зацикленный на технике

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

В нашей инфраструктурной команде (мы строили API для внутренних сервисов) его предложения часто вызывали бесконечные споры и срывали дедлайны. Формально он сдавал код, но в компании ключевым показателем успеха было внедрение (adoption) этих API. Я объяснил Сэму, что писать код недостаточно — нужно создавать решения, которые решают реальные бизнес-задачи.

Сара

Опытный бэкенд-разработчик, не просившая повышения

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

Но она застряла на одном уровне надолго. Почему? Она сомневалась в себе и никогда не просила повышения вслух. Мы вместе поработали над её уверенностью, я помог ей объективно оценить свой вклад, и она получила повышение очень быстро.

В обоих случаях (Сэм и Сара) ключевым триггером стало ясное понимание их реальной готовности к следующему уровню.

Рассылка

Подписываясь, вы соглашаетесь с Политика.