Drive your career as React Developer with Symphony Solutions!
×Закрыть

Почему на самом деле вы не хотите быть Project Manager

Поговорим о карьерном развитии в менеджеры и том, как понять, что вы хотите быть Project Manager. А также — почему некоторые люди возвращаются в разработку, тестирование или анализ.

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

Чаще всего на вопрос «Что делает РМ?» мне отвечают:

  • «Менеджер управляет людьми, помогает им развиваться, говорит, что надо делать»
  • «Менеджер ходит по встречам, общается с людьми, решает их проблемы».
  • «Управляет командой, а с этим я уже сталкивался».

Иногда на вопрос, почему ты хочешь быть РМ, отвечают:

  • «У меня хорошо получается общаться с людьми».
  • «Я хочу помогать людям развиваться».
  • «А куда мне еще развиваться?»

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

Если необдуманно выбрать развитие в менеджеры, результаты могут быть разрушительными для самого человека, команды, которую ему доверили, и клиента. Лично моё мнение: переход в менеджмент сравним с переходом на темную сторону силы :)

Предлагаю рассмотреть вместе причины, из-за которых не стоит становиться РМ.

Иллюстрация Уляны Патоки

Направлений развития много, и это всего лишь один из вариантов

Самая частая причина, которую я слышала от сотрудников или менти: «А куда ж еще?».

Другие варианты:

  • «Ну так QA прямая дорога в РМ».
  • «Ну так сеньору куда еще развиваться?»
  • «Ну так аналитики все идут в РМ».

Выбор направления, потому что «все идут» или «а куда еще» — неправильный. Если не знаете, куда двигаться, лучше поговорить с руководителем, более опытным приятелем, ментором и так далее. Обсудить, что хотелось бы получить, с чем работать, и выбрать ту позицию, которая максимально соответствует ожиданиям. Иногда аналитики уходят в девелоперы или архитекторы, QA вырастают в Test Manager, автоматизаторов, разработчиков, аналитиков. Иногда SME уходят в аналитики или доменные девелоперы\тестировщики.

Стоит также рассмотреть другие менеджерские роли: Tech Lead, Team Lead, Scrum Master, Product Manager...

Если ищете новые проекты, вам интересно участвовать в разработке нового продукта или интересен R&D, обратите внимание, что менеджеров, в отличие от сеньоров, архитекторов или экспертов в доменной области, зачастую туда не приглашают.

Поэтому, прежде чем принять решение «Хочу в РМ», подумайте, что вы хотите получить от работы и чем именно заниматься, а затем выберете направление и по возможности ментора, который сможет помочь на начальном этапе.

Потеря экспертности

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

На пути в менеджеры такому человеку стоит помнить, что при переходе из «крутого Senior» в «джуніор PM» он перестанет быть крутым, потом перестанет быть и Senior. И понадобиться несколько лет, чтобы снова стать сеньором уже в менеджменте и опять стать востребованным.

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

Я не говорю, что абсолютно нет позиций, где совмещаются эти роли, но в какой-то момент все равно придется сделать выбор, на какой стороне силы вы находитесь. Не раз видела менеджеров, которые через полгода или год бросали работу и уходили в разработчики или в архитекторы. Поэтому, прежде чем «становится РМ», ответьте честно хотя бы себе: готовы ли вы отказаться от девелопмента, анализа или тестирования?

Работа с людьми, или Власть vs ответственность

«Мне нравится работать с людьми — я иду в РМ»

Если это единственная причина, то стоит подумать, насколько взвешенное такое решение. «Нравится работать с людьми» — это можно делать на любой позиции. РМ о другом.

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

«Если я буду РМ, смогу помочь людям развиваться»

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

Если вы не являетесь экспертом или гуру в конкретной области, то чем поможет вам позиция РМ?

«Если буду РМ, меня будут слушаться»

То есть сейчас, работая в команде, вас не слушаются? Разочарую: даже если вы станете РМ, признания сразу это не даст. Признание — это авторитет в команде. Профессиональный или нет, но признание идет не за должность. Уже сейчас начинайте работать над собой, чтобы заработать в команде это признание.

Как говорил один из моих менторов, сначала ты выходишь за рамки позиции, а потом позицию подгоняют под тебя.

«У меня есть опыт управления, и я хочу принимать решение, что мы будем делать»

Хочу обратить внимание: власть имеет обратную сторону — ответственность. Именно вы будете ответственными за каждую ошибку, совершенную командой. Именно вы ответственны за реализацию, идею, направление, сроки, сокращение и все, что происходит внутри команды. Готовы?

Переговоры и коммуникация

Ключевой аспект менеджерской работы — коммуникации и переговоры. Самые сложные виды: работа с клиентами, со «звездами» внутри команды и при конфликте интересов.

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

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

Иногда надо кого-то сокращать (особенно если это аутсорс и сильно зависит от клиента) и выбрать, кто это будет (а вся команда супер). С этим нужно научится работать, продумывать альтернативы и варианты для тех, кто остается, и тех, кто выходит из проекта. Именно вы, смотря в глаза своему человеку, будете говорить о его сокращении, потому что... Да, именно вам нужно будет подготовить объяснение, почему именно он. И желательно, чтобы к этому времени были варианты, которые сможете предложить в рамках компании.

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

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

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

Sales

Как говорил хороший знакомый: «Достигая определенного уровня в менеджменте, уже не важно, в какой сфере работаешь». Абсолютно все равно, что продавать: человеко-дни или ящики печенья, также без разницы, под какой торговой маркой это делаешь. Соглашусь, что мы создаем продукты, сервисы, разрабатываем суперские вещи и всякие ноу-хау и это совсем не то, что делать печенье на заводе. Да! И еще раз да! На уровне деливери-команды.

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

Да, мне приятно работать в деливери. И это приятнее, чем менеджить поставку печенья :) И так же бесспорно, что продажа — не единственный аспект работы менеджера. Но умение презентовать — один из ключевых навыков, и это нужно принять.

Work-life balance

На менеджерской позиции нет такого понятия, как «ушел из офиса и не работаю». Менеджерская работа сильно интегрирована в повседневную жизнь. Тайм-менеджмент, доведенный до совершенства, работает безукоризненно, пока ничего не «упало» и у клиента ничего не случилось. Вы будете первым человеком, у которого прозвенит телефон.

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

Ну и напоследок зарплата :)

Если планируете сменить роль, нужно быть готовым к пересмотру зарплаты. Чтобы сравнить уровни зарплат, посмотрите статистику на DOU.

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

Если после всего этого вы все же решили: «РМ — это мое», welcome to the club :) На темной стороне силы есть свои преимущества, даже несмотря на то, от чего пришлось отказаться.

LinkedIn

51 комментарий

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

Сомнительное утверждение, тут в статистике много ПМов из Веб-кухонь, которые не особо блещут зп. В топ галерах переход в ПМ — это повышение, в том числе и по ЗП

Джун РМ даже в топ-5 аутсорс компаниях не будет получать много. Я не могу говорить за все компании, но зачастую РМ получает меньше чем тех лид или архитектор.

понятие джун ПМ мне не так хорошо знакомо, видел это в Люксе.
И пример из Люкса из 2013 года.
Работает себе БА на $3500, выростает из штанов и становится джун ПМ на непродолжительный срок. Могу поверить что на это время ему не повышают зп (кроме плановых), такое возможно, но после — становясь ПМом — это однозначный промоушен. Но что бы он получал МЕНЬШЕ?) ну это чисто физически бредовый кейс, в норм галерах зп не понижают (разве что массово), и опять же — переход в ПМы — это всегда повышение, когда сотрудник вырос из своих обязанностей дева\ба\куа

хороший архитектор ОБЯЗАн получать больше ПМа, тут вопросов нет, тех лид — не везде, зависит от проекта.

QA вырастают в Test Manager, автоматизаторов, разработчиков, аналитиков

Серьезно?!
В 2020м году PM говорит, что QA *вырастает* в разработчика....
Дальше читать не смог(

Мое мнение, что любой переход на другую роль — это развитие и рост.

Сейчас заминусуют из-за того, что напишу.
В украинском аутсорсе большинство ПМ вызывают отвращение, так как реально хороших (полезных) ПМ-в видел очень мало. ПМ на стороне заказчика ещё можно воспринимать как координатора, ПМ на стороне аутсорс конторы зачастую какой-то погонщик для слабо мотивированных команд, которым пофиг на проект, скроки, расспорядок, планирование (причем ПМ даже ничего сделать не может с учетом текучести кадров и возможности уйти на 500+ в любое другое место). Если еще и команда работает по скарму, не вижу смысла в этих ПМ-ах как таковых.
На западе ПМ-мы нравятся больше, потому что как минимум там адекватность на порядок выше.
А в целом сказать ПМ — это не сказать ничего. ПМ — настолько разные в разных компаниях, что судить по всем ПМ-ам не нужно.

В украинском аутсорсе большинство ПМ вызывают отвращение
слабо мотивированных команд, которым пофиг на проект, скроки, расспорядок, планирование

Какие команды — такие и ПМы :)

Учитывая, что среднее время работы на аутсорс проектах около 1 года, то команд таких большинство. Большинство народу просто не имеет никакой мотивации что-либо делать, если завтра будет новые проект, а после завтра его поманят на +500 через дорогу. В итоге «опытный синьор» 10 лет работы ~ 8-10 разных компаний. Что вообще можно хотеть от команд, в которых люди примерно такого состава?

Вот я в компании 5 лет, проектов поменялось за это время = 3.
Проекты живут не сильно дольше синьоров)

Я имел ввиду проекты между компаниями. Проекты в рамках одной компании могут иметь одинаковую направленность, domain так сказать. Да и понятие проекта слишком разное. Недавно вот делал такую штуку: в существующем проекте переделывал, делал более гибкими permission-ны. Ну чтобы можно было универсально накидывать пермишины для более специфических понятий (скажем message-ей) и чтобы это работало не как hard code, а динамически в зависимости от permissions конкрентного пользователя. PM называл это проектом. Хотя по сути была сделана новая прослойка (service) между UI и back-end, которая умела модифицировать SQL запросы на лету с автоматическим дополнеными where conditions сгенереными на основе security context-а пользователя. У меня это язык не поворачивался назвать проектом, хотя по времени вышло где-то 2-3 месяца 2-х человек прежде вышло в прод.

Да я про большие проекты с иностранными компаниями.
Как-то 2-3 года и что-то происходит с ним. Проект достаточно стабилен и контракт закрывают.

Не все команды такие :) Как и не все РМы.
Есть РМы которые умеют создавать крутые команды не на один проект, не на один год.

Какие ПМы/тилиды — такие и команды. ПМ строит процесс и команду, а не наоборот.

Автора статьи знаю лично. И она лучший ПМ, которого я знаю за свои 15 лет в ИТ.

Спасибо! Для меня такая обратная связь очень ценная.

Основной продукт украинского аутсорса — тела. Очень часто в аутсорсе ПМ является прокси между командой и клиентом. Цели ПМа аутсорса (продать как можно больше тело-часов, удовлетворение заказчика не должно упасть ниже определенной планки, проект должен существовать как можно больше вне зависимости от бизнес-валью клиента) и ПМа клиента часто бывают разные. В итоге вовлеченность команды в проект минимальная, в первую очередь это касается бизнес-валью проекта. По этим и не только причинам проекты, отдаваемые на аутсор, редко бывают интересные с бизнес точки зрения. Как результат:

ПМ на стороне аутсорс конторы зачастую какой-то погонщик для слабо мотивированных команд

Жизнь менеджера сплошная печаль сдобренная плюшками. И это самая неблагодарная работа в команде разработки. Серьезно? ))) Хотя если нет хорошего технического бекграунда и опыта работы с бизнесом, то да — боль, печаль и грусть в режиме 24/7. Если есть, то самая интересная работа в ИТ. Хотя и самая сложная.

Жизнь менеджера сплошная печаль сдобренная плюшками. И это самая неблагодарная работа в команде разработки.

Подскажите пожалуйста, у вас сложилось такое впечатление после прочтения? Или это из рабочего опыта?

Это был сарказм после прочтения статьи )))

Люблю это напряжение, когда ты в огне, все в огне, а ты такой- It’s fine ;) Лично меня бодрит и держит в тонусе. Ты тот человек, который всегда имеет план и продумал риски и ничто не может тебя выбить из седла, всегда можно придумать как и что и с наиболее минимальными потерями, ну иногда и не с минимальными )
Самое главное ещё уметь брать ответственность за косяки и нести ее и делать выводы.

и при этом уметь отдыхать, чтобы не выгореть :)

«Если уж писать, то только тогда, когда не можешь не писать» Л. Н. Толстой

В управленцы стоит идти только если по-другому уже не можешь. То есть если появились вопросы «а стоит ли мне идти в менеджеры» — то скорее всего, нет, не стоит.

P.S. в последнее время появилось много людей с громкими тайтлами. Ребят, вы — менеджер, только если можете выбирать (нанимать/увольнять) людей, которыми вы будете управлять.

и еще если есть навыки выстраивания процессов, чтобы были аргументы почему одно — хорошо, а другое — плохо, или например почему решение клиента может быть ок или не ок с т.зр разработки архитектуры решения. Этот опыт можно набирать даже не на позиции РМа.

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

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

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

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

Менеджер це в принципі не про роботу з людьми, а про роботу з ресурсами для реалізації поставленої задачі в рамках встановлених обмежень. І все. Трактувати проджект-менеджера як піпл-менеджера це дорога в нікуди.
Можливо корені того ростуть у появі проєктних координаторів, яким «справжній» ПМ (тепер він сіньйор ПМ, часом акаунт чи навіть делівері) делегував зверху саме ту частину повноважень, яку найлегше і найефективніше масштабувати, тобто власне роботу з тімкою і частково з завданням (scope).
Але це досить далеко від суті управління проєктом. Може тому їх і називають джуніор ПМ-ми, що масштаб задач як у джуніка порівняно з сіньйором...

Я, как менеджер, работаю с людьми для достижения результата.
И лично мое мнение, что относится к командам только как к ресурсу — это достижение результатов в краткосрочной перспективе. А в «игре в долгую» моя команда — это моя опора.

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

Поддержу, что работа РМ — это не только работа с людьми. В статье и не говорилось про то, что есть компонентами работы, на эту тему достаточно материала даже на DOU. Я, основываясь на опыте работы с разными РМами, обозначила наиболее «болевые» точки, почему из РМов уходят.

Поддержу, что работа РМ — это не только работа с людьми

а с чем еще работает PM в IT?

Если брать общее опеределение, то
Ме́неджмент (англ. management — управление, руководство, администрирование, дирекция, умение распоряжаться, владеть, управлять) или управление производством — разработка и создание (организация), максимально эффективное использование (управление) и контроль социально-экономических систем.
...
Субъект менеджмента — это человек или группа людей, создающих управленческие воздействия в рамках организации и в целях реализации её целей и задач.

Объект менеджмента — это все то, на что ориентированы управленческие воздействия субъекта менеджмента. Объектами менеджмента могут выступать персонал организации, её конкуренты, финансы организации, производство, сбыт, поставщики ресурсов, информация т.д.

Субъекты и объекты менеджмента представляют собой в совокупности систему управления организации
(конец цитаты вики)

Что является в IT субъектами менеджмента помимом людей?
Для PM ессно, а не для любого менеджера.

Процессами? так это не объекты менеджмента, а инструменты.
как и остальное в списке
Элементы системы менеджмента
Миссия организации
Цели организации
Организационная схема подчинённости
Подразделения
Показатели оценки результативности деятельности (KPI)
Регламенты работы
Система измерений деятельности

а про що ще думає PM у IT?
назвіть що в IT —

купа техніки, логістика пального, набоїв і харчів

щоб довести що:

Менеджер це в принципі не про роботу з людьми

у IT, а не взагалі.

бо взагалі так, офіс-менеджер наприклад не працює з людьми :)
у менеджера з закупівель, supply chain і т.і — теж, не робота з людьми головне

а чи можете довести що:
PM у IT — це в принципі не про роботу з людьми

Люто плюсую. Была очень удивлена, что весь текст про работу с людьми. Перед тем как идти в PM в первую очередь стоит задуматься, чем он занимается, помимо работы с людьми.

Головні, майже єдині ресурси в IT — це люди.
Тому суть управління проектом — це досягнення злагодженної праці — людей

Peopleware. Одним словом.
Дивно що на it сайті треба пояснювати специфіку менеджменту у it. Без піплменеджменту ніякого успіху не буде. «пасти котів» головний обов’язок менеджера.
За інші важливі речі відповідають інші спеціалисти

Хороший материал. Правда, хотелось бы узнать у самой авторки — а почему она захотела в PM? Может тогда бы и другие люди лучше для себя поняли? Если рассказывать про кайф, который лично ты или твои коллеги получают от должности, то у читающего будет полная картина, чтобы решить, а надо ему ли это.

Да, такая информация позволяет более полно взглянуть на картину.
Это будет в следующей части.

Спасибо за статью.
У меня отношение к менеджерским ролям предельно утилитарное.
Если отбросить карьерную и монетарную составляющую, то, по-сути, менеджером нужно становиться ровно тогда, когда видится невозможным реализовать проект собственными усилиями или усилиями небольшой самоорганизованной команды.

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

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

Очень хорошие вопросы!
Есть еще вариации: почему я хочу быть менеджером? какие мои потребности будут удовлетворены? какую ценность я могу принести?
Если после этих вопросов останется желание пробовать и развиваться в этом направлении — это хороший стимул реализоваться в своих ценностях.
Спасибо за комментарий.

PM — это когда «все горит, и ты горишь...». Имхо, это самая неблагодарная позиция в ИТ. Тут нужен особый склад ума, mindset, чтобы комфортно себя чувствовать между молотом и наковальней.

На ПМ-а давление со всех сторон — команда, топ-менеджмент, кастомеры, HR, etc.

При прочих равных и при возможности выбора между PM/SA/Engineering Manager/Team Lead — что угодно, но не ПМ. Особенно, когда ты не «ноулайфер» и есть семья, хобби, друзья.

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

Каждый человек принимает для себя решение самостоятельно.
Я за то, чтобы это было взвешенное решение.

Я бы не сказал, что PM это когда «все горит, и ты горишь...». Если горит часто значит PM, что-то делает не так или не совсем понимает, что надо чтобы не горело. У джунов горит чаще, для мидл меньше. Конечно бывают моменты, но если ты хороший PM и понимаешь правила игры и умеешь думать головой, общаться эффективно с людьми, умеешь управлять ожиданиями и стейкхолдерами, анализируешь, пробуешь разные варианты, то ты найдешь способ выйти из огня и вытащить проект.

В статье как раз речь и идет о тех, кто задумался о переходе в ПМ-ы. По началу подгорать будет постоянно. До того самого момента, пока не начнешь разбираться в правилах, в людях, в ожиданиях.
Из моего опыта сказать, что это процесс не быстрый. Пара-тройка лет «в огне», несколько зафакапленных проектов....
А потом да, начинаешь видеть и понимать горит проект или нет, стоит в него влазить или нет, что за команда на проекте, attrition, velocity и вот это все.

На пути в менеджеры такому человеку стоит помнить, что при переходе из «крутого Senior» в «джуніор PM» он перестанет быть крутым, потом перестанет быть и Senior.
Не раз видела менеджеров, которые через полгода или год бросали работу и уходили в разработчики или в архитекторы.
Стоит также рассмотреть другие менеджерские роли: Tech Lead, Team Lead, Scrum Master, Product Manager...

Лучше не скажешь.
Прочувствовал на себе лично и ушел обратно из PM в разработку.

Это не редкость в моей практике.
Радуюсь тому, что вы идете по своему Пути.

Статья Агонь!
Очень раскрыли тему. Спасибо!

Хорошая, развёрнутая статья.
Наверное ещё стоило затронуть альтернативные направления развития типа Engineering Manager, где технический бекграунд более востребован.

Это я включила во вторую часть: за что я люблю свою работу.
И там рассматриваю 2 ветки: Delivery (Engineering) Manager и Project Manager

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