Это третий по счету пост (ссылки на первыйи второй), которым я описываю на ДОУ свои карьерные скитания примерно раз в год и затем наслаждаюсь вашими дорогими комментариями до следующего поста. В этой статье я поделюсь своей историей становления как менеджера, как это было, и что из этого получилось. Думаю, этот пост особенно развлечет тех, кто интересуется работой в США и/или позицией менеджера и/или как перейти от разработчика в менеджеры.
Даже не знаю, с чего начать рассказ об этом — поэтому в лучших традициях презентаций и постов, начну с «коротко о себе». Хештег блог. Вернее, #блог (:
Давайте знакомиться
С первых дней карьеры в ИТ, я слышала от коллег, что у меня хорошо получается распределять задачи, создавать атмосферу в команде и т.д. Я периодически задумывалась о том, что пора рассмотреть менеджерскую позицию. Однако, в то время все-таки больше нравилось быть разработчиком (задачки для ума держали в тонусе). Также не было четкого понимания, чем именно менеджеры целый день занимаются, и как они влияют на процесс разработки. Возможно, это было связано с тем, что я не часто сталкивалась с (хорошими?) менеджерами, ибо во многих проектах я сама себе ставила задачи, выполняла их, демила и отправляла статусы заказчику — отличный план. (:
С недавних пор я стала замечать, что как разработчик я больше сосредоточена на своей части проекта и не всегда успеваю сделать шаг назад и смотреть на проект в целом. В некоторых компаниях проекты поставлены на поток, и от тебя не ждут большего, как закрыть свой таск и перейти к следующему. Мне стало скучно работать, не понимая, куда проект идет и что ждет нашу команду. Я старалась участвовать в стратегических митингах, предлагать идеи по улучшению продукта. Как оказалось, заказчикам нравился мой комитмент, поэтому мне относительно быстро дали возможность себя проявить в менеджерском деле.
Сильное влияние на мое стремление стать менеджером оказало и создание команды 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, и хочешь стать менеджером, то желательно это делать в той же области (карты), ибо знание доменной области поможет уменьшить стресс от новой должности. Также, переход из команды в команду или переезд добавит ненужный стресс и будет отвлекать от работы в первые месяцы. В идеале, рекомендуют оставаться в той же команде, если это возможно. Если вы читали выше, то поняли, что я пошла другим путем, было сложно, но все получилось.
Челленджи
В отличие от менеджеров в украинских ИТ-компаниях, мне никто из тех команды не подчиняется. Мы равны и репортим одному и тому же менеджеру. В данном случае, возникает вопрос — как я могу повлиять на своих коллег и заставить их прислушаться к своему мнению? Особенно, если команда сильная и каждый имеет свое мнение на все? Особенно, когда ты новый член команды? А если ситуация критическая, и вы опаздываете по срокам, и все паникуют?
В моей должности без тех бекграунда никуда. Он важен по многим причинам, включая: легче заслужить доверие разработчиков и понять, когда разработчики вешают лапшу на уши. Команда должна видеть, что ты не только понимаешь, о чем идет речь, но и задаешь правильные вопросы и предлагаешь продуктивные идеи. Тогда они начинают прислушиваться. Кроме того, я до сих пор пишу код
Однако, наибольшее влияние на мою репутацию в команде оказало даже не понимание технологий или решений, а банальная компетентность в своем деле. По-моему, роль менеджера — помочь команде стать и оставаться успешной. Все разработчики хотят сдать проект в срок и получить хорошую з/п, просто менеджер должен напоминать и помогать им в этом. Приведу пример текущего проекта. Я присоединилась к команде за 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.