Mall för karriärstege

Mall för karriärstege för mjukvaruutvecklare

Fem nivåer från junior till Principal, sex kompetenser från att leverera kod till att utveckla teamet.

Gratisplan · Inget kreditkort behövs

Den här karriärstegen är skriven för produktbolag med ungefär 20–200 anställda: utvecklarna bygger funktioner från början till slut, teamen är små och ingen på HR sitter och skriver en befattningsstruktur. Den beskriver fem nivåer, från någon i början av karriären till någon som formar hela företagets tekniska inriktning. Den högsta nivån, Principal Engineer, är en specialistnivå; att leda utvecklare beskrivs i den separata karriärstegen för engineering managers.

Varje nivå definieras av vad personen gör, inte av antal år i yrket. Läs en rad i kompetensmatrisen från vänster till höger för att se hur en förväntan växer; läs avsnittet för en nivå för att se allt som förväntas på den nivån samtidigt. Använd den för att förklara vad nästa nivå innebär, för att strukturera självskattningar och avstämningar och för att göra underlag för befordran jämförbara mellan team.

Se den som en utgångspunkt. Byt namn på nivåerna så att de stämmer med dina titlar, slå ihop eller stryk kompetenser som inte passar ditt företag och skriv om förväntningarna med egna ord innan du publicerar karriärstegen för teamet.

Nivåerna i korthet

Junior utvecklare
Lär sig kodbasen och levererar tydligt avgränsade uppgifter med handledning.
Omfattning
Enskilda uppgifter inom ett område av produkten, oftast nedbrutna av någon mer erfaren.
Utvecklare
Levererar funktioner självständigt och är en pålitlig medlem i teamet.
Omfattning
Små och medelstora funktioner inom ett teams område, från en kort designanteckning till produktion.
Senior utvecklare
Leder större arbeten och höjer nivån i teamet runt sig.
Omfattning
Projekt som spänner över flera tjänster eller flera personer, och ett teams tekniska beslut.
Staff Engineer
Löser problem som går över teamgränserna och styr tekniska beslut bortom det egna teamet.
Omfattning
Flera team eller ett helt produktområde, inklusive problem som inget enskilt team äger.
Principal Engineer
Sätter företagets tekniska riktning och ansvarar för dess långsiktiga tekniska hälsa.
Omfattning
Hela utvecklingsorganisationen och företagets tekniska strategi för de närmaste åren.

Kompetensmatris

Varje rad är en kompetens och varje kolumn en nivå. Läs en rad från vänster till höger för att se hur förväntningarna växer.

Vad varje kompetens innebär

Teknisk leverans: Att omsätta krav i fungerande, underhållbar mjukvara och få ut den till användarna.
Systemdesign: Att välja strukturer, gränssnitt och avvägningar som håller när produkten växer.
Kvalitet och tillförlitlighet: Att hålla produkten korrekt, observerbar och tillgänglig, och att lära av fel.
Samarbete och kommunikation: Att arbeta effektivt med andra utvecklare, produkt, design och resten av verksamheten.
Ägarskap och produktpåverkan: Att förstå varför arbetet spelar roll och ta ansvar för resultat, inte bara för uppgifter.
Mentorskap och teamutveckling: Att hjälpa andra att bli bättre och göra teamet starkare än någon enskild person i det.

Mjukvaruutvecklare: förväntningar per kompetens och nivå
Kompetens	Junior utvecklare	Utvecklare	Senior utvecklare	Staff Engineer	Principal Engineer
Teknisk leverans	Slutför väl avgränsade uppgifter med läsbar kod och tester, ber om hjälp efter att ha suttit fast i några timmar snarare än några dagar och åtgärdar granskningskommentarer innan merge.	Tar en funktion från en kort designanteckning till produktion utan att behöva hållas i handen, delar upp den i pull requests som är lätta att granska och ger realistiska uppskattningar för bekant arbete.	Levererar projekt som spänner över flera tjänster eller bidragsgivare, ordnar arbetet så att något användbart släpps tidigt och undanröjer risker innan de blockerar teamet.	Löser upp hinder för leverans mellan team: redar ut gemensamma beroenden, bygger verktygen eller genomför migreringarna som flera team behöver och håller projekt med flera team på rätt spår.	Formar hur hela organisationen levererar – releaserutiner, plattformsval, verktyg för bygge och driftsättning – så att varje team levererar snabbare och säkrare.
Systemdesign	Följer de befintliga mönstren i kodbasen och kan förklara varför koden hen har ändrat är uppbyggd som den är.	Designar komponenter inom en befintlig tjänst, skriver en kort designanteckning för icke-triviala ändringar och jämför minst två alternativ innan hen väljer ett.	Leder designen av funktioner som spänner över flera tjänster, skriver ner avvägningarna så att andra kan granska dem och granskar andra utvecklares designer på ett konstruktivt sätt.	Definierar arkitektur över teamgränserna – gemensamma datamodeller, tjänstekontrakt, beslut om att bygga eller köpa – och förutser hur systemet måste förändras under det närmaste året eller två.	Äger företagets tekniska strategi: vilka tekniker man ska satsa på, vilka som ska fasas ut och hur arkitekturen ska utvecklas med verksamheten under flera år.
Kvalitet och tillförlitlighet	Skriver tester för sina egna ändringar, kontrollerar sitt arbete före release och rättar buggar i kod hen har rört.	Lägger till övervakning och larm för de funktioner hen bygger, deltar i jourschemat och hanterar rutinincidenter med hjälp av runbooken.	Leder incidenthanteringen för teamets system, skriver skuldfria post mortem-analyser och ser till att uppföljningsåtgärderna faktiskt blir gjorda.	Hittar tillförlitlighets- och säkerhetsrisker som spänner över flera system, sätter standarder som teststrategi och servicenivåmål och driver åtgärderna genom flera team.	Definierar vad tillförlitlighet, säkerhet och kvalitet betyder för företaget, väger dem mot tempo tillsammans med ledningsgruppen och är sista eskaleringsnivå för de svåraste incidenterna.
Samarbete och kommunikation	Delar öppet med sig av framsteg och hinder och ställer tydliga frågor när ett krav är oklart.	Arbetar direkt med produkt och design för att förtydliga krav, förklarar tekniska begränsningar med enkla ord och skriver beskrivningar av pull requests som granskarna kan följa.	Representerar teamet i planeringen, förhandlar omfattning och avvägningar med produkt och skriver dokument som personer utanför utvecklingen förstår.	Samlar flera team och funktioner kring en teknisk plan, löser oenigheter mellan team och förklarar teknisk risk för ledningen.	Är en betrodd röst i beslut på företagsnivå, översätter affärsstrategi till teknisk riktning och tillbaka och representerar utvecklingsorganisationen inför kunder, partner eller investerare när det behövs.
Ägarskap och produktpåverkan	Förstår syftet med sina uppgifter, kontrollerar att det hen har släppt fungerar för användarna och följer upp tills det gör det.	Äger en funktion efter lansering: följer användningen och felen, rättar det som går fel och föreslår förbättringar utifrån det hen lär sig.	Äger ett område av produkten från början till slut, ifrågasätter krav som inte tjänar användarna och föreslår arbete som för teamet närmare dess mål.	Hittar de problem i ett produktområde som ger störst effekt – även sådana som inget team har tagit på sig – och ser till att de blir lösta.	Kopplar investeringar i utveckling till företagets resultat och argumenterar för eller emot stora satsningar utifrån deras tekniska och affärsmässiga effekt.
Mentorskap och teamutveckling	Ber om feedback och agerar på den, och skriver ner vad hen har lärt sig så att nästa nyanställda får en enklare start.	Gör noggranna kodgranskningar, hjälper till att introducera nya kollegor och parprogrammerar med juniora utvecklare i obekanta delar av koden.	Är medvetet mentor för en eller två utvecklare, ger feedback som hjälper dem att nå nästa nivå och deltar i rekryteringsintervjuer.	Utvecklar seniora utvecklare i flera team, formar intervjuprocessen och utvecklingsmetoderna och är någon som andra söker upp för råd.	Bygger företagets tekniska kultur – hur beslut fattas och hur kunskap delas – och utvecklar nästa generation av staff engineers.

Skrolla tabellen i sidled för att se alla nivåer.

Ladda ner som CSV Öppnas i Excel, Google Sheets eller Numbers.

Junior utvecklare: vad som förväntas

Lär sig kodbasen och levererar tydligt avgränsade uppgifter med handledning. Enskilda uppgifter inom ett område av produkten, oftast nedbrutna av någon mer erfaren.

Teknisk leverans: Slutför väl avgränsade uppgifter med läsbar kod och tester, ber om hjälp efter att ha suttit fast i några timmar snarare än några dagar och åtgärdar granskningskommentarer innan merge.
Systemdesign: Följer de befintliga mönstren i kodbasen och kan förklara varför koden hen har ändrat är uppbyggd som den är.
Kvalitet och tillförlitlighet: Skriver tester för sina egna ändringar, kontrollerar sitt arbete före release och rättar buggar i kod hen har rört.
Samarbete och kommunikation: Delar öppet med sig av framsteg och hinder och ställer tydliga frågor när ett krav är oklart.
Ägarskap och produktpåverkan: Förstår syftet med sina uppgifter, kontrollerar att det hen har släppt fungerar för användarna och följer upp tills det gör det.
Mentorskap och teamutveckling: Ber om feedback och agerar på den, och skriver ner vad hen har lärt sig så att nästa nyanställda får en enklare start.

Utvecklare: vad som förväntas

Levererar funktioner självständigt och är en pålitlig medlem i teamet. Små och medelstora funktioner inom ett teams område, från en kort designanteckning till produktion.

Teknisk leverans: Tar en funktion från en kort designanteckning till produktion utan att behöva hållas i handen, delar upp den i pull requests som är lätta att granska och ger realistiska uppskattningar för bekant arbete.
Systemdesign: Designar komponenter inom en befintlig tjänst, skriver en kort designanteckning för icke-triviala ändringar och jämför minst två alternativ innan hen väljer ett.
Kvalitet och tillförlitlighet: Lägger till övervakning och larm för de funktioner hen bygger, deltar i jourschemat och hanterar rutinincidenter med hjälp av runbooken.
Samarbete och kommunikation: Arbetar direkt med produkt och design för att förtydliga krav, förklarar tekniska begränsningar med enkla ord och skriver beskrivningar av pull requests som granskarna kan följa.
Ägarskap och produktpåverkan: Äger en funktion efter lansering: följer användningen och felen, rättar det som går fel och föreslår förbättringar utifrån det hen lär sig.
Mentorskap och teamutveckling: Gör noggranna kodgranskningar, hjälper till att introducera nya kollegor och parprogrammerar med juniora utvecklare i obekanta delar av koden.

Senior utvecklare: vad som förväntas

Leder större arbeten och höjer nivån i teamet runt sig. Projekt som spänner över flera tjänster eller flera personer, och ett teams tekniska beslut.

Teknisk leverans: Levererar projekt som spänner över flera tjänster eller bidragsgivare, ordnar arbetet så att något användbart släpps tidigt och undanröjer risker innan de blockerar teamet.
Systemdesign: Leder designen av funktioner som spänner över flera tjänster, skriver ner avvägningarna så att andra kan granska dem och granskar andra utvecklares designer på ett konstruktivt sätt.
Kvalitet och tillförlitlighet: Leder incidenthanteringen för teamets system, skriver skuldfria post mortem-analyser och ser till att uppföljningsåtgärderna faktiskt blir gjorda.
Samarbete och kommunikation: Representerar teamet i planeringen, förhandlar omfattning och avvägningar med produkt och skriver dokument som personer utanför utvecklingen förstår.
Ägarskap och produktpåverkan: Äger ett område av produkten från början till slut, ifrågasätter krav som inte tjänar användarna och föreslår arbete som för teamet närmare dess mål.
Mentorskap och teamutveckling: Är medvetet mentor för en eller två utvecklare, ger feedback som hjälper dem att nå nästa nivå och deltar i rekryteringsintervjuer.

Staff Engineer: vad som förväntas

Löser problem som går över teamgränserna och styr tekniska beslut bortom det egna teamet. Flera team eller ett helt produktområde, inklusive problem som inget enskilt team äger.

Teknisk leverans: Löser upp hinder för leverans mellan team: redar ut gemensamma beroenden, bygger verktygen eller genomför migreringarna som flera team behöver och håller projekt med flera team på rätt spår.
Systemdesign: Definierar arkitektur över teamgränserna – gemensamma datamodeller, tjänstekontrakt, beslut om att bygga eller köpa – och förutser hur systemet måste förändras under det närmaste året eller två.
Kvalitet och tillförlitlighet: Hittar tillförlitlighets- och säkerhetsrisker som spänner över flera system, sätter standarder som teststrategi och servicenivåmål och driver åtgärderna genom flera team.
Samarbete och kommunikation: Samlar flera team och funktioner kring en teknisk plan, löser oenigheter mellan team och förklarar teknisk risk för ledningen.
Ägarskap och produktpåverkan: Hittar de problem i ett produktområde som ger störst effekt – även sådana som inget team har tagit på sig – och ser till att de blir lösta.
Mentorskap och teamutveckling: Utvecklar seniora utvecklare i flera team, formar intervjuprocessen och utvecklingsmetoderna och är någon som andra söker upp för råd.

Principal Engineer: vad som förväntas

Sätter företagets tekniska riktning och ansvarar för dess långsiktiga tekniska hälsa. Hela utvecklingsorganisationen och företagets tekniska strategi för de närmaste åren.

Teknisk leverans: Formar hur hela organisationen levererar – releaserutiner, plattformsval, verktyg för bygge och driftsättning – så att varje team levererar snabbare och säkrare.
Systemdesign: Äger företagets tekniska strategi: vilka tekniker man ska satsa på, vilka som ska fasas ut och hur arkitekturen ska utvecklas med verksamheten under flera år.
Kvalitet och tillförlitlighet: Definierar vad tillförlitlighet, säkerhet och kvalitet betyder för företaget, väger dem mot tempo tillsammans med ledningsgruppen och är sista eskaleringsnivå för de svåraste incidenterna.
Samarbete och kommunikation: Är en betrodd röst i beslut på företagsnivå, översätter affärsstrategi till teknisk riktning och tillbaka och representerar utvecklingsorganisationen inför kunder, partner eller investerare när det behövs.
Ägarskap och produktpåverkan: Kopplar investeringar i utveckling till företagets resultat och argumenterar för eller emot stora satsningar utifrån deras tekniska och affärsmässiga effekt.
Mentorskap och teamutveckling: Bygger företagets tekniska kultur – hur beslut fattas och hur kunskap delas – och utvecklar nästa generation av staff engineers.

Så anpassar du den här karriärstegen

Matcha nivåerna mot dina titlar
Om dina titlar är Utvecklare I, II och III, byt namn på nivåerna men behåll en nivå för varje verkligt steg i ansvar. De flesta företag med färre än 100 utvecklare behöver ännu ingen Principal-nivå: hoppa över den tills någon faktiskt gör det jobbet.
Håll dig till fem till sju kompetenser
Med fler än sju läser ingen dem; med färre än fyra ser väldigt olika personer likadana ut. Slå ihop kompetenser som du alltid bedömer tillsammans, och lägg bara till en ny när den skulle ändra ett verkligt beslut.
Skriv om förväntningarna som något man kan se
Fråga för varje cell om en chef kan peka på ett exempel från de senaste sex månaderna. Byt ut ord som ”stark” eller ”djup” mot vad personen faktiskt gör, till exempel ”leder incidenthanteringen för teamets tjänster”.
Testa den på verkliga personer innan du publicerar
Be två eller tre chefer placera sina teammedlemmar i utkastet. Där de är oeniga är formuleringen tvetydig: rätta den, publicera karriärstegen och kom överens om att se över den igen om sex månader.

Vanliga frågor

Frågor om den här karriärstegen

Hur många nivåer bör en karriärstege för mjukvaruutvecklare ha?

Fyra till sex är vanligt för ett företag med 20–200 anställda. Med färre blir befordringar sällsynta och enorma; med fler blir skillnaden mellan två nivåer för liten för att beskriva. Den här mallen använder fem: Junior utvecklare, Utvecklare, Senior, Staff och Principal.

Måste utvecklare bli chefer för att utvecklas?

Nej. Det här är en karriärstege för specialistspåret: Staff och Principal Engineers växer i ansvar och inflytande utan att leda personal. Använd den tillsammans med karriärstegen för engineering managers, så att steget in i ledarskap blir ett byte av spår snarare än en befordran.

Hur använder vi karriärstegen i beslut om befordran?

Befordra personer som redan konsekvent arbetar på nästa nivå, inte dem som kanske skulle kunna. Be personen och chefen samla konkreta exempel för varje kompetens på målnivån, och jämför varje underlag mot samma matris så att besluten blir konsekventa mellan team.

Hur passar karriärstegen in i avstämningar och 1:1-samtal?

Använd den som agenda för regelbundna avstämningar: personen bedömer sig själv mot sin nuvarande nivå, chefen gör detsamma, och skillnaderna mellan de två blir några konkreta utvecklingsaktiviteter för de kommande månaderna.

Hur ofta bör vi uppdatera karriärstegen?

Se över den en eller två gånger om året, och när företaget ändrar form – till exempel när du skapar ett plattformsteam eller börjar rekrytera staff engineers. Skriv om en cell när bedömningarna gång på gång snubblar på den.

Bygg den här karriärstegen i LadderKit – gratis

Lägg upp dess nivåer och färdigheter för ditt team, bedöm folk mot dem i avstämningar och håll besluten om befordran konsekventa.

Börja gratis Utforska demon Ingen registrering