Szablon drabiny kariery

Szablon drabiny kariery programisty

Pięć poziomów od Junior Developera do Principal Engineera i sześć kompetencji – od dostarczania kodu po rozwój zespołu.

Plan bezpłatny · Bez karty kredytowej

Ta drabina kariery powstała z myślą o firmach produktowych liczących mniej więcej od 20 do 200 osób: programiści dostarczają funkcje od początku do końca, zespoły są małe, a nikt w HR nie projektuje architektury stanowisk. Opisuje pięć poziomów – od osoby na początku kariery po kogoś, kto wyznacza kierunek techniczny całej firmy. Najwyższy poziom, Principal Engineer, jest poziomem eksperckim; zarządzanie programistami opisuje osobna drabina kariery engineering managera.

Każdy poziom określa to, co dana osoba robi, a nie lata doświadczenia. Czytaj wiersz matrycy kompetencji od lewej do prawej, aby zobaczyć, jak rośnie jedno oczekiwanie; czytaj sekcję poziomu, aby zobaczyć naraz wszystko, czego się na nim oczekuje. Wykorzystaj ją, by wyjaśnić, co oznacza kolejny poziom, uporządkować samoocenę i check-iny oraz sprawić, by wnioski o awans dało się porównać między zespołami.

Traktuj ją jako punkt wyjścia. Dopasuj nazwy poziomów do stanowisk w swojej firmie, połącz lub usuń kompetencje, które do niej nie pasują, i przepisz oczekiwania własnymi słowami, zanim opublikujesz drabinę zespołowi.

Poziomy w skrócie

Junior Developer
Poznaje kod i realizuje dobrze zdefiniowane zadania pod okiem bardziej doświadczonych osób.
Zakres
Pojedyncze zadania w jednym obszarze produktu, zwykle rozpisane przez kogoś bardziej doświadczonego.
Mid Developer
Samodzielnie dostarcza funkcje i jest solidnym, niezawodnym członkiem zespołu.
Zakres
Małe i średnie funkcje w obszarze jednego zespołu – od krótkiej notatki projektowej po produkcję.
Senior Developer
Prowadzi większe przedsięwzięcia i podnosi poprzeczkę całemu zespołowi.
Zakres
Projekty obejmujące kilka serwisów lub kilka osób oraz decyzje techniczne jednego zespołu.
Staff Engineer
Rozwiązuje problemy wykraczające poza granice zespołów i wpływa na decyzje techniczne poza własnym zespołem.
Zakres
Kilka zespołów lub cały obszar produktu, w tym problemy, których nie jest właścicielem żaden zespół.
Principal Engineer
Wyznacza kierunek techniczny firmy i odpowiada za jej długoterminową kondycję techniczną.
Zakres
Cała organizacja inżynieryjna i strategia techniczna firmy na najbliższe kilka lat.

Matryca kompetencji

Każdy wiersz to kompetencja, a każda kolumna – poziom. Czytaj wiersz od lewej do prawej, aby zobaczyć, jak rosną oczekiwania.

Co oznacza każda kompetencja

Dostarczanie oprogramowania: Przekładanie wymagań na działające, łatwe w utrzymaniu oprogramowanie i dostarczanie go użytkownikom.
Projektowanie systemów: Dobór struktur, interfejsów i kompromisów, które wytrzymają rozwój produktu.
Jakość i niezawodność: Dbanie o to, by produkt działał poprawnie, był obserwowalny i dostępny, oraz wyciąganie wniosków z awarii.
Współpraca i komunikacja: Skuteczna współpraca z innymi programistami, produktem, designem i resztą firmy.
Odpowiedzialność i wpływ na produkt: Rozumienie, dlaczego praca ma znaczenie, i branie odpowiedzialności za rezultaty, a nie tylko za zadania.
Mentoring i rozwój zespołu: Pomaganie innym w rozwoju i budowanie zespołu silniejszego niż którakolwiek osoba w nim.

Programista: oczekiwania według kompetencji i poziomu
Kompetencja	Junior Developer	Mid Developer	Senior Developer	Staff Engineer	Principal Engineer
Dostarczanie oprogramowania	Realizuje dobrze określone zadania, pisząc czytelny kod i testy, prosi o pomoc po kilku godzinach utknięcia, a nie po kilku dniach, i uwzględnia uwagi z code review przed scaleniem zmian.	Prowadzi funkcję od krótkiej notatki projektowej do produkcji bez prowadzenia za rękę, dzieli ją na pull requesty łatwe do przejrzenia i realistycznie szacuje znaną sobie pracę.	Dostarcza projekty obejmujące kilka serwisów lub kilka osób, układa kolejność prac tak, by coś użytecznego trafiło do użytkowników wcześnie, i usuwa ryzyka, zanim zablokują zespół.	Odblokowuje dostarczanie między zespołami: rozplątuje wspólne zależności, buduje narzędzia lub przeprowadza migracje potrzebne kilku zespołom i pilnuje, by projekty wielozespołowe szły zgodnie z planem.	Kształtuje sposób, w jaki cała organizacja dostarcza oprogramowanie – proces wydań, wybór platform, narzędzia do budowania i wdrażania – tak by każdy zespół dostarczał szybciej i bezpieczniej.
Projektowanie systemów	Trzyma się wzorców istniejących w kodzie i potrafi wyjaśnić, dlaczego zmieniany przez siebie kod ma taką, a nie inną strukturę.	Projektuje komponenty w ramach istniejącego serwisu, pisze krótką notatkę projektową przy nietrywialnych zmianach i przed wyborem porównuje co najmniej dwie opcje.	Prowadzi projektowanie funkcji obejmujących kilka serwisów, spisuje kompromisy do przeglądu przez innych i konstruktywnie recenzuje projekty innych programistów.	Definiuje architekturę ponad granicami zespołów – wspólne modele danych, kontrakty między serwisami, decyzje „budować czy kupić” – i przewiduje, jak system musi się zmienić w ciągu najbliższego roku lub dwóch.	Odpowiada za strategię techniczną firmy: na jakie technologie postawić, które wycofać i jak architektura ma ewoluować razem z biznesem przez kilka lat.
Jakość i niezawodność	Pisze testy do swoich zmian, sprawdza swoją pracę przed wydaniem i naprawia błędy w kodzie, który zmieniał.	Dodaje monitoring i alerty do budowanych przez siebie funkcji, bierze udział w dyżurach on-call i obsługuje rutynowe incydenty według runbooka.	Prowadzi reagowanie na incydenty w systemach zespołu, pisze post-mortemy bez szukania winnych i dopilnowuje, by działania naprawcze faktycznie zostały wykonane.	Wychwytuje ryzyka dla niezawodności i bezpieczeństwa obejmujące wiele systemów, ustala standardy, takie jak strategia testów i cele poziomu usług (SLO), i prowadzi naprawy w wielu zespołach.	Definiuje, co niezawodność, bezpieczeństwo i jakość oznaczają dla firmy, równoważy je z tempem razem z kadrą kierowniczą i jest ostatnim punktem eskalacji przy najtrudniejszych incydentach.
Współpraca i komunikacja	Otwarcie informuje o postępach i blokerach oraz zadaje jasne pytania, gdy wymaganie jest niejasne.	Współpracuje bezpośrednio z produktem i designem przy doprecyzowaniu wymagań, wyjaśnia ograniczenia techniczne prostym językiem i pisze opisy pull requestów, w których recenzenci łatwo się odnajdują.	Reprezentuje zespół w planowaniu, negocjuje z produktem zakres i kompromisy oraz pisze dokumenty zrozumiałe dla osób spoza działu inżynierii.	Jednoczy kilka zespołów i funkcji wokół planu technicznego, rozwiązuje spory między zespołami i wyjaśnia kierownictwu ryzyko techniczne.	Ma zaufany głos w decyzjach na poziomie firmy, przekłada strategię biznesową na kierunek techniczny i z powrotem, a w razie potrzeby reprezentuje inżynierię przed klientami, partnerami lub inwestorami.
Odpowiedzialność i wpływ na produkt	Rozumie cel swoich zadań, sprawdza, czy to, co trafiło na produkcję, działa dla użytkowników, i wraca do tematu, dopóki nie zacznie działać.	Opiekuje się funkcją po wdrożeniu: śledzi jej użycie i błędy, naprawia to, co nie działa, i proponuje usprawnienia na podstawie zebranych wniosków.	Odpowiada za cały obszar produktu od początku do końca, kwestionuje wymagania, które nie służą użytkownikom, i proponuje prace przybliżające zespół do jego celów.	Znajduje problemy o największej dźwigni w całym obszarze produktu – także te, których nie przejął żaden zespół – i dopilnowuje, by zostały rozwiązane.	Łączy inwestycje w inżynierię z wynikami firmy i argumentuje za dużymi zakładami lub przeciw nim na podstawie ich wpływu technicznego i biznesowego.
Mentoring i rozwój zespołu	Prosi o feedback i wprowadza go w życie, a zdobytą wiedzę spisuje, żeby kolejnej nowej osobie łatwiej było zacząć.	Starannie robi code review, pomaga wdrażać nowe osoby w zespole i pracuje w parze z juniorami nad nieznanymi im częściami kodu.	Świadomie mentoruje jednego lub dwóch programistów, daje feedback, który pomaga im osiągnąć kolejny poziom, i bierze udział w rozmowach rekrutacyjnych.	Rozwija seniorów w wielu zespołach, kształtuje proces rekrutacji i praktyki inżynierskie, a inni sami przychodzą po jego radę.	Buduje kulturę techniczną firmy – sposób podejmowania decyzji i dzielenia się wiedzą – i rozwija kolejne pokolenie staff engineerów.

Przewiń tabelę w bok, aby zobaczyć wszystkie poziomy.

Pobierz jako CSV Otwiera się w Excelu, Arkuszach Google lub Numbers.

Junior Developer: czego się oczekuje

Poznaje kod i realizuje dobrze zdefiniowane zadania pod okiem bardziej doświadczonych osób. Pojedyncze zadania w jednym obszarze produktu, zwykle rozpisane przez kogoś bardziej doświadczonego.

Dostarczanie oprogramowania: Realizuje dobrze określone zadania, pisząc czytelny kod i testy, prosi o pomoc po kilku godzinach utknięcia, a nie po kilku dniach, i uwzględnia uwagi z code review przed scaleniem zmian.
Projektowanie systemów: Trzyma się wzorców istniejących w kodzie i potrafi wyjaśnić, dlaczego zmieniany przez siebie kod ma taką, a nie inną strukturę.
Jakość i niezawodność: Pisze testy do swoich zmian, sprawdza swoją pracę przed wydaniem i naprawia błędy w kodzie, który zmieniał.
Współpraca i komunikacja: Otwarcie informuje o postępach i blokerach oraz zadaje jasne pytania, gdy wymaganie jest niejasne.
Odpowiedzialność i wpływ na produkt: Rozumie cel swoich zadań, sprawdza, czy to, co trafiło na produkcję, działa dla użytkowników, i wraca do tematu, dopóki nie zacznie działać.
Mentoring i rozwój zespołu: Prosi o feedback i wprowadza go w życie, a zdobytą wiedzę spisuje, żeby kolejnej nowej osobie łatwiej było zacząć.

Mid Developer: czego się oczekuje

Samodzielnie dostarcza funkcje i jest solidnym, niezawodnym członkiem zespołu. Małe i średnie funkcje w obszarze jednego zespołu – od krótkiej notatki projektowej po produkcję.

Dostarczanie oprogramowania: Prowadzi funkcję od krótkiej notatki projektowej do produkcji bez prowadzenia za rękę, dzieli ją na pull requesty łatwe do przejrzenia i realistycznie szacuje znaną sobie pracę.
Projektowanie systemów: Projektuje komponenty w ramach istniejącego serwisu, pisze krótką notatkę projektową przy nietrywialnych zmianach i przed wyborem porównuje co najmniej dwie opcje.
Jakość i niezawodność: Dodaje monitoring i alerty do budowanych przez siebie funkcji, bierze udział w dyżurach on-call i obsługuje rutynowe incydenty według runbooka.
Współpraca i komunikacja: Współpracuje bezpośrednio z produktem i designem przy doprecyzowaniu wymagań, wyjaśnia ograniczenia techniczne prostym językiem i pisze opisy pull requestów, w których recenzenci łatwo się odnajdują.
Odpowiedzialność i wpływ na produkt: Opiekuje się funkcją po wdrożeniu: śledzi jej użycie i błędy, naprawia to, co nie działa, i proponuje usprawnienia na podstawie zebranych wniosków.
Mentoring i rozwój zespołu: Starannie robi code review, pomaga wdrażać nowe osoby w zespole i pracuje w parze z juniorami nad nieznanymi im częściami kodu.

Senior Developer: czego się oczekuje

Prowadzi większe przedsięwzięcia i podnosi poprzeczkę całemu zespołowi. Projekty obejmujące kilka serwisów lub kilka osób oraz decyzje techniczne jednego zespołu.

Dostarczanie oprogramowania: Dostarcza projekty obejmujące kilka serwisów lub kilka osób, układa kolejność prac tak, by coś użytecznego trafiło do użytkowników wcześnie, i usuwa ryzyka, zanim zablokują zespół.
Projektowanie systemów: Prowadzi projektowanie funkcji obejmujących kilka serwisów, spisuje kompromisy do przeglądu przez innych i konstruktywnie recenzuje projekty innych programistów.
Jakość i niezawodność: Prowadzi reagowanie na incydenty w systemach zespołu, pisze post-mortemy bez szukania winnych i dopilnowuje, by działania naprawcze faktycznie zostały wykonane.
Współpraca i komunikacja: Reprezentuje zespół w planowaniu, negocjuje z produktem zakres i kompromisy oraz pisze dokumenty zrozumiałe dla osób spoza działu inżynierii.
Odpowiedzialność i wpływ na produkt: Odpowiada za cały obszar produktu od początku do końca, kwestionuje wymagania, które nie służą użytkownikom, i proponuje prace przybliżające zespół do jego celów.
Mentoring i rozwój zespołu: Świadomie mentoruje jednego lub dwóch programistów, daje feedback, który pomaga im osiągnąć kolejny poziom, i bierze udział w rozmowach rekrutacyjnych.

Staff Engineer: czego się oczekuje

Rozwiązuje problemy wykraczające poza granice zespołów i wpływa na decyzje techniczne poza własnym zespołem. Kilka zespołów lub cały obszar produktu, w tym problemy, których nie jest właścicielem żaden zespół.

Dostarczanie oprogramowania: Odblokowuje dostarczanie między zespołami: rozplątuje wspólne zależności, buduje narzędzia lub przeprowadza migracje potrzebne kilku zespołom i pilnuje, by projekty wielozespołowe szły zgodnie z planem.
Projektowanie systemów: Definiuje architekturę ponad granicami zespołów – wspólne modele danych, kontrakty między serwisami, decyzje „budować czy kupić” – i przewiduje, jak system musi się zmienić w ciągu najbliższego roku lub dwóch.
Jakość i niezawodność: Wychwytuje ryzyka dla niezawodności i bezpieczeństwa obejmujące wiele systemów, ustala standardy, takie jak strategia testów i cele poziomu usług (SLO), i prowadzi naprawy w wielu zespołach.
Współpraca i komunikacja: Jednoczy kilka zespołów i funkcji wokół planu technicznego, rozwiązuje spory między zespołami i wyjaśnia kierownictwu ryzyko techniczne.
Odpowiedzialność i wpływ na produkt: Znajduje problemy o największej dźwigni w całym obszarze produktu – także te, których nie przejął żaden zespół – i dopilnowuje, by zostały rozwiązane.
Mentoring i rozwój zespołu: Rozwija seniorów w wielu zespołach, kształtuje proces rekrutacji i praktyki inżynierskie, a inni sami przychodzą po jego radę.

Principal Engineer: czego się oczekuje

Wyznacza kierunek techniczny firmy i odpowiada za jej długoterminową kondycję techniczną. Cała organizacja inżynieryjna i strategia techniczna firmy na najbliższe kilka lat.

Dostarczanie oprogramowania: Kształtuje sposób, w jaki cała organizacja dostarcza oprogramowanie – proces wydań, wybór platform, narzędzia do budowania i wdrażania – tak by każdy zespół dostarczał szybciej i bezpieczniej.
Projektowanie systemów: Odpowiada za strategię techniczną firmy: na jakie technologie postawić, które wycofać i jak architektura ma ewoluować razem z biznesem przez kilka lat.
Jakość i niezawodność: Definiuje, co niezawodność, bezpieczeństwo i jakość oznaczają dla firmy, równoważy je z tempem razem z kadrą kierowniczą i jest ostatnim punktem eskalacji przy najtrudniejszych incydentach.
Współpraca i komunikacja: Ma zaufany głos w decyzjach na poziomie firmy, przekłada strategię biznesową na kierunek techniczny i z powrotem, a w razie potrzeby reprezentuje inżynierię przed klientami, partnerami lub inwestorami.
Odpowiedzialność i wpływ na produkt: Łączy inwestycje w inżynierię z wynikami firmy i argumentuje za dużymi zakładami lub przeciw nim na podstawie ich wpływu technicznego i biznesowego.
Mentoring i rozwój zespołu: Buduje kulturę techniczną firmy – sposób podejmowania decyzji i dzielenia się wiedzą – i rozwija kolejne pokolenie staff engineerów.

Jak dopasować tę drabinę

Dopasuj poziomy do swoich stanowisk
Jeśli stanowiska w twojej firmie to Developer I, II i III, zmień nazwy poziomów, ale zostaw po jednym poziomie na każdy realny skok zakresu. Większość firm z mniej niż 100 programistami nie potrzebuje jeszcze poziomu Principal: pomiń go, dopóki ktoś faktycznie nie zacznie wykonywać tej pracy.
Ogranicz się do pięciu–siedmiu kompetencji
Gdy jest ich więcej niż siedem, nikt ich nie czyta; gdy mniej niż cztery, bardzo różne osoby wyglądają tak samo. Połącz kompetencje, które zawsze oceniasz razem, a nową dodawaj tylko wtedy, gdy zmieniłaby realną decyzję.
Opisz oczekiwania tym, co widać
Przy każdej komórce zapytaj, czy menedżer mógłby wskazać przykład z ostatnich sześciu miesięcy. Słowa w rodzaju „mocny” czy „głęboki” zastąp tym, co dana osoba faktycznie robi, np. „prowadzi reagowanie na incydenty w serwisach zespołu”.
Przetestuj ją na prawdziwych ludziach przed publikacją
Poproś dwóch lub trzech menedżerów, by przypisali członków swoich zespołów do poziomów w wersji roboczej. Tam, gdzie się nie zgadzają, sformułowanie jest niejednoznaczne: popraw je, opublikuj drabinę i umów się na ponowny przegląd za sześć miesięcy.

FAQ

Pytania o tę drabinę

Ile poziomów powinna mieć drabina kariery programisty?

W firmie liczącej 20–200 osób typowo od czterech do sześciu. Przy mniejszej liczbie awanse są rzadkie i ogromne; przy większej różnica między sąsiednimi poziomami jest zbyt mała, by dało się ją opisać. Ten szablon ma pięć: Junior Developer, Mid Developer, Senior, Staff i Principal.

Czy programista musi zostać menedżerem, żeby się rozwijać?

Nie. To drabina ścieżki eksperckiej: Staff i Principal Engineerowie poszerzają zakres i wpływ bez zarządzania ludźmi. Używaj jej razem z drabiną kariery engineering managera, aby przejście do zarządzania było zmianą ścieżki, a nie awansem.

Jak korzystać z drabiny kariery programisty przy decyzjach o awansie?

Awansuj osoby, które już stale pracują na kolejnym poziomie, a nie te, które być może by mogły. Poproś daną osobę i jej menedżera o zebranie konkretnych przykładów dla każdej kompetencji docelowego poziomu i porównuj każdy przypadek z tą samą matrycą, aby decyzje były spójne między zespołami.

Jak drabina kariery programisty wpisuje się w check-iny i spotkania 1:1?

Traktuj ją jako agendę regularnych check-inów: osoba ocenia się względem swojego obecnego poziomu, menedżer robi to samo, a różnice między tymi ocenami zamieniają się w kilka konkretnych działań rozwojowych na najbliższe miesiące.

Jak często aktualizować drabinę kariery programisty?

Przeglądaj ją raz lub dwa razy w roku oraz zawsze, gdy firma zmienia kształt – na przykład gdy tworzysz zespół platformowy albo zaczynasz zatrudniać Staff Engineerów. Przepisz komórkę, gdy oceny wciąż się na niej potykają.

Zbuduj tę drabinę kariery w LadderKit – za darmo

Ustaw jej poziomy i umiejętności dla swojego zespołu, oceniaj według nich ludzi w check-inach i zachowaj spójność decyzji o awansach.

Zacznij za darmo Zobacz wersję demo Bez rejestracji