May 24, 2024

#9: Грейды I. Карьерный рост в BigTech

Вам переслали эту ссылку? Вы можете подписаться на рассылку и получать письма по пятницам. Или подписывайтесь на канал Meet Deadlines в Телеграм, если вы предпочитаете эту платформу

Я запустил канал в Телеграм, посвященный этой рассылке. Я не планирую вести канал, это лишь еще один канал коммуникации с вами. Если вам удобнее получать уведомления о том, что вышел новый выпуск рассылки - подписывайтесь: https://t.me/MeetDeadlines

Также, в канале, под постом, буду рад увидеть ваши комментарии!

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

1. Система грейдов и процесс повышения в BigTech (на примере Microsoft).
2. Зачем в принципе нужна система грейдов в компании и для сотрудника (или не нужна).
3. Как я создавал систему грейдов в Точке (горжусь этой работой). Хотя, ребята из Точки уже описали этот опыт со своей точки зрения.
4. Еще одна система оценки компетенций Менеджера проектов. Рассылка же про менеджмент.

Сегодня первая статья. Я попытаюсь достаточно сухо описать как устроена система карьерного роста (promotion) в Microsoft, но в конце поделюсь своим мнением об этом.

В этой статье:

• Процесс карьерного роста в компании Microsoft. Критерии повышения в компании.
• Поделюсь своим мнением об этой системе.
• Влияние продукта компании на возможности карьерного развития сотрудников.

Уровни

Уже упоминал про систему уровней в Microsoft. Посмотреть их можно на сайте levels.fyi в разрезе регионов и с размером выплат в регионе.

levels.fyi: Карьерные уровни для Product Manager

Уровень - это совокупность обязанностей на конкретной роли и привязанная к этому уровню размерная вилка оплаты (компенсации). Для каждой роли на каждом уровне определен набор обязанностей, иными славами размер ответственности. Каждому уровню полагается свое название позиции: Senior, Principal, Partner, и другие. Это позволяет выстраивать иерархию внутри компании.

Для каждой роли - свой путь и предел роста. Я удивился, что для каждой специальности - есть свой предел. Например, в ветке Product / Project Manager'a предел роста - ниже, чем для того кто управляет командой разработки (Engineering Manager). Как и разработчика. Один мой знакомый радовался наименованию должности: "Technical Fellow". Если посмотреть на компенсацию на этой позиции (1.9$ млн. в год в Сан-Франциско), то можно и позавидовать :).

Levels.fyi: Engineering Managers levels

Levels.fyi: Software Developers levels

Для компании уровни упрощают процесс бюджетирования. К уровню привязаны:

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

Также, для каждого региона, к уровню привязана вилка дохода. То есть, быть Product Manager L62 в Чехии или в США - это разница в 2-3 раза в доходе в абсолютных величинах.

Переход на следующий уровень - это единственный значительный способ увеличить свой базовый доход в Microsoft. Переход по горизонтали (Product Manager L62 -> Software Developer L62) не приводит к существенному изменению дохода.

Если почитать Blind, то можно заметить отношение людей к этим уровням. Из интересного, я нашел оценку (я думаю что она достаточно близка к правде) - в компании около 20% инженеров, кто имеет уровень выше Principal (65). Это добавляет определенную статусность этой позиции :)

Критерии для Promotion

Если смотреть на то, как заявляется процесс Promotion в MS, то звучит он так (мой свободный перевод):

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

Promotion - это единственный вариант, с использованием которого мы можем признать и инвестировать в развитие карьеры сотрудников Microsoft.

При этом, чтобы повышение произошло, дополнительно должны совпасть критерии:

• Потребность бизнеса. То есть, в подразделении должен быть запрос на специалиста более высокого уровня. Я думаю, что это относится к L67 и выше. Потому что эти уровни предполагают управление менеджерами, командами 50 и более человек. Если нет такой необходимости (места в компании) - не получится достигнуть этого уровня.
• Влияние (Impact). Значимость действий, направленные на достижения своих результатов, результатов коллег и подразделения.
• Бюджет. Все логично - если денег в бюджете на повышение нет - повышение не случится.

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

• Обратная связь от коллег, желательно старшего уровня.
• Желание и хорошие отношения с менеджером.
• Случай. Нужно оказаться в нужное время, в нужном месте.
• Ваш менеджер обладает достаточным авторитетом, чтобы обосновать ваш уровень.
• Негласное требование, что сотрудник должен пробыть на позиции минимум 1 год (никто не признает, но фактически смотрят с подозрением на ранний промоушен).
• Наличие / отсутствие других сотрудников в команде / цикле, которые тоже промоутятся.

Процесс

Теперь рассмотрим как выстроен процесс, в деталях.

Описанное характерно до уровня 65. Выше - уже случай и продукт влияют больше, нежели способности.

Шаг первый - определить готовность.

Готовность

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

И тут возникает сложность - требования общие для десятков тысяч человек. Для разных продуктов, для разных стран, для разных направлений (условно, для инженера, который занимается разработкой сервисов Azure Managed SQL Server, или Visual Studio Code, или внутренних систем безопасности). И это приводит к тому, что все требования написаны очень общим языком и интерпретация этих требований - отдана руководителю. Это сложность, она приводит к разночтению требований и каждый понимает по-своему - готов он или нет к росту.

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

Примеры таких требований:

• Быть ориентированным на клиента (внутреннего или внешнего) и помогать команде сосредоточиться на клиенте.
• Демонстрировать хорошие лидерские качества, которые внушают доверие: быть уверенным, красноречивым, вдумчивым и откровенным.
• Налаживать партнерские отношения между организациями для обеспечения успешного взаимодействия команд и достижения более широкого эффекта, чем это было бы возможно в одиночку.

Это некоторые примеры требований для Engineering Manager. Не весь список настолько общий, есть достаточно однозначные критерии:

• Определение соответствующих метрик для создания циклов обучения, чтобы команда могла измерять свой прогресс и самостоятельно корректироваться.
• Представление своей организации и/или компании на мероприятиях Microsoft или индустриальных событиях, таких как Build, Ignite и т.д.

То есть, говоря о соответствии требований будущего уровня - возможны разночтения. И здесь уже зависит от того, насколько хорошие отношения с вашим менеджером, насколько вы говорите на одном языке, насколько другие люди подтверждают способности кандидата. Но на этом этапе важно - определить (набрать аргументы), что кандидат соответствует следующему уровню.

Обоснование повышения и Обратная связь.

Promotion Justification - это документ. Документ, который в виде фактов, выполненной работы - подкрепляют каждый или большинство критериев для следующего уровня. Такой документ обязателен для уровня 63 и выше, в некоторых случаях могут попросить его подготовить для каждого случая (переход с 59 на 60й уровень, с Интерна на джуниор-разработчика).

Как правило, этот документ готовит менеджер / руководитель того, кого собираются повышать. Если менеджер плотно взаимодействует со своей командой, то ему не составит труда составить такой документ. Но, если менеджер удаленный (например, находится на удалении 4-8 часовых поясов от команды), то ему сложно составить полное понимание достижений участника своей команды. Для этого ему помогают два дополнительных инструмента:

• Connect. Это процедура, когда каждый сотрудник, 2 раза в год фиксирует итоги своей работы, достижений и планы, обсуждает их с менеджером.
• Perspectives. Обратная связь от коллег, с кем сотрудник работал. Как правило, здесь менеджер может запросить рекомендацию - считает ли другой человек, что кто-то достоин повышения и соответствует следующему уровню? Если человек, кто дал обратную связь - выше уровня - это повышает шансы на одобрение повышения.

Размер документа увеличивается с ростом уровня. Минимум - 1 страница. На уровень 65 наберется уже 10-12 страниц :)

Пример документа, который я писал для повышения на 64-65 уровень. С графиками, примерами писем (подтверждения)

People Discussion

Стоит отметить еще раз, что этот процесс и конкретно этот шаг работает для тех, кто повышается до уровня 66-67. Все кто идут выше - уже другие критерии будут работать. Но в тоже время, большинство команд разработки описанный процесс затрагивает в таком виде :)

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

Отлично, когда будет больше 1 кандидата для перехода на один уровень (например, 2 инженера из разных команд на 63 уровень). Это позволит сравнить достижения каждого и "откалибровать" видение.

По итогу встречи, принимается решение по каждому кандидату - достоин ли кандидат следующего уровня или результатов недостаточно и нужно дополнительное время.

Какого рода вопросы могут спросить (нестандартные)?

• Как давно человек в MS и как давно его повышали?
• А может ему лучше дать повышенный годовой бонус, а не повысить уровень?
• Что кандидат сделал для демонстрации "вот этого критерия"?
• Есть люди, которые ручаются (согласны с повышением)?

На моей памяти, такие встречи длятся по 4 часа.

Финализация

После формирования списка подтвержденных на повышение - он подымается вверх по иерархии. Там меня не было, но по опыту происходит следующее:

• Оценка бюджета. Если бюджет на уровне организации есть - принимается.
• Могут быть сделаны корректировки. Если слишком высокий процент повышения дохода, то его могут скорректировать. Без объяснения причин.
• Если приходит отказ - в большинстве случаев тоже, без объяснения причин. Нужно повторить в следующем цикле

Но если все успешно, то можно будет получить публичное одобрение и слова поддержки от вышестоящих лидеров, что "эти люди заслужили признание". Может измениться Title в адресной книги (например, назовут Technical Fellow), изменится финансовый план (к каждому уровню привязан максимальный уровень акций и годовых бонусов).

Весь процесс занимает около 2 месяцев.

---

Мое мнение

Если смотреть на всю систему промоушена, то это отражение уровня ответственности, который у тебя есть. Это не отражение твоих знаний и умений. В статье про Менеджера в BigTech я использовал вот эту картинку. Я вижу, что она отражает суть promotion. Ну и факт, что нужно оказаться в нужное время, в нужном месте.

Взято тут. Есть 2 типа коллег - кто делает много работы и не заботиться о своем повышении, и кто вкладывает много сил в рассказ о себе, но мало реально делает.

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

Рекомендации по построению карьеры от одного анонимного участника

Перевод текста выше:

5 советов от меня:

1) Используйте все инструменты, предоставляемые компанией (ознакомьтесь со страницами карьеры. Компания явно хочет, чтобы вы преуспели в своей карьере, и предоставляет множество полезной информации для помощи в этом).

2) Используйте своего менеджера как ресурс. Как упомянуто в блоге Mini-Microsoft, он является вашим путём к повышению, а не препятствием.

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

4) Стройте сеть и выполняйте отличные проекты за пределами вашей команды. Тесное сотрудничество с товарищами по команде - это хорошо, но вы обнаружите, что для продвижения на более высокие уровни вам понадобится не только поддержка вашего менеджера. Вам также понадобится поддержка его коллег (это более важно для продвижения на уровень 63 и выше). Я всегда говорю своим сотрудникам, что я могу рассказывать о их успехах на собрании по повышению, но это будет гораздо мощнее, если я смогу просто сидеть и слушать, как другой менеджер говорит об их успехах и о том, как их помощь и знания позволили его/ее команде выполнить отличную работу.

5) Работайте усердно. Это может показаться немного банальным, но это правда. Помните, как вы чувствовали себя в первый месяц в компании, когда были взволнованы и хотели изменить мир. Сохраняйте этот уровень энтузиазма каждый день и работайте, как будто это ваш первый день. Снова, один из советов, который я даю своим сотрудникам: "Не просто приходите на работу - Приходите на работу в Microsoft." Это значит, выберитесь из рутины и "Делайте Эпические Вещи".

Система предвзята

Любая система грейдов / повышения - субъективна. Это факт. В этой же системе я вижу факторы предвзятости, то есть то, что не зависит от кандидата:

• Если менеджер не хочет повышать сотрудника - сотрудник не будет повышен, независимо от способностей и достижений последнего.
• Если сотрудника видят в организации, он выступает везде, всегда на виду - это сильно повышает шанс получить повышение. Картинка выше это показывает.
• Я встречал случаи, когда на people discussion команда менеджеров отклонила кандидата, потому что он был повышен меньше 1 года назад (негласное правило, что нужно от 1 до 4 лет посидеть на уровне). Ну или, как минимум, с особым вниманием отнесутся к этому случаю.
• Можно ничего не делать, и ты будешь повышен, как выслуга лет. Потому что для менеджера считается плохим показателем, если у него не растет команда.
• Если у вас быстрорастущий продукт (сейчас это все, что касается AI) - люди растут быстро. 3-5 лет назад это был MS Teams. Посмотрите какой быстрый карьерный рост. В то время как, 80% организации борется с legacy продуктами.

Система оценивает навыки менеджера, а не сотрудника

Я убежден, что если менеджер хочет повысить своего подчиненного - он сможет это сделать. Особенно, если у него отличные презентационные навыки, он хорошо и красиво рассказывает. Это касается части процесса People Discussion. Сотрудник может не иметь значимых достижений, но если менеджер, даже скудные результаты, может представить в виде достижений - то это заслуга менеджера. Неважно что сделал сотрудник.

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

¯\(ツ)/¯

Мотив положительный - это позволит в рамках текущей системы повышать людей. То есть, есть правила - в рамках этих правил мы работаем. Если это повышает шансы на рост команды - давайте использовать эту возможность. Моя же изначальная идея была, чтобы инициировать изменения в этом процессе, для устранения изъяна...

Только последовательный рост

Если вы начали карьеру в Microsoft на уровне 62, то через год вы можете рассчитывать на 63, еще через год на 64, через 3 года - на 65. Переход 62->64 - крайне не приветствуется. Хотя и возможен.

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

Отсюда вывод - чем выше уровень будет на входе в компанию, чем быстрее будет идти карьера в компании.

Perspectives (отзывы) - это валюта

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

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

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

При этом, здесь тоже может присутствовать предвзятость. Сталкивался со случаями, когда написанному отзыву не доверяют, потому что лично не знают автора этого отзыва. Например, когда решение о повышении принимают в Рэдмонте (головной офис Microsoft), а отзывы собраны от людей в удаленных офисах, с которыми у людей из Рэдмонда нет знакомства.

Рост на верхних уровнях быстрее, чем на нижних

Мое субъективное мнение: получить повышение с уровня 62 на 63 сложнее чем с 69 на 70. Хотя отзывы других людей и говорят об обратном:

Levels at MSFT are intentionally non-linear. That is to say, they're supposed to get harder the higher you get. The jump from 61-62 is fairly minor. Getting from 65-66 is very difficult. I was a L61 for only six months. I was a L65 for six years.

Alex Jauch, Quora

Мое мнение отличается, потому что один из критериев для повышения - Impact. Значимость твоей работы. Плюс, видимость твоей работы. То есть, чем выше твой уровень, тем больше шансов что у тебя уже есть команда, которая делает проекты, от твоего имени (ведь вы руководите этими людьми), и достижения этих команд - ваши достижения в том числе.

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

Продукты, которые не растут - не развивают людей

Связано напрямую со значимостью и видимостью вашей работы. Если ваш продукт растет - на него обращают внимание, о нем пишут в отчетах (Microsoft рассказывает о росте MS Teams в каждом финансовом отчете). Любой менеджер, может с небольшими усилиями вырасти. Потому что все растет: продукт, количество людей, количество пользователей. Расширяется штат - расширяется ответственность менеджера. Разработчики могут использовать новые технологии, потому что у нет тех.долга еще. Это развивает разработчиков. Любая новая фича может выстрелить и стать привлекательной в продукте. А это говорит о том, что вы, как инженер, сделали эту фичу - это вас продвинуло. Вы показали "готовность" к росту вашей карьеры.

И в тоже время, в продуктах, которые уже приносят прибыль (Windows, Skype, семейство Office) - все сложнее. Есть уже текущие обязательства перед клиентами. Есть техдолг. Код, написанный 40 лет назад. И когда, работа инженера заключается в рефакторинге этого кода, обновлении пакетов и зависимостей - это не выглядит так значимо, как запуск Copilot.

Я также сталкивался с историями, когда менеджер не в состоянии дать оценку значимости работы инженера. Инженер улучшил кодек, который участвует в передаче видео в MS Teams. Работал над этим 4 месяца, но эти изменения не видимы глазу, менеджер не понимает технических деталей, а инженер просто сделал задачу и не в состоянии красноречиво это описать. В результате, работа не оценена.

Ну и в случае со старой кодовой базой - туда не приходят новые технологии и фреймворки. Редкая удача, когда можно начать писать новый сервис, используя новые технологии. Чаще, вы работаете в команде, которая уже 10-20 лет использует одни и те же процессы и технологии, что-то новое отвергается (потому что работает - не трожь) и задача команды - не совершить прорыв, а сделать так, чтобы не сломалось то, что работает уже. Это тормозит рост инженера.

Заключение

Пока я писал эту статью, я пытался найти ответ - почему мое мнение об этой системе столь критично настроено? Ответ нашел: вся система построена на том, чтобы сделать видимость работы, а не сделать реальную работу. Найти способы сказать, что ты должен вырасти в карьере. То есть, реальная работа инженера может быть не так важна, как то, как о ней говорят. Много сил и времени тратится на то, чтобы доказать, что ты уже готов к росту, занять следующую позицию. И это трата времени на то, что не приносит пользу компании. Это не помощь клиентам, это не решение реальных проблем, которые стоят перед компанией. Это игра. Люди пытаются загеймить систему.

Этот выпуск рассылки не относится напрямую к проектному менеджменту. Хотя он про карьеру, в том числе в менеджменте. В приветственном письме этой рассылки, я пишу:

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

Взято тут

Этот выпуск про расширение кругозора менеджера.

Приходите в канал обсуждать статью :)

Укладывайтесь в срок!
Станислав

Узнать подробнее обо мне можно здесь, об этой рассылке - в специальном разделе