December 29, 2023

#5: Менеджер в BigTech

Менеджер проектов в BigTech. Что ждать от этой позиции? Стоит ли откликаться на нее? А хотите ли вы работать на этой позиции?

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

У меня никогда не было желания работать в крупной компании такой как 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. После того, как Джеймс защитил свои планы на следующей период. Теперь необходимо рассказывать о прогрессе по этим OKR. Как ни странно, для этого нужен еще один документ и отдельная процедура. Такие документы и встречи могут называться по-разному (MBR - Monthly Business Review, WBR - Weekly Business Review, QBR - Quarterly Business Review, Rhytm Of Business), в зависимости от периодичности и предпочтений команды, но суть остается одинаковой:

• Отметка прогресса по OKR (Проекта) - успеваем, опаздываем или закрываемся раньше срока?
• На какие моменты стоит обратить внимание вышестоящие лица?
• Какие успехи за рамками OKR
• Что получилось плохо и какие уроки извлечены
• Это представляется в виде цифр, графиков
• Это документ, размером со Стратегию выше
• Периодическое обновление

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

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

Задачи своей команде. Если у Джеймса есть команда, с которой он работает - необходимо поставить им задачи. Задачи могут быть разного уровня - Epics / Features / OKRs. В зависимости от договоренностей с Engineering Manager команды (напомню, что PM напрямую командой не управляет и не управляет приоритетами в команде) - описывает тот или иной тип. Если договоренность с Engineering Manager, что PM описывает все до уровня Epic, а дальше уже команда декомпозирует до задач - PM пишет Epics. Описывает то, что нужно сделать команде, какие цели в рамках эпика должны быть достигнуты. Все Epics - небольшие шаги в достижении конкретных OKR. Если Джеймс технически-образованный, он может снабдить задачу данными (выборкой данных) из разных источников. Например, список серверов, которые потенциально могут быть затронуты при выполнении данной задачи.

Описанные задачи далее требуют контроля. Что ушло в работу? Какие сложности на выполнении отдельной задачи? Это все оперативная работа PM, которую он выполняет, чтобы в дальнейшем отразить в очередном M/W/QBR.

Распространение знаний внутри компании. Если мы говорим о внутренних проектах Джеймса, где ему необходимо сделать работу не своими руками, а попросить другие команды (владельцев сервисов), внести исправления в свои сервисы, чтобы повысить уровень безопасности? Напомню, что у Джеймса в юните - 2000 человек или 200 команд. Что вы сделаете?

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

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

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

• Амбассадор Security & Privacy - лицо, которое заинтересовано в продвижении обще-компанейских инициатив по безопасности
• Руководитель текущего юнита - непосредственно лицо, которое заинтересовано в том, чтобы ответственное ему подразделение достигало целей по различных критериям.
• Непосредственные подчиненные руководителя Юнита - каждое лицо имеет свои персональные планы и цели, которые делигированны ему вышестоящим руководителем (свои же OKR). И далеко не всегда, эти цели соотносятся с целями Джеймса, даже если они в одном подразделении.

Зачем Джеймсу встречаться с ними? Например, это может быть еще один канал для распространения информации или влияния на команды. Если Джеймс не смог договориться с отдельной командой, но его проект все еще важен для всего Юнита, Джеймс эскалирует вопрос для того, чтобы изменить приоритеты у подчиненных команд.

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

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

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

В своей практике я встречаюсь с огромным количеством документов. Стоит отметить, что это именно документы в Word. Не Notion / OneNote / Статья Wiki / Microsoft Loop (рекомендую попробовать), а именно классический документ. Я и сам пишу такие документы. Проблема только остановится в нужный момент. История из моего опыта. Меня попросили объяснить преимущества жизни с микро-репозиториями, в сравнении с одним большим моно-репозиторием. И вроде, эту информацию можно нагуглить, но когда информация обогащена реальными примерами из жизни команд, с которыми ты работаешь - информация воспринимается легче и уровень доверия к ней выше.

Ниже скрин этого документа. Мои изначальные ожидания были сделать 2 страницы. На выходе получился 10-страничный документ, поскольку потребовалось расписания преимущества и недостатки с разных сторон. Я потратил 10 часов на написание этого документа и дополнительно 4 часа встреч с другими людьми в течение 1 месяца. 10% моего рабочего времени за месяц. Этот документ прочитали 8 человек. Эффективная ли инвестиция времени? Оставлю возможность вам ответить на этот вопрос самостоятельно. Лично для себя я собрал хорошие статические данные, которые могу использовать в дальнейшем в своей работе.

Возможно, стоит отдельно сделать статью о том, зачем нужны такие документы (хотя я искренне не поддерживаю этот подход).

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

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

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

Что еще?. Определенно, это не конечный список того, что делает PM в подобной компании. Но если зарезюмировать, то это все еще остаются Коммуникации. Коммуникации, которые не подходят для маленькой команды, коммуницировать нужно с очень занятыми людьми, нужно уметь в 30 минут доступного времени на встречу уместить ваши последние 6 месяцев работы или рассказать о целях на следующий год, уметь работать с огромной, не вовлеченной и уставшей аудиторией. Но все это - коммуникации.

Вызовы

Если выделить отдельно вызовы, с которыми сталкивается менеджер в подобной компании, то список будет такой:

• Коммуникации с распределенной командой, менеджерами других подразделений: почту не читают, с каждым лично не поговорить (их много), чаты не читают.
• Если вы взаимодействуете с менеджерами других команд - у вас нет рычагов влияния на них. Но вас все еще нужно повлиять на приоритеты этой команды. И также, нужно держать в уме, что есть и другие менеджеры проектов, которые приходят к менеджерам команд с похожими запросами :)
• Все коммуникации растянуты во времени - нужно держать контекст в голове или используя другой ресурс (делать заметки), чтобы не упустить все данные обещания и ожидания от третьих лиц.
• Работая с командами в разных регионах - означает, что вам нужно встречаться с ними в удобной для них временной зоне. В их рабочее время. Это не всегда будет ваше рабочее время.
• Работать с Огромным количеством информации, уметь выделять главное из этого потока. Много людей, которые пишут документы. Не все документы оказываются полезными для вас, но чтобы понять - нужно прочитать. Хотя, Copilot позволяет сэкономить время в этой задаче уже. А как использовать Chat GPT и подобные им системы - я уже писал.

Какие способности нужны

Или же - Hard Skills или Soft Skills. Вы могли заметить, что на примере Джеймса нет каких-либо специальных скиллов. Он не использует Microsoft Project для планирования, максимум - только ставит задачи. Не управляет рисками, не пишет Технических заданий и многое из того, что делают классические проектные менеджеры. Не применяет стандарты управления проектами.

Но в тоже время, много сил вкладывает в применение Soft Skills:

• Коммунницирует много и используя разные каналы (почта, чаты, устная презентация).
• Писать понятно и четко.
• Иметь терпение и выдержку.
• Быть бдительным и внимательным.
• Знать Word и Excel.
• Уметь решать конфликты.

Как пример хорошей коммуникации, ниже сообщение в чате от моего коллеги:

Преимущества

Возможно, может показаться, что только сложности в работе у Проектного менеджера в BigTech компании. Но, в целом, есть и преимущества, о которых обязательно стоит упомянуть:

• Строчка в резюме. Опыт работы в крупной компании может сыграть положительную роль для перехода в другую компанию. Не для всех компаний это работает, но в целом - это хороший и положительный опыт.
• Спокойствие и пенсия. Дэвид Хэнсон, CTO 37Signals, писал, что работать в компаниях BigTech - это как сидеть на скамейке запасных. Нет потрясений, не нужно бросать вызовы - делай планомерно свою работу. В сравнении со Стартапами, конечно же.
• Возможность работать над большими проектами и продуктами, которыми пользуются миллионы людей. Это отдельный опыт и практики, которые развиваются.
• Карьерный рост. Он есть все же, несмотря на описанные сложности. Корпорации ценят тех, кто работает много лет в компании. Как правило, чем дольше ты работаешь в компании, тем выше шансов на карьерный рост. Если посмотреть на руководство Microsoft - это люди, кто работает 15-25 лет в Microsoft, пришли после Университета. Мой любимый пример - Игорь Зайка, CVP of Engineering, начал карьеру в Microsoft в 1994 году, в 1990 году окончил Новосибирский Государственный Университет. Сатья Наделла начал работать в MS в 1992 году.
• Релокация внутри компании. Между странами, где представлены офисы компании.
• Обучение. Много, доступно всем и бесплатно.

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

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

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

• What do Microsoft program managers do? (2018)
• Day in the Life of a Technical Program Manager (2023)
• My Experience As An Amazon Product Manager: A Deep Dive
• TPM Framework
• Пузырь BigTech'a
• Sitting on the Bench. David Heinemeier

Вместо эпилога

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

Тем не менее, я инвестировал много времени в улучшение курса "Менеджер проектов в ИТ", где я являюсь ментором (не реклама). Эта работа закончена и я планирую вернуться к регулярным выпускам. Частота не будет 1 раз в неделю, скорее всего я буду писать 1-2 раза в месяц. Подобные статьи требуют много времени на написание (на эту статью я потратил около 14 часов =), но и объем получился не меньше, чем в исследовании применимости Chat GPT для работы менеджера).

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

Спасибо, что вы читаете! Укладывайтесь в срок :)

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