Predložak karijerne ljestvice

Predložak karijerne ljestvice za softverske inženjere

Pet razina od juniora do principala i šest kompetencija, od isporuke koda do razvoja tima.

Besplatni paket · Kreditna kartica nije potrebna

Ova karijerna ljestvica napisana je za produktne tvrtke s otprilike 20 do 200 ljudi: inženjeri sami vode funkcionalnosti od početka do kraja, timovi su mali, a nitko u HR timu ne izrađuje arhitekturu radnih mjesta. Opisuje pet razina, od osobe na početku karijere do osobe koja oblikuje tehnički smjer cijele tvrtke. Najviša razina, Principal inženjer, stručna je razina; vođenje inženjera opisuje zasebna ljestvica za Engineering Managere.

Svaka je razina definirana onim što osoba radi, a ne godinama iskustva. Pročitajte redak matrice kompetencija slijeva nadesno da vidite kako jedno očekivanje raste; pročitajte odjeljak jedne razine da odjednom vidite sve što se na njoj očekuje. Upotrijebite je da objasnite što znači sljedeća razina, da strukturirate samoprocjene i check-ine te da prijedloge za promaknuće učinite usporedivima među timovima.

Shvatite je kao polazište. Preimenujte razine prema svojim nazivima radnih mjesta, spojite ili izbacite kompetencije koje ne odgovaraju vašoj tvrtki i preformulirajte očekivanja vlastitim riječima prije nego što ljestvicu objavite timu.

Razine ukratko

Junior inženjer
Upoznaje kodnu bazu i uz vodstvo isporučuje jasno definirane zadatke.
Opseg
Pojedinačni zadaci u jednom dijelu proizvoda, koje obično razlomi netko iskusniji.
Medior inženjer
Samostalno isporučuje funkcionalnosti i pouzdan je član tima.
Opseg
Male i srednje funkcionalnosti unutar područja jednog tima, od kratke bilješke o dizajnu do produkcije.
Senior inženjer
Vodi veće cjeline posla i podiže standard tima oko sebe.
Opseg
Projekti koji obuhvaćaju više servisa ili više ljudi te tehničke odluke jednog tima.
Staff inženjer
Rješava probleme koji prelaze granice timova i usmjerava tehničke odluke izvan jednog tima.
Opseg
Više timova ili cijelo područje proizvoda, uključujući probleme koje nijedan tim ne posjeduje.
Principal inženjer
Određuje tehnički smjer tvrtke i odgovara za njezino dugoročno tehničko zdravlje.
Opseg
Cijela inženjerska organizacija i tehnička strategija tvrtke za sljedećih nekoliko godina.

Matrica kompetencija

Svaki redak je kompetencija, a svaki stupac razina. Čitajte redak slijeva nadesno da biste vidjeli kako očekivanja rastu.

Što znači svaka kompetencija

Razvoj i isporuka: Pretvaranje zahtjeva u ispravan softver koji se lako održava i njegova isporuka korisnicima.
Dizajn sustava: Odabir struktura, sučelja i kompromisa koji će izdržati rast proizvoda.
Kvaliteta i pouzdanost: Održavanje proizvoda ispravnim, vidljivim za nadzor i dostupnim te učenje iz kvarova.
Suradnja i komunikacija: Učinkovit rad s drugim inženjerima, produktom, dizajnom i ostatkom tvrtke.
Odgovornost i utjecaj na proizvod: Razumijevanje zašto je posao važan i preuzimanje odgovornosti za ishode, a ne samo za zadatke.
Mentorstvo i razvoj tima: Pomaganje drugima da napreduju i jačanje tima tako da bude snažniji od bilo kojeg pojedinca u njemu.

Softverski inženjer: očekivanja po kompetenciji i razini
Kompetencija	Junior inženjer	Medior inženjer	Senior inženjer	Staff inženjer	Principal inženjer
Razvoj i isporuka	Završava jasno omeđene zadatke čitljivim kodom i testovima, traži pomoć kad zapne nekoliko sati, a ne nekoliko dana, i prije spajanja rješava komentare iz pregleda koda.	Bez stalnog nadzora vodi funkcionalnost od kratke bilješke o dizajnu do produkcije, dijeli je na pull requestove koje je lako pregledati i daje realne procjene za poznati posao.	Isporučuje projekte koji obuhvaćaju više servisa ili suradnika, slaže redoslijed posla tako da nešto korisno izađe rano i uklanja rizike prije nego što zaustave tim.	Deblokira isporuku među timovima: razmrsuje zajedničke ovisnosti, gradi alate ili provodi migracije koje treba više timova i drži projekte više timova na pravom putu.	Oblikuje način na koji cijela organizacija isporučuje — prakse izdavanja, izbor platformi, alate za build i deploy — tako da svaki tim isporučuje brže i sigurnije.
Dizajn sustava	Slijedi postojeće obrasce u kodnoj bazi i zna objasniti zašto je kod koji je mijenjao strukturiran upravo tako.	Dizajnira komponente unutar postojećeg servisa, za netrivijalne promjene piše kratku bilješku o dizajnu i prije odluke uspoređuje barem dvije mogućnosti.	Vodi dizajn funkcionalnosti koje obuhvaćaju više servisa, zapisuje kompromise kako bi ih drugi mogli pregledati i konstruktivno pregledava dizajne drugih inženjera.	Definira arhitekturu preko granica timova — zajedničke podatkovne modele, ugovore između servisa, odluke o tome graditi ili kupiti — i predviđa kako se sustav mora mijenjati u sljedećih godinu-dvije.	Odgovara za tehničku strategiju tvrtke: u koje se tehnologije kladiti, koje ugasiti i kako bi se arhitektura trebala razvijati zajedno s poslovanjem kroz nekoliko godina.
Kvaliteta i pouzdanost	Piše testove za vlastite promjene, provjerava svoj rad prije izdanja i popravlja greške u kodu koji je dirao.	Dodaje monitoring i upozorenja za funkcionalnosti koje gradi, sudjeluje u rasporedu dežurstava i uz runbook rješava rutinske incidente.	Vodi odgovor na incidente za sustave svog tima, piše post-mortem analize bez traženja krivca i brine se da se dogovorene popravne mjere stvarno provedu.	Pronalazi rizike pouzdanosti i sigurnosti koji obuhvaćaju više sustava, postavlja standarde poput strategije testiranja i ciljeva razine usluge (SLO) te pokreće popravke u više timova.	Definira što pouzdanost, sigurnost i kvaliteta znače za tvrtku, s vodstvom ih odvaguje naspram brzine i posljednja je točka eskalacije za najteže incidente.
Suradnja i komunikacija	Otvoreno dijeli napredak i prepreke te postavlja jasna pitanja kad zahtjev nije jasan.	Radi izravno s produktom i dizajnom na razjašnjavanju zahtjeva, jednostavnim jezikom objašnjava tehnička ograničenja i piše opise pull requestova koje recenzenti mogu pratiti.	Predstavlja tim u planiranju, s produktom pregovara o opsegu i kompromisima te piše dokumente koje razumiju i ljudi izvan inženjeringa.	Usklađuje više timova i funkcija oko tehničkog plana, rješava nesuglasice između timova i vodstvu objašnjava tehničke rizike.	Pouzdan je glas u odlukama na razini tvrtke, prevodi poslovnu strategiju u tehnički smjer i obratno te prema potrebi predstavlja inženjering pred klijentima, partnerima ili investitorima.
Odgovornost i utjecaj na proizvod	Razumije svrhu svojih zadataka, provjerava radi li ono što je isporučio za korisnike i ne odustaje dok ne proradi.	Brine se o funkcionalnosti i nakon lansiranja: prati njezino korištenje i greške, popravlja ono što pođe po zlu i predlaže poboljšanja na temelju naučenog.	Odgovara za jedno područje proizvoda od početka do kraja, propituje zahtjeve koji ne služe korisnicima i predlaže posao koji pomiče ciljeve tima.	U cijelom području proizvoda pronalazi probleme s najvećim učinkom — uključujući one koje nijedan tim nije preuzeo — i brine se da budu riješeni.	Povezuje ulaganja u inženjering s rezultatima tvrtke i zalaže se za velike oklade ili protiv njih na temelju njihova tehničkog i poslovnog učinka.
Mentorstvo i razvoj tima	Traži povratne informacije i postupa prema njima te zapisuje što je naučio kako bi sljedeći novi kolega lakše krenuo.	Pažljivo pregledava kod, pomaže u uvođenju novih članova tima i radi u paru s junior inženjerima na nepoznatim dijelovima koda.	Namjerno mentorira jednog ili dva inženjera, daje povratne informacije koje im pomažu doći do sljedeće razine i sudjeluje u intervjuima za zapošljavanje.	Razvija senior inženjere u više timova, oblikuje proces intervjua i inženjerske prakse te je osoba kojoj se drugi obraćaju za savjet.	Gradi tehničku kulturu tvrtke — kako se donose odluke i kako se dijeli znanje — i razvija sljedeću generaciju staff inženjera.

Pomaknite tablicu vodoravno da biste vidjeli sve razine.

Preuzmi kao CSV Otvara se u Excelu, Google tablicama ili Numbersu.

Junior inženjer: što se očekuje

Upoznaje kodnu bazu i uz vodstvo isporučuje jasno definirane zadatke. Pojedinačni zadaci u jednom dijelu proizvoda, koje obično razlomi netko iskusniji.

Razvoj i isporuka: Završava jasno omeđene zadatke čitljivim kodom i testovima, traži pomoć kad zapne nekoliko sati, a ne nekoliko dana, i prije spajanja rješava komentare iz pregleda koda.
Dizajn sustava: Slijedi postojeće obrasce u kodnoj bazi i zna objasniti zašto je kod koji je mijenjao strukturiran upravo tako.
Kvaliteta i pouzdanost: Piše testove za vlastite promjene, provjerava svoj rad prije izdanja i popravlja greške u kodu koji je dirao.
Suradnja i komunikacija: Otvoreno dijeli napredak i prepreke te postavlja jasna pitanja kad zahtjev nije jasan.
Odgovornost i utjecaj na proizvod: Razumije svrhu svojih zadataka, provjerava radi li ono što je isporučio za korisnike i ne odustaje dok ne proradi.
Mentorstvo i razvoj tima: Traži povratne informacije i postupa prema njima te zapisuje što je naučio kako bi sljedeći novi kolega lakše krenuo.

Medior inženjer: što se očekuje

Samostalno isporučuje funkcionalnosti i pouzdan je član tima. Male i srednje funkcionalnosti unutar područja jednog tima, od kratke bilješke o dizajnu do produkcije.

Razvoj i isporuka: Bez stalnog nadzora vodi funkcionalnost od kratke bilješke o dizajnu do produkcije, dijeli je na pull requestove koje je lako pregledati i daje realne procjene za poznati posao.
Dizajn sustava: Dizajnira komponente unutar postojećeg servisa, za netrivijalne promjene piše kratku bilješku o dizajnu i prije odluke uspoređuje barem dvije mogućnosti.
Kvaliteta i pouzdanost: Dodaje monitoring i upozorenja za funkcionalnosti koje gradi, sudjeluje u rasporedu dežurstava i uz runbook rješava rutinske incidente.
Suradnja i komunikacija: Radi izravno s produktom i dizajnom na razjašnjavanju zahtjeva, jednostavnim jezikom objašnjava tehnička ograničenja i piše opise pull requestova koje recenzenti mogu pratiti.
Odgovornost i utjecaj na proizvod: Brine se o funkcionalnosti i nakon lansiranja: prati njezino korištenje i greške, popravlja ono što pođe po zlu i predlaže poboljšanja na temelju naučenog.
Mentorstvo i razvoj tima: Pažljivo pregledava kod, pomaže u uvođenju novih članova tima i radi u paru s junior inženjerima na nepoznatim dijelovima koda.

Senior inženjer: što se očekuje

Vodi veće cjeline posla i podiže standard tima oko sebe. Projekti koji obuhvaćaju više servisa ili više ljudi te tehničke odluke jednog tima.

Razvoj i isporuka: Isporučuje projekte koji obuhvaćaju više servisa ili suradnika, slaže redoslijed posla tako da nešto korisno izađe rano i uklanja rizike prije nego što zaustave tim.
Dizajn sustava: Vodi dizajn funkcionalnosti koje obuhvaćaju više servisa, zapisuje kompromise kako bi ih drugi mogli pregledati i konstruktivno pregledava dizajne drugih inženjera.
Kvaliteta i pouzdanost: Vodi odgovor na incidente za sustave svog tima, piše post-mortem analize bez traženja krivca i brine se da se dogovorene popravne mjere stvarno provedu.
Suradnja i komunikacija: Predstavlja tim u planiranju, s produktom pregovara o opsegu i kompromisima te piše dokumente koje razumiju i ljudi izvan inženjeringa.
Odgovornost i utjecaj na proizvod: Odgovara za jedno područje proizvoda od početka do kraja, propituje zahtjeve koji ne služe korisnicima i predlaže posao koji pomiče ciljeve tima.
Mentorstvo i razvoj tima: Namjerno mentorira jednog ili dva inženjera, daje povratne informacije koje im pomažu doći do sljedeće razine i sudjeluje u intervjuima za zapošljavanje.

Staff inženjer: što se očekuje

Rješava probleme koji prelaze granice timova i usmjerava tehničke odluke izvan jednog tima. Više timova ili cijelo područje proizvoda, uključujući probleme koje nijedan tim ne posjeduje.

Razvoj i isporuka: Deblokira isporuku među timovima: razmrsuje zajedničke ovisnosti, gradi alate ili provodi migracije koje treba više timova i drži projekte više timova na pravom putu.
Dizajn sustava: Definira arhitekturu preko granica timova — zajedničke podatkovne modele, ugovore između servisa, odluke o tome graditi ili kupiti — i predviđa kako se sustav mora mijenjati u sljedećih godinu-dvije.
Kvaliteta i pouzdanost: Pronalazi rizike pouzdanosti i sigurnosti koji obuhvaćaju više sustava, postavlja standarde poput strategije testiranja i ciljeva razine usluge (SLO) te pokreće popravke u više timova.
Suradnja i komunikacija: Usklađuje više timova i funkcija oko tehničkog plana, rješava nesuglasice između timova i vodstvu objašnjava tehničke rizike.
Odgovornost i utjecaj na proizvod: U cijelom području proizvoda pronalazi probleme s najvećim učinkom — uključujući one koje nijedan tim nije preuzeo — i brine se da budu riješeni.
Mentorstvo i razvoj tima: Razvija senior inženjere u više timova, oblikuje proces intervjua i inženjerske prakse te je osoba kojoj se drugi obraćaju za savjet.

Principal inženjer: što se očekuje

Određuje tehnički smjer tvrtke i odgovara za njezino dugoročno tehničko zdravlje. Cijela inženjerska organizacija i tehnička strategija tvrtke za sljedećih nekoliko godina.

Razvoj i isporuka: Oblikuje način na koji cijela organizacija isporučuje — prakse izdavanja, izbor platformi, alate za build i deploy — tako da svaki tim isporučuje brže i sigurnije.
Dizajn sustava: Odgovara za tehničku strategiju tvrtke: u koje se tehnologije kladiti, koje ugasiti i kako bi se arhitektura trebala razvijati zajedno s poslovanjem kroz nekoliko godina.
Kvaliteta i pouzdanost: Definira što pouzdanost, sigurnost i kvaliteta znače za tvrtku, s vodstvom ih odvaguje naspram brzine i posljednja je točka eskalacije za najteže incidente.
Suradnja i komunikacija: Pouzdan je glas u odlukama na razini tvrtke, prevodi poslovnu strategiju u tehnički smjer i obratno te prema potrebi predstavlja inženjering pred klijentima, partnerima ili investitorima.
Odgovornost i utjecaj na proizvod: Povezuje ulaganja u inženjering s rezultatima tvrtke i zalaže se za velike oklade ili protiv njih na temelju njihova tehničkog i poslovnog učinka.
Mentorstvo i razvoj tima: Gradi tehničku kulturu tvrtke — kako se donose odluke i kako se dijeli znanje — i razvija sljedeću generaciju staff inženjera.

Kako prilagoditi ovu ljestvicu

Uskladite razine sa svojim nazivima radnih mjesta
Ako su vaši nazivi Developer I, II i III, preimenujte razine, ali zadržite po jednu razinu za svaki stvarni korak u opsegu. Većini tvrtki s manje od 100 inženjera razina Principal još ne treba: izostavite je dok netko stvarno ne počne raditi taj posao.
Zadržite pet do sedam kompetencija
Kad ih je više od sedam, nitko ih ne čita; kad ih je manje od četiri, vrlo različiti ljudi izgledaju isto. Spojite kompetencije koje uvijek ocjenjujete zajedno, a novu dodajte samo ako bi promijenila stvarnu odluku.
Preformulirajte očekivanja u ono što se može vidjeti
Za svaku ćeliju zapitajte se bi li voditelj mogao pokazati primjer iz posljednjih šest mjeseci. Riječi poput „snažan“ ili „dubok“ zamijenite onim što osoba stvarno radi, npr. „vodi odgovor na incidente za servise tima“.
Isprobajte je na stvarnim ljudima prije objave
Zamolite dva ili tri voditelja da članove svog tima rasporede po nacrtu. Gdje god se ne slažu, formulacija je dvosmislena: popravite je, objavite ljestvicu i dogovorite novi pregled za šest mjeseci.

Česta pitanja

Pitanja o ovoj ljestvici

Koliko razina treba imati karijerna ljestvica softverskog inženjera?

Za tvrtku od 20 do 200 ljudi uobičajeno je četiri do šest. S manje razina promaknuća postaju rijetka i ogromna; s više je razlika između dviju razina premala da bi se opisala. Ovaj predložak koristi pet: Junior inženjer, Medior inženjer, Senior, Staff i Principal.

Moraju li inženjeri postati menadžeri da bi napredovali?

Ne. Ovo je ljestvica stručnog puta: staff i principal inženjeri rastu u opsegu i utjecaju bez vođenja ljudi. Koristite je uz ljestvicu za Engineering Managere, tako da prelazak u upravljanje bude promjena puta, a ne promaknuće.

Kako koristiti ljestvicu u odlukama o promaknuću?

Promaknite ljude koji već dosljedno rade na sljedećoj razini, a ne one koji bi mogli. Zamolite osobu i njezina voditelja da za svaku kompetenciju ciljne razine prikupe konkretne primjere i svaki slučaj usporedite s istom matricom kako bi odluke bile dosljedne među timovima.

Kako se ljestvica uklapa u check-ine i 1:1 razgovore?

Koristite je kao dnevni red redovitih check-ina: osoba se ocjenjuje prema svojoj trenutačnoj razini, voditelj čini isto, a razlike između tih dviju procjena postaju nekoliko konkretnih razvojnih aktivnosti za sljedeće mjesece.

Koliko često treba ažurirati ljestvicu?

Pregledajte je jednom ili dvaput godišnje i kad god tvrtka promijeni oblik — na primjer kad osnujete platformski tim ili počnete zapošljavati staff inženjere. Preformulirajte ćeliju kad god procjene stalno zapinju na njoj.

Izgradite ovu karijernu ljestvicu u LadderKitu — besplatno

Postavite njezine razine i vještine za svoj tim, procjenjujte ljude prema njima u check-inima i održite dosljednost odluka o promaknućima.

Započnite besplatno Pogledajte demo Bez registracije