Как технический руководитель я больше чувствую себя менеджером, и я ненавижу это

Полгода назад я стал техлидом, ранее был старшим разработчиком.

В моей команде около 20 человек (включая QA, UX и разработчиков).

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

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

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

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

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

Есть ли выход из этой «судьбы»? Как оставаться в курсе событий и не устаревать на рынке?


Редактировать: Спасибо, все ответы мне очень помогли. Я постараюсь использовать 50% своего времени для написания кода в качестве технического лидера и дать понять своим менеджерам, что я хочу быть полезным больше как индивидуальный участник, чем ведущий. Однако я могу использовать остальные 50% своего времени, чтобы преподавать и делать некоторые документы, без проблем. Если это не сработает, я буду искать место, где я смогу заниматься тем, что мне нравится больше всего: программировать.

«а потом я думаю, что не могу снова стать разработчиком, так как это заставит меня регрессировать». – А если регрессировать? Деньги важны, но ваше счастье, вероятно, важнее. Моя последняя работа оплачивалась больше, чем моя текущая, но я также ненавидел ее, поэтому я пошел на сокращение зарплаты, чтобы сменить карьеру. Теперь я намного счастливее.
Возможно актуально: stackoverflow.blog/2021/12/29/…
Насколько велика компания? (Например, 50-500 сотрудников, 1000-3000 сотрудников и т. д.)
Ваша компания в целом рациональна? Если вы предложите изменения, вы получите шлепок? Старая история о том, как лучшего сварщика повысили до менеджера, он потерял сварщика и получил дрянного менеджера. Нужно продвинуть его на новый вид работы, суперсварщик. Можете ли вы предложить это?
Возможно актуально: en.wikipedia.org/wiki/Peter_principle .

Ответы (15)

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

Что касается «карьеры», вы должны «продвинуться» в менеджмент. Либо управление проектами, либо управление людьми, либо управление технологиями, но управление. Потому что, за исключением владельца всего этого, «карьера» заканчивается тем, что он становится CPO, CEO или CTO.

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

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

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

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

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

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

Это твое решение.

Я думаю, что карьерное понимание «постепенно меньше программирования, больше управления» верно только для определенных компаний. В крупной софтверной корпорации, где я работаю, всех спрашивают, хотели бы они продвигаться по карьерной лестнице в техническом направлении (например: разработчик > старший разработчик > руководитель / ...) или в управленческом направлении (разработчик > руководитель группы > менеджер > директор / . ..). Разработчики остаются 80%-разработчиками даже на высоких должностях в своей карьере. Они работают только над более важными проектами, чем другие, или на передовых рубежах.
Мне нравится ваш ответ, но он не отвечает на вопрос. Эти рабочие места существуют, где вы являетесь звездным разработчиком и на самом деле все еще развиваетесь.
@usr1234567: Да, но не менеджер и, может быть, даже не технический руководитель. На последней работе, на которой я работал, «технический руководитель» означало «выполнять все свои обычные обязанности, а также все эти отчеты, которые мы хотим получить от вашей группы». В данном случае это также означало «без повышения заработной платы». Нет, спасибо.
«Вам нужно было бы заработать кучу денег, чтобы компенсировать то, что вы были несчастливы 8-10 часов в любой рабочий день». - Кроме того, постоянное недовольство сделает вас паршивым менеджером и само по себе будет ограничивать вашу карьеру.
Я также согласен с тем, что этот ответ не является стандартным, а скорее «может произойти в определенных местах». Наш технический руководитель ведет нашу технологию ; принимает решения по архитектуре высокого уровня, определяет стандарт кодирования, имеет окончательное право вето на технические решения и т. д. Совершенно другой (и нетехнический) человек — наш менеджер, занимающийся «кадровыми вопросами».
@ R.Schmitz И тем не менее, архитектурные решения высокого уровня, стандарты кодирования, права вето - это все, что вы делаете на встречах, в электронной почте, в Word или вики. Без использования отладчика. Лидерство, чем бы вы ни руководили, — это совершенно другая повседневная работа, чем реальная работа.
«Я никогда не видел, чтобы разработчик поставил перед собой цель уйти из разработки программного обеспечения в качестве карьерной цели». -- контраргумент, я полагаю: лично мне нравится создавать успешные вещи больше всего на свете, есть много причин, по которым это может потерпеть неудачу (ошибки, неправильный дизайн, плохая коммуникация и т. д.); причина, по которой я в последнее время больше склоняюсь к управлению, заключается в том, что я вижу здесь пробел, я мог бы написать лучший код в своей жизни, и не важно, например, это неправильный продукт. Как разработчик я не в силах решить эту проблему, как менеджер могу.
@nvoigt Да, но без отдела кадров это всего лишь 20% их времени. Тогда, действительно, сводится к личной перспективе. На мой взгляд, как неруководителю, вам придется «использовать отладчик» (как при практическом кодировании) так, как вы считаете не лучшим, когда так решит технический руководитель. Как технический руководитель, вы можете «использовать отладчик» именно так, как считаете нужным, потому что вы принимаете эти решения, но это, конечно, требует времени.
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.Ух ты. Я только что увидел, как мой собственный карьерный путь описан в одном предложении.

Есть ли выход из этой «судьбы»? Как оставаться в курсе событий и не устаревать на рынке?

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

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

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

Этот. Технические руководители у моего нынешнего работодателя тратят гораздо меньше времени на кодирование в неделю, но не совсем не тратят времени на кодирование в неделю. И у меня нет оснований думать, что мы находимся в дальнем конце пространства для компромиссов.
Я бы назвал техлида с меньшим количеством кода архитектором. Архитектор проектирует и использует свои прошлые знания, но не обязательно участвует в кодировании. Оставаться в курсе современных разработок непросто. Вы не хотите быть архитектором, это может помочь вам при собеседовании на новые должности.
@ usr1234567 Я согласен. Я работаю в области электроники, и я не ожидал, что технический руководитель будет заниматься пайкой или, возможно, даже проектированием схем, что почти эквивалентно кодированию в программном обеспечении. Я ожидаю, что они будут разрабатывать систему.
Я работал в местах, где «руководитель» (технический или другой) должен был бы выполнять управленческие обязанности в дополнение к поддержанию уровня производительности при выполнении своих обычных обязанностей, поэтому определенно интересуйтесь определением их должностей в компании.
Это правильный ответ.. Я видел много компаний, в которых менеджером является техлид.
Технический руководитель в одной компании должен был составлять отчеты и приставать к техническим специалистам, которые не были вашими прямыми подчиненными, чтобы сделать вашу работу выполнимой. «Ведущий» был низшим техническим специалистом в корпоративной структуре, поскольку технические специалисты были частью сайта и имели совершенно разных менеджеров с другими приоритетами. Я не задержался надолго.
+1. Определение технического руководителя размыто. Таким образом, вы должны быть точны в том, что означает для вас техлид, если вы хотите продолжать быть техническим специалистом. Во время собеседования я всегда заранее говорю, что не вижу проблем с анимацией технических совещаний, но я не хочу иметь дело с температурой открытого пространства или ежегодным обзором производительности. Если техлид на самом деле имел в виду менеджера, я завершаю процесс.

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

Ты можешь:

  1. Просто берите работу «только кодирование». Вы можете заработать много денег, делая это, например, в FAANG. Вы по-прежнему будете чем-то вроде старшего разработчика, но со временем заработаете больше долларов. Или в стартапах, но там денег не получишь, только раздашь «лотерейные билеты». Но при поиске работы уточните, что вас интересует кодирование, а не лидерство. Таким образом, вы не получите лучшие должности (никто в мире, зарабатывающий более миллиона долларов, не делает этого, потому что знает новейший язык программирования), но вы можете получить хорошую работу.
  2. Берите на себя ведущую и техническую роли попеременно, чтобы сохранить свое техническое превосходство. Или в небольших организациях, где больше работы выполняется всеми, а чистой руководящей работы меньше.
  3. Займитесь консалтингом, где вы можете далеко пойти, просто выполняя работу.

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

(2) звучит привлекательно, но часто ли это работает на практике? Против того, что вас переводят в ту или иную роль в зависимости от обстоятельств? Кроме того, лидерство, управление проектами и менеджмент с точки зрения бизнеса кажутся отдельными специальностями, которые могут занять много попыток, чтобы достичь уровня компетентности.
@PeteW Спасибо за подсказку, как бы вы разделили технического руководителя и менеджера по проектам?
Конечно, вам придется сменить работу, чтобы изменить обстоятельства. И да, вы будете распространять свои знания в нескольких областях.
@Ben - «технический руководитель», я полагаю, объединяет их. возможно, поможет жесткая стандартизированная методология (за пределами моего опыта) ... мое собственное наблюдение в проектах по оборудованию: могут быть лидеры, хорошо умеющие заставить группы людей / организации сотрудничать гладко, но плохо управляющие техническим потоком проектов / требования / управление рисками и люди, обладающие противоположным и дополняющим навыком. иногда не оба сразу
Этот ответ немного упускает суть. Сама проблема ОП заключается в том, что его работа подрывает его способность учить и руководить другими людьми, отталкивая их от соответствующих технологий, тем самым постепенно снижая их способность принимать осмысленные решения о любой работе, связанной с ними.

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

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

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

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

Эти 2 цитаты могут помочь вам.

Стив Возняк (Apple):

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

Марк Твен (автор):

Найдите работу, которая вам нравится, и вам не придется работать ни дня в своей жизни.

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

РЕДАКТИРОВАТЬ : нашел видео Воза

Технический руководитель может быть отличной работой. Вам просто нужно сделать это таким образом.

Больше кодом не занимаюсь и только немного технических вещей (что забавно, если учесть название должности).

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

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

Вы слишком важны для организации, чтобы заниматься рутинной работой. Делегат. Если вашей команде нужен кто-то, кто объяснит требования, посмотрите, сможете ли вы нанять в команду бизнес-аналитика, даже 0,5 FTE могут иметь большое значение, а иногда они могут приходиться на бизнес-сторону организации, то есть это не ударит по вашим бюджет команды. Для шаблонных документов, таких как формы запросов на изменение, назначьте их инженерам по контролю качества, которые сделают тщательную работу и, как правило, хорошо подходят для повторяющихся задач. Один из ваших самых умных QA может даже найти способ их автоматизировать.

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

Ваш опыт кодера очень ценен. Лучший программист компании иногда в десять раз производительнее самого младшего. Вы можете выделить время для самых важных (т.е. самых интересных) задач по программированию. Если у вас нет времени, объявите по средам «день потока», во время которого не будет встреч и у всех будет время сосредоточиться на программировании, включая вас. Это на благо команды.

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

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

Есть ли выход из этой «судьбы»? Как оставаться в курсе событий и не устаревать на рынке?

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

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

Я бы бросил вызов этому мнению: «Вы можете выделить время для самых важных (т.е. самых интересных) задач кодирования». Как технический руководитель, если вы оставите все самые интересные (возможно, и самые сложные?) задачи для себя, как ваша команда научится их выполнять?
@ZachTurn Ну, очевидно, им не нужно будет делать то, что вы только что сделали, потому что вы уже это сделали. Я думаю, вы спрашиваете, как они научатся делать подобные вещи. Что они узнают, выполняя их, следуя вашему примеру.

Переосмыслите свою концепцию инженерии

Как технарь, вы, естественно, сосредоточены на создании хорошего кода. Но...

Как старший инженер, вы на самом деле сосредоточены на создании хорошего проекта . Код может быть любым подходящим языком, который вам нравится для реализации этого дизайна, и если вы переедете в новое место, вы сможете переделать этот дизайн с их предпочтительным языком. C++, C#, Java, что угодно, концепции остаются прежними. В значительной степени определение старшего инженера заключается в том, чтобы признать это разделение и не зацикливаться на каком-либо конкретном языке. С таким опытом я ожидаю, что старший инженер в любом случае поднимет любой язык до функционального уровня менее чем за две недели. Важны концепции, а не реализация.

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

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

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

А кто может, тот научит

Сколько часов у вас в сутках? Даже если ваш худший член команды всего на четверть медленнее вас, команда из 8 человек все равно удвоит вашу производительность. Если вы можете использовать свое время, чтобы получить их вдвое медленнее, чем вы, они получат в 4 раза больше вашего результата за то, что они вложили в 1 раз больше вашего времени. Это победа. Вот для чего вы здесь.

Это для тебя?

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

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

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

  1. Поручите немного работы по кодированию и себе.
  2. Просмотрите и рефакторинг кода ваших младших разработчиков.

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

Другие ответы хороши, я просто хочу обратиться к этому конкретному вопросу:

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

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

Также рассмотрите разницу между техническими навыками и человеческими навыками:

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

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

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

  1. Пока вы назначаете/объясняете задачи, поднимайте планку ожиданий от разработчика. Пример: попросите их проверить, как ваш конкурент делает то же самое. Попросите их провести мозговой штурм и найти решения. Вы просто адвокат дьявола. Продолжайте показывать им дыры в их решении.
  2. Теперь происходит то, что вы узнаете больше, чем могли бы, если бы программировали сами.
  3. Как только они предложат решения, вы сможете увидеть более серьезные проблемы, которые необходимо решить. Пример: что, если кто-то уйдет в отставку. Или единая точка отказа в системе.
  4. В конце концов у вас появится горстка надежных людей, которым вы сможете делегировать большую часть работы.

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

Как человек, который столкнулся с этой проблемой и победил ее в параллельной сфере работы, это мой наспех составленный список лучших советов… надеюсь, он поможет!!

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

Я рано перешел из крупной компании в маленькую (SME).

Большой компании нужен менеджер, который просто управляет. Небольшой компании в хорошей нише нужен менеджер, который также является универсальным и практическим членом команды. В конечном итоге вы станете техническим директором с командой из 5-10 человек, а не с командой из 20-200 человек. И выигрыш ОГРОМНЫЙ, если это хорошая профессиональная компания, и вы ладите со своим менеджером (важно, сосредоточьтесь на этом при принятии решения).

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

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

Я тоже после этого переключился на нишевую сферу и работал подрядчиком

Управление — не единственный способ получить высокую зарплату. Ниша — еще один способ. Примеры в области технологий могут включать, например, ИТ-безопасность. Кобол. Пользовательские расширения SAP. Базы данных. Высокая доступность. Специализируясь на критически важной области продукта, такой как медицинское программное обеспечение или программное обеспечение для авиакомпаний. Поиск неисправностей. Спасение проектов, нуждающихся в интенсивной работе по кодированию «без экономии средств» для какого-то критического срока или потребности рынка. Обновление старого кода до современного кода. Вероятно, есть много ниш, в которых вам хорошо платят, если вы работаете перед компьютером. Найдите специализированную нишу, которая сосредоточена на жизни кодирования, которую вы хотите.

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

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

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

На вашем месте у меня был бы откровенный разговор с моим менеджером:

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

Хороший менеджер найдет способ использовать ваши сильные стороны и интересы. Некоторые возможные результаты:

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

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

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

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

Возьмите недавнее волнение по поводу log4j. Использует ли его ваша организация? И кто принял такое решение? Используют ли его все ваши службы/серверы, или только некоторые, или ни одного? Если нет, то что еще они используют?

Такое решение можно оставить (старшим) инженерам. Но если их больше одного, кто ведет?

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

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

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

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

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

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