Перехід до керівної команди [закрито]


16

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

  • У вас було слабке бажання писати код, але все ще сильне бажання створювати програми?
  • Чи ти зрозумів, що ти більше людина, і ти можеш краще використовувати свої навички спілкування?
  • Це було тому, що вас запитали керівництво і подумали, чому б ні?
  • За гроші?
  • Як пройшли перші кілька місяців після переїзду?
  • Чи вплинули стосунки з колегами?

Відповіді:


14

Я змінив подібний тип кілька років тому. У моєму конкретному місці я відчував себе неефективним у своїй ролі розвитку в той час і розглядав роль керівництва як можливість впливати на кращі практики програмування в моїй організації.

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

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

Щодо деяких конкретних питань:

  • Мене розчарувало брак часу, необхідний для розвитку розвитку, на пошук потрібного балансу знадобився близько року
  • Я витрачав багато часу, відточуючи свої міжособистісні навички, що зробило мене сильнішим лідером у всіх сферах життя
  • Мене попросили керівництво, і незначне підвищення заробітної плати було, але моя основна мотивація - кар’єрний розвиток
  • Стосунки з колегами були добрі. Я вважаю, що це тому, що я доклав великих зусиль, щоб працювати захисником команди, і був мотивований діяти на їх користь. У зв'язку з цим я працював з ними на відміну від них.

"просто не бійтеся приймати рішення", важливий момент, який, мабуть, пропущено багатьма статтями на цю тему
Адрієн Бе

11

Я став командою / технічним керівником, тому що я люблю робити технічні команди в кінці :-). Я переконаний у силі технічних команд / громад зробити багато позитивних змін у світі.

У вас було слабке бажання писати код, але все ще сильне бажання створювати програми?

У мене все ще є сильне бажання писати код і створювати корисні речі, але я однаково (якщо не більше) намагаюся намагатися позитивно впливати на команду людей, які будують програмне забезпечення. Я намагаюся зосередитись на тому, щоб усунути всі бар’єри, які їм досягаються, і створити і написати великий код.

Чи ти зрозумів, що ти більше людина, і ти можеш краще використовувати свої навички спілкування?

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

Це було тому, що вас запитали керівництво і подумали, чому б ні?

Я вперше був технічним керівником - так. У той час це було просто тому, що я був єдиним, хто знав технологію, що є у нас (веб-бази Java).

За гроші?

Ні - для мене я би заробляв більше на день або на годину як прямий розробник. Команда / Технічні ведучі, як правило, повинні тривати більше годин. YMMV з цього приводу.

Як пройшли перші кілька місяців після переїзду?

Акт врівноваження! Політика та "м'яка майстерність", безумовно, були найважчими. Технічні рішення тощо були простішими, але у вас є дуже мало часу для фактичного кодування, поки ви не досвідченіші в управлінні своїм часом.

Чи вплинули стосунки з колегами?

Спочатку так - я був набагато молодший, ніж решта команди - це був тонкий балансуючий акт навчання мистецтву розробки програмного забезпечення з них, а також перехід від фронту «нових технологій».

HTH!


9

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

Що стосується конкретних питань:

  • У вас було слабке бажання писати код, але все ще сильне бажання створювати програми?

Ні - я продовжував писати код. Дивись вище.

  • Чи ти зрозумів, що ти більше людина, і ти можеш краще використовувати свої навички спілкування?

Я більше не людина, яка є людиною, але в мене є чудові комунікативні навички - і не були мотивацією.

  • Це було тому, що вас запитали керівництво і подумали, чому б ні?

До певної міри. Хтось зрештою повинен зробити вас лідером / менеджером в ієрархічних бізнес-ситуаціях.

  • За гроші?

Безумовно допомагає!

  • Як пройшли перші кілька місяців після переїзду?

Чудово, що стосується управління командою та розвитком, то не так добре в роботі із зовнішньою політикою, що є мухою в цій мазі.

  • Чи вплинули стосунки з колегами?

Зовсім ні.


Чому потрібно залишатися сильним програмістом, коли ти TL або менеджер? Не вистачає чіткого огляду технічних аспектів проектів?
Джон Шафт

6
@Pablo Ні, це не так. Ви повинні відповідати тим, чим займається команда, і вам потрібно надати такі речі, як оцінки часу, оцінки змін в архітектурі і т. Д. Ви не можете цього робити, якщо ви не є сильним розробником і добре знати кодову базу Якщо ви цього не зробите, ви просто перероджуєтесь у гострий бос.
Ніл Баттерворт

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

1
@ Марк О, звичайно, я це знаю. Це не означає, що мені це сподобається. Час, який мені довелося летіти з Лондона до Нью-Джерсі та назад на однугодинну зустріч, був особливо болючим!
Ніл Баттерворт

3

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

Моє бажання писати код ніколи не згасало протягом багатьох років, а іноді це трохи заважає. Мені довелося навчитися ставити власні бажання на один бік і робити те, що найкраще для команди, особливо як майстер Scrum. Я ніколи більше не був людиною, і мені довелося навчитися багатьом навичкам управління. Однак я спостерігав протягом багатьох років, що якщо ти хочеш потрапити в управління, ти повинен зробити вибір. Ви можете бути (комерційно) успішним менеджером, або можете бути хорошим лідером команди. Дуже мало кому вдається бути одночасно обома (а в деяких компаніях це буквально неможливо). У більшості місць, де я був, єдиним пріоритетом керівництва є гроші, а всі інші речі, такі як побудова команди, якість, цінності громади тощо, не рахують абсолютно нічого.

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

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


2

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

Перші кілька місяців були хиткими, деякі пропущені терміни і якийсь дуже поганий код, але я врешті-решт отримав повісити.

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

Що стосується стосунків з моїми колегами, то вони не надто впливали. Я пройшов дистанційний курс незабаром після того, як став керівником команди під назвою «Будівництво команд, які працюють». У ньому прописано багато м'яких навичок та способів зближення команди. Я взяв деякі поради з цього курсу і застосував його до своєї команди, і це справді спрацювало.

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

Всього два мої центи :)


1

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


хахаха. "В ідеалі вони будуть набагато кращими за мене, і я зможу просто вказати на них проблему, а потім просто посидіти і взяти кредит".
Адрієн Бе

1

Зазвичай, на мій досвід, єдиним критерієм є стаж, який змінюється залежно від удачі; якщо ти зайдеш і хлопці там більше від’їжджають, ти зараз старший розробник (хоча це може бути не надто добре, залежно від причин, чому інші виїхали…) і станеш лідером, коли наймають більше людей або просто бути Сміттером / Так-Людиною для управління, незалежно від того. Фактична майстерність та знання, мабуть, мають дуже мало спільного з цим, оскільки я під час своєї кар'єри зіштовхнувся лише з декількома "ведучими", які знали достатньо, щоб бути потенційними - в більшості випадків вони просто були в компанії.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.