Mal for karrierestige

Karrierestige for utviklere: mal

Fem nivåer fra Junior til Principal og seks kompetanser – fra å levere kode til å utvikle teamet.

Gratisplan · Ingen betalingskort nødvendig

Denne karrierestigen er skrevet for produktselskaper med omtrent 20–200 ansatte: utviklerne leverer funksjoner fra start til slutt, teamene er små, og ingen i HR sitter og lager en stillingsstruktur. Den beskriver fem nivåer, fra en som er i starten av karrieren, til en som former den tekniske retningen for hele selskapet. Det øverste nivået, Principal Engineer, er et spesialistnivå; ledelse av utviklere dekkes av en egen karrierestige for Engineering Managers.

Hvert nivå er definert ut fra hva personen gjør, ikke ut fra antall års erfaring. Les en rad i kompetansematrisen fra venstre mot høyre for å se hvordan én forventning vokser; les avsnittet om et nivå for å se alt som forventes på det nivået, samlet på ett sted. Bruk den til å forklare hva neste nivå innebærer, til å strukturere egenvurderinger og check-iner og til å gjøre forfremmelsesforslag sammenlignbare på tvers av team.

Se på den som et utgangspunkt. Gi nivåene de titlene dere bruker, slå sammen eller fjern kompetanser som ikke passer selskapet, og skriv om forventningene med egne ord før du publiserer karrierestigen for teamet.

Nivåene i korte trekk

Junior Engineer
Lærer seg kodebasen og leverer veldefinerte oppgaver med veiledning.
Omfang
Enkeltoppgaver i ett område av produktet, som regel brutt ned av noen med mer erfaring.
Engineer
Leverer funksjoner selvstendig og er et pålitelig medlem av teamet.
Omfang
Små og mellomstore funksjoner innenfor ett teams område, fra et kort designnotat til produksjon.
Senior Engineer
Leder større arbeidsoppgaver og løfter standarden i teamet rundt seg.
Omfang
Prosjekter som strekker seg over flere tjenester eller flere personer, og de tekniske beslutningene i ett team.
Staff Engineer
Løser problemer som går på tvers av team, og styrer tekniske beslutninger utover sitt eget team.
Omfang
Flere team eller et helt produktområde, inkludert problemer som ikke ett enkelt team eier.
Principal Engineer
Setter den tekniske retningen for selskapet og står ansvarlig for den langsiktige tekniske helsen.
Omfang
Hele utviklingsorganisasjonen og selskapets tekniske strategi for de neste årene.

Kompetansematrise

Hver rad er en kompetanse og hver kolonne et nivå. Les en rad fra venstre mot høyre for å se hvordan forventningen øker.

Hva hver kompetanse betyr

Teknisk leveranse: Å gjøre krav om til fungerende programvare som er lett å vedlikeholde, og få den ut til brukerne.
Systemdesign: Å velge strukturer, grensesnitt og avveininger som holder når produktet vokser.
Kvalitet og pålitelighet: Å holde produktet korrekt, observerbart og tilgjengelig, og å lære av feil.
Samarbeid og kommunikasjon: Å jobbe godt sammen med andre utviklere, produkt, design og resten av virksomheten.
Eierskap og produkteffekt: Å forstå hvorfor arbeidet betyr noe, og å ta ansvar for resultater, ikke bare oppgaver.
Mentorskap og teamutvikling: Å hjelpe andre å bli bedre og gjøre teamet sterkere enn noen enkeltperson i det.

Software Engineer: forventninger etter kompetanse og nivå
Kompetanse	Junior Engineer	Engineer	Senior Engineer	Staff Engineer	Principal Engineer
Teknisk leveranse	Fullfører godt avgrensede oppgaver med lesbar kode og tester, ber om hjelp etter å ha stått fast i noen timer i stedet for noen dager, og følger opp kommentarer fra kodegjennomgang før merge.	Tar en funksjon fra et kort designnotat til produksjon uten tett oppfølging, deler den opp i pull requests som er lette å gjennomgå, og gir realistiske estimater for kjent arbeid.	Leverer prosjekter som strekker seg over flere tjenester eller bidragsytere, legger opp arbeidet slik at noe nyttig kommer ut tidlig, og fjerner risikoer før de stopper teamet.	Fjerner hindringer for leveranser på tvers av team: løser opp felles avhengigheter, bygger verktøyene eller gjennomfører migreringene flere team trenger, og holder prosjekter med flere team på sporet.	Former hvordan hele organisasjonen leverer – releasepraksis, plattformvalg, bygge- og deployverktøy – slik at alle team leverer raskere og tryggere.
Systemdesign	Følger de eksisterende mønstrene i kodebasen og kan forklare hvorfor koden de har endret, er strukturert slik den er.	Designer komponenter innenfor en eksisterende tjeneste, skriver et kort designnotat for ikke-trivielle endringer og sammenligner minst to alternativer før de velger.	Leder designet av funksjoner som strekker seg over flere tjenester, skriver ned avveiningene slik at andre kan vurdere dem, og gir konstruktive tilbakemeldinger på andre utvikleres design.	Definerer arkitektur på tvers av team – felles datamodeller, tjenestekontrakter, valg mellom å bygge og kjøpe – og ser i forkant hvordan systemet må endre seg det neste året eller to.	Eier selskapets tekniske strategi: hvilke teknologier man satser på, hvilke man faser ut, og hvordan arkitekturen skal utvikle seg med virksomheten over flere år.
Kvalitet og pålitelighet	Skriver tester for egne endringer, sjekker eget arbeid før release og retter feil i kode de har vært borti.	Legger til overvåking og varsler for funksjonene de bygger, deltar i vaktordningen og håndterer rutinehendelser ved hjelp av runbooken.	Leder hendelseshåndteringen for teamets systemer, skriver post mortem-analyser uten skyldfordeling og sørger for at oppfølgingspunktene faktisk blir gjort.	Finner risikoer for pålitelighet og sikkerhet som går på tvers av systemer, setter standarder som teststrategi og tjenestenivåmål (SLO-er), og driver frem rettingene på tvers av team.	Definerer hva pålitelighet, sikkerhet og kvalitet betyr for selskapet, balanserer dem mot fart sammen med ledergruppen og er siste eskaleringspunkt for de vanskeligste hendelsene.
Samarbeid og kommunikasjon	Deler fremdrift og hindringer åpent og stiller tydelige spørsmål når et krav er uklart.	Jobber direkte med produkt og design for å avklare krav, forklarer tekniske begrensninger på et enkelt språk og skriver beskrivelser av pull requests som de som gjennomgår, kan følge.	Representerer teamet i planleggingen, forhandler omfang og avveininger med produkt og skriver dokumenter som folk utenfor utvikling forstår.	Samler flere team og funksjoner rundt en teknisk plan, løser uenigheter mellom team og forklarer teknisk risiko for ledelsen.	Er en stemme det lyttes til i beslutninger på selskapsnivå, oversetter forretningsstrategi til teknisk retning og tilbake, og representerer utvikling overfor kunder, partnere eller investorer ved behov.
Eierskap og produkteffekt	Forstår hensikten med oppgavene sine, sjekker at det som er levert, fungerer for brukerne, og følger opp til det gjør det.	Eier en funksjon etter lansering: følger med på bruk og feil, retter det som går galt, og foreslår forbedringer basert på det de lærer.	Eier et område av produktet fra start til slutt, utfordrer krav som ikke tjener brukerne, og foreslår arbeid som bringer teamet nærmere målene sine.	Finner problemene med størst gevinst i et produktområde – også de ingen team har tatt eierskap til – og sørger for at de blir løst.	Knytter investeringer i utvikling til selskapets resultater og argumenterer for eller mot store satsinger ut fra deres tekniske og forretningsmessige effekt.
Mentorskap og teamutvikling	Ber om tilbakemelding og handler på den, og skriver ned det de har lært, slik at neste nykommer får en enklere start.	Gjør grundige kodegjennomganger, hjelper nye kolleger i gang og parprogrammerer med juniorutviklere i ukjente deler av koden.	Er bevisst mentor for én eller to utviklere, gir tilbakemeldinger som hjelper dem til neste nivå, og deltar i rekrutteringsintervjuer.	Utvikler seniorutviklere på tvers av team, former intervjuprosessen og utviklingspraksisen og er en som andre oppsøker for råd.	Bygger selskapets tekniske kultur – hvordan beslutninger tas og hvordan kunnskap deles – og utvikler neste generasjon Staff Engineers.

Rull tabellen sidelengs for å se alle nivåene.

Last ned som CSV Åpnes i Excel, Google Sheets eller Numbers.

Junior Engineer: hva som forventes

Lærer seg kodebasen og leverer veldefinerte oppgaver med veiledning. Enkeltoppgaver i ett område av produktet, som regel brutt ned av noen med mer erfaring.

Teknisk leveranse: Fullfører godt avgrensede oppgaver med lesbar kode og tester, ber om hjelp etter å ha stått fast i noen timer i stedet for noen dager, og følger opp kommentarer fra kodegjennomgang før merge.
Systemdesign: Følger de eksisterende mønstrene i kodebasen og kan forklare hvorfor koden de har endret, er strukturert slik den er.
Kvalitet og pålitelighet: Skriver tester for egne endringer, sjekker eget arbeid før release og retter feil i kode de har vært borti.
Samarbeid og kommunikasjon: Deler fremdrift og hindringer åpent og stiller tydelige spørsmål når et krav er uklart.
Eierskap og produkteffekt: Forstår hensikten med oppgavene sine, sjekker at det som er levert, fungerer for brukerne, og følger opp til det gjør det.
Mentorskap og teamutvikling: Ber om tilbakemelding og handler på den, og skriver ned det de har lært, slik at neste nykommer får en enklere start.

Engineer: hva som forventes

Leverer funksjoner selvstendig og er et pålitelig medlem av teamet. Små og mellomstore funksjoner innenfor ett teams område, fra et kort designnotat til produksjon.

Teknisk leveranse: Tar en funksjon fra et kort designnotat til produksjon uten tett oppfølging, deler den opp i pull requests som er lette å gjennomgå, og gir realistiske estimater for kjent arbeid.
Systemdesign: Designer komponenter innenfor en eksisterende tjeneste, skriver et kort designnotat for ikke-trivielle endringer og sammenligner minst to alternativer før de velger.
Kvalitet og pålitelighet: Legger til overvåking og varsler for funksjonene de bygger, deltar i vaktordningen og håndterer rutinehendelser ved hjelp av runbooken.
Samarbeid og kommunikasjon: Jobber direkte med produkt og design for å avklare krav, forklarer tekniske begrensninger på et enkelt språk og skriver beskrivelser av pull requests som de som gjennomgår, kan følge.
Eierskap og produkteffekt: Eier en funksjon etter lansering: følger med på bruk og feil, retter det som går galt, og foreslår forbedringer basert på det de lærer.
Mentorskap og teamutvikling: Gjør grundige kodegjennomganger, hjelper nye kolleger i gang og parprogrammerer med juniorutviklere i ukjente deler av koden.

Senior Engineer: hva som forventes

Leder større arbeidsoppgaver og løfter standarden i teamet rundt seg. Prosjekter som strekker seg over flere tjenester eller flere personer, og de tekniske beslutningene i ett team.

Teknisk leveranse: Leverer prosjekter som strekker seg over flere tjenester eller bidragsytere, legger opp arbeidet slik at noe nyttig kommer ut tidlig, og fjerner risikoer før de stopper teamet.
Systemdesign: Leder designet av funksjoner som strekker seg over flere tjenester, skriver ned avveiningene slik at andre kan vurdere dem, og gir konstruktive tilbakemeldinger på andre utvikleres design.
Kvalitet og pålitelighet: Leder hendelseshåndteringen for teamets systemer, skriver post mortem-analyser uten skyldfordeling og sørger for at oppfølgingspunktene faktisk blir gjort.
Samarbeid og kommunikasjon: Representerer teamet i planleggingen, forhandler omfang og avveininger med produkt og skriver dokumenter som folk utenfor utvikling forstår.
Eierskap og produkteffekt: Eier et område av produktet fra start til slutt, utfordrer krav som ikke tjener brukerne, og foreslår arbeid som bringer teamet nærmere målene sine.
Mentorskap og teamutvikling: Er bevisst mentor for én eller to utviklere, gir tilbakemeldinger som hjelper dem til neste nivå, og deltar i rekrutteringsintervjuer.

Staff Engineer: hva som forventes

Løser problemer som går på tvers av team, og styrer tekniske beslutninger utover sitt eget team. Flere team eller et helt produktområde, inkludert problemer som ikke ett enkelt team eier.

Teknisk leveranse: Fjerner hindringer for leveranser på tvers av team: løser opp felles avhengigheter, bygger verktøyene eller gjennomfører migreringene flere team trenger, og holder prosjekter med flere team på sporet.
Systemdesign: Definerer arkitektur på tvers av team – felles datamodeller, tjenestekontrakter, valg mellom å bygge og kjøpe – og ser i forkant hvordan systemet må endre seg det neste året eller to.
Kvalitet og pålitelighet: Finner risikoer for pålitelighet og sikkerhet som går på tvers av systemer, setter standarder som teststrategi og tjenestenivåmål (SLO-er), og driver frem rettingene på tvers av team.
Samarbeid og kommunikasjon: Samler flere team og funksjoner rundt en teknisk plan, løser uenigheter mellom team og forklarer teknisk risiko for ledelsen.
Eierskap og produkteffekt: Finner problemene med størst gevinst i et produktområde – også de ingen team har tatt eierskap til – og sørger for at de blir løst.
Mentorskap og teamutvikling: Utvikler seniorutviklere på tvers av team, former intervjuprosessen og utviklingspraksisen og er en som andre oppsøker for råd.

Principal Engineer: hva som forventes

Setter den tekniske retningen for selskapet og står ansvarlig for den langsiktige tekniske helsen. Hele utviklingsorganisasjonen og selskapets tekniske strategi for de neste årene.

Teknisk leveranse: Former hvordan hele organisasjonen leverer – releasepraksis, plattformvalg, bygge- og deployverktøy – slik at alle team leverer raskere og tryggere.
Systemdesign: Eier selskapets tekniske strategi: hvilke teknologier man satser på, hvilke man faser ut, og hvordan arkitekturen skal utvikle seg med virksomheten over flere år.
Kvalitet og pålitelighet: Definerer hva pålitelighet, sikkerhet og kvalitet betyr for selskapet, balanserer dem mot fart sammen med ledergruppen og er siste eskaleringspunkt for de vanskeligste hendelsene.
Samarbeid og kommunikasjon: Er en stemme det lyttes til i beslutninger på selskapsnivå, oversetter forretningsstrategi til teknisk retning og tilbake, og representerer utvikling overfor kunder, partnere eller investorer ved behov.
Eierskap og produkteffekt: Knytter investeringer i utvikling til selskapets resultater og argumenterer for eller mot store satsinger ut fra deres tekniske og forretningsmessige effekt.
Mentorskap og teamutvikling: Bygger selskapets tekniske kultur – hvordan beslutninger tas og hvordan kunnskap deles – og utvikler neste generasjon Staff Engineers.

Slik tilpasser du denne stigen

Tilpass nivåene til titlene deres
Hvis titlene deres er Utvikler I, II og III, gir du nivåene nye navn, men beholder ett nivå for hvert reelle steg i ansvarsomfang. De fleste selskaper med færre enn 100 utviklere trenger ikke et Principal-nivå ennå: utelat det til noen faktisk gjør den jobben.
Hold deg til fem til sju kompetanser
Med flere enn sju er det ingen som leser dem; med færre enn fire ser svært ulike personer like ut. Slå sammen kompetanser som dere alltid vurderer samtidig, og legg bare til en ny når den ville endret en reell beslutning.
Skriv forventningene som noe du kan se
Spør for hver celle om en leder kunne vist til et eksempel fra de siste seks månedene. Bytt ut ord som «sterk» eller «dyp» med hva personen faktisk gjør, for eksempel «leder hendelseshåndteringen for teamets tjenester».
Test den på ekte personer før du publiserer
Be to eller tre ledere plassere teammedlemmene sine på utkastet. Der de er uenige, er formuleringen tvetydig: rett den, publiser karrierestigen og avtal å gå gjennom den igjen om seks måneder.

Vanlige spørsmål

Spørsmål om denne karrierestigen

Hvor mange nivåer bør en karrierestige for utviklere ha?

Fire til seks er vanlig i et selskap med 20–200 ansatte. Med færre blir forfremmelser sjeldne og store; med flere blir forskjellen mellom to nivåer for liten til å beskrive. Denne malen bruker fem: Junior Engineer, Engineer, Senior, Staff og Principal.

Må utviklere bli ledere for å utvikle seg?

Nei. Dette er en karrierestige for spesialistsporet: Staff og Principal Engineers vokser i ansvarsomfang og innflytelse uten å lede folk. Bruk den sammen med karrierestigen for Engineering Managers, slik at overgangen til ledelse er et bytte av karrierespor og ikke en forfremmelse.

Hvordan bruker vi karrierestigen i forfremmelsesbeslutninger?

Forfrem folk som allerede jobber stabilt på neste nivå, ikke dem som kanskje kunne gjort det. Be personen og lederen deres samle konkrete eksempler for hver kompetanse på målnivået, og vurder hver sak mot den samme matrisen, slik at beslutningene blir konsekvente på tvers av team.

Hvordan passer karrierestigen inn i check-iner og 1:1-samtaler?

Bruk den som agenda for faste check-iner: personen vurderer seg selv mot nåværende nivå, lederen gjør det samme, og avstanden mellom de to vurderingene blir noen få konkrete utviklingsaktiviteter for de kommende månedene.

Hvor ofte bør vi oppdatere karrierestigen?

Gå gjennom den én eller to ganger i året, og hver gang selskapet endrer form – for eksempel når dere oppretter et plattformteam eller begynner å ansette Staff Engineers. Skriv om en celle når vurderingene stadig snubler over den.

Bygg denne karrierestigen i LadderKit – gratis

Sett opp nivåene og ferdighetene for teamet ditt, vurder folk mot dem i check-iner, og hold beslutningene om forfremmelse konsekvente.

Start gratis Utforsk demoen Ingen registrering