🗞️ Менеджер в BigTech

Этот пост - часть письма из рассылки “Уложиться в срок”. Подписывайтесь и будете получать каждую неделю по одному письму от меня, с информацией о проектном менеджменте :)

У меня никогда не было желания работать в крупной компании такой как Microsoft, но я тут оказался :) И в принципе, время которое провожу здесь - это в том числе изучение и накопление собственного опыта. Один из таких моментов - понять как устроены процессы в крупных корпорации, почему компании неэффективны, в чем они неэффективны, почему это сложно исправить? Здесь еще мое личное изучение не завершено, но есть чем поделиться интересным для вас.

Возможно, некоторые из вас мечтают или хотели бы оказаться в крупных компаниях - Microsoft, Google, Apple, Amazon, u name it. И это мечта и желание основано на том - что это огромные компании, делают продукты для миллионов пользователей! Вы лично пользуетесь как минимум одним из продуктов этих компаний. И естественным образом возникает желание приобщиться к этому крупному, большому, внести свой вклад в развитие и гордиться собой. Или же, получить красивую строчку в резюме. В тоже время, специально никто не ищет информацию - что значит работать в компании BigTech. В этом выпуске рассылки я попробую описать то, что я здесь увидел и дать вам возможность решить - хотите ли вы этим заниматься. Итак - Менеджер проектов в BigTech (на примере Microsoft).

Дисклеймер

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

• Я вижу лишь небольшую часть компании (условно, 1-2% от всей компании);
• В тоже время, 1% от Microsoft это подразделение в 3500 человек;
• В каждом подразделении - свои правила, ограничения и процессы;
• Microsoft - компания с иерархической структурой. Чем выше позиция - тем у тебя больше возможностей и иной взгляд на процессы и эффективность. Моя же позиция - где-то в нижней части иерархической пирамиды;
• Если вы работаете в крупной компании, такой как Газпром, Сбербанк - возможно, для вас информация будет банальной. Извините :)

Проблема

Основные мотивы, почему я решил написать об этом, следующие:

• Незнание и отсутствие представления о том, что происходит внутри крупной корпорации
• Студенты мне задавали вопросы - как можно устроиться в крупную интернациональную компанию. И вместо ответа на этот вопрос, я бы задал встречный - А хотите ли вы устроиться в крупную интернациональную компанию?
• Если после прочтения статьи вы укрепитесь в желании устроиться - вы столкнетесь с непониманием обязанностей Менеджера проектов в компании - вакансии очень размыты

Ниже я привел описание вакансий с сайта Microsoft для разных должностей.

Вакансия Technical Project Manager. Оригинал и автоматический перевод на русский. Изображение можно открыть в новом окне для чтения

Если смотреть на описание этой вакансии, возникает вопрос - почему на эту вакансию вы не подходите? В целом, перечислены все стандартные требования к позиции, все по PMBoK. Вероятно вы получите отказ, если откликнитесь на позицию, поскольку вам незнаком контекст.

Вакансия Project Manager. Оригинал и автоматический перевод на русский. Изображение можно открыть в новом окне для чтения

Эта вакансия чуть лучше, чем предыдущая - здесь больше конкретики - планирование, продажи, полностью ответственны за реализацию. Но это вакансия Project Manager, а предыдущая – Technical Program Manager. В чем разницам между ними? Обязательства одинаковые. Почему ваш профиль не подойдет?

Вакансия Technical Program Manager II. Оригинал и автоматический перевод на русский. Изображение можно открыть в новом окне для чтения

И последний пример вакансии - Technical Program Manager II. Выглядит намного содержательнее - взаимодействие с командой, которая занимается Центрами обработки данных (ЦОД), Создание отчетов на конкретные процессы, преследование конкретных целей. Это дает больше понимания контекста по позиции и позволяет соискателю получить ответ на вопрос - есть ли у него подобный опыт, подойдет ли он на позиции. Но, чем Technical Program Manager отличается от Technical Program Manager II?

То есть - даже читая вакансии, у вас не появляется ответа на вопрос - что же делает человек на этой позиции и что предстоит делать вам, если вы решили устроиться в Microsoft на эту позицию?

Контекст

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

Какие менеджеры бывают

В виду того, что компания огромная - роли и задачи специалистов становится узко-направленными. Это вполне естественный процесс. В маленькой компании на 30 человек - все занимаются всем, независимо от названия вашей позиции. Если вы проектный менеджер, то вы будете еще и заниматься продажами, и настраивать SEO-аналитику и тестировать. В крупной компании - роли менеджера поделены на области.

• Product Manager - На этой позиции все стандартно. Необходимо разрабатывать видение продукта на 0.5-3 года, считать метрики, оценивать потенциальную прибыль, искать инсайты дя развития продукта. Важно отметить, что “Продуктом” может быть все что угодно - Внедрять Microsoft 365 Copilot в продукты, развивать внутренний продукт или экономику отдельно взятой игры.
• Program / Project Manager - основная задача, вести проекты в определенной области, в который вы эксперт. Например, проекты по внедрении платформы для сбора телеметрии во внутренних сервисах (внедрению, не разработки), ведение внутренних проектов с фокусом на медицину. Program от Project Manager’a может в принципе ничем не отличаться (внутри компании могут неверно назвать позиции) или же, Program Manager - ведет множество проектов в одной конкретной области, например - Телеметрия.
• Technical Program Manager (TPM) - Менеджер проекта с хорошим техническим бэкграундом в отдельной области - архитектура, Дата Центры, безопасность и т.д. Часто, это инженер или аналитик в прошлом, который понял что говорить и договариваться у него получается лучше :). В отличии от позиции выше, TPM может самостоятельно ответить на вопросы технического характера, сделать предварительный анализ без привлечения команды инженеров. В тоже время, TPM может быть одним, без команды и самостоятельно вести проекты (универсальный специалист). Тут важно уточнить, что TPM можно разделить на 2 подроли:
  • Process Owner - TPM, которые владеет процессом. Например, Инцидент-менеджмент, Релиз-менеджмент. “Владеет” - означает, что TPM является экспертом по этому процессу, знает какие метрики и как их собрать, понимает их суть, ищет варианты постоянно улучшать этот процесс. Роль TPM живет до тех пор, пока живет процесс. Процесс умирает - роль TPM уходит вместе с ним.
  • Product Owner - Эта роль TPM пересекается с Product Manager, с той лишь разницей, что работа будет идти преимущественно над внутренними продуктами, без влияния на внешних пользователей. И TPM владеет отдельный продуктом, работая с командами внутри компании, чтобы интегрировать его в существующие продукты. Например, работать со студиями разработки игр, чтобы внести унифицированные стандарты
• Engineering Manager - менеджер команды, которые в первую очередь отвечает за развитие людей в команде и планирует разработку в команде. Project Manager напрямую не работает с командой и не указывает команде что делать. Инженерный менеджер в команде приоритезирует работу команды, на основании общения с TPM. Например, управлять командой, которая предоставляет Managed PostgreSQL для пользователей Azure Cloud.

Итак, определились с классификацией менеджеров - нужно понимать, что вы хотите делать в компании, перед тем, как откликаться на позицию :) В этой же рассылке речь будет идти про Tehchnical Program Manager, который ведет внутренние проекты. Далее, если вы переходили по ссылкам выше, вы могли заметить, что у каждой роли присутствуют градации - Senior, Principal, Staff. Давайте посмотрим на это.

Уровни

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

Для создания контекста мне поможет сайт levels.fyi. Ниже таблица уровней, которые существуют для Technical Program Manager в Microsoft. От 59 - до 68. К каждому уровню у вас есть ваш band - Senior / Principal / Partner.

Мне понравилось вот этот фреймворк для описания разницы между уровнями TPM. С ростом вашего уровня - у вас изменяется скилл по направлениям:

• Процессы
• Влияние
• Работа с людьми
• Дизайн систем
• Технологии

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

Масштаб

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

Если говорить про Microsoft, то в компании 400к+ людей, выстроенная иерархия и отдельные бизнес-юниты по 2-4 тыс человек, которое отвечает за создание и развитие отдельного продукта. Юнитом руководит Vice President / Technical Fellow / Partner Director / whatever. Внутри юнита - отдельное подразделение, задача которого - оптимизация процессов разработки, внедрять практики из соседних подразделений, применять стандарты управления / разработки. То есть, именно здесь будет работать наш Technical Program Manager, о котором пойдет речь в статье. Сразу оговорюсь, что это не единственное место, где такая роль есть, но на этом примере будем рассказывать.

Что такое 2000-4000 человек? Это Инженеры, Разработчики, Инженерные менеджеры / Тимлиды, Дизайнеры, тестировщики, Продакты и т.д. В большинстве своем - все те люди, которые создают ценность в конечном продукте.

Сколько это - 2000-4000 человек? Например, это население небольшой деревни. Вместимость Большого театра 1740 человек. Или же Театр с Амфитеатром

Или таблица 50x40.

И вам, как Менеджеру проектов, нужно донести идею, запланировать работы всех 2000 людей, которые вовлечены в организацию. В случае нахождения со всеми людьми в одной комнате - вы можете рассказать со сцены. Или подойти к каждому и потратить 1 минуту, чтобы рассказать вашу мысль персонально (2000 минут = 33 часа). Учитывая такой объем людей - вам нужно выбрать правильные механизмы взаимодействия.

Можно упростить это тем, что 2000 человек - это 200 команд по 10 человек, у каждой команды есть менеджер и вам нужно связаться только с менеджером этой команды. Поставим тут запятую :)

Следующая сложность масштаба - география. Если смотреть на современный BigTech - команды распределены по Миру. Особенно после пандемии. Команды разбросаны от США, до Европы и Китая / Австралии. Ниже картинка показывает сколько времени во всех уголках мира, где потенциально может быть команда, с которой вам нужно работать:

• В Рэдмонде 08.00, в Китае - это 00.00, в Дублине - 16.00 (конец рабочего дня)
• В Китае (Пекине) - 10.00, в Рэдмонде - 18.00, в Дублине - 02.00
• В Нью Дели - 12.00, в Рждмонде - 23.00, в Китае - 15.00, в Дублине - 07.00

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

И, на мой взгляд, тот самый уровень - Middle, Senior, Principal, Staff - определяет способности менеджера подбирать правильные каналы коммуникаций, чтобы доносить сообщения бОльшим массам. Чем выше уровень менеджера - тем эффективнее он может взаимодействовать с большим количество людей.

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

Знакомьтесь - Джеймс

Давайте рассмотрим профиль типичного менеджера проектов в такой компании - Джеймс.

Джеймс на позиции Principal Technical Program Manager. Он работает в компании уже 15 лет, для него это может быть первая и единственная работа. Ему уже 40+ лет. Джеймс работает не один - у него есть команда инженеров, но у команды есть свой Engineering Manager. Профиль Джеймса - Информационная Безопасность. То есть, он ведет проекты, связанные с информационной безопасностью (Information Security) разрабатываемых приложений, идентификация и устранение уязвимостей разной степени критичности. Безопасность создаваемых сервисов - должна быть на высоком уровне. Для понимания критичности, могу привести цифру - по подсчетам Microsoft за прошедший год в среднем совершается более 4000 атак на аккаунты пользователей в секунду (в сервисах Microsoft), например - попытка подобрать пароль с учетной записи. Поэтому, работа Джеймса востребована в компании и проекты часто имеют высокий приоритет.

Типичные обязанности Джеймса

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

Планирование. Одна из основных задач Менеджера - обеспечить команду работу на следующий квартал, семестр, год. Вероятно, он каждый год участвует в составлении или составляет сам документ под названием “Стратегия”. В документе описывается текущая деятельность и плановая деятельность команды, как минимум на 1 год, а вероятно на 3. Этот документ должен дать прозрачное понимание для команды и для менеджмента команды, вплоть до руководителя юнита в 2000-4000 человек.

Чтобы отслеживать прогресс по выполнению стратегии, Джеймс выделяет OKR - цель работы и ключевые показатели, для оценки уровня достижения. Каждый OKR - отдельный проект по внедрению, изменению внутри юнита на 2000 человек. Например, “Обнаруженные уязвимости с наивысшим приоритетом закрываются командами в течение 15 дней”. Данный проект непосредственно связан с Информационной безопасностью, но его влияние на все команды разработки в юните, над которыми у Джеймса нет прямой власти.

Защита плана. После того, как стратегия написана, OKR выделены и согласованы внутри команды - необходимо защитить стратегию перед руководителями нескольких уровней. Защита подразумевает, что выделенные OKR с заданными приоритетами приняты вышестоящими менеджерами, они согласны с ними, с результатами. То есть, согласны с тем, что нужно инвестировать усилия команды Джеймса на следующий период. Если не согласны - могут попросить перепланировать или учесть дополнительные вводные, что отправляет Джеймса на повторный круг описания и защиту Стратегии. Ниже пример такого документа для небольшой команды в 4-5 человек. Чем больше команда - больше текста. Для понимания ожидания размера “Стратегии” команды.

Отслеживание прогресса OKR.

Вызовы

• Если вы будете писать персональные сообщения Менеджерам команд (наиболее эффективный подход, на мой взгляд) - вы потратите целый день на уведомление каждого;
• Если вы напишите сообщение в общий чат - его увидят процентов 20 от всех необходимых лиц;
• Если напишите письмо с 200+ получателями - это попадает под массовую рассылки и вовлеченность читателей в такие письма (прочитать письмо) - тоже в районе 30%.
• С людьми в вашей таймзоне можно организовать встречу - это еще один эффективный способ.

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

Дополнительный материал

Я боюсь показаться тем, кто прав, поэтому если вам хочется узнать иную точку зрения на подобный материал, то поделюсь дополнительными ссылками

• What do Microsoft program managers do? (2018)
• Day in the Life of a Technical Program Manager (2023)
• TPM Framework
• Пузырь BigTech’a

P.S.

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

Спасибо, что вы читаете!