Forstå incitamenterne når du læser team topologies.

onsdag den 13. december 2023

Mit tanker om bogen bliver muligvis lige så rodet som selve bogen. Den er svær at sætte ord på fordi den i flæng, danser rundt om alle muligt emner.

Da jeg havde læst bogen, sad jeg tilbage med følelsen af:

Min udfordring er ikke bogen som sådan. Jeg finder den rodet skrevet, og den hviler på andres værker. Jeg synes, det er lidt en farlig bog. Min største udfordring er, at læserne af den formentlig vil bruge bogens mange, dog knap så underbyggede ideer (jeg taler her ikke om bogens referencer til andre litterære værker) uden selv at tænke over, hvilke kommunikationsstrukturer der hæmmer ens egen organisation. Problemet med bøger som denne, der er letlæselige, og som kommer med nemme-at-gengive anekdoter - især fra andre menneskers værker og tanker - og dens umiddelbart simple anbefalinger, gør, at nogle læsere vil forstå det samme overfladiske indhold og derpå gengive det, fordi, ja, det er jo så nemt at forstå.

Når noget virker nemt at forstå - men hvor konteksten immervæk er kompleks, så er det ofte fordi nogen ikke fortæller hele sandheden. At "lave teams om" i en organisation er ikke simpelt. Det har potentielt store implikationer for en organisation. Derfor skal man naturligvis også spørge sig selv: "Er vores ansatte modne nok til disse forandringer?"

Så mit review handler egentlig mere om, og jeg beder dig venligst om, at hvis du læser bogen, så stil dig selv i et kritisk hjørne og skriv en liste, i hånden på et stykke papir, for hvordan din egen organisation ville tackle det, som bogen lægger op til. Du skal ikke skrive, hvorfor det er en god ide; det gør forfatterne et stort nummer ud af at beskrive. Du skal skrive, hvordan de anbefalinger, bogen kommer med, skal implementeres i jeres organisation.

Når jeg tænker over det, så gjorde Agile noget af det samme ved vores branche. Netop fordi "blueprintet" omkring Agile er så simpelt - bare læs manifestet - i sin reneste form, er det samtidig blevet så nemt for de uindviede frit at tolke på det. Agile er misforstået, fordi det er for simpelt for de fleste at acceptere, at noget kan være så simpelt.

Men det er selvfølgelig mere end det. De af jer, som besidder kompetencerne, ved godt, at man ikke kan lave trade-offs omkring Agile/Conways lov/etc. og opnå samme resultat. Og det er hele tiden det, der sker, når andre mennesker end dig forsøger at bøje "loven" for at få den til at passe ind i deres egen virkelighed. Jeg får det til at lyde, som om det er de andres skyld. Tro mig, jeg er i lige så høj grad drevet af incitamenter. Forskellen er bare, at jeg på forhånd godt ved, det trækker mig i en retning, som kan være ufordelagtig for mine medmennesker.

Det tager faktisk kun et øjeblik, hvis man er kompetent, at kigge på sit eget team og finde de trade-offs, der eksisterer. Du skal lære at forstå, hvorfor trade-offs eksisterer. Mennesker ønsker ofte at bøje ofte "loven", fordi de er drevet af person

lige incitamenter, noget der er velbeskrevet i psykologien. Så det fører mig i virkeligheden til det, som det i bund og grund handler om: Mennesker.

Jeg vil virkelig anbefale, at du læser Charles Mungers "The Psychology of Human Misjudgment".

Ligesom forretningen (ikke mindsettet) omkring Agile har gjort det de sidste 20 år, lægger team topologies op til nogle "regler" for, hvordan teams bør designes for at fremme stabilitet og hastighed i softwareorganisationer. Det er ikke anderledes end at anbefale et BUFD, noget bogen paradoksalt nok ikke anbefaler, men selv udøver i stor stil.

De af os, som har været tilskuere til diverse virksomheders såkaldte Agile og DevOps-transformationer, ved også godt, at første gang et menneske i hierarkiet bøjer reglerne for enten at indløse egne incitamenter eller fordi vedkommende ikke er inviteret eller kompetent, så er det som jord på kuglelejer: A slippery slope.

Og det er nøjagtigt det samme, som vil gøre sig gældende med de "principper" og team-strukturer, som team topologies lægger op til. Det er en arrogant indstilling, synes jeg, at forfatterne først lægger op til at erstatte et mindre fordelagtigt design med et, som i lige så høj grad minder om "a grand design". Og de gør det så subtilt i bogen, at jeg ikke tror, de selv indser, hvad det er, de i virkeligheden lægger op til.

Her vil jeg sagtens kunne tegne en streg fra Agile til bogens oplæg, fordi ligesom med de såkaldte Agile roller (servant leader, anyone?) vil virksomheder putte hvad som helst ind i de teams, som der lægges op til i bogen, fordi "det siger bogen jo". Også når det så viser sig, at de trade-offs, som I, kompetente mennesker, godt ved, vil være som en kæp i hjulet på organisationen, så vil der stå nogen og sige "I har gjort det forkert" eller endnu værre "det er ikke det, Conways lov siger". Fuldstændig som da Agile blev sat på flasker og solgt til virksomhederne.

En af de ting i bogen, som jeg virkelig finder tragikomisk, er den umiddelbare manglende forståelse for, hvad det egentlig vil sige at ændre på de vaner, strukturer og incitamenter, der gør, at en organisations kultur er, som den er. Det er de her små subtile ting, som ikke rigtig bliver taget for noget som helst i bogen, men som fylder alt i virkeligheden.

Jeg har f.eks. hjulpet organisationer, hvor titlen hos den enkelte ansatte var som en guldbarre i lommen på vedkommende. Og hvis du ville tage den væk fra vedkommende, så ville det næsten være som at fjerne en ikke ubetydelig mængde identitet. Det er jo et incitament for den ansatte, fordi organisationen er bygget omkring, at man kan blive til noget mere end man allerede er. Og det skal du altså ind og pille ved, hvis du skal lave om i en organisation.

En erfaring fra to virksomheder, jeg har hjulpet, er, hvor den såkaldte Spotify-model var blevet plastret på software-organisationen. Men fordi der åbenbart ikke kan være mere end en "høvding i stammen" (whatever det nu hedder) i den model, så lavede organisationen et trade-off og gjorde dem med nuværende manager-titel til høvdinge, så de på samme måde havde den samme plads i hierarkiet som tidligere. Og det er et trade-off, som har betydelig effekt på den model, man forsøger at påtage sig, fordi modellen lægger op til, at man ikke har flere høvdinge til at hindre bedre kommunikationsstrømme. Det er altså et trade-off, som ødelægger mere end det gavner i det tilfælde.

Så hvis man piller ved menneskers incitamenter, så skal man virkelig koncentrere sig. Det aspekt har bogen slet ikke sig, og det mener jeg sådan set er grundlæggende for overhovedet at forstå, hvordan en organisation er forankret, og hvordan den kan ændres. Også mener jeg også, at bogen, på vanlig arkitektonisk Big Up Front Design-vis, lægger op til store ændringer i stedet for at starte helt småt. Men det er også svært.

De forsøger at sælge muligheden med det, som der kaldes en "inverse Conway maneuver", som er en fin tanke, men som i praksis sjældent fungerer, fordi selvom den tager udgangspunkt i, at teams ejer mandatet til at skabe forandringer i deres eget tempo, ikke tager højde for de udfordringer, der eksisterer udenfor teamet, og som vil hæmme teamets eget formåen. Et godt eksempel er, at teamet, som udøver denne "inverse Conway maneuver" og f.eks. bygger et produkt, ikke har adgang til nøglepersoner andre steder i virksomheden, fordi designet i organisationen ikke er forankret på samme måde. Det oplevede jeg selv i en produktvirksomhed, hvor vi byggede et produkt i et lille sammentømret team, men hvor organisationen udenom teamet ikke var designet til, i dette tilfælde, at være til stede, når vi havde behovet.

Der er rigtig mange ting i den bog, som er interessante at diskutere, og det er mit bud, at det vil vi gøre i årene, som kommer.