Podczas mojej kariery w firmie Microsoft moi menedżerowie wielokrotnie pytali mnie, czy chcę objąć stanowisko kierownicze, czy pozostać na ścieżce IC (indywidualny współpracownik). Obie były tam w porządku. Gdybyś podążał za IC, zostałbyś architektem, a na końcu technicznym facetem, a na ścieżce zarządzania zostałbyś wiceprezesem linii biznesowej.

Zawsze odpowiadałem, że chcę pozostań na ścieżce IC, ponieważ to była moja pasja, tak jak Ty. Miałem okazję do zarządzania, na przykład tworzenia kopii zapasowych kierownika zespołu lub tworzenia wirtualnego zespołu między działami i kierowania ich do pobocznego projektu. Ale moja główna praca zawsze polegała na pisaniu kodu, rozwiązywaniu problemów inżynieryjnych, optymalizacji rzeczy.

Jednak dzisiaj żałuję tej decyzji z dwóch powodów: Po pierwsze, mogłem dzisiaj naprawdę wykorzystać to doświadczenie jako właściciel własnego uruchomienie. Firma Microsoft dokłada wszelkich starań, aby Cię przeszkolić, zapewniając Ci najlepsze zasoby, które pozwolą Ci awansować na stanowisku kierowniczym i myślę, że mógłbym na tym mniej więcej skorzystać.

Po drugie i ważniejsze jest to, że: zarządzanie pozwala na tworzenie oprogramowania, którego samemu sobie nie wyobrażasz. Myślę, że tej części brakuje nam w obrazie ścieżki zarządzania. W rzeczywistości wzmacnia naszą zdolność do tworzenia oprogramowania o rzędy wielkości. Wiem, jak kusząca jest samodzielna praca nad kodem, ale kiedy widzisz, że przy odpowiednim kierunku i wskazówkach możesz osiągnąć dziesięciokrotną, stukrotną przepustowość, jest to ekscytujące. Pomyśl o równoległym wszechświecie, w którym Linus Torvalds nalegał na samodzielne kodowanie całego Linuksa. Jak daleko by się posunął? Oczywiście żaden z twoich programistów nie będzie kodował tak jak ty, ale niektórzy będą kodować nawet lepiej niż ty, a ty nauczysz się radzić sobie ze sporadycznym brakiem jakości lub błędami w komunikacji. Będziesz rozwijać każdą z nich, aby być lepszym sobą, zwielokrotniając swoją produktywność i jakość produktu.

Jeśli twoja pasja do tworzenia dobrego oprogramowania jest lepsza od pasji do rozwiązywania problemów technicznych, ścieżka zarządzania może nie być zbyt odległa.

Tylko moje dwa centy.

Bardzo trudno odpowiedzieć na to definitywnie. Z mojego doświadczenia wynika, że ​​każda firma reaguje inaczej.

Pracowałem dla firmy, w której nie było innej ścieżki dla programisty. Jeśli nie zostałeś menedżerem, to nigdy nie dostałeś podwyżki poza stopę inflacji.

Pracowałem dla kilku firm, w których od deweloperów oczekiwano, że chcą pozostać programistami. Zostali dobrze nagrodzeni za to, że byli dobrymi programistami i dziwnie patrzyli na to, czy wykazywali ambicję, by być kimś innym.

Pracowałem dla firmy, w której można było podążać wieloma ścieżkami od rozwoju do zarządzania ludźmi lub zarządzania projektami, lub po prostu bądź naprawdę dobrym programistą i zarabiaj odpowiednio.

Sugeruję, aby być uczciwym w kwestii swoich aspiracji i pozwolić im zdecydować, czy pasujesz do ich filozofii. W ten sposób nie utkniesz w pierwszej firmie, o której wspomniałem powyżej.

Twój sentyment jest czymś, co inni programiści mogą zrozumieć, ale menedżerowie nie. Zamiast mówić, czego nie chcesz robić (i zabrzmieć negatywnie), sugeruję, abyś podkreślił, co naprawdę chcesz zrobić.

Powiedz im, że chcesz, aby ręce były „brudne” i lubisz kodować. Może w miarę upływu czasu stworzą dla Ciebie pozycję „nadrzędnego programisty”. Widziałem podobne rzeczy.

Awans niekoniecznie oznacza, że ​​nie będziesz już programistą, może oznaczać na przykład, że będziesz mógł podejmować szersze decyzje techniczne.

Po prostu przedstaw swoje ambicje, tak jak tutaj.

Pracując na kilku stanowiskach kierowniczych technicznych, najbardziej doceniam to: nie ma nic łatwiejszego w zarządzaniu niż pracownicy, którzy wiedzą, czego chcą (jeśli jest to w z ich możliwościami).

Niedoświadczeni menedżerowie często awansują najlepszego inżyniera, jakiego potrzebują, na menedżera, zakładając, że robią dobrze. Rezultat: wymieniają najlepszego inżyniera, jakiego mają, na często przeciętnego menedżera. (Dalsze rozwijanie tej koncepcji jest często określane jako Zasada Petera). Powodem jest to, że zarządzanie wymaga innego zestawu umiejętności niż inżynieria, co oznacza, że ​​doświadczeni menedżerowie spędzali czas na rozwijaniu umiejętności zarządzania, a nie umiejętności inżynierskich.

Powiedz swojemu menedżerowi, że chcesz zostać starszym programistą / architektem, i że byłoby lepiej, gdyby pomyślał o ścieżce kariery w tym kierunku, jeśli chce, abyś został na dłużej.

Powiedz im, że wolisz ścieżkę techniczną niż karierę menedżerską . Nawet w ramach tworzenia oprogramowania istnieją role młodsze i starsze. Młodsi członkowie zespołu mają tendencję do naprawiania błędów i pisania kodu modułów, za które są odpowiedzialni. Starsi członkowie projektują interfejsy API i podejmują decyzje architektoniczne. Aby zostać starszym programistą potrzeba wielu lat doświadczenia. Na przykład musisz

• zdobyć doświadczenie z szeroką gamą technologii
• Dostrzegać trendy w branży (i rozpoznawać mody do ignorowania!)
• Naucz się przed błędami technicznymi i nie dopuścić do ich ponownego popełnienia przez zespół
• Projektuj eleganckie rozwiązania, które również działają wydajnie

Krótko mówiąc, możesz być wartościowy jako starszy programista, nie w zarządzaniu. Jeśli Twoja obecna firma nie ma możliwości rozwoju technicznego, możesz zaproponować sobie kierownictwo techniczne (tylko jeśli uważasz, że jesteś gotowy!) Lub znaleźć firmę, która ma ścieżkę techniczną.

Nigdy nie mów nigdy. Kto wie, gdzie będziesz za dziesięć lat? Rzeczy się zmieniają.

To powiedziawszy, inne odpowiedzi dotyczyły tego, co powiedzieć, ale równie ważne jak co jest kiedy . Ty i Twój menedżer powinniście okresowo omawiać swoją karierę, przynajmniej w ramach corocznych przeglądów wyników. To jest czas, aby określić, czego chcesz i wspólnie zidentyfikować możliwości i przeszkody. Kiedy twój menedżer decyduje, jak obsłużyć projekty, powinien wziąć pod uwagę pragnienia swoich ludzi, których nie może zrobić, jeśli nie wie, czym one są.

Jeśli to nie jest częścią proces oceny wyników, poproś kierownika o spotkanie na ten konkretny temat. Na tym spotkaniu porozmawiaj o tym, co robisz, a które kochasz, o umiejętnościach, które chciałbyś dalej rozwijać, o rodzajach projektów, nad którymi chcesz pracować i tak dalej. Jeśli ma na myśli inne rzeczy, prawdopodobnie je poruszy, a wtedy możesz odpowiedzieć zamiast uprzedzającego mówić „nie chcę zarządzać”.

Osobiście nigdy nie wypowiedziałbym tego stwierdzenia, ponieważ A) To prawdopodobnie brzmi źle dla przełożonych, jakbyś nie miał ambicji / oddania swojej pracy / karierze B) Powiedziano mi, żebym nigdy nie mówił, że nie Nie myśl o zostaniu menedżerem któregoś dnia podczas rozmów kwalifikacyjnych, a to sprawi, że będziesz kłamać w możliwej przyszłości i C) Nigdy nie wiesz, czy będziesz się czuł inaczej w przyszłości. Skąd wiesz, że NIGDY w swoim życiu nie będziesz chciał zostać menedżerem? Myślę, że byłoby lepiej po prostu odrzucić promocje, gdy są oferowane.

Trzymaj się tego, czego chcesz i staraj się unikać negatywnych stwierdzeń na temat tego, czego nie chcesz. W końcu wszelkie rozmowy o awansach są prawdopodobnie czymś, co miałbyś ze swoim menedżerem, który jest jednym z tych morderczych maniaków, którzy byli na tyle szaleni, że chcieli zarządzać ludźmi. Powiedzenie „tylko orzechowe kulki wykonałyby tę pracę” może być trafne, ale raczej nie jest politycznie ryzykowne.

Zamiast tego nakreśl promocję, którą chcesz, jeśli dobrze cię czytam, która obejmuje:

• Ewolucja i narastanie wyzwań technicznych
• Odpowiedzialność i znajomość większych części opracowywanego rozwiązania technicznego
• Szansa na poznanie i opanowanie nowych technologii, gdy firma napotyka ich potrzeby
• Ostatecznie - odpowiedzialność za znalezienie przyszłych rozwiązań technicznych i pomoc firmie poprzez zostanie ekspertem technicznym przed kierowcami biznesowymi.

To jest ścieżka kariery, którą można promować . Może nie jest to oczywiste w Twojej firmie, ale większość firm ma ścieżkę dla pracowników umysłowych, którzy chcą doskonalić się w zakresie wiedzy technicznej bez kosztów / harmonogramu lub obowiązków ludzkich. Być może będą musieli uczyć innych lub mentora, ale to bardzo różni się od „zarządzania” ludźmi.

Trzymaj się tego, co jest dobre w Twojej pracy i wszelkich przyszłych awansach.

Najlepsze, co możesz zrobić, to poczekać, aż zostanie Ci zaoferowana promocja, ocenić tę ofertę, a jeśli nie chcesz, zrezygnować z promocji.

Większość firm publikuje wolne stanowiska i chce, aby pracownicy korzystali z okazji, które ich interesują. Po pewnym czasie, jeśli pojawi się stanowisko, które według twojego przełożonego byłoby dobre, może zasugerować, że się o nie ubiegasz. W tym czasie możesz przekazać swojemu przełożonemu swoje krótkoterminowe cele. Jeśli wolisz pozostać na bardziej technicznym stanowisku, Twój menedżer może wypatrywać stanowisk, które będą dla Ciebie bardziej wymagające, ale mogą Cię zainteresować. Lub po prostu pozwól ci pozostać tam, gdzie jesteś szczęśliwy i produktywny. Firmy potrzebują robotnic, a jeśli jesteś szczęśliwy będąc jednym z nich i dobrze wykonujesz swoją pracę, rzadko zdarza się, że będziesz zmuszony do zrobienia czegoś, co spowoduje, że będziesz nieszczęśliwy i mniej produktywny.

Myślę, że wielu profesjonalnych programistów boryka się z tym „problemem” w trakcie swojej kariery. Niewielu zdecyduje się pozostać w kodowaniu „na podłodze”, ale ci, którzy to robią, ostatecznie stają się prawdziwymi mistrzami sztuki.

Ale myślę, że twoje ambicje powinny się ujawniać naturalnie, gdy pracujesz w różnych zespołach i zawsze jest tym, który używa nowych konstrukcji programistycznych, używa najlepszych wzorców i tworzy najlepsze algorytmy wśród was. W ten sposób sygnalizujesz innym, że naprawdę jesteś pro-koderem i jeśli jednocześnie będziesz nadal komunikować swoje życzenie, aby na zawsze kodować dobre rozwiązania, to w końcu się rozprzestrzeni i ludzie zaczną patrzeć na Ciebie jak na prawdziwego frajera. i przestań pytać, czy chcesz zostać kierownikiem zespołu administracyjnego, czy kimkolwiek innym.

Pomyśl między innymi o ludziach takich jak Bjarne Stroustrup, James Gosling, Dennis Ritchie, Larry Wall, Sergey Brin i Anders Hejlsberg. myślę, że zrobili coś innego niż kodowanie, mimo że mogliby na swojej drodze zająć bardziej lukratywne stanowiska.

Myślę, że Twoim głównym celem powinno być uczynienie siebie niezbędnym. Twórz kod, który jest tak wspaniały, że nikt w firmie może zrobić to samo lub lepiej. Następnie możesz ubiegać się o tyle podbić, ile chcesz i nadal kodować!

Jeśli nie dostaniesz podwyżki, nie udało Ci się wykonać wspomnianego kroku wcześniej o komunikowaniu swoich ambicji. Szefowie nie rozumieją twojej wyższości. Jeśli tak jest, upewnij się, że masz dużo dokumentacji potwierdzającej Twoje umiejętności i pracuj dla Google czy coś takiego!

Miej to w swoim umowie lub napisz nową umowę mówiącą, że do odwołania wolałbyś pozostać na takim stanowisku / klasie pracownika, ale będąc tam rezygnujesz z możliwości awansu.

Jednocześnie chciałbym jednocześnie poprosić, aby skoro zrezygnowałeś z możliwości uzyskania wyższej płatnej pozycji, Twój dochód byłby co roku zwiększany o procent w lejach zwiększenie tytułu stanowiska pracy, do wysokości kwoty pieniężnej, zostało uzgodnione.

Ponieważ jeśli pracujesz dla określonego typu osoby, mogą one utrzymać Cię na tym samym poziomie płac, ponieważ nie jesteś zainteresowany awansem zawodowym, i nigdy nie nauczą się niczego nowego. Chociaż języki mogą się zmieniać, uważają, że nadal wykonują tę samą pracę, którą wykonujesz teraz. Logiczne lub nielogiczne, jestem teraz w takim miejscu, więc w ostatnim fragmencie mówię z powodu doświadczenia.

Uważam, że ważne jest tutaj to, czym jest Twoja ambicja i skuteczne przekazywanie tego. Mówisz, że jesteś ambitny na własnej ścieżce kariery, ale „samo kodowanie” to nie ścieżka kariery . Jeśli masz problemy do rozwiązania, rozwiązania ich, a następnie przejścia do następnego problemu, to jest opis stanowiska. Nie ma w tym nic złego, ale musisz pomyśleć o tym, jak chcesz na tym budować, aby stać się bardziej wartościowym dla firmy i jak przełożyć tę wartość na coś, co Twój menedżer może zrozumieć, i właśnie tam pojawia się aspekt ścieżki kariery w.

Twoje ambicje jako programisty mogą przybrać formę: chcę wykorzystać moje umiejętności rozumienia technologii, aby być odpowiedzialnym za projektowanie / tworzenie / ulepszanie narzędzi, które radykalnie obniżają koszty naszej działalności lub które mogą zostać sprzedane lub w jakiś sposób dodać wartość istniejącemu produktowi, umożliwiając jego sprzedaż na nowy rynek (np. aplikacja internetowa przenosząca się na iOS itp.)

Wtedy to Ty musisz przyjrzyj się możliwościom lub pozycjom w firmie, które pozwoliłyby Ci najskuteczniej wykorzystać te umiejętności. Pamiętaj, że może to oznaczać więcej pracy nad projektem / architekturą, niż byś chciał, aw zależności od struktury Twojej firmy może to być ograniczające.

Możesz mieć inne pomysły. Ale najważniejsze jest, aby spojrzeć na ludzi z naszej branży, którymi chciałbyś być, zobaczyć, gdzie oni są i spełnić ambicję, aby się tam dostać. Następnie opisz ich rolę w kontekście tego, co wnoszą do swojej firmy. A jeśli zauważysz, że patrzysz na ludzi, którzy osiągnęli mniejszy wzrost, nie ma w tym nic złego .

Wszystkie firmy cenią ludzi, którzy mają wpływ na biznes, wizję i zysk. (niekoniecznie w dowolnej kolejności). Jeśli potrafisz zakomunikować wartość bycia indywidualnym współpracownikiem i jak to wpływa na ogólną wizję Twojej firmy / oddziału, to świetnie.

Mógłbyś definitywnie przeformułować swój cel kariery. Na przykład pisanie kodu będzie tak naprawdę tylko małą częścią pracy, nawet dla indywidualnej roli. Indywidualni współpracownicy, którzy ciągle uczą się nowych rzeczy, spędzają większość czasu na posługiwaniu się różnymi językami i technologiami, przez co ogólnie są użyteczni dla wielu osób w moim zespole. Uważam, że zespół zyskuje na produktywności, gdy są ludzie, którzy pomagają innym, posiadając większą wiedzę. Książki takie jak Pragmatic Programmer i Clean Code podkreślają potrzebę programistów, którzy są „pasjonatami” rozwoju.

W każdym razie nie można być programistą i unikać tzw. Zostaniesz poproszony o oszacowanie, skomentowanie priorytetów, stworzenie awaryjnych problemów klientów, poinformowanie o nowych pomysłach na produkty ... z których żaden nie jest „kodowany”

Więc moje podejście będzie stanowić nową wiadomość, przećwicz to, a następnie powiedz o tym przełożonym.

Możesz rozważyć zawarcie kontraktu. Jeśli jesteś kompetentnym (lub lepszym) programistą i chcesz od czasu do czasu zmieniać pracę, jako wykonawca możesz zarobić bardzo dobre pieniądze. Uważam, że ten ruch jest bardzo wyzwalający. Ogłosiłem się jako starszy inżynier oprogramowania (którym jestem) i zostałem zatrudniony specjalnie na trudne stanowiska programistyczne. Nie spodziewałem się, że przejdę do kierownictwa właśnie dlatego, że byłem wykonawcą.

To nie tylko pozwala uniknąć presji, aby zmienić to, co robisz, ale uznałem to za niezwykle pouczające, aby pracować w wielu różnych środowiskach i zobaczyć sam, jak rozwija się wiele firm.

Pokaż swoje ambicje, sprzedając pracodawcy pomysł stworzenia ścieżki kariery obejmującej kilka poziomów programisty. Może bardziej zajmiesz się projektowaniem i będziesz mieć wkład w planowanie i przeglądanie kodu, ale nadal skupiasz się na programowaniu. Dla wielu programowanie nie powinno być wstępną fazą kariery, ale samą karierą. Teraz, jeśli Twoja firma starzeje się w swoich potrzebach programistycznych i wszystko jest takie samo wsparcie dla tej samej bazy kodu, może to być trudne do sprzedania, ale zrób to mimo wszystko.

Sugerowałbym, że wiele zależy od tego, co rozumiesz przez zarządzanie i zarządzanie projektami, a także od stylu zarządzania, w którym pracujesz.

Nie chcąc wdawać się w długą debatę (której jest wiele w sieci!), jeśli jako specjalista techniczny jesteś zainteresowany / zaangażowany w podejście do rozwoju Agile / Scrum, wtedy koncepcja „zarządzania projektem „lub„ lider zespołu ”nie zawsze pasuje do wszystkich interpretacji tych technik.

Dwóch członków mojego zespołu programistów na kurdzie certyfikacji Scrum-Master stwierdziło ostatnio, że co najmniej połowa uczestników była„ klasyczni „wodospadowi” kierownicy projektów, próbujący dowiedzieć się, jaka była ich rola w Scrumie ...

W wielu organizacjach rola kierownika projektu już nie istnieje.

Mam członków zespołu po prostu tak jak ty - decydują się na pracę dla mnie, ponieważ po części nie oczekuję od nich formalnego zarządzania lub przywództwa (poza płaską strukturą Scruma), a ponadto mam nieskończoną (!) dostawę niezwykle trudne problemy techniczne, napędzane przez głodny badań i rozwoju, bogaty w gotówkę przemysł. Kompromis polega na tym, że muszą pracować w zespole Scrumowym, a nie być „samotnym bohaterem”.

Jeśli Twoja organizacja jest bardzo zaangażowana w zatrudnianie i zarządzanie, możesz ją znaleźć trudne do stworzenia ścieżki kariery technicznej zgodnej z wytycznymi, do których dążysz; warto o tym porozmawiać, jak sugerują ludzie, ale jeśli pracujesz w dużej firmie, zmiana może być wyzwaniem.

Ostatecznie może być konieczne znalezienie kultury organizacyjnej, która pasuje do wybranej ścieżki kariery, ale jeśli rozumiesz czego szukasz, jesteś daleko, aby to się stało.

Jeśli chodzi o Twoje inne komentarze na temat umiejętności specjalistycznych i ogólnych, sugeruję, że byłbyś silnym atutem w każdym środowisku Agile / Scrum.

Tylko jedna rzecz na tym świecie jest stała i jest to „ZMIANA”!

W wielu firmach zazwyczaj istnieje stanowisko zwane „Analitykiem systemowym”, a osoby na tych stanowiskach zawsze są zaangażowane kod wysokiego poziomu, taki jak tworzenie struktury aplikacji.

Oznacza to, że nadal możesz robić postępy na ścieżce kariery, ale bez konieczności odchodzenia od technicznych aspektów kodowania, które kochasz.