Lag · 02 / LAG 2

Lag 2 — Struktur & organisering

Hvad et produktteam organiseres efter, når koden er en commodity.

Indhold

Den gamle trio falder fra hinanden

Tech Lead, Design Lead, Product Manager. Den klassiske produkttrio. Bygget på en præmis der ikke længere holder: at koden er den dyre del.

Kode er ved at blive en commodity. Når en designer kan prompte sig til en fungerende prototype, og en PM kan kode et MVP på en eftermiddag, skal teamet ikke længere organiseres efter hvem der eksekverer på hvad.

Spørgsmålet er hvad det så skal organiseres efter.

Tre kompetenceområder, ikke tre nye titler

Den nemme reaktion er at tegne tre nye roller. Generalisten, Arkitekten, Compliance-ankeret. Det er fristende fordi roller er nemme at tale om, nemme at hyre på, nemme at sætte i et organisationsdiagram.

Det er den samme fejl produktorganisationer altid har lavet: at tro at struktur følger titler. Den fejl er værd at lade være med at gentage.

En ærlig modposition: formelle titler er ikke værdiløse. De tvinger en artikulation af ansvar der ellers forsvinder ind i det uformelle (Pollok et al., 2019), og de er ét af fire indbyrdes afhængige ben — struktur, processer, belønning, mennesker — i en velfungerende organisation (Galbraith, 1982). Pointen er ikke at titler skal afskaffes. Pointen er at de er sekundære til kompetencerne, og at de fleste organisationer har den rækkefølge omvendt.

Tre kompetenceområder skal altid være dækket i et produktteam. Hvor mange mennesker der dækker dem, og om de samme mennesker dækker flere, afhænger af konteksten.

Generalist-evne. Forståelse for bruger, forretning og produkt på én gang. Evnen til at shippe selv uden at vente på nogen. For et år siden ville du have kaldt det en urealistisk profil. I dag er det bare en person med et AI-abonnement og en god produktsans.

Arkitektur-overblik. Ikke for at skrive koden, men for at validere den. Når alle prompter sig til features i hver deres retning, skal nogen sikre at det hænger sammen. At databasen ikke ligner en losseplads. At sikkerhedsmodellen ikke er bygget på håb. Det kræver det eneste AI endnu ikke kan erstatte: overblik.

Compliance-bevidsthed. Sikkerhed, GDPR, regulering. Når kode skrives hurtigere end nogensinde, og halvdelen af teamet ikke kan forklare hvad deres egen kode gør, bliver den kedelige person i rummet pludselig den vigtigste.

Brug listen som et tjek på om teamet er i balance. Mangler ét af de tre, er du i problemer, uanset hvor mange mennesker du har.

Cagans fire risici overlever, koblingen til rolle gør ikke

Det her er ikke en undskyldning for at glemme kundeværdien. Marty Cagans fire risici står stadig: kan vi bygge det, vil nogen bruge det, bliver det betalt for, virker det i forretningen.

Det der ændrer sig er ikke om risiciene skal dækkes. Det er hvem der dækker dem.

Trio-modellen, PM, designer, lead engineer, holdt sammen på en præmis: at hver rolle var den eneste der kunne lave sit eget arbejde. PM’en kunne ikke kode. Engineers lavede ikke design-research. Designere tog ikke produktbeslutninger. Samarbejdet var en nødvendighed, ikke et valg.

Den præmis er væk. Enhver af de tre roller kan nu lave et udkast til de andres arbejde.

Det betyder ikke at Cagan tager fejl om at trio-modellen er værdifuld. Han har ret i at god produktudvikling kræver at de tre fagligheder mødes om beslutninger. Men begrundelsen har skiftet fundament. Det der før hang sammen på arbejdsdeling, hænger nu sammen på beslutningsdeling: på hvem der ved hvad der skal gøres.

Forskningen peger samme vej

En undersøgelse af 38 udviklere og 102 surveyrespondenter fandt at folk der tildelte AI flere fluide roller havde højere adoption og brug end folk der låste sig fast på én rolle (Zakharov et al., 2025). Pointen handler om AI, men den rækker bredere: organisering der lever af fluiditet slår organisering der lever af titler.

Det er også der diskussionen står lige nu. Cagan forsvarer trio-modellen som elevated faglighed. Andre stemmer som Benioff, Tsemirava og versatilist-tænkningen argumenterer for at rollerne flyder ud i generalister med dybde i ét område.

Min position ligger tættere på den anden lejr. Roller er nyttige som retning, ikke som mure.

Små teams vinder, og har altid gjort

Team Topologies-tænkningen fra Skelton og Pais starter med en simpel observation: afhængigheder mellem teams er det største skaleringsproblem i moderne software.

Indsigten er ikke ny. Brooks’ law er fra 1975: adding manpower to a late software project makes it later. Et empirisk studie af 58 open source-projekter med 580.000+ commits og 30.000+ udviklere bekræftede det kvantitativt: koordineringsbehov skalerer ikke-lineært med teamstørrelse, og produktiviteten falder (Scholtes et al., 2015).

Vi har vidst det i 50 år. Alligevel har danske enterprise-projekter konsekvent løst forsinkelser ved at sætte flere folk på. Deadline gled, en konsulent blev ringet ind, et nyt scrum-team blev formeret, og forsinkelsen blev værre.

Hvorfor? Fordi alternativet, at sige vi har ikke kapacitet, vi udskyder eller skærer i scope, har været organisatorisk umuligt. Output blev målt på “har vi nok mennesker på opgaven”. Så ansatte man flere.

AI fjerner undskyldningen.

Hvis tre personer kan levere det fem kunne før, og fem kan levere det ti kunne før, kan man endelig organisere sig efter den regel der altid har været rigtig: hold teams så små som muligt og afhængighederne ude.

Idéen er gammel. Forskellen er at den for første gang er praktisk realiserbar i en dansk enterprise-kontekst.

Hvad der styrer i produktorganisationen

Når teams bliver små og selvkørende, hvad styrer så produktorganisationen?

Ikke at fordele opgaver. Ikke at tracke output. Ikke at koordinere release-noter. Ikke at lave kapacitetsplaner.

Produktorganisationen styres af outcomes: hvilke effekter der tæller, og hvilke trade-offs der er acceptable. Output bliver måleløst i AI-volumen, fordi alle kan producere mere. Den eneste meningsfulde måling tilbage er om noget faktisk gjorde en forskel.

En strukturpointe, før det er en personalepointe. Hvis output stadig er det der bestemmer beslutninger om budget, prioritering og retning, falder hele resten af pyramiden sammen. Outcomes er forudsætningen for alt det andet.

Tværgående koordinering, et åbent spørgsmål

Tværgående koordinering forsvinder ikke. Den minimeres, men er stadig til stede.

I en AI-tid tror jeg at koordineringen flytter sig fra rolle til værdistrøm. Du organiserer dig efter den vej en kundes problem rejser fra start til løsning, og lader teams følge værdistrømmen frem for at tildele dem komponenter. Roller skal stadig findes, men de er sekundære til hvad strukturen betjener.

Forskningen er enig om at moderate koordineringsniveauer slår både minimal og maksimal koordinering (Hahn et al., 2025). I store organisationer findes der 27 forskellige mekanismer der kan bære den koordinering (Berntzen et al., 2023).

Jeg er stadig i tvivl her. Det her er ikke færdigt-tænkt. Min foreløbige holdning: følg værdistrømmen, hold koordineringen så minimal som muligt, og acceptér at noget fortsat skal koordineres på tværs.

Princippet for laget

Princippet er kort:

Færrest mulige mennesker. Færrest mulige afhængigheder.

Det er den ramme alt andet hænger på. Færre mennesker bliver kun til virkelighed hvis de få der er, har den rette kombination af kompetencer — som er emnet for næste lag.

Næste lag
Lag 3 — Kompetencer & praksis

Skriv en kommentar