Ścieżka kariery dla programisty?
Często spotykany model ścieżki kariery dla programistów jest mniej więcej taki:
- programista
- starszy programista
- team leader
- project manager
- kierownik techniczny
- dyrektor
- prezes :)
Innymi słowy przyjmowane jest założenie, że w wyniku rozwoju i awansów, programista z czasem będzie przejmował coraz większą odpowiedzialność za grupę, innych pracowników i warstwę biznesową. A przecież niekoniecznie każdy chce i ma predyspozycje by się rozwijać w tym kierunku.
Pytania i wątpliwości:
1. Czy ten model w ogóle ma sens? Czy - biorąc pod uwagę typowe cechy programistów - mają oni zwykle szanse być dobrymi menedżerami?
2. Z jakimi inny modelami się spotkaliście w swoich firmach (bądź jakie uważacie za sensowne)?
3. Czy można planować rozwój bardziej związny z warstwą techniczną i zachować nadal przewagę konkurencyjną przed "młodymi wilkami"?
Pozdr.
Marek
- programista
- starszy programista
- team leader
- project manager
- kierownik techniczny
- dyrektor
- prezes :)
Innymi słowy przyjmowane jest założenie, że w wyniku rozwoju i awansów, programista z czasem będzie przejmował coraz większą odpowiedzialność za grupę, innych pracowników i warstwę biznesową. A przecież niekoniecznie każdy chce i ma predyspozycje by się rozwijać w tym kierunku.
Pytania i wątpliwości:
1. Czy ten model w ogóle ma sens? Czy - biorąc pod uwagę typowe cechy programistów - mają oni zwykle szanse być dobrymi menedżerami?
2. Z jakimi inny modelami się spotkaliście w swoich firmach (bądź jakie uważacie za sensowne)?
3. Czy można planować rozwój bardziej związny z warstwą techniczną i zachować nadal przewagę konkurencyjną przed "młodymi wilkami"?
Pozdr.
Marek
31/03/2007,
Marek Rafałowicz
1.
Moim zdaniem nie ma.
Jedni są świetnymi inżynierami, ale nie nadają się do zarządzania, bo nie czują ,,blusa''. Co zazwyczaj widać z daleka po sposobie komunikacji z ,,nie-inżynierami'' :).
Inni najlepszymi programistami nie są, ale mają techniczny ,,background'', co daje nadzieję, ze zespół ceniący sobie kompetencje łatwiej go zaakceptuje jako przełożonego, niż kogoś kto ,,backgroundu'' nie ma.
2.
W jednej firmie nie było ,,średniego'' stopnia zarządzania (team leader//project manager), a dyrektor produkcji przyszedł z zewnątrz i autorytetu wśród zespołu nie miał (między innymi z tego powodu).
W obecnej pojawił się średni stopień zarządzania, gdy zaistniała taka potrzeba. Team leaderzy zostali wyłonieni w konkursie, co wydaje się być o wiele sensowniejszą metodą, niż wskazanie ich palcem i powierzenie nowych obowiązków.
Wierzę, że awans wewnętrzny, gdy tylko jest możliwy, bazujący na kompetencji i woli awansowanego jest najlepszym wyjściem.
Dzięki temu awansowany może liczyć na autorytet zespołu, a członkowie zespołu na awans i zwiększenie odpowiedzialności, jeżeli mają taką potrzebę.
3.
Moim zdaniem *zdecydowanie tak*.
W naszej branży liczy się doświadczenie i praktyka.
,,Młode wilki'' tego nie mają. Może wiedzą jak tworzyć aplikacje w RoR (czy co tam jest na topie), ale że obliczeń walutowych nie robi się na typach zmiennoprzecinkowych już nie.
Moim zdaniem nie ma.
Jedni są świetnymi inżynierami, ale nie nadają się do zarządzania, bo nie czują ,,blusa''. Co zazwyczaj widać z daleka po sposobie komunikacji z ,,nie-inżynierami'' :).
Inni najlepszymi programistami nie są, ale mają techniczny ,,background'', co daje nadzieję, ze zespół ceniący sobie kompetencje łatwiej go zaakceptuje jako przełożonego, niż kogoś kto ,,backgroundu'' nie ma.
2.
W jednej firmie nie było ,,średniego'' stopnia zarządzania (team leader//project manager), a dyrektor produkcji przyszedł z zewnątrz i autorytetu wśród zespołu nie miał (między innymi z tego powodu).
W obecnej pojawił się średni stopień zarządzania, gdy zaistniała taka potrzeba. Team leaderzy zostali wyłonieni w konkursie, co wydaje się być o wiele sensowniejszą metodą, niż wskazanie ich palcem i powierzenie nowych obowiązków.
Wierzę, że awans wewnętrzny, gdy tylko jest możliwy, bazujący na kompetencji i woli awansowanego jest najlepszym wyjściem.
Dzięki temu awansowany może liczyć na autorytet zespołu, a członkowie zespołu na awans i zwiększenie odpowiedzialności, jeżeli mają taką potrzebę.
3.
Moim zdaniem *zdecydowanie tak*.
W naszej branży liczy się doświadczenie i praktyka.
,,Młode wilki'' tego nie mają. Może wiedzą jak tworzyć aplikacje w RoR (czy co tam jest na topie), ale że obliczeń walutowych nie robi się na typach zmiennoprzecinkowych już nie.
03/04/2007,
Grzegorz
Akurat ostatnio robiłem prezentację na temat ścieżek rozwoju kariery dla developerów i przy okazji przeprowadziłem małą ankietę wśród słuchaczy (pytałem jaką rolę pełnisz obecnie i jaką chciałbyś pełnić za 5 lat). Trochę więcej o jej wynika można przeczytać na moim blogu.
W skrócie:
- Zaskakująco (dla mnie) mało programistów chce iść w ścieżkę managerską, czyli tą którą narysowałeś.
- Architektura/projektowanie to evergreen. To akurat mnie nie dziwi - ta rola jest postrzegana jako "lepsza" i ciekawsza niż programowanie, a jednocześnie nie wymaga silnych zdolności managerskich.
- Programiści myślą o własnych biznesach, co jest generalnie wywróceniem tradycyjnych ścieżek kariery do góry nogami.
Gdybym miał ogólnie jeszcze dodać coś do zaproponowanej przez Marka ścieżki to uważam ją za dość duże uproszczenie. Po prostu opcji jest tak naprawdę mnóstwo i wg mnie w planowaniu własnej kariery należy się raczej skupić na ogólnym kierunku i rozwoju i najbliższym stopniu który nas tam zaprowadzi. Project manager (w sensie prowadzenia projektów dla klientów) i szef zespołu developerskiego to dla mnie dwie bardzo różne pozycje wymagające różnych predyspozycji.
A co do pytań:
1. Nie istnieje coś takiego jak typowe cechy programistów :) Programiści są bardzo różni, co zresztą można powiedzieć o każdym zawodzie. Jedni będą mieli predyspozycje do managerki, inni nie. Zresztą dlatego rysowanie uniwersalnych ścieżek kariery dla programistów moim zdaniem mija się z celem.
2. Z bardzo licznymi. Najlepszy jest taki który pozwala ludziom w miarę elastycznie wybierać kierunki rozwoju. Przykładowych, bardzo ciekawych, ścieżek rozwoju mógłbym podać bardzo dużo. Handlowiec, lead tester, product manager (czyli stanowisko w zasadzie konsultingowe)...
3. Oczywiście. To u nas ukuł się mit tego że przed 30 trzeba uciec od developerki bo przyjdą studenci i zadepczą. Rynek na devów z dużym kilkunastoletnim lub nawet dłuższym doświadczeniem jest dość duży i będzie rósł. Doświadczenie w realizacji różnych projektów, różne architektury systemów, różne wymagania wydajnościowe, niezawodnościowe, wreszcie "czucie" różnych technologii - tego wszystkiego nabywa się przez lata. Ucząc się na (najczęściej swoich) błędach. Ale do tego też oczywiście trzeba mieć predyspozycje.
W skrócie:
- Zaskakująco (dla mnie) mało programistów chce iść w ścieżkę managerską, czyli tą którą narysowałeś.
- Architektura/projektowanie to evergreen. To akurat mnie nie dziwi - ta rola jest postrzegana jako "lepsza" i ciekawsza niż programowanie, a jednocześnie nie wymaga silnych zdolności managerskich.
- Programiści myślą o własnych biznesach, co jest generalnie wywróceniem tradycyjnych ścieżek kariery do góry nogami.
Gdybym miał ogólnie jeszcze dodać coś do zaproponowanej przez Marka ścieżki to uważam ją za dość duże uproszczenie. Po prostu opcji jest tak naprawdę mnóstwo i wg mnie w planowaniu własnej kariery należy się raczej skupić na ogólnym kierunku i rozwoju i najbliższym stopniu który nas tam zaprowadzi. Project manager (w sensie prowadzenia projektów dla klientów) i szef zespołu developerskiego to dla mnie dwie bardzo różne pozycje wymagające różnych predyspozycji.
A co do pytań:
1. Nie istnieje coś takiego jak typowe cechy programistów :) Programiści są bardzo różni, co zresztą można powiedzieć o każdym zawodzie. Jedni będą mieli predyspozycje do managerki, inni nie. Zresztą dlatego rysowanie uniwersalnych ścieżek kariery dla programistów moim zdaniem mija się z celem.
2. Z bardzo licznymi. Najlepszy jest taki który pozwala ludziom w miarę elastycznie wybierać kierunki rozwoju. Przykładowych, bardzo ciekawych, ścieżek rozwoju mógłbym podać bardzo dużo. Handlowiec, lead tester, product manager (czyli stanowisko w zasadzie konsultingowe)...
3. Oczywiście. To u nas ukuł się mit tego że przed 30 trzeba uciec od developerki bo przyjdą studenci i zadepczą. Rynek na devów z dużym kilkunastoletnim lub nawet dłuższym doświadczeniem jest dość duży i będzie rósł. Doświadczenie w realizacji różnych projektów, różne architektury systemów, różne wymagania wydajnościowe, niezawodnościowe, wreszcie "czucie" różnych technologii - tego wszystkiego nabywa się przez lata. Ucząc się na (najczęściej swoich) błędach. Ale do tego też oczywiście trzeba mieć predyspozycje.
20/04/2007,
Paweł Brodziński
No właśnie, ciekawi mnie ten temat. W moim przypadku doszedłem do wniosku że dev nie ma żadnej przyszłości. Przyjdą lepsi, mi się już powoli nie chce... co robić Waszym zdaniem? Hodowla ogórków?
11/10/2008,
l0co
A jak w przypadku zmiany pozycji z "programisty" na "TeamLeadera" zmienia się formalna umowa o pracę ? Czy zapis w umowie o pracę przewiduje stanowisko "programista - Team leader" itd... Czy w związku z tym zakres obowiązków z "programowanie,dokumentowanie itd..." ulega zmianie. Czy team-leader bierze na siebie dodatkową odpowiedzialnośc ? No i w końcu czy przejście pomiędzy tymi pozycjami powinno wiązac sie z dyskusją nad warunkami finansowymi ?
14/10/2008,
Jacek
