Przeprowadzka do zespołu prowadzącego [zamknięty]


16

Szukam przykładów doświadczeń od osób, które przeszły od programisty do kierownika zespołu. W pewnym sensie chcę wiedzieć, dlaczego ludzie to zrobili. W szczególności są to niektóre pytania i wątpliwości, które krążą w mojej głowie.

  • Czy miałeś słabnące pragnienie pisania kodu, ale nadal silną chęć tworzenia programów?
  • Czy zdałeś sobie sprawę, że jesteś bardziej osobą i możesz lepiej wykorzystać swoje umiejętności komunikacyjne?
  • Czy to dlatego, że zostałeś zapytany przez kierownictwo i pomyślałeś, dlaczego nie?
  • Za te pieniądze?
  • Jak wyglądały pierwsze miesiące po przeprowadzce?
  • Czy wpłynęły na relacje z kolegami?

Odpowiedzi:


14

Dokonałem tego rodzaju zmiany kilka lat temu. W moim konkretnym miejscu czułem się wtedy nieefektywnie na mojej roli programistycznej i patrzyłem na rolę lidera jako okazję do wpływania na lepsze praktyki programowania w mojej organizacji.

To było trudne przejście przez pierwsze kilka miesięcy, ponieważ odkryłem, że było znaczne obciążenie, które odebrało mi zdolność kodowania. Ponadto była niepewność, że nie chcę przekraczać moich granic.

Po kilku miesiącach mój szef był chory przez kilka tygodni, co spowodowało, że pod jej nieobecność wykonywałem wiele obowiązków kierowniczych. W tym czasie zyskałem większą swobodę w podejmowaniu decyzji, w którym to momencie mogłem dokonać zmian w naszych procesach, co pozwoliło mi na bardziej efektywne wykorzystanie mojego czasu. To był prawdziwy klucz do sukcesu w roli, po prostu nie bój się podejmować decyzji.

W zakresie niektórych szczegółowych pytań:

  • Byłem sfrustrowany brakiem czasu na rozwój, znalezienie właściwej równowagi zajęło mi około roku
  • Sporo czasu spędziłem na doskonaleniu umiejętności interpersonalnych, dzięki czemu jestem silniejszym liderem we wszystkich dziedzinach życia
  • Kierownictwo poprosiło mnie o niewielką podwyżkę wynagrodzenia, ale moją główną motywacją był rozwój kariery
  • Relacje z kolegami były w porządku. Wierzę, że dzieje się tak dlatego, że włożyłem duży wysiłek, aby pracować jako rzecznik zespołu i byłem zmotywowany do działania na ich rzecz. Pod tym względem współpracowałem z nimi, a nie nad nimi.

„po prostu nie bój się podejmować decyzji”, ważnego punktu, który prawdopodobnie pomija wiele artykułów na ten temat
Adrien Be

11

Stałem się liderem zespołu / techniki, ponieważ uwielbiam robić zespoły techniczne :-). Wierzę mocno w siłę zespołów technicznych / społeczności, które dokonują wielu pozytywnych zmian na świecie.

Czy miałeś słabnące pragnienie pisania kodu, ale nadal silną chęć tworzenia programów?

Nadal mam silną potrzebę pisania kodu i tworzenia przydatnych rzeczy, ale jestem w równym stopniu (jeśli nie bardziej) nastawiony na próbę wywarcia pozytywnego wpływu na zespół ludzi tworzących oprogramowanie. Staram się skupić na usunięciu wszystkich barier, które uniemożliwiają im dotarcie do celu, zaprojektowanie i napisanie świetnego kodu.

Czy zdałeś sobie sprawę, że jesteś bardziej osobą i możesz lepiej wykorzystać swoje umiejętności komunikacyjne?

Bardzo podoba mi się społeczna część mojej pracy. Tak, uważam, że tworzenie oprogramowania jest w istocie działalnością społeczną oraz techniczną / inżynierską.

Czy to dlatego, że zostałeś zapytany przez kierownictwo i pomyślałeś, dlaczego nie?

Pierwszy raz byłem technicznym tropem - tak. W tamtym czasie było to po prostu dlatego, że jako jedyny znałem dostępną technologię (rzeczy Java oparte na sieci Web).

Za te pieniądze?

Nie - dla mnie zarabiałbym więcej dziennie lub godzinę jako zwykły programista. Zespół / kierownicy techniczni zwykle wymagają dłuższych godzin pracy. YMMV w tej sprawie.

Jak wyglądały pierwsze miesiące po przeprowadzce?

Równoważenie! Polityka i „miękkie umiejętności” były zdecydowanie najtrudniejsze. Decyzje techniczne itp. Były łatwiejsze, ale masz mało czasu na kodowanie, dopóki nie będziesz bardziej doświadczony w zarządzaniu czasem.

Czy wpłynęły na relacje z kolegami?

Początkowo tak - byłem znacznie młodszy od reszty zespołu - był to delikatny balansujący proces uczenia się od nich sztuki tworzenia oprogramowania, a także prowadzenia od frontu „nowych technologii”.

HTH!


9

Pracowałem jako zespół i kierownik projektu przy wielu dużych projektach. Zrobiłem to, ponieważ byłem tam najbardziej doświadczonym programistą. Moim zdaniem, bardzo ważne jest, aby liderzy zespołów i menedżerowie ds. Rozwoju byli bardzo silnymi programistami i pisali (i, co ważniejsze), recenzując kod dla projektu.

Jak w przypadku konkretnych pytań:

  • Czy miałeś słabnące pragnienie pisania kodu, ale nadal silną chęć tworzenia programów?

Nie - pisałem kod. Patrz wyżej.

  • Czy zdałeś sobie sprawę, że jesteś bardziej osobą i możesz lepiej wykorzystać swoje umiejętności komunikacyjne?

Nie jestem raczej człowiekiem, ale mam doskonałe umiejętności komunikacyjne - nie były też motywacją.

  • Czy to dlatego, że zostałeś zapytany przez kierownictwo i pomyślałeś, dlaczego nie?

Do pewnego stopnia. W końcu ktoś musi uczynić cię liderem / menedżerem w hierarchicznych sytuacjach biznesowych.

  • Za te pieniądze?

Z pewnością pomaga!

  • Jak wyglądały pierwsze miesiące po przeprowadzce?

Świetnie, jeśli chodzi o zarządzanie zespołami i rozwojem, ale nie tak dobrze radzić sobie z polityką zewnętrzną, która jest latem w maści do tej roli.

  • Czy wpłynęły na relacje z kolegami?

Ani trochę.


Dlaczego nadal musisz być silnym programistą, gdy jesteś TL lub managerem? Czy wystarczający jest dobry przegląd technicznych aspektów projektów?
John Shaft,

6
@Pablo Nie, nie jest. Powinieneś odpowiadać za to, co robi zespół, i to ty musisz dostarczać takich danych, jak szacunki czasu, oceny zmian w architekturze itp. Nie możesz robić tych rzeczy, chyba że sam jesteś silnym programistą i dobrze znasz bazę kodów. Jeśli nie, po prostu przerodzisz się w spiczastego szefa.
Neil Butterworth,

1
Czuję twój ból związany z polityką zewnętrzną, ale jest to jedna z najważniejszych rzeczy, które robisz dla swojego zespołu.
MarkJ

1
@ Mark Och, jasne, wiem o tym. Nie znaczy to jednak, że muszę to lubić. Czas, który musiałem polecieć z Londynu do New Jersey i wrócić na godzinne spotkanie, był szczególnie bolesny!
Neil Butterworth,

3

15 lat temu przeszedłem do zarządzania. Moim początkowym powodem było to, że widziałem siebie jako osobę, która musi osiągnąć karierę, i to była droga do tego. Z biegiem lat ustąpiło to pragnieniu posuwania się naprzód rzeczy, które są większe niż jeden człowiek może znieść.

Moje pragnienie pisania kodu nigdy nie zanikło przez lata, a czasem przeszkadza. Musiałem nauczyć się odkładać na bok własne pragnienia i robić to, co najlepsze dla zespołu, zwłaszcza jako Scrum Master. Nigdy nie byłem bardziej człowiekiem i musiałem nauczyć się wielu umiejętności zarządzania. Przez lata obserwowałem jednak, że jeśli chcesz dostać się do zarządzania, musisz dokonać wyboru. Możesz być (handlowo) odnoszącym sukcesy menedżerem lub dobrym liderem zespołu. Bardzo niewielu osobom udaje się być jednocześnie jednocześnie (w niektórych firmach jest to dosłownie niemożliwe). W większości miejsc, w których byłem, jedynym priorytetem najwyższego kierownictwa są pieniądze, a wszystkie inne rzeczy, takie jak budowanie zespołu, jakość, wartości społeczności itp. Nie mają absolutnie nic.

Moje pierwsze miesiące były stosunkowo łatwe, ponieważ przeniosłem się z jednej części firmy do drugiej, kiedy zmieniłem się w kierownictwo, więc nie było konfliktu ze starymi kolegami.

Wzrost pieniędzy był mile widziany, ale teraz uważam, że jeśli nie przejdziesz do wyższego kierownictwa, możesz osiągnąć to samo, po prostu będąc doskonałym inżynierem SW i odpowiednio się sprzedając (i wierz mi, biorąc pod uwagę bóle głowy i stresy praca średniego kierownictwa, to naprawdę kuszący pomysł).


2

Zrobiłem skok do świata liderów zespołu podczas mojej ostatniej pracy. Zostałem wybrany przez mojego kierownika, ponieważ był pod wrażeniem mojej pracy i chciał sprawdzić, czy dam sobie radę. Postanowiłem spróbować i pobiec z nim.

Pierwsze miesiące były niepewne, niektóre terminy nie dotarły i bardzo zły kod, ale w końcu go zrozumiałem.

Jako kierownik zespołu odkryłem, że wciąż dużo koduję, akurat oglądałem kod innych ludzi i postępy.

Jeśli chodzi o relacje z moimi kolegami, nie wpłynęły one zbytnio. Wziąłem kurs na odległość krótko po zostaniu liderem zespołu o nazwie „Budowanie zespołów, które działają”. Wyjaśnia wiele miękkich umiejętności i tego, jak zgromadzić zespół. Skorzystałem z kilku rad z tego kursu i zastosowałem je w moim zespole i to naprawdę zadziałało.

Musisz upewnić się, że twoi koledzy nie widzą cię, jak zostawiasz ich za sobą, jesteś umiejętny w pracy z nimi i teraz dla nich. Niektórzy będą myśleć, że pracują dla ciebie, ale imo jest zadaniem kierownika zespołu, aby upewnić się, że mają wszystkie narzędzia potrzebne do osiągnięcia sukcesu. Gdy im się uda, zespół się udaje.

Tylko moje dwa centy :)


1

Robię to, ponieważ jest za dużo pracy i za mało mnie. Moim planem jest zatrudnienie ludzi, którzy nie potrzebują nadzoru. Idealnie będą znacznie lepsi ode mnie, a ja będę mógł wskazać im problem, a następnie usiąść i wziąć kredyt.


hahaha. „Idealnie będą znacznie lepsi ode mnie, a ja będę mógł wskazać im problem, a następnie usiąść i wziąć kredyt”.
Adrien Be

1

Z mojego doświadczenia wynika, że ​​jedynym kryterium jest staż pracy, który różni się w zależności od szczęścia; jeśli wejdziesz, a faceci tam dłużej odejdą, jesteś teraz starszym programistą (chociaż może to nie być dobra rzecz, w zależności od powodów, dla których inni odeszli ...) i stanie się liderem w miarę zatrudniania większej liczby osób lub po prostu będąc Smithers / Yes-Man do zarządzania bez względu na wszystko. Rzeczywiste umiejętności i wiedza zdają się mieć z tym niewiele wspólnego, ponieważ w trakcie mojej kariery natknąłem się tylko na kilka „potencjalnych klientów”, którzy wiedzieli wystarczająco dużo, aby być potencjalnymi klientami - w większości przypadków po prostu byli najdłużej w firmie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.