Hvilke kriterier bruker du for å evaluere en utviklers ytelse?

Question

Accepted Answer

Jeg evaluerer utviklere på **resultatene de produserer og effekten de har på teamet**, ikke på rå produksjonsmetrikker som kodelinjer, commits eller story points. God evaluering trianguler flere signaler over et meningsfullt tidsvindu, ikke en enkelt sprint.

## Hva jeg faktisk ser på

- **Effekt og eierskap.** Leverer de arbeid som driver produktet eller løser opp for andre? Eier de et problem fra ende til ende, inkludert de rotete delene som utrulling, overvåking og oppfølgingsbugs?
- **Kvalitet og pålitelighet.** Holder koden deres i produksjon? Etterlater de kodebasen bedre eller akkumulerer de **tech debt** som andre må betale ned?
- **Autonomi på riktig nivå.** En mellomnivåingeniør som trenger håndholding på rutineoppgaver er forskjellig fra en senior som kan ta et tvetydig problem og returnere en plan.
- **Samarbeidsmultiplikator.** Kvalitet på code review, mentoring, designinnspill, dokumentasjon. De beste ingeniørene løfter folkene rundt seg.
- **Vekstbane.** Er de bedre enn for seks måneder siden? Responderer de på tilbakemelding?

## Hvordan jeg gjør det rettferdig

- Kalibrer mot **forventningene til nivået deres**, nedskrevet, slik at tilbakemelding ikke er vilkårlig.
- Samle konkret bevis kontinuerlig i stedet for å rekonstruere det ved review-tid. Jeg fører notater per person.
- Skill **ytelse** (resultater) fra **potensial** (kapasitet for neste nivå). Å blande dem forårsaker dårlige beslutninger om forfremmelse og PIP.

| Signal | God kilde | Misvisende kilde |
|---|---|---|
| Produktivitet | Leverte resultater | Kodelinjer, antall commits |
| Kvalitet | Trender for incidents/defekter | Subjektiv magefølelse |
| Samarbeid | Tilbakemelding fra kolleger, PR-historikk | Mengde møter |

## Fallgruver

- **Nyhetsskjevhet** — å bedømme de siste to ukene, ikke perioden.
- **Synlighetsskjevhet** — å belønne høylytt arbeid og overse stille limarbeid som on-call og reviews.
- Å behandle metrikker som mål; i det øyeblikket en metrikk blir et mål, spiller folk den.

## Hvorfor det er viktig

Rettferdig, evidensbasert evaluering driver tillit, retensjon og de riktige vekstinvesteringene. Gjør den feil, og du forfremmer feil folk, demoraliserer dine sterkeste bidragsytere, og lærer teamet at oppvisningsarbeid slår ekte effekt.

Signal	God kilde	Misvisende kilde
Produktivitet	Leverte resultater	Kodelinjer, antall commits
Kvalitet	Trender for incidents/defekter	Subjektiv magefølelse
Samarbeid	Tilbakemelding fra kolleger, PR-historikk	Mengde møter