Skabelon til karrierestige

Skabelon til karrierestige for softwareudviklere

Fem niveauer fra juniorudvikler til Principal Engineer og seks kompetencer – fra at levere kode til at udvikle teamet.

Gratis abonnement · Intet kreditkort nødvendigt

Denne karrierestige er skrevet til produktvirksomheder med cirka 20–200 medarbejdere: Udviklerne bygger features fra start til slut, teamene er små, og ingen i HR sidder og udarbejder en jobarkitektur. Den beskriver fem niveauer, fra en person i starten af karrieren til en, der former den tekniske retning for hele virksomheden. Det øverste niveau, Principal Engineer, er et specialistniveau; ledelse af udviklere hører til den separate karrierestige for engineering managers.

Hvert niveau er defineret ud fra, hvad personen gør, ikke ud fra antal års erfaring. Læs en række i kompetencematrixen fra venstre mod højre for at se, hvordan én forventning vokser; læs afsnittet om et niveau for at se alt, hvad der forventes på det niveau. Brug den til at forklare, hvad det næste niveau betyder, til at strukturere selvevalueringer og check-ins og til at gøre forfremmelsessager sammenlignelige på tværs af teams.

Se den som et udgangspunkt. Omdøb niveauerne, så de passer til jeres titler, slå kompetencer sammen eller fjern dem, der ikke passer til jeres virksomhed, og omskriv forventningerne med jeres egne ord, før du offentliggør karrierestigen for teamet.

Niveauerne i overblik

Juniorudvikler
Lærer kodebasen at kende og leverer veldefinerede opgaver med vejledning.
Omfang
Enkeltopgaver i ét område af produktet, som regel brudt ned af en mere erfaren kollega.
Udvikler
Leverer features selvstændigt og er et pålideligt medlem af teamet.
Omfang
Små og mellemstore features inden for ét teams område, fra et kort designnotat til produktion.
Seniorudvikler
Leder større arbejdsopgaver og hæver niveauet i teamet omkring sig.
Omfang
Projekter, der går på tværs af flere services eller flere personer, og de tekniske beslutninger i ét team.
Staff Engineer
Løser problemer, der krydser teamgrænser, og styrer tekniske beslutninger ud over ét team.
Omfang
Flere teams eller et helt produktområde, herunder problemer, som intet enkelt team ejer.
Principal Engineer
Sætter den tekniske retning for virksomheden og står til ansvar for dens tekniske sundhed på lang sigt.
Omfang
Hele udviklingsorganisationen og virksomhedens tekniske strategi for de næste par år.

Kompetencematrix

Hver række er en kompetence og hver kolonne et niveau. Læs en række fra venstre mod højre for at se hvordan forventningerne vokser.

Hvad hver kompetence betyder

Teknisk leverance: At omsætte krav til velfungerende software, der er til at vedligeholde, og få den ud til brugerne.
Systemdesign: At vælge strukturer, grænseflader og afvejninger, der holder, efterhånden som produktet vokser.
Kvalitet og driftssikkerhed: At holde produktet korrekt, observerbart og tilgængeligt – og at lære af fejl.
Samarbejde og kommunikation: At arbejde effektivt sammen med andre udviklere, produkt, design og resten af forretningen.
Ejerskab og produkteffekt: At forstå, hvorfor arbejdet betyder noget, og tage ansvar for resultater, ikke kun opgaver.
Mentorskab og teamudvikling: At hjælpe andre med at blive bedre og gøre teamet stærkere end nogen enkelt person i det.

Softwareudvikler: forventninger pr. kompetence og niveau
Kompetence	Juniorudvikler	Udvikler	Seniorudvikler	Staff Engineer	Principal Engineer
Teknisk leverance	Løser velafgrænsede opgaver med læsbar kode og tests, beder om hjælp efter at have siddet fast i et par timer frem for et par dage og håndterer review-kommentarer før merge.	Fører en feature fra et kort designnotat til produktion uden at skulle holdes i hånden, deler den op i pull requests, der er lette at reviewe, og giver realistiske estimater for kendt arbejde.	Leverer projekter, der spænder over flere services eller bidragydere, lægger arbejdet i en rækkefølge, så noget brugbart kommer ud tidligt, og fjerner risici, før de blokerer teamet.	Fjerner blokeringer for leverancen på tværs af teams: løser fælles afhængigheder op, bygger de værktøjer eller gennemfører de migreringer, flere teams har brug for, og holder projekter med flere teams på sporet.	Former, hvordan hele organisationen leverer – releasepraksis, platformvalg, build- og deploy-værktøjer – så alle teams leverer hurtigere og mere sikkert.
Systemdesign	Følger de eksisterende mønstre i kodebasen og kan forklare, hvorfor den kode, de har ændret, er struktureret, som den er.	Designer komponenter inden for en eksisterende service, skriver et kort designnotat ved ikke-trivielle ændringer og sammenligner mindst to løsninger, før de vælger én.	Leder designet af features, der spænder over flere services, skriver afvejningerne ned, så andre kan reviewe dem, og giver konstruktive reviews af andre udvikleres design.	Definerer arkitektur på tværs af teamgrænser – fælles datamodeller, servicekontrakter, beslutninger om at bygge eller købe – og forudser, hvordan systemet skal ændre sig over de næste et-to år.	Ejer virksomhedens tekniske strategi: hvilke teknologier der skal satses på, hvilke der skal udfases, og hvordan arkitekturen skal udvikle sig med forretningen over flere år.
Kvalitet og driftssikkerhed	Skriver tests til egne ændringer, tjekker sit arbejde før release og retter fejl i kode, de selv har rørt.	Tilføjer overvågning og alarmer til de features, de bygger, deltager i vagtordningen og håndterer rutinehændelser ud fra runbooken.	Leder håndteringen af hændelser i teamets systemer, skriver post-mortems uden skyld og sørger for, at opfølgningspunkterne faktisk bliver gjort.	Finder risici for driftssikkerhed og sikkerhed, der går på tværs af systemer, fastsætter standarder som teststrategi og serviceniveaumål og driver rettelserne på tværs af teams.	Definerer, hvad driftssikkerhed, sikkerhed og kvalitet betyder for virksomheden, afvejer dem mod hastighed sammen med ledelsen og er sidste eskaleringspunkt ved de sværeste hændelser.
Samarbejde og kommunikation	Deler fremskridt og blokeringer åbent og stiller klare spørgsmål, når et krav er uklart.	Arbejder direkte med produkt og design for at afklare krav, forklarer tekniske begrænsninger i et letforståeligt sprog og skriver pull request-beskrivelser, som reviewerne kan følge.	Repræsenterer teamet i planlægningen, forhandler omfang og afvejninger med produkt og skriver dokumenter, som folk uden for udviklingsafdelingen forstår.	Samler flere teams og funktioner om en teknisk plan, løser uenigheder mellem teams og forklarer tekniske risici for ledelsen.	Er en betroet stemme i beslutninger på virksomhedsniveau, oversætter forretningsstrategi til teknisk retning og tilbage igen og repræsenterer udviklingsorganisationen over for kunder, partnere eller investorer, når det er nødvendigt.
Ejerskab og produkteffekt	Forstår formålet med sine opgaver, tjekker, at det leverede virker for brugerne, og følger op, indtil det gør.	Ejer en feature efter lancering: holder øje med brug og fejl, retter det, der går galt, og foreslår forbedringer ud fra det, de lærer.	Ejer et område af produktet fra start til slut, udfordrer krav, der ikke tjener brugerne, og foreslår arbejde, der rykker teamets mål.	Finder de problemer med størst løftestang på tværs af et produktområde – også dem, intet team har taget – og sørger for, at de bliver løst.	Forbinder investeringer i udvikling med virksomhedens resultater og argumenterer for eller imod store satsninger ud fra deres tekniske og forretningsmæssige effekt.
Mentorskab og teamudvikling	Beder om feedback og handler på den og skriver ned, hvad de har lært, så den næste nye får en lettere start.	Giver grundige code reviews, hjælper med onboarding af nye kolleger og parprogrammerer med juniorudviklere i ukendte dele af koden.	Er bevidst mentor for en eller to udviklere, giver feedback, der hjælper dem med at nå det næste niveau, og deltager i ansættelsessamtaler.	Udvikler seniorudviklere på tværs af teams, former rekrutteringsprocessen og udviklingspraksis og er en, andre opsøger for at få råd.	Opbygger virksomhedens tekniske kultur – hvordan beslutninger træffes, og hvordan viden deles – og udvikler den næste generation af staff engineers.

Rul tabellen sidelæns for at se alle niveauer.

Download som CSV Kan åbnes i Excel, Google Sheets eller Numbers.

Juniorudvikler: hvad der forventes

Lærer kodebasen at kende og leverer veldefinerede opgaver med vejledning. Enkeltopgaver i ét område af produktet, som regel brudt ned af en mere erfaren kollega.

Teknisk leverance: Løser velafgrænsede opgaver med læsbar kode og tests, beder om hjælp efter at have siddet fast i et par timer frem for et par dage og håndterer review-kommentarer før merge.
Systemdesign: Følger de eksisterende mønstre i kodebasen og kan forklare, hvorfor den kode, de har ændret, er struktureret, som den er.
Kvalitet og driftssikkerhed: Skriver tests til egne ændringer, tjekker sit arbejde før release og retter fejl i kode, de selv har rørt.
Samarbejde og kommunikation: Deler fremskridt og blokeringer åbent og stiller klare spørgsmål, når et krav er uklart.
Ejerskab og produkteffekt: Forstår formålet med sine opgaver, tjekker, at det leverede virker for brugerne, og følger op, indtil det gør.
Mentorskab og teamudvikling: Beder om feedback og handler på den og skriver ned, hvad de har lært, så den næste nye får en lettere start.

Udvikler: hvad der forventes

Leverer features selvstændigt og er et pålideligt medlem af teamet. Små og mellemstore features inden for ét teams område, fra et kort designnotat til produktion.

Teknisk leverance: Fører en feature fra et kort designnotat til produktion uden at skulle holdes i hånden, deler den op i pull requests, der er lette at reviewe, og giver realistiske estimater for kendt arbejde.
Systemdesign: Designer komponenter inden for en eksisterende service, skriver et kort designnotat ved ikke-trivielle ændringer og sammenligner mindst to løsninger, før de vælger én.
Kvalitet og driftssikkerhed: Tilføjer overvågning og alarmer til de features, de bygger, deltager i vagtordningen og håndterer rutinehændelser ud fra runbooken.
Samarbejde og kommunikation: Arbejder direkte med produkt og design for at afklare krav, forklarer tekniske begrænsninger i et letforståeligt sprog og skriver pull request-beskrivelser, som reviewerne kan følge.
Ejerskab og produkteffekt: Ejer en feature efter lancering: holder øje med brug og fejl, retter det, der går galt, og foreslår forbedringer ud fra det, de lærer.
Mentorskab og teamudvikling: Giver grundige code reviews, hjælper med onboarding af nye kolleger og parprogrammerer med juniorudviklere i ukendte dele af koden.

Seniorudvikler: hvad der forventes

Leder større arbejdsopgaver og hæver niveauet i teamet omkring sig. Projekter, der går på tværs af flere services eller flere personer, og de tekniske beslutninger i ét team.

Teknisk leverance: Leverer projekter, der spænder over flere services eller bidragydere, lægger arbejdet i en rækkefølge, så noget brugbart kommer ud tidligt, og fjerner risici, før de blokerer teamet.
Systemdesign: Leder designet af features, der spænder over flere services, skriver afvejningerne ned, så andre kan reviewe dem, og giver konstruktive reviews af andre udvikleres design.
Kvalitet og driftssikkerhed: Leder håndteringen af hændelser i teamets systemer, skriver post-mortems uden skyld og sørger for, at opfølgningspunkterne faktisk bliver gjort.
Samarbejde og kommunikation: Repræsenterer teamet i planlægningen, forhandler omfang og afvejninger med produkt og skriver dokumenter, som folk uden for udviklingsafdelingen forstår.
Ejerskab og produkteffekt: Ejer et område af produktet fra start til slut, udfordrer krav, der ikke tjener brugerne, og foreslår arbejde, der rykker teamets mål.
Mentorskab og teamudvikling: Er bevidst mentor for en eller to udviklere, giver feedback, der hjælper dem med at nå det næste niveau, og deltager i ansættelsessamtaler.

Staff Engineer: hvad der forventes

Løser problemer, der krydser teamgrænser, og styrer tekniske beslutninger ud over ét team. Flere teams eller et helt produktområde, herunder problemer, som intet enkelt team ejer.

Teknisk leverance: Fjerner blokeringer for leverancen på tværs af teams: løser fælles afhængigheder op, bygger de værktøjer eller gennemfører de migreringer, flere teams har brug for, og holder projekter med flere teams på sporet.
Systemdesign: Definerer arkitektur på tværs af teamgrænser – fælles datamodeller, servicekontrakter, beslutninger om at bygge eller købe – og forudser, hvordan systemet skal ændre sig over de næste et-to år.
Kvalitet og driftssikkerhed: Finder risici for driftssikkerhed og sikkerhed, der går på tværs af systemer, fastsætter standarder som teststrategi og serviceniveaumål og driver rettelserne på tværs af teams.
Samarbejde og kommunikation: Samler flere teams og funktioner om en teknisk plan, løser uenigheder mellem teams og forklarer tekniske risici for ledelsen.
Ejerskab og produkteffekt: Finder de problemer med størst løftestang på tværs af et produktområde – også dem, intet team har taget – og sørger for, at de bliver løst.
Mentorskab og teamudvikling: Udvikler seniorudviklere på tværs af teams, former rekrutteringsprocessen og udviklingspraksis og er en, andre opsøger for at få råd.

Principal Engineer: hvad der forventes

Sætter den tekniske retning for virksomheden og står til ansvar for dens tekniske sundhed på lang sigt. Hele udviklingsorganisationen og virksomhedens tekniske strategi for de næste par år.

Teknisk leverance: Former, hvordan hele organisationen leverer – releasepraksis, platformvalg, build- og deploy-værktøjer – så alle teams leverer hurtigere og mere sikkert.
Systemdesign: Ejer virksomhedens tekniske strategi: hvilke teknologier der skal satses på, hvilke der skal udfases, og hvordan arkitekturen skal udvikle sig med forretningen over flere år.
Kvalitet og driftssikkerhed: Definerer, hvad driftssikkerhed, sikkerhed og kvalitet betyder for virksomheden, afvejer dem mod hastighed sammen med ledelsen og er sidste eskaleringspunkt ved de sværeste hændelser.
Samarbejde og kommunikation: Er en betroet stemme i beslutninger på virksomhedsniveau, oversætter forretningsstrategi til teknisk retning og tilbage igen og repræsenterer udviklingsorganisationen over for kunder, partnere eller investorer, når det er nødvendigt.
Ejerskab og produkteffekt: Forbinder investeringer i udvikling med virksomhedens resultater og argumenterer for eller imod store satsninger ud fra deres tekniske og forretningsmæssige effekt.
Mentorskab og teamudvikling: Opbygger virksomhedens tekniske kultur – hvordan beslutninger træffes, og hvordan viden deles – og udvikler den næste generation af staff engineers.

Sådan tilpasser du stigen

Tilpas niveauerne til jeres titler
Hvis jeres titler er Udvikler I, II og III, så omdøb niveauerne, men behold ét niveau for hvert reelt trin i ansvarsområde. De fleste virksomheder med under 100 udviklere har endnu ikke brug for et Principal-niveau: Udelad det, indtil nogen faktisk udfylder den rolle.
Hold dig til fem til syv kompetencer
Med flere end syv læser ingen dem; med færre end fire ligner meget forskellige mennesker hinanden. Slå kompetencer sammen, som du altid vurderer samlet, og tilføj kun en ny, når den ville ændre en reel beslutning.
Omskriv forventningerne til noget, man kan se
Spørg for hver celle, om en leder kunne pege på et eksempel fra de sidste seks måneder. Erstat ord som »stærk« eller »dyb« med det, personen faktisk gør, for eksempel »leder håndteringen af hændelser i teamets services«.
Test den på rigtige mennesker, før du offentliggør den
Bed to eller tre ledere om at placere deres teammedlemmer på udkastet. Hvor de er uenige, er formuleringen tvetydig: Ret den, offentliggør karrierestigen og aftal at gennemgå den igen om seks måneder.

FAQ

Spørgsmål om denne stige

Hvor mange niveauer skal en karrierestige for softwareudviklere have?

Fire til seks er typisk for en virksomhed med 20–200 medarbejdere. Med færre bliver forfremmelser sjældne og store; med flere er forskellen mellem to niveauer for lille til at beskrive. Denne skabelon bruger fem: Juniorudvikler, Udvikler, Seniorudvikler, Staff og Principal.

Skal udviklere blive ledere for at udvikle sig?

Nej. Dette er en karrierestige for specialistsporet: Staff og Principal Engineers vokser i ansvarsområde og indflydelse uden at lede mennesker. Brug den sammen med karrierestigen for engineering managers, så et skift til ledelse er et skift af spor og ikke en forfremmelse.

Hvordan bruger vi karrierestigen til beslutninger om forfremmelse?

Forfrem folk, der allerede konsekvent arbejder på det næste niveau, ikke dem, der måske kunne. Bed personen og vedkommendes leder om at samle konkrete eksempler for hver kompetence på målniveauet, og sammenlign hver sag med den samme matrix, så beslutningerne er ensartede på tværs af teams.

Hvordan passer karrierestigen ind i check-ins og 1:1-samtaler?

Brug den som dagsorden for faste check-ins: Personen vurderer sig selv i forhold til sit nuværende niveau, lederen gør det samme, og forskellene mellem de to bliver til nogle få konkrete udviklingsaktiviteter for de kommende måneder.

Hvor ofte bør vi opdatere karrierestigen?

Gennemgå den en eller to gange om året, og hver gang virksomheden ændrer form – for eksempel når I opretter et platformteam eller begynder at ansætte staff engineers. Omskriv en celle, når vurderingerne bliver ved med at snuble over den.

Byg denne karrierestige i LadderKit – gratis

Sæt dens niveauer og færdigheder op til dit team, vurdér folk ud fra dem i check-ins, og hold beslutninger om forfremmelser konsistente.

Start gratis Udforsk demoen Ingen tilmelding