Vilka kriterier använder du för att utvärdera en utvecklares prestation?

Question

IT Interview Practice · Accepted Answer

Jag utvärderar utvecklare utifrån **de resultat de producerar och den påverkan de har på teamet**, inte utifrån råa output-mått som rader kod, commits eller story points. Bra utvärdering triangulerar flera signaler över ett meningsfullt tidsfönster, inte en enda sprint.

## Vad jag faktiskt tittar på

- **Påverkan och ägarskap.** Levererar de arbete som flyttar produkten framåt eller avblockerar andra? Äger de ett problem från början till slut, inklusive de röriga delarna som utrullning, övervakning och uppföljningsbuggar?
- **Kvalitet och pålitlighet.** Håller deras kod i produktion? Lämnar de kodbasen bättre eller ackumulerar de **tech debt** som andra får betala av?
- **Autonomi på rätt nivå.** En mid-level-ingenjör som behöver handpåläggning på rutinuppgifter är något annat än en senior som kan ta ett otydligt problem och returnera en plan.
- **Samarbetsmultiplikator.** Kvalitet på code review, mentorskap, designinput, dokumentation. De bästa ingenjörerna lyfter människorna runt omkring sig.
- **Utvecklingsbana.** Är de bättre än för sex månader sedan? Tar de till sig feedback?

## Hur jag gör det rättvist

- Kalibrera mot **förväntningarna för deras nivå**, nedskrivna, så att feedback inte är godtycklig.
- Samla in konkreta bevis kontinuerligt istället för att rekonstruera det vid utvärderingstillfället. Jag för anteckningar per person.
- Skilj **prestation** (resultat) från **potential** (förmåga för nästa nivå). Att blanda ihop dem leder till dåliga beslut om befordran och PIP.

| Signal | Bra källa | Vilseledande källa |
|---|---|---|
| Produktivitet | Levererade resultat | Rader kod, antal commits |
| Kvalitet | Trender för incident/defekt | Subjektiv magkänsla |
| Samarbete | Peer-feedback, PR-historik | Volym av möten |

## Fallgropar

- **Recency bias** — att bedöma de senaste två veckorna, inte hela perioden.
- **Synlighetsbias** — att belöna högljutt arbete och missa tyst limarbete som on-call och reviews.
- Att behandla mått som mål; i samma stund som ett mått blir ett mål börjar folk gama det.

## Varför det är viktigt

Rättvis, evidensbaserad utvärdering driver förtroende, retention och rätt investeringar i utveckling. Gör du det fel befordrar du fel människor, demoraliserar dina starkaste bidragsgivare och lär teamet att performativt arbete slår verklig påverkan.

Signal	Bra källa	Vilseledande källa
Produktivitet	Levererade resultat	Rader kod, antal commits
Kvalitet	Trender för incident/defekt	Subjektiv magkänsla
Samarbete	Peer-feedback, PR-historik	Volym av möten

Vad jag faktiskt tittar på

Hur jag gör det rättvist

Fallgropar

Varför det är viktigt

Relaterade frågor