Релокейт-опрос 2017 (для тех, кто уже уехал). Собрано более 1500 анкет.
×Закрыть

Карьера в иностранной компании: из девелопера в менеджеры

Это третий по счету пост (ссылки на первый и второй), которым я описываю на ДОУ свои карьерные скитания примерно раз в год и затем наслаждаюсь вашими дорогими комментариями до следующего поста. В этой статье я поделюсь своей историей становления как менеджера, как это было, и что из этого получилось. Думаю, этот пост особенно развлечет тех, кто интересуется работой в США и/или позицией менеджера и/или как перейти от разработчика в менеджеры.

Даже не знаю, с чего начать рассказ об этом — поэтому в лучших традициях презентаций и постов, начну с «коротко о себе». Хештег блог. Вернее, #блог (:

Давайте знакомиться

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

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

Сильное влияние на мое стремление стать менеджером оказало и создание команды DА-14 с нуля. Основатель любого проекта знает, что без хотя бы базовых управленческих навыков будет сложно (читай, невозможно) поддерживать и развивать свой бизнес.

В общем, на момент официального перевода на позицию Technical Program Manager, где я по сей день трудоустроена, я накопила пару лет опыта ведения проектов, скрам-мастеринга и продакт-оунершипства (не нашла русский эквивалент этих терминов). Если кому-то интересно, детали моего бэкграунда доступны легким кликом мыши по ссылке на мой профиль в LinkedIn.

Как это было

Я работала web dev eng — 2 (эквивалентно уровню middle в Украине) в AmazonRobotics (Бостон, США). Появилось желание стать менеджером. А каким, как и где?

Первым делом нужно было понять, какая именно менеджерская должность будет наиболее интересна. В отличие от моего предыдущего опыта работы в украинском аутсорсе, где более всего распространена одна должность — прожект менеджер (PM), в США я столкнулась со следующими вариантами расшифровки буквы «P» в титуле «PM»: Project, Program и Product. Все эти позиции могут быть как не технические (PM), так и технические (TPM). Для того, чтобы окончательно запутать народ, еще добавили Software Development Manager (SDM), Subject Matter Expert (SME). Скорее всего, это не полный список, но вы уловили суть — позиций много, требования к ним разные.

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

  • Техническая должность соответствует моему опыту и видению дальнейшей карьеры.
  • TPM отвечает за коммуникации со смежными командами, статус-репорты вышестоящему руководству (включая директоров и VP) и запуск продукта, что делает работу более разнообразной и дает возможность не только участвовать во всех стадиях разработки проекта, но и развивать свои коммуникативные навыки.
  • Не нужно проводить evaluations, 1-to-1, карьерные митинги и т.д. с членами команды, что позволяет сфокусироваться на проекте.

Дальше нужно было найти вакансию TPM’a на интересном проекте, где я бы могла принести пользу. В AmazonRobotics все места были заняты и я обратила свой взор на Amazon HQ, потому что именно там новые проекты растут, как грибы, и кто-то должен ими управлять (я, мхахаха!). Один из проектов выглядел многообещающе и получил хорошие отзывы в прессе. Я поговорила с нанимающим менеджером и командой. Перспективы показались достойными.

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

  • Для начала ознакомилась с описанием похожих вакансий, в частности с квалификациями, требованиями и что нужно будет делать, чтобы понять, куда я ввязалась.
  • Поговорила с текущими TPM’ами и теми, кто их собеседует, чтобы узнать, к чему стоит быть готовым на интервью. К примеру, оказалось, что стоит быть готовой к coding exercise. Когда меня пригласили на собеседование в Google на аналогичную позицию, то предложили присоединиться к онлайн-созвону, где кто-то из компании давал рекомендации по прохождению интервью. В частности, там я услышала про «mock interviews», про которые написано ниже.
  • Организовала для себя тестовые (aka «mock») интервью, чтобы попрактиковать скилл прохождения собеседований на новую должность и получить полезный фидбек от коллег. Можно даже пойти на настоящие собеседования в компании, в которых вы точно не станете работать (например, расположены супер-неудобно).
  • Обновила тех знания, включая такие основы CS как структуры данных и алгоритмы с помощью онлайн-курсов (есть много хороших, Pluralsight мне нравится больше остальных по соотношению потраченного времени к результату).
  • Стремилась использовать любую возможность проявить и развить свои лидерские качества и организационные навыки: проводила тех толки или иные мероприятия, улучшала рабочие процессы, решала конфликтные ситуации в команде, собеседовала, нанимала и менторила...
  • Структурировала свои знания с помощью PMBok — свод знаний по управлению проектами, а также американский стандарт проектного менеджмента. В книге популярно описаны процессы управления. PMI использует этот документ в качестве основного справочного материала для своих программ по профессиональному развитию. Зачастую вижу наличие сертификата Project Management Professional, PMP в требованиях к вакансии TPM.
  • Glassdoor — мой источник получения информации о компании, команде, зарплате, и даже возможных вопросах на собеседовании. В плане аналогичного ресурса в Украине, слышала, что по зарплатному вопросу люди ссылаются на DOU.ua.

Сам процесс собеседования был довольно стандартным (упрощен ввиду внутреннего перевода), подобрала пару интересных ссылок по теме: Microsoft, Google, Amazon.

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

Челленджи

В отличие от менеджеров в украинских ИТ-компаниях, мне никто из тех команды не подчиняется. Мы равны и репортим одному и тому же менеджеру. В данном случае, возникает вопрос — как я могу повлиять на своих коллег и заставить их прислушаться к своему мнению? Особенно, если команда сильная и каждый имеет свое мнение на все? Особенно, когда ты новый член команды? А если ситуация критическая, и вы опаздываете по срокам, и все паникуют?

В моей должности без тех бекграунда никуда. Он важен по многим причинам, включая: легче заслужить доверие разработчиков и понять, когда разработчики вешают лапшу на уши. Команда должна видеть, что ты не только понимаешь, о чем идет речь, но и задаешь правильные вопросы и предлагаешь продуктивные идеи. Тогда они начинают прислушиваться. Кроме того, я до сих пор пишу код 10-30% времени. Мои коллеги знают: если надо — я готова закатать рукава, сесть и «напедалить».

Однако, наибольшее влияние на мою репутацию в команде оказало даже не понимание технологий или решений, а банальная компетентность в своем деле. По-моему, роль менеджера — помочь команде стать и оставаться успешной. Все разработчики хотят сдать проект в срок и получить хорошую з/п, просто менеджер должен напоминать и помогать им в этом. Приведу пример текущего проекта. Я присоединилась к команде за 4 месяца до того, как его нужно было сдать. В тот момент он находился в статусе Red. У нас еще не было требований, но уже было понятно, что скоуп очень объемный. Осложняло ситуацию то, что дедлайны были спущены сверху и их невозможно было передвинуть по бизнес-причинам (это жизнь). Разработчики полушутили, что если мы успеем завершить проект и все останутся живыми и здоровыми — это будет чудо. Нужно было понять, что и как мы можем разработать за такой срок, составить проектный план, трекать прогресс, риски и т.д. В итоге, титаническими усилиями, но проект был успешно сдан, клиент доволен. В этот напряженный период удалось сократить овертаймы до минимума (всего пару человек пожертвовали парой выходных) — не идеально, но лучше, чем было. Команда поняла мою роль и ценность, их поддержка помогает нам ставить более амбициозные планы и стремиться к большему.

В общем, как у нас принято говорить: Earn trust. Influence without authority. И будет вам счастье, (будущие) менеджеры!

FAQ

Q: Поменялась ли зарплата?
A: Нет.
Q: Нравится ли текущая должность?
A: Пока все идет сложно, но хорошо, ни о чем не жалею (:

Q: Расскажи о своей команде.
A: Product: Product Manager −1, Program Manager — 1; Tech: SDM — 1, TPM — 1, Senior SDE — 4, Middle SDE — 5, Junior SDE — 3. Все умные.
Q: Расскажи о проекте.
A: Извиняйте, не могу сказать больше, чем доступно в Интернете по причине NDA.

Q: Какие еще проекты есть в Амазоне?
A: Амазон в наше время делает все.

Итого

Пока все идет сложно, но хорошо, ни о чем не жалею (:
Делитесь своим мнением, историями и прочим в комментариях или в соцсети (мои аккаунты привязаны к профилю ДОУ) — буду рада услышать! Самые интересные вопросы добавлю в FAQ.

46 комментариев

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

Анна, на Ваш взгляд, как лучше всего достичь «Earn trust. Influence without authority», не имея титула authority. Вы собственно в этой заметке упомянули, что не став ещё формально TPM, старались всячески практиковать присущие данной позиции навыки. Мне знакома эта ситуация, и я лично отметил для себя, что «Earn trust. Influence without authority» очень сложно, как раз таки без authority. Вопрос доверия, мне кажется не является первопричиной, просто по сути мои инициативы начинают накладываться/конкурировать с работой существующего менеджера, и люди вроде бы и не против influence, включая менеджера, но объективно и не могут рассматривать мои инициативы как приоритетные, т.к. понятно, что у них есть свои задачи за которые должны держать ответ перед формальным authority. Расскажите немного о том, сталкивались ли вы с такими коллизиями вообще, и если да, как практиковали навыки, которые по сути не в рамках Ваших должностных обязанностей.

Hi Anna — great article! how did you clear it with PR team? I remember it wasn’t so trivial for me

Все, что здесь указано — это общеизвестная информация(включая фото, взятые из интернета). В таких случаях можно с ПР отделом не общаться. А о чем ты хотел написать?

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

Одна компания пригласила меня делать вебинар по мобильным технологиям. ПР сказали что надо пройти медиа тренинг сначала (

Мдас. Хорошо ты обгадил контору в которой работаешь. Боись, что отправят тебя обратно в Украину.

Да, так получается каждый комментарий надо одобрять у ПР отдела)

Аня, отличная статья! :) Только можно англицизмов поменьше, ну или пиши их без транслитерации.
С удовольствием почитал бы о твоем карьерном пути в больших подробностях. Вообще, круто что хватает мотивации писать нечто подобное, а то обычно вылазят всякие: то к формулировкам цепляются, то видите ли ждали статью про робототехнику, то критикуют чей-то образ жизни выпячивая собственную зашоренность и примитивность...
В общем, все ок — не обращай внимания и продолжай в том же духе!

Да-да, всегда найдут, о чем написать — глас народа!
Спасибо за поддержку, Макс. Желаю удачи!

+1! автору статті! в Україні був знайомий особисто.

Спасибо, Сергей) И сейчас знакомы!

Не совсем понимаю как регулар может стать толковым ТПМ, откуда берется опыт набитых шишек и тд. Или почти все задачи сводятся просто к сбору репортов?

Нет, вот цитата по теме:

В общем, на момент официального перевода на позицию Technical Program Manager, где я по сей день трудоустроена, я накопила пару лет опыта ведения проектов, скрам-мастеринга и продакт-оунершипства (не нашла русский эквивалент этих терминов). Если кому-то интересно, детали моего бэкграунда доступны легким кликом мыши по ссылке на мой профиль в LinkedIn.

Конечно опыт был, не стала сюда включать, чтобы не потерять фокус. Читайте в следующей статье )

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

Если работа состоит только в координации, то скоро все будет гораздо проще: vc.ru/p/ai-boss
Думаю, в аутсорсинге можно заменить менеджеров на бота вообще без всяких проблем, ну еще можно добавить модуль генерации отмазок. Работа будет следующей: 1) Утром выслал всем инвайты на митинг, опросил статусы всех, раздал задачи, обновил доску. 2) По статусам сгенерил отмазку или отчет клиенту, сгенерил отмазку или отчет стоящему выше менеджеру. 3) Бот может вести всю статистику, автоматически генерить квартальные отчеты начальникам, отсылать инвойсы клиентам итд. Чем такое бот хуже менеджеров в аутсорсе? Я бы сказал, местами даже лучше :)

Ты не согласен с тем, что менеджеров-передастов легко заменить ботом?

настоящего менеджера — нет. прокси между клиентом и программистами — да

Настоящий менеджер-передаст — впечатляет.

Зачем же сужать роль менеджеров до «передаста»? Упраление ожиданиями заказчика и команды, просчитывание рисков, распределение ресурсов, и т.д. и т.п.

Упраление ожиданиями заказчика и команды, просчитывание рисков, распределение ресурсов, и т.д. и т.п.
не более чем красивые слова, особенно когда касается крупной компании ака Амазон)

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

И отлично, ибо надо рабоать с душой))) Чего как раз у многих в крупных компаниях не хватает.

з.ы. если что я большой оптимист) просто хорошо осведомленный)

Да расслабься. Девушка поняла главное в работе менеджера и далеко пойдет.

Зачем же сужать роль менеджеров до «передаста»?
Это не ко мне вопрос, а к тем конторам, которые таких юзают.

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

Какие гарантии что такого не произойдет с менеджером?

Тоже верно, но с людьми как-то привычнее работать.

В отличие от менеджеров в украинских ИТ-компаниях, мне никто из тех команды не подчиняется.

Еще один пример того, как не нужно говорить обо «всех». Если на какой-то галере это не так, это не означает что в украинском аутсорсе так везде.

Тем более в данном случае автор странным образом отождествляет Project Manager (коих абсолютное большинство среди наших «менеджеров») с собой, Program Manager (их, как и Product Manager не столь часто можно встретить в отечественных аутсорсинговых компаниях).

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

Согласна с большой честью вышесказанного.

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

По своему опыту скажу, что многие продакт менеджеры имеют-таки подчиненных, часто других менеджеров, но бывает и тех команды(особенно, в отсутствии других менеджеров).

Но не иметь в непосредственном подчинении команду разработчиков — не означает не иметь влияния на них.
О том и речь.

Вот это немного позабавило:

В отличие от моего предыдущего опыта работы в украинском аутсорсе, где более всего распространена одна должность — прожект менеджер (PM), в США я столкнулась со следующими вариантами расшифровки буквы «P» в титуле «PM»: Project, Program и Product.
Вы вообще до это PMBook читали?

Александр а что конкретно там в PMBOK (Project Management Body of Knowledge) об этом написано?

По крайней мере там описано, что это такое и как одно к другому относится. А то автор подает так, как вроде только в США это используется и больше нигде в остальном мире об этом не знают. То, что автор с таким не столкнулся с таким в украинском аутсорсе еще собственно ничего не значит.

А зачем на галере столько разных Pxx позиций? Берем одного ПМа и на него вешаем вот это вот все. Да и ПМы в аутсорсе зачастую могут влиять чуть менее чем не на что. Бюджетом и властью владеет Джон из-за океана...

Да откуда на галере Program Manager и Product Manager?

На галерах сейчас модно Solution Architect и PDS 2.0 я случайно мимо шёл зашёл на одного с титулом человек совершенно искренне реально гордится что сам своими руками настроил у себя на сайте поддомены вместо разных портов на апаче а ну ок Solution Architect detected.

Я думаю здесь речь идет о том, что больше всего у нас в аутсорсе получила распространение роль Project Manager (PM). Хотя в последние годы все больше становится Product Managerов. А когда апплаишься на вакансию PM в U.S. необходимо уточнять, что конкретно стоит за PM — Product, Project, Program Management.

Product Manager
для галлер это сильно ответственная работа, как минимум требует знание рынка, а с этим беда, когда рынок за пару тысяч километорв

Конечно, читала. Слово «распространено» означает, что эта наиболее часто встречаемая позиция, разве это не так? В амер. компаниях, кот. я работаю структура более четко выстроена(на мой взгляд), имеются все представители буквы «P» во множественном экземпляре.

Да, меня эта формулировка автора тоже позабавила.

На всякий случай — www.quora.com/...and-Project-manager-roles

Опять же, все комментирующие из-за океана. Покажите, где на укр. форумах люди обсуждали такую насущную проблему?

Если я не ошибаюсь, речь шла о популярности проектных и программных менеджеров в Украине и США. Не так?

Нет, речь шла о вашем удивлении при встрече иных расшифровок аббревиатуры PM в контексте того, что с PMBOK вы уже были знакомы.

Дело в том, что теория и практика не всегда пересекаются.

Подписаться на комментарии