Полгода назад я стал техлидом, ранее был старшим разработчиком.
В моей команде около 20 человек (включая QA, UX и разработчиков).
После того, как я стал техлидом, моя работа стала больше похожа на управление, чем на что-либо другое, я больше не занимаюсь кодом и занимаюсь только техническими вещами (что забавно, если учесть название должности).
Все, что я делаю, это разбираюсь в реквизитах и помогаю разработчикам понять и то, и другое, следую за «процессом» (это действительно масштабно и требует много сил и времени), рисую диаграммы и участвую в куче совещаний.
Иногда я помогаю младшим разработчикам понять некоторые концепции, но это единственный «код», к которому я прикасаюсь, помимо помощи со спецификациями API и тому подобными вещами. Большая часть работы — это просто вещи, которые я действительно ненавижу, потому что мне кажется, что я не узнаю ничего, что считаю полезным.
Мне нужно программировать в свободное время и изучать другие вещи, поэтому я могу чувствовать себя немного обновленным, и это заставляет меня чувствовать себя очень грустно. Я боюсь, что через какое-то время я стану никчемным, я буду теми парнями, которые просто лидируют и ничего не знают о коде, новых технологиях и так далее.
Но когда я исследую «карьерный путь разработчика», я всегда нахожу роль «Технического руководителя» в шагах, чтобы заработать больше денег, а потом я думаю, что я не могу вернуться к тому, чтобы стать разработчиком, так как это заставит меня регрессировать. .
Есть ли выход из этой «судьбы»? Как оставаться в курсе событий и не устаревать на рынке?
Редактировать: Спасибо, все ответы мне очень помогли. Я постараюсь использовать 50% своего времени для написания кода в качестве технического лидера и дать понять своим менеджерам, что я хочу быть полезным больше как индивидуальный участник, чем ведущий. Однако я могу использовать остальные 50% своего времени, чтобы преподавать и делать некоторые документы, без проблем. Если это не сработает, я буду искать место, где я смогу заниматься тем, что мне нравится больше всего: программировать.
Да, действительно, вы обнаружили, почему разработка программного обеспечения в целом не является очень конкурентной средой: большинство разработчиков любят свою профессию (не свою конкретную работу , а то, что им платят за разработку программного обеспечения) и не хотят, чтобы их повысили до руководящей должности.
Что касается «карьеры», вы должны «продвинуться» в менеджмент. Либо управление проектами, либо управление людьми, либо управление технологиями, но управление. Потому что, за исключением владельца всего этого, «карьера» заканчивается тем, что он становится CPO, CEO или CTO.
Теперь я беру слово «карьера» в кавычки, потому что это то, что, по мнению других людей, у вас должно быть. Я никогда не видел, чтобы разработчик поставил перед собой цель уйти из разработки программного обеспечения в качестве карьерной цели. Конечно, некоторые могут обнаружить, что через некоторое время им больше нравится что-то другое, но в отличие от других работ, где вы знаете, когда начинаете работу, что не хотите делать эту дерьмовую работу вечно, и это просто необходимая ступенька на лестнице, разработка программного обеспечения - это то, чего на самом деле хочет большинство в нашей работе . Не необходимое временное зло на пути к отличной работе, а великая работа сама по себе. Так что конкуренция за следующую ступеньку карьерной лестницы невероятно низкая по сравнению с другими профессиями.
Я был менеджером отдела, техническим руководителем, архитектором, менеджером проекта, владельцем продукта и скрам-мастером. Откровенно говоря, потому что я не могу держать рот на замке при разработке программного обеспечения, и я хочу облегчить работу нам, разработчикам, и если у вас есть хорошие идеи и планы, как это сделать в компании, и вы можете их продать, вы окажетесь в одном из этих роли. Но каждый раз, когда я ищу новую работу, я выбираю разработчика программного обеспечения. Это то, что я люблю . И я не думаю, что вы можете составить хороший план улучшений, если вы сами не испытали реальный процесс (при условии, что вы работаете там только потому, что это хорошая работа для начала, каждый может улучшить дерьмо).
Я могу делать все эти вещи, и я более чем счастлив использовать эти навыки для моего работодателя на временной основе. Например, я более чем счастлив подменять других в отпуске, в декретном отпуске или на любой другой временной должности. Я думаю, что это отличный аргумент в пользу того, чтобы нанять меня. Но в качестве долгосрочной работы, которую я намерен сохранить в течение многих лет... Я хочу разрабатывать программное обеспечение на уровне, требующем отладчика, а не инструмента планирования.
Так что да, вы нашли истину в разработке программного обеспечения или вообще в профессиональной жизни: ведущие роли не имеют ничего общего с реальной ролью. Вы не откроете IDE или отладчик, так как все, что содержит в названии лида или менеджера, точно так же, как лид или менеджер каналоочистителей никогда больше не увидит канализацию изнутри. Для последних это большой шаг вперед, для нас, разработчиков, это большой шаг назад.
Только вы можете решить, могут ли немного больше денег и престижа купить вам столько счастья, что вы сможете с улыбкой оставить развитие позади. Некоторые могут. Многие считают, что оно того не стоит. И не бойтесь сделать шаг «назад». Здесь нет официального направления. Только люди, которые ненавидят свою работу, видят «направление» на лестнице. Важная часть заключается в том, зарабатываете ли вы достаточно денег, чтобы содержать себя и потенциальную семью. В любой западной стране ответом на этот вопрос должно быть «да, быть разработчиком легко оплачивать счета». И в качестве второго приоритета вы должны быть довольны тем, что вы делаете. Вам нужно будет заработать кучу денег, чтобы компенсировать то, что вы были несчастливы 8-10 часов в любой рабочий день. Это огромная часть вашей жизни.
Кто-то еще, не помню кто, сравнивал так: если бы у тебя были дети, какого отца они, наверное, заслужили бы? Отец, который приходит домой довольный, играет с ними, а когда им исполняется 16 лет, покупает им новый велосипед на день рождения, или отец, который каждый день приходит домой злым, как правило, сердит, потому что им не нравится идея вернуться работать завтра, но может купить им машину, когда они достаточно стары?
Это твое решение.
Quite frankly because I cannot keep my mouth shut while developing software and I want to make the job easier for us developers and if you have good ideas and plans how to do that in the company and can sell them, you end up in one of those roles.
Ух ты. Я только что увидел, как мой собственный карьерный путь описан в одном предложении.Есть ли выход из этой «судьбы»? Как оставаться в курсе событий и не устаревать на рынке?
Роль техлида варьируется от компании к компании (а иногда и от команды к команде внутри компании). Я работал в некоторых компаниях, где техлид был в основном менеджером. И я работал в некоторых компаниях, где техлид был просто суперразработчиком.
Вам просто нужно найти работу, где роль технического руководителя больше связана с технологиями, а не с лидерством. Такие вакансии существуют, но, возможно, не в вашей компании.
Во время собеседования убедитесь, что вы задали достаточно вопросов, чтобы узнать ожидания от работы. Вы можете попросить поговорить с некоторыми будущими коллегами по техническим вопросам, если они есть у компании. Посмотрите, на что похож «день из жизни» для них.
Вы должны понимать, что в целом ваша ценность для организации увеличивается, когда вы можете учить и руководить большим количеством людей. Вы можете сделать так много кода, в отличие от того, чтобы научить 20 человек, как правильно кодировать. Таким образом, даже на «техническом треке» многие промо-акции и тому подобное требуют различного рода наставничества и технического лидерства.
Ты можешь:
В конце концов вы либо достигнете вершины и просто скажете: «Я хочу программировать и зарабатывать 150-200 тысяч в год до конца своей жизни», что является прекрасной жизнью, либо созреете и станете лидером.
Компании значительно различаются по тому, как далеко вы можете зайти в качестве индивидуального участника. Кое-где очень много чисто технических ролей выше уровня «старший разработчик». Они включают в себя различные разновидности «главного инженера» или «архитектора» и т. д.
Что бы ни случилось, по мере того, как вы будете продвигаться вперед, ваша работа будет меньше касаться непосредственно написания кода. С чисто технической точки зрения работа больше сосредоточена на разработке программного обеспечения и систем, улучшении процессов, принятии технологических решений и т. д. Вам нужно использовать свой опыт, делегируя полномочия и оказывая влияние, вместо того, чтобы делать все самому. Возможность улучшить что-то большее, чем ваша личная работа, делает вас более достойным.
Тем не менее, если вы очень хорошо пишете код, то все равно может быть продуктивно потратить на это много времени. Ни разу в своей карьере (а я довольно стар) я не тратил меньше 30% своего времени на программирование.
Если вы действительно не хотите идти по пути управления, то, возможно, вам следует начать искать работу в компании, которая предлагает более высокий уровень для отдельных сотрудников. Возможно, у вас получится лучше, если вы сделаете это сейчас, когда никуда не торопитесь.
Эти 2 цитаты могут помочь вам.
Стив Возняк (Apple):
По сей день я останусь в нижней части организационной структуры как инженер, потому что именно там я хочу быть.
Марк Твен (автор):
Найдите работу, которая вам нравится, и вам не придется работать ни дня в своей жизни.
Если вам нравилось развитие, и если вы пробовали и не наслаждались другой карьерой, то нет ничего постыдного в выборе карьеры, которая вам больше нравится: разработка!
РЕДАКТИРОВАТЬ : нашел видео Воза
Технический руководитель может быть отличной работой. Вам просто нужно сделать это таким образом.
Больше кодом не занимаюсь и только немного технических вещей (что забавно, если учесть название должности).
Вы тот, кто владеет техническими результатами. Если вы должны владеть им, вы можете управлять им так, как хотите. Ключевой частью этого является решение, какие действия стоят времени технического руководителя, а какие можно делегировать. Вы должны делать только то, что (1) важно и (2) не может быть сделано кем-то другим. Обычно это также самые веселые вещи.
Все, что я делаю, это разбираюсь в реквизитах и помогаю разработчикам понять и то, и другое, следую за «процессом» (это действительно масштабно и требует много сил и времени), рисую диаграммы и участвую в куче совещаний.
Вы слишком важны для организации, чтобы заниматься рутинной работой. Делегат. Если вашей команде нужен кто-то, кто объяснит требования, посмотрите, сможете ли вы нанять в команду бизнес-аналитика, даже 0,5 FTE могут иметь большое значение, а иногда они могут приходиться на бизнес-сторону организации, то есть это не ударит по вашим бюджет команды. Для шаблонных документов, таких как формы запросов на изменение, назначьте их инженерам по контролю качества, которые сделают тщательную работу и, как правило, хорошо подходят для повторяющихся задач. Один из ваших самых умных QA может даже найти способ их автоматизировать.
Иногда я помогаю младшим разработчикам понять некоторые концепции, но это единственный «код», к которому я прикасаюсь, помимо помощи со спецификациями API и тому подобными вещами.
Ваш опыт кодера очень ценен. Лучший программист компании иногда в десять раз производительнее самого младшего. Вы можете выделить время для самых важных (т.е. самых интересных) задач по программированию. Если у вас нет времени, объявите по средам «день потока», во время которого не будет встреч и у всех будет время сосредоточиться на программировании, включая вас. Это на благо команды.
Большая часть работы — это просто вещи, которые я действительно ненавижу, потому что мне кажется, что я не узнаю ничего, что считаю полезным.
Мне нужно программировать в свободное время и изучать другие вещи, поэтому я могу чувствовать себя немного обновленным, и это заставляет меня чувствовать себя очень грустно. Я боюсь, что через какое-то время я стану никчемным, я буду теми парнями, которые просто лидируют и ничего не знают о коде, новых технологиях и так далее.
Есть ли выход из этой «судьбы»? Как оставаться в курсе событий и не устаревать на рынке?
Ответ на это прост. У вас есть команда. Если есть новая технология, которая может представлять ценность для команды, назначьте разработчика для ее изучения и проведения презентации. Если это действительно интересно, вы можете попросить его провести пару технических занятий. Некоторые организации делают такие вещи как «коричневую сумку» за обедом.
Я хочу сказать, что технический руководитель - это сердце команды. И главная часть этого — ваша собственная производительность и ваше собственное счастье. Со своей позиции вы можете в значительной степени контролировать его.
Как технарь, вы, естественно, сосредоточены на создании хорошего кода. Но...
Как старший инженер, вы на самом деле сосредоточены на создании хорошего проекта . Код может быть любым подходящим языком, который вам нравится для реализации этого дизайна, и если вы переедете в новое место, вы сможете переделать этот дизайн с их предпочтительным языком. C++, C#, Java, что угодно, концепции остаются прежними. В значительной степени определение старшего инженера заключается в том, чтобы признать это разделение и не зацикливаться на каком-либо конкретном языке. С таким опытом я ожидаю, что старший инженер в любом случае поднимет любой язык до функционального уровня менее чем за две недели. Важны концепции, а не реализация.
И тогда вы делаете шаг вверх, чтобы стать техническим руководителем. На данный момент вы не создаете хороший дизайн для вашего отдельного компонента. Вместо этого вы создаете хороший архитектурный проект, в рамках которого ваши инженеры могут разрабатывать собственные проекты компонентов. Вы устанавливаете стандарты кодирования и стандарты дизайна, чтобы помочь им достичь этого. Вы следите за тем, чтобы у них были хорошие требования и все такое хорошее.
Теперь ваш инженерный инструмент — это не дизайн, а команда . Теперь ваша задача состоит в том, чтобы спроектировать командную среду для достижения результатов, которые работают эффективно и надежно, точно так же, как ваша работа по проектированию заключалась в создании кода, который работал бы эффективно и надежно. Вы по-прежнему ищете ошибки, за исключением того, что теперь ошибки — это вещи, которые мешают работе команды , а не просто останавливают работу кода.
Это сочетание системной инженерии и технологической инженерии. Оба являются хорошо признанными областями знаний, и вы можете научиться делать это хорошо.
Сколько часов у вас в сутках? Даже если ваш худший член команды всего на четверть медленнее вас, команда из 8 человек все равно удвоит вашу производительность. Если вы можете использовать свое время, чтобы получить их вдвое медленнее, чем вы, они получат в 4 раза больше вашего результата за то, что они вложили в 1 раз больше вашего времени. Это победа. Вот для чего вы здесь.
Если вы не заинтересованы в наставничестве других людей и не хотите переходить на следующий уровень знаний, это нормально. В настоящее время вы находитесь на том уровне, на котором вы можете работать, и вы останетесь на этом уровне и не выше до конца своей трудовой жизни. Это неплохо — я знаю нескольких инженеров, которые сделали этот звонок, потому что дополнительная ответственность повлияла бы на их семейное время. Но тогда вам нужно смириться с тем фактом, что дальше этого вы никуда не пойдете, потому что дальше этого пути технической карьеры нет.
Или, если быть более точным, существует очень мало технических карьерных путей для глубокой специализации в каком-либо аспекте инженерии. Вы не можете достичь этого только с помощью кодирования, потому что только в этом нет глубокой специализации. И даже в этом случае эта специализация будет заключаться в том, что большую часть вашего времени вы будете тратить на наставничество других людей, а не на то, чтобы делать это самостоятельно.
Если вы не перегружены простым управлением проектом и командой, я действительно не понимаю, что мешает вам писать код. Я могу придумать 2 способа, которыми вы также можете кодировать, управляя своей командой:
(Второй вариант был бы лучше, так как вы узнаете, как думают ваши разработчики, младший разработчик также может учиться у вас, и вы получите хорошее представление о способностях разработчиков, что очень поможет вам делегировать задачи нужному человеку, таким образом делая облегчить себе работу).
Другие ответы хороши, я просто хочу обратиться к этому конкретному вопросу:
Я боюсь, что через какое-то время я стану никчемным, я буду теми парнями, которые просто лидируют и ничего не знают о коде, новых технологиях и так далее.
Рассмотрим идею о том, что дефицит увеличивает ценность чего-либо. При разработке программного обеспечения большинство инженеров хотят не отвлекаться и писать код, не взаимодействуя с людьми. Если вы один из немногих инженеров, которые могут заниматься собеседованиями, ростом сотрудников, обзорами производительности и т. д., вы противоположны бесполезности , вы более ценны.
Также рассмотрите разницу между техническими навыками и человеческими навыками:
Если вы не готовы к этому и предпочитаете не поднимать голову, назначьте цену. т.е. сколько кто-то должен был бы заплатить вам, чтобы не программировать и иметь дело с людьми? Для меня это была большая сумма в долларах, но это была подходящая сумма для моего босса, и теперь мне платят (больше) за то, что я наставляю людей. Со временем это становится легче, как и любой другой навык.
Первые дни будут точно такими, как вы сказали. Посмотрите, имеет ли смысл приведенный ниже план для вас.
За пределами кодирования существует целый мир. Когда вы читаете документацию по программному обеспечению, вы обнаружите так много новых функций, которые в противном случае вы могли бы не обнаружить, если бы просто кодировали.
Как человек, который столкнулся с этой проблемой и победил ее в параллельной сфере работы, это мой наспех составленный список лучших советов… надеюсь, он поможет!!
Я рано перешел из крупной компании в маленькую (SME).
Большой компании нужен менеджер, который просто управляет. Небольшой компании в хорошей нише нужен менеджер, который также является универсальным и практическим членом команды. В конечном итоге вы станете техническим директором с командой из 5-10 человек, а не с командой из 20-200 человек. И выигрыш ОГРОМНЫЙ, если это хорошая профессиональная компания, и вы ладите со своим менеджером (важно, сосредоточьтесь на этом при принятии решения).
Это очень хорошо оплачивается, потому что вы фактически являетесь либо техническим директором, либо руководителем этой команды, непосредственно подчиненной техническому директору. Вы можете многое сказать о продукте и подходе, приоритетах, инновациях, выборе того, что внедрять, а также о том, как их пилотировать и внедрять. Таким образом, вы можете убедиться, что все сделано правильно. Но на самом деле это не основная часть работы, которую вы делаете. Вам все еще нужно кодировать; в небольшой команде он не будет писать или отлаживать себя. Но также, как второй в технической команде, ваш технический директор занимается большей частью административной стороны команды, ваша роль гораздо больше заключается в том, чтобы код работал, а не только в том, чтобы следить за тем, чтобы другие кодировали, пока вы руководите.
Небольшие, но процветающие компании могут начать работать или еще недостаточно большие, чтобы нуждаться в преданных старших технических менеджерах, или предпринимательский стартап, ищущий кого-то компетентного, чтобы заставить его продукт работать, и готовый начать с команды из 3 сейчас и команды из 15 человек. в 4 года.
Я тоже после этого переключился на нишевую сферу и работал подрядчиком
Управление — не единственный способ получить высокую зарплату. Ниша — еще один способ. Примеры в области технологий могут включать, например, ИТ-безопасность. Кобол. Пользовательские расширения SAP. Базы данных. Высокая доступность. Специализируясь на критически важной области продукта, такой как медицинское программное обеспечение или программное обеспечение для авиакомпаний. Поиск неисправностей. Спасение проектов, нуждающихся в интенсивной работе по кодированию «без экономии средств» для какого-то критического срока или потребности рынка. Обновление старого кода до современного кода. Вероятно, есть много ниш, в которых вам хорошо платят, если вы работаете перед компьютером. Найдите специализированную нишу, которая сосредоточена на жизни кодирования, которую вы хотите.
Такие роли можно выполнять в качестве сотрудника. Но также подумайте о том, чтобы заключить контракт или даже начать собственное дело. Если вы запускаете свои собственные задачи и часы, вы можете заниматься любимым делом, и единственный вопрос заключается в том, чтобы найти места, требующие высокого уровня навыков в том, что вы хотите делать в любом случае, которые готовы платить за это. Для чего см. выше.
В случае успеха вы можете нанять кого-то еще или отдать на аутсорсинг то, что вам не нужно, или вступить в партнерство с какой-либо другой небольшой компанией, что позволит вам расти и по-прежнему сосредоточиться на кодировании, которое вы любите.
На вашем месте у меня был бы откровенный разговор с моим менеджером:
Я хотел перейти на следующий уровень, потому что хотел более высокую зарплату. Но характер работы изменился, и мне это действительно не нравится. Я хотел бы проводить больше времени за программированием, и я чувствую, что мой уровень производительности оправдывает более высокую зарплату, даже если я не «множитель силы». Можете ли вы помочь мне найти способ вернуться к моей лучшей работе, не чувствуя при этом понижения в должности?
Хороший менеджер найдет способ использовать ваши сильные стороны и интересы. Некоторые возможные результаты:
Этот разговор может стать облегчением для вашего менеджера. Возможно, они уже знали, что новая роль вам не понравится, но вы заслужили эту возможность, не их дело говорить вам, что вам нравится, а что не нравится, и они не хотят вас терять.
Если разговор идет не очень хорошо, вероятно, пришло время искать другую работу.
Одна из вещей, которая должна быть работой технического руководителя, — управлять направлением стека технологий. Это может отличаться от корпоративной архитектуры, потому что EA больше касается общей картины, но это не менее важно.
Возьмите недавнее волнение по поводу log4j. Использует ли его ваша организация? И кто принял такое решение? Используют ли его все ваши службы/серверы, или только некоторые, или ни одного? Если нет, то что еще они используют?
Такое решение можно оставить (старшим) инженерам. Но если их больше одного, кто ведет?
Считаете ли вы, что вам нужно продолжать практиковать свои навыки программирования, чтобы хорошо выполнять свою работу в качестве технического руководителя? Если да, то нет ничего постыдного в том, чтобы выделить часть своего времени на разработку. Относитесь к этому как к чему-то священному, как к чему-либо другому, что, по вашему мнению, вы «должны» делать.
Если это оставляет слишком мало времени для всех других задач, которые люди ожидают от вас, проблема не в вашем распределении времени, а в их ожиданиях. Работайте над тем, чтобы это исправить.
Ваша работа заключается в том, чтобы распределять свое время таким образом, который, по вашему мнению, оптимален для вашей долгосрочной работы. Это не меняется, когда вы становитесь техническим руководителем — во всяком случае, это становится еще более важным. Не позволяйте другим людям и процессам распределять ваше время за вас. Они, как правило, делают ужасную работу.
Если вы хотите занимать руководящую должность в технической сфере и в то же время хотите быть практичным, вы можете рассмотреть роль архитектора программного обеспечения . Определение и интерпретация этой роли различаются в разных компаниях, но в целом считается очень позитивным, если Архитектор все еще может кодировать.
Ключевое отличие роли Архитектора от роли Техника. Менеджер заключается в том, что Архитектор не является менеджером по персоналу. Тем не менее, если вы действительно старший, от вас будут ожидать, что вы будете вести себя как взрослый, и вам, возможно, придется направлять, тренировать и наставлять младших. Кроме того, вам нужно хорошо разбираться в политике компании и стейкхолдерах, но это цена, которую вы платите за более высокую зарплату, связанную с этим званием.
Но вы можете кодировать, создавая прототипы новых вариантов использования или даже внедряя новые функции. Но имейте в виду, что вам лучше делать это хорошо, иначе разработчики это ненавидят.
Таннер Светт
компьютерный автомобиль
Мирослав
Дэн
фраксинус