Как я могу сообщить о своем желании оставаться там, где я сейчас нахожусь в своей карьере, а не двигаться «вверх»?

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

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

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

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

Есть большая разница между «Я никогда не хочу повышения по службе» и «Я никогда не хочу заниматься менеджментом».
«Дядя Боб» Мартин сказал: «Мой девиз на данный момент:« Я хочу, чтобы они нашли меня с моим носом между ключами »... Я некоторое время занимался менеджментом и стал архитектором для какое-то время... что я действительно хотел сделать, так это написать много кода». Полное интервью: se-radio.net/2009/11/…
Кстати, если вы думаете, что управление проектами — это секретарская работа, то вы понятия не имеете, чем занимается руководитель проекта. Тот факт, что вы хотите только программировать, не означает, что другие профессии не такие сложные и трудные или даже более сложные, чем выбранная вами профессия. Хорошее управление проектами — гораздо более сложная работа, чем кодирование. Плохое управление проектом может быть расценено как секретарская работа, но так же может быть и плохое кодирование (программисты вырезания и вставки просто печатают чужую работу без необходимости ее понимать).
Кстати, The Codist написал статью под названием « Мое самое большое сожаление как программиста » , которая, похоже, связана с этой темой.
Я не понимаю, как быть премьер-министром можно рассматривать как шаг вперед. Это даже не продолжение разработки программного обеспечения. Это больше похоже на пастьбу кошек.
Вы тот человек, которого обсуждали на work.stackexchange.com/questions/87085/… хе-хе- хе? (Я шучу, чтобы было понятно). Этот вопрос действительно звучит как противоположная сторона, хотя +1
@HLGEM Я думаю, что ваш оборонительный подход не нужен. Он никогда не говорил, что PM проще, чем программирование. И действительно, есть аналогия с секретарской работой, если подумать. Это не означает, что работа менеджера по программному обеспечению так же проста, как секретарская работа. Ну, а кто сказал, что секретарская работа — это легко? Я никогда не пробовал.
@MatthewWhited — «Это больше похоже на пасти кошек». Это сделало мой день.
youtube.com/watch?v=WTdqqJI02HE <= это может помочь сделать его еще лучше
@HLGEM, никто не говорил, что быть руководителем проекта легко. Но это другой тип работы, и нормально не хотеть ее делать. Я не хочу быть стоматологом, но это тяжелая работа.

Ответы (17)

Однозначно ответить на этот вопрос очень сложно. У каждой компании своя реакция на это, по моему опыту.

Я работал в компании, где для разработчика не было другого пути. Если вы не перешли в управление, то вы никогда не получите прибавку к зарплате выше уровня инфляции.

Я работал в нескольких компаниях, где ожидалось, что разработчики захотят остаться разработчиками. И их хорошо вознаграждали за то, что они были хорошими разработчиками, и смотрели на них странно, если они проявляли стремление стать кем-то еще.

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

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

+1 за честность. Вы должны чувствовать, что можете обратиться к своему менеджеру в любое время в любом случае. Они существуют не только для того, чтобы управлять бизнесом; менеджеры тоже управляют людьми. Между прочим, я разработчик, который стал «менеджером по продукту» (в небольшой компании, в которой я работаю, это похоже на сочетание ведущего разработчика и линейного менеджера). Уверяю вас, нам не даны магические способности знать, что думают люди. Хотя я думаю, что хороший менеджер уже знает об этом, приятно, когда ему говорят.

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

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

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

Второй и более важный аспект заключается в том, что управление позволяет вам создавать программное обеспечение, которое вы не можете себе представить самостоятельно. Я думаю, что это та часть, которую мы упускаем в картине пути управления. Это фактически увеличивает нашу способность создавать программное обеспечение на несколько порядков. Я знаю, как заманчиво работать над кодом самостоятельно, но когда вы видите, что при правильном направлении и руководстве вы можете достичь десятикратной, стократной производительности, это так захватывающе. Подумайте о параллельной вселенной, где Линус Торвальдс настоял на том, чтобы самому кодировать весь Linux. Как далеко он ушел бы? Конечно, никто из ваших разработчиков не будет кодировать так, как вы, но некоторые будут кодировать даже лучше, чем вы, и вы научитесь справляться со случайным отсутствием качества или недопониманием. Вы будете растить каждого из них, чтобы стать лучше,

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

Просто мои два цента.

Это действительно хороший момент. В качестве контрапункта я знаю соучредителей предприятий, которые продали свою долю в компании, потому что не хотели управлять. Сид Мейер из Microprose сделал это. Мне было бы любопытно, сделал ли Спилберг что-то подобное. Со стороны кажется, что он скорее будет снимать новый фильм, чем управлять Dreamworks SKG (его компания).

Ваше мнение может быть понятно другим разработчикам, но не менеджерам. Вместо того, чтобы говорить, чего вы не хотите делать (и звучать негативно), я предлагаю вам подчеркнуть, что вы ДЕЙСТВИТЕЛЬНО хотите делать.

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

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

+1: многие менеджеры, поднявшиеся по служебной лестнице, были только рады перестать программировать и начать управлять. Но в большинстве иерархий, в которых я работал, по необходимости менеджер проекта находится на ступеньку выше руководителя группы разработки, который находится выше градиента от старших до младших разработчиков. Отразится ли это превосходство на шкале заработной платы, зависит от компании, но пока вы хотите программировать, говоря иерархически, вы будете оставаться относительно низко на тотемном столбе.
@KeithS не всегда верно. Я видел Senior Dev->Architect->Senior Architect. Старший архитектор был иерархически выше продакт-менеджеров и большинства менеджеров среднего звена.
В некоторых компаниях даже есть технический директор, но даже эта должность может включать в себя больше людей, чем хотелось бы ОП.
На самом деле в большинстве компаний есть технический директор, и да, все дело в управлении людьми. Что касается «Архитектора», эта должность обычно меньше кодирует и больше HW/SW A&D. Архитекторы — это «менеджеры нескольких проектов», работающие над тем, чтобы связать проекты вместе, чтобы наилучшим образом использовать существующие кодовые базы, оборудование хостинга и т. д.

Просто сформулируйте свои амбиции, как вы сделали здесь.

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

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

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

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

  • Получите опыт работы с широким спектром технологий
  • Выявляйте отраслевые тенденции (и распознавайте причуды, чтобы их игнорировать!)
  • Учитесь на технических ошибках и не позволяйте вашей команде совершать их снова
  • Разрабатывайте элегантные решения, которые также эффективно работают

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

Никогда не говори никогда. Кто знает, где вы будете через десять лет? Вещи меняются.

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

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

Лично я бы никогда не стал делать это заявление, потому что А) Это, вероятно, звучит плохо для начальства, как будто у вас нет амбиций/преданности своей работе/карьере Б) Мне сказали никогда не говорить, что вы не подумаете стать менеджером когда-нибудь на интервью, и это заставит вас лгать о возможном будущем и C) вы никогда не знаете, будете ли вы чувствовать себя иначе в будущем. Откуда вы знаете, что НИКОГДА в жизни не захотите стать менеджером? Я думаю, что было бы лучше просто отказаться от рекламных акций, когда они предлагаются.

+1 Я, 18-летний, был бы счастлив программировать на ассемблере и COBOL навсегда (потому что, когда тебе 18, то есть до 21), но сегодня я бы нашел физические пытки менее болезненными.
Зависит от того, что вы кодируете. Работа, подобная моей нынешней, которая дает вам доступ к различным технологиям, где вы делаете одно, а следующее, что вам дается, сильно отличается, является сложной и интересной и чем-то, чем я буду наслаждаться на протяжении десятилетий, пока она остается. так. С другой стороны, я работал на работах, которые на 99,99% состояли в обслуживании одной и той же части программного обеспечения. Хрупкая кодовая база в сочетании с вновь обретенным анально-сохраняющим вниманием к деталям со стороны руководства (потому что они упустили это в предыдущие годы) сделали эту работу по кодированию чрезвычайно болезненной.

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

Вместо этого укажите желаемую рекламную акцию, если я вас правильно понял, которая включает в себя:

  • Развитие и увеличение технических проблем
  • Ответственность и знание больших частей разрабатываемого вами технического решения
  • Возможность изучать и осваивать новые технологии по мере того, как в них возникает потребность бизнеса.
  • В конце концов – ответственность за продумывание будущих технических решений и помощь компании, став техническим экспертом раньше бизнес-драйверов.

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

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

Лучшее, что вы можете сделать, это подождать, пока вам не предложат повышение, оценить это предложение и, если вы не хотите, отказаться от предложения.

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

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

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

Подумайте о таких людях, как Бьерн Страуструп, Джеймс Гослинг, Деннис Ритчи, Ларри Уолл, Сергей Брин и Андерс Хейлсберг среди прочих. Я не думаю, что они занимались чем-то другим, кроме кодирования, хотя на своем пути они могли бы занять более прибыльные позиции.

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

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

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

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

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

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

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

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

Затем вы должны рассмотреть возможности или должности в вашем бизнесе, которые позволят вам наиболее эффективно использовать эти навыки. Обратите внимание, что это может означать, что вам придется больше работать над дизайном/архитектурой, чем вам хотелось бы, и в зависимости от структуры вашей компании это может быть ограничением.

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

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

Вы можете окончательно перефразировать свою карьерную цель. Например, написание кода на самом деле будет лишь небольшой частью работы, даже для отдельной роли. Отдельные участники, которые постоянно изучают новые вещи, тратят большую часть времени на использование нескольких языков и технологий и, следовательно, в целом полезны для многих людей в моей команде. Я считаю, что продуктивность команды повышается, когда есть люди, которые помогают другим, обладая превосходными знаниями. Такие книги, как Pragmatic Programmer и Clean Code, подчеркивают необходимость разработчиков, «увлеченных» разработкой.

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

Итак, мой вариант — создать новое сообщение, отрепетировать его, а затем сообщить об этом вашему руководству.

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

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

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

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

Не желая вдаваться в длительные дебаты (которых в сети много!), если как технический специалист вы заинтересованы/участвуете в подходах к разработке Agile/Scrum, тогда понятие «управление проектом» или «руководитель группы» не имеет смысла. не всегда укладываются во все интерпретации этих приемов.

Двое из моей команды разработчиков, проходивших курс сертификации Scrum-Master, недавно прокомментировали, что по крайней мере половина участников были «классическими» водопадными «менеджерами проектов», пытающимися выяснить, какова их роль в Scrum...

Во многих организациях роль PM больше не существует.

У меня есть такие же члены команды, как и вы — они предпочитают работать на меня, потому что отчасти я не ожидаю от них какого-либо формального управления или лидерства (кроме плоской структуры Scrum), и у меня также есть бесконечная (!) Решение чрезвычайно сложных технических проблем, движимое жаждущей НИОКР и богатой наличными деньгами отраслью. Компромисс заключается в том, что они должны работать в Scrum-команде, а не быть «героем-одиночкой».

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

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

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

Только одно в этом мире постоянно и это "ИЗМЕНЕНИЕ"!

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

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

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