En ikke-teknisk leder kan se mere, end de fleste tror. Koden kan I ikke selv bedømme. Til gengæld kan I se, om der kommer virkende software ud med faste mellemrum, om forsinkelser bliver varslet i god tid, og om I kan få et klart svar på et spørgsmål. Det siger en hel del om et team. Spørgsmålet om selve kodens kvalitet kræver en anden fagperson, og det er værd at vide, hvornår det spørgsmål skal stilles.
Det, I selv kan se
Løbende demo af virkende software. Bed om at se produktet køre hver eller hver anden uge, med det nye i. Det skal være det rigtige produkt, ikke slides eller skærmbilleder. Et godt team har noget at vise næsten hver gang, selv om det er lille. Hvordan det sættes i system, står i sådan følger I fremdriften.
Varsler om forsinkelse. Forsinkelser sker for alle. Forskellen ligger i, hvornår I hører om dem. Gode udviklere siger fra tidligt: det her bliver større, end vi troede, og her er vores forslag. Det dårlige tegn er, at alt er på plads frem til dagen før, se hvorfor estimaterne aldrig holder.
Svar på spørgsmål. Spørg, hvorfor noget tager tid. Kan personen forklare det i almindelige ord, så I forstår det? Et godt svar gør emnet tydeligere. Et svar fyldt med fagord, der ender med “det er kompliceret”, kan betyde, at personen ikke har overblikket, eller ikke ønsker at dele det.
Fejl, der vender tilbage. Alle laver fejl. Men hvis samme type fejl kommer igen og igen, eller hvis noget, der virkede, går i stykker ved hver opdatering, er det et tegn på, at der mangler noget i kvaliteten eller i rutinerne.
Hvordan de taler om kunderne. Gode udviklere vil gerne vide, hvem der bruger produktet, og hvorfor. Spørger de ind til formålet, eller lader de opgaven gå igennem uden spørgsmål?
Spørgsmål, I kan stille
I behøver ingen fagord. Stil disse spørgsmål, og lyt efter, om svarene er tydelige og hænger sammen:
- Hvad er det sværeste ved at ændre noget i produktet i dag?
- Hvis en af jer er væk i en måned, hvad går så i stå?
- Hvordan ved I, at en ændring ikke har ødelagt noget andet?
- Hvor lang tid tager det at få en fejlrettelse ud til kunderne?
- Hvad ville I gøre anderledes, hvis I startede forfra?
- Hvad har I ændret, efter den sidste større fejl?
Det sidste spørgsmål er særlig brugbart. Et team, der lærer af sine fejl, har altid et konkret svar. Svaret på spørgsmål 2 viser, om I har en risiko, som I bør gøre noget ved, se når én udvikler kender hele koden.
Det, I skal passe på med
Nogle af de mest oplagte målinger siger meget lidt. Antal timer på kontoret, antal linjer kode og antal løste opgaver kan alle sammen se flotte ud uden at sige noget om værdien. Mere kode er ofte værre end mindre kode. En udvikler, der hjælper tre kollegaer videre, ser ineffektiv ud på sådanne tal, selv om vedkommende løfter hele teamet. Hvad der kan måles i stedet, står i hvorfor går udviklingen langsommere end før?.
Pas også på med ét indtryk. Den, der taler bedst til møderne, er ikke altid den bedste udvikler. Den stille person bagerst kan være den, de andre går til. Spørg teamet, hvem de går til, når de sidder fast.
Et svagt resultat kan også skyldes jer selv. Skifter prioriteterne hver uge, eller er kravene uklare, kan selv dygtige udviklere ikke levere. Spørg derfor også: hvad gør vi som ledelse, der gør jeres arbejde sværere?
Det, der kræver en anden fagperson
Der er ting, I ikke selv kan bedømme: om koden er vedligeholdelsesvenlig, om arkitekturen, dvs. produktets grundlæggende opbygning, vil holde, om sikkerheden er i orden, og om udviklerne reelt er stærke fagligt. Hertil må I have nogen med teknisk erfaring.
Det kan være en, der gennemgår koden og giver et billede af kvalitet og risici. Hvad en gennemgang kan svare på, er beskrevet som generel viden i uafhængig gennemgang af koden. Det kan også være en teknisk leder, der arbejder sammen med teamet over tid og ser, hvordan de løser opgaverne. Hent den vurdering, når jeres egne tegn peger i forskellige retninger, når I står foran en større beslutning, eller hvis I har en leverandør, som I ikke kan bedømme. Bruger I et udviklingshus, står styringen i sådan styrer I en udviklingsleverandør.
Gør det åbent, så teamet ved, hvad der sker og hvorfor. En hemmelig vurdering af jeres udviklere koster tillid, og det er tit de bedste, der tager den ilde op.
Hvis svaret er nej
Hvis teamet ikke er godt nok, så find ud af, om det handler om færdigheder, ledelse eller retning. Ofte er det sidste. Hvis det handler om den enkelte, er det en personalesag: giv klar besked og tid til at rette op, og tal med en advokat, hvis det ender med en afskedigelse.
Tænkt eksempel: en direktør er utilfreds med tempoet. Spørgsmålene viser, at teamet bruger det meste af ugen på fejl i en gammel del af produktet, som ingen har turdet ændre. Udviklerne er dygtige nok. Problemet er gæld, se ingen tør røre koden.
Det skal I lade være med
- At måle på linjer kode eller timer · det fremmer det forkerte, og de dygtige opdager det hurtigt.
- At sammenligne jeres team med en leverandørs salgsmateriale · det sammenligner virkelighed med reklame.
- At bede en bekendt kigge på det uden mandat · en løs vurdering kan gøre mere skade, end den gavner.
Det skal I kræve af den eksterne
- ☐ En vurdering af teamet, der forholder sig til rammerne og ledelsens egen andel.
- ☐ Konkrete eksempler frem for generelle holdninger.
- ☐ Samtaler med teamet, før der konkluderes noget.
- ☐ Forslag til, hvad I selv kan følge med i bagefter.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Syv tegn på, at produktet mangler teknisk ledelse · Teknisk gæld forklaret for ledelsen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
