Карьерный путь разработчика
Наверняка вы стали (или хотите стать) разработчиком, потому что вы любите кодить. Любите "заворачивать" абстрактные идеи в код. Создавать что-то важное из ничего. Изучать новые технологии, языки программирования, фреймворки и т.д. Разбираться, как все утроено. Поэтому пока вы работаете на позиции junior-девелопера, постепенно развиваетесь до крепкого "среднячка" и достигаете статуса senior, вы получаете удовольствие от того, что делаете. И вот в один прекрасный день вы достигаете пиковой формы в своем деле, или вдруг проявляете себя хорошим организатором, или просто в вашей команде нет никого подходящего на роль менеджера, что эту должность предлагают вам. В таких случах принято говорить: "Перейти на руководящую должность — в порядке вещей". Но я хотел бы возразить: думаю, никто не должен делать то, что он делать не хочет.Почему такой переход — не в порядке вещей
Во-первых, если вы просите специалиста, которому нравится писать код, стать кем-то, кто этим не занимается совсем, где логика? Он почувствует, что у него отняли любимое занятие, и рано или поздно сгорит и возненавидит свою работу. Конечно, он может отмахнуться от новых обязанностей и продолжить кодить, но тогда в команде “провиснут” менеджерские функции. А это плохо для бизнеса. Зачем кому-то нужен руководитель, который не хочет управлять людьми? Во-вторых, если человек хорошо пишет код, это не значит, что он будет хорошим менеджером. Разработка и управление — разные сферы деятельности, в которых важны разные навыки и образ мышления. Это как футболисты и тренеры. Если ты хороший футболист, это не значит, что ты сможешь хорошо вести дела футбольной команды (хотя конечно же, такое встречается). Менеджеру нужно тесно взаимодействовать с людьми и настраивать рабочий процесс так, чтобы она приносил плоды. Нужно давать людям возможность выпонять свою работу так, чтобы она была результативной, но не делать эту работу вместо них. А разработчик — это линейный сотрудник. Быть менеджером = добиваться результатов, правильно организуя работу других людей, а не делая ее самостоятельно. В-третьих, есть положение, известное как "принцип Питера". Его суть в том, что специалисты получают повышение, основанное на их предыдущем рабочем опыте, пока не дорастают до позиции, для которой им не хватает компетенции. Таким образом, если хорошего разработчика повышают до управленца, а он к этому не готов, он не сможет выполнять новую работу как следует. Переход хорошего разработчика в плохого менеджера будет только во вред компании. Повышать нужно в рамках текущей деятельности. И если разработчик добровольно не тянет на себя менеджерские компетенции, не стоит его толкать в этом направлении. В-четвертых, некоторые специалисты соглашаются на менеджерскую должность ради повышения зарплаты. Да, часто менеджеры получают больше своих подчиненных. Но не всегда: встречаются и обратная ситуация. Если в команде работают сильные специалисты, им будет сложнее найти замену, чем менеджеру. Если вклад разработчика в компанию ценнее, чем вклад менеджера, нет причин переплачивать управленцу. Кроме того, заплата — это еще не все. Лучше заниматься тем, что нравится, за меньшие деньги, чем выполнять ненавистную работу за более высокую зарплату. В-пятых, никогда не стоит соглашаться на должность управленца только потому, что в вашей команде больше нет никого подходящего на эту роль. Это не ваша вина. Вам нужно сознательно строить свою карьеру. Иначе пострадает не только ваше настроение и самооценка, но и компания. Так что же делать, если вы любите программировать и не хотите переходить на сторону управления? Выход есть!У вас есть выбор
Должность senior-разработчика может быть проежуточным этапом перед менеджерской позицией. А может и не быть. В общем, может быть карьерный путь управленческий, а может и технический. Вы можете спокойно развиваться в технической сфере, ведь есть такие должности:Senior/главный разработчик — это может быть именно та позиция, на которой вы захотите и далее развиваться. Позволить программистам senior-уровня оставаться линейными сотрудниками — это нормально.
Ведущий разработчик (техлид) — это полуменеджерская роль. Ведущие разработчики управляют проектами / людьми только с технической точки зрения. У них нет прямых подчиненных и они не управляют сотрудниками: они могут влиять на окончательное решение по тем или иным вопросам силой своего авторитета. Впрочем, компетенции и зона влияния этого специалиста могут отличаться в разных компаниях.
Архитектор – если вам нравится проектировать сложные системы и у вас это получается хорошо, можете стать архитектором. Архитектор часто считается высшей точкой карьерного развития в техническом направлении. Должностные обязанности архитектора также могут отличаться, вплоть до того, что не все архитекторы пишут код.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ