Fem udviklere kan klare det meste ved at tale sammen. Tyve kan ikke. Et sted på vejen holder alle op med at kende alt, og det, der før gik af sig selv, begynder at gå i stykker: hvem ejer koden, hvem beslutter, og hvem ved, hvad de andre laver? Løsningen er at dele teamet i mindre, selvstændige grupper med hvert sit ansvar og klare ejere af hver del af koden. Det kræver få og faste aftaler, og det kræver, at I gør det, før problemerne vokser sig store.
Det, der går i stykker
Tegnene kommer gradvist, og de opdages typisk i denne rækkefølge:
- To udviklere har løst det samme, eller ændret det samme, uden at vide det.
- Fejl i én del af produktet opstår, efter en anden del blev ændret.
- Fælles møder bliver lange, og de fleste sidder og venter.
- Nye medarbejdere er længe om at blive nyttige.
- Ingen føler ansvar for de gamle dele af koden.
- Afgørelser bliver taget på gangen, og resten hører om dem bagefter.
Antallet af forbindelser mellem folk vokser langt hurtigere end antallet af folk. Derfor hjælper det ikke at holde flere møder.
Del op i mindre team
Et team på 4 til 8 personer er stort nok til at levere noget selvstændigt og lille nok til, at alle kender hinandens arbejde. Når I nærmer jer ti udviklere, er det tid til at overveje det første skel.
Del helst efter en del af produktet eller en kundegruppe, fx kundeportalen, betaling eller integrationer. Så kan teamet følge en opgave fra idé til kunde og bærer resultatet. Deler I efter teknik, fx ét team til frontend og ét til backend, skal næsten alle opgaver gennem begge team, og I har bygget en ny kø.
Hvert team bør have:
- En klar opgave, der kan forklares i en sætning.
- En person, der prioriterer arbejdet sammen med forretningen.
- En teknisk ansvarlig, der holder øje med kvaliteten.
- Mulighed for at sende en ændring ud uden at vente på et andet team.
Ejerskab af kode
Når alle ejer alt, ejer ingen noget. Skriv ned, hvilket team der ejer hvilken del af koden. Ejerskab betyder, at teamet svarer for kvalitet, gæld og drift dér, og at andre spørger dem, før de ændrer noget stort. Andre må stadig gerne foreslå ændringer.
Fælles dele, som login og byggesystem, er den svære rest. Giv dem en navngiven ejer, også selv om det kun er en del af et teams arbejde. Bliver opgaven for stor, kan I samle dem i et lille team, der arbejder for de andre. Hvordan ansvaret for driften fordeles, står i hvem ejer driften.
Mens I gør det, er det en god anledning til at opdage de områder, kun én person kender, se når én udvikler kender hele koden.
Færre møder, bedre skriftlighed
Et stort fællesmøde med tyve personer løser næsten ingenting. Skift til møder i hvert team og korte fælles møder, fx en gang om ugen med ledelsen af teamene og en gang om måneden med alle.
Det, der før blev klaret ved at tale sammen, skal nu skrives ned. Det gælder især de tekniske beslutninger. Et kort notat om, hvad I valgte og hvorfor, sparer mange samtaler, se skriv de tekniske beslutninger ned. Også rutinerne skal skrives om, for det, der passer til fem, er for løst til tyve. Udgangspunktet står i rutinerne for et lille team.
Roller, der kommer til
Når teamene deles op, opstår der nogle nye roller. Det betyder ikke, at I skal ansætte dem alle på én gang.
Teamledere. Den ene person, der havde alle udviklerne, kan ikke holde samtaler med tyve. Se hvornår I skal have den første teamleder.
Produktansvarlig. Når der er flere team, skal nogen beslutte, hvad hvert team arbejder på, og afklare det med salg og kunder.
En teknisk leder på tværs. Med flere team skal nogen se helheden: arkitektur, fælles standarder, rekruttering og den tekniske plan. Det er CTO-rollen. Ligger den stadig hos lead developeren eller en stifter med fuldt skema, er det tiden at tage stilling, se CTO, VP Engineering og tech lead.
Rækkefølgen, når I vokser
Tag ikke alt på én gang. En rimelig rækkefølge er:
- Skriv ned, hvem der ejer hvad i dag.
- Få de faste rutiner til at køre, før I ansætter mange.
- Lav det første skel, når I kan se en naturlig opdeling, og lad folk være med til at vælge.
- Sæt teamledere på, før den sidste leder går i stå.
- Justér hvert halve år, og vær forberedt på at lave om igen.
Ansæt i et tempo, teamet kan bære. Hver ny person kræver tid fra de erfarne, så mange nye på én gang kan gøre teamet langsommere i en periode. Hvis det allerede er gået sådan, kan I læse hvorfor går udviklingen langsommere end før?.
Tænkt eksempel: et softwarehus med fjorten udviklere og ét fælles møde deler sig i tre team efter produktområde. Ét team ejer kundeportalen, ét ejer integrationer, og ét ejer drift og fælles dele. Det fælles møde bliver til et kort ugemøde, og hvert team får en teknisk ansvarlig. Nogle måneder senere flytter de grænsen mellem to af teamene, fordi den første opdeling viste sig ikke at passe. Sådan skal det gerne gå.
Det skal I lade være med
- At kopiere en kendt organisationsmodel fra en stor techvirksomhed · den er lavet til en helt anden størrelse.
- At dele teamet efter teknik · så skal alt arbejde gennem to køer.
- At lade en reorganisering komme som en overraskelse · inddrag udviklerne, for de ved, hvor grænserne bør gå.
Det skal I kræve af den eksterne
- ☐ Et overblik over, hvem der ejer hvilke dele af koden i dag.
- ☐ Et forslag til opdeling med begrundelser, som teamet har haft mulighed for at påvirke.
- ☐ En plan for ansættelser, der passer til, hvad teamet kan tage imod.
- ☐ Faste punkter, hvor opdelingen tages op igen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Teknisk køreplan ved siden af produktkøreplanen · Når de erfarne udviklere vil videre
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
