Кар'єра в іноземній компанії: девелопера менеджери

Це третій за рахунком пост (посилання на перший і другий ), якими я описую на ДОУ свої кар'єрні поневіряння приблизно раз на рік і потім насолоджуюся вашими дорогими коментарями до наступного посту. У цій статті я поділюся своєю історією становлення як менеджера, як це було, і що з цього вийшло. Думаю, цей пост особливо розважить тих, хто цікавиться роботою в США і/або позицією менеджера і/або як перейти від розробника в менеджери.

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

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

З перших днів кар'єри в ІТ, я чула від колег, що у мене добре виходить розподіляти завдання, створювати атмосферу в команді і т. д. Я періодично замислювалася про те, що пора розглянути менеджерську позицію. Однак, у той час все-таки більше подобалося бути розробником (задачки для розуму тримали в тонусі). Також не було чіткого розуміння, чим саме менеджери цілий день займаються, і як вони впливають на процес розробки. Можливо, це було пов'язано з тим, що я не часто стикалася з (хорошими?) менеджерами, бо у багатьох проектах я сама собі ставила завдання, виконувала їх, демила і відправляла статуси замовнику — відмінний план. (:

З недавніх пір я стала помічати, що як розробник я більше зосереджена на своїй частині проекту і не завжди встигаю зробити крок назад і дивитися на проект в цілому. У деяких компаніях проекти поставлені на потік, і від тебе не чекають більшого, як закрити свій таск і перейти до наступного. Мені стало нудно працювати, не розуміючи, куди проект йде і що чекає нашу команду. Я намагалася брати участь у стратегічних мітингах, пропонувати ідеї щодо поліпшення продукту. Як виявилося, замовникам подобався мій комитмент, тому мені відносно швидко дали можливість себе проявити в менеджерському справі.

Сильний вплив на моє прагнення стати менеджером зробило і створення команди 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. Without Influence 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.

Опубліковано: 16/01/17 @ 11:00
Розділ Блоги

SEO Блог