De lerende organisatie met João Rosa

Wat betekent "waarde leveren" eigenlijk?

Gien: Als je zegt dat teams hun volle potentieel moeten kunnen benutten om waarde te leveren, wat betekent waarde dan voor jou?

João Rosa: Waarde heeft een paar dimensies. De eerste en belangrijkste is de klant — de mensen die onze software gebruiken, of dat nu collega's van een andere afdeling zijn of mensen die voor een licentie betalen. Beantwoorden we aan hun noden? Is de digitale dienst die we leveren echt nuttig? Goede software kan onzichtbaar zijn: ik heb mijn eigen leven en ik wil geen tijd doorbrengen in een app waarmee ik moet worstelen om iets gedaan te krijgen.

De tweede dimensie is het team dat die software bouwt en onderhoudt. Zijn de mensen gelukkig? Is de codebase redelijk om mee te werken? Zijn de grenzen logisch? Leren mensen bij — niet alleen over nieuwe technologie, maar ook over het domein? Sterk gemotiveerde mensen leveren betere resultaten, en daar is ruim bewijs voor.

De derde is financieel. De meesten van ons werken in bedrijven binnen een kapitalistisch systeem — er moeten lonen betaald worden. Ik voel me ongemakkelijk bij "we bestaan om de aandeelhouderswaarde te verhogen" als het hele verhaal, maar ik erken ook dat een bedrijf zonder enige cashflow geen risico's kan nemen of in nieuwe richtingen kan investeren. Waarde moet dus werken over alle drie de dimensies: nuttige software, betrokken teams en een business die zichzelf in stand kan houden.

Gien: Wanneer ik bij softwareteams kom, merk ik vaak dat de band met de financiële realiteit van het bedrijf onderweg wat verloren is gegaan. Zie jij hetzelfde?

João Rosa: Ja. De vroege Agile-beoefenaars waren software engineers die code uitrolden en rechtstreeks van gebruikers hoorden wanneer er iets stuk was — ze kregen echte feedback en begrepen wat er op het spel stond. Wat er de voorbije 30 jaar gebeurd is, is dat bedrijven, vanuit een mindset uit de industriële revolutie, engineers zijn gaan isoleren. Je bent duur, dus je schrijft alleen code — andere mensen handelen de klanten af. Dat is vreemd als je erover nadenkt: burgerlijk ingenieurs die een brug bouwen, worden niet geïsoleerd van de vereisten waaraan die moet voldoen of van de kostenimplicaties van hun beslissingen. Waarom zouden we dat met software wel doen?

Een financiële dienstverlener in Brazilië waarmee ik werkte, heeft dat omgedraaid. Hun FinOps-rapportering was gekoppeld aan de verkoopcyclus — wanneer sales een grote klant binnenhaalde, kon het team precies zien wat de impact op de infrastructuurkosten zou zijn. Daardoor gebeurden architectuurdiscussies proactief: als we volgend kwartaal drie klanten als deze binnenhalen, moeten we onze architectuur herbekijken vóór de kosten exponentieel worden. Dat is het soort handelingsvermogen dat teams zouden moeten hebben.

Anti-patronen die teams beletten hun potentieel te bereiken

Gien: Als je het hebt over teams die hun volle potentieel bereiken, welke veelvoorkomende patronen zie je die dat verhinderen?

João Rosa: Het eerste is de mindset uit de industriële revolutie die mensen via extreme specialisatie omvormt tot taakuitvoerende machines. Sociale wetenschappers bestuderen dat al sinds de jaren veertig en vijftig. We zijn niet betrokken op het werk. Het team is de eenheid van levering — het heeft vaardigheden, het past zich aan en het vangt zijn eigen gaten op. Individuen isoleren in nauwe functies vernietigt dat.

Het tweede is teams isoleren van hun omgeving: hun klanten, hun kosten, hun strategische context. Teams hebben dat zicht nodig om goede beslissingen te nemen. Bouwen we voor product-market fit, waar bewust bochten afsnijden en kijken of het werkt de juiste keuze is? Of zitten we in een stabiel product waar kwaliteit en onderhoudbaarheid zwaarder wegen? Je kunt die vragen niet beantwoorden zonder het bredere plaatje te begrijpen.

Het derde is teams de tijd ontnemen om na te denken en te leren. De vrije vrijdagnamiddagen bij Google leverden enorm veel innovatie op — en toen ze die in naam van efficiëntie afschaften, daalde de innovatie. Bedrijven moeten speling voor leren financieren. Je kunt geen prijskaartje hangen aan iemand die naar een conferentie gaat en terugkomt met een idee dat verandert hoe het team werkt. COVID heeft thuiswerk versneld, wat overwegend positief was, maar het heeft ook veel tussentijd weggenomen — de wandelingen, de gesprekken, de ademruimte waarin ideeën ontstaan.

AI maakt dit allemaal urgenter. Code produceren was nooit de echte bottleneck — het juiste model van een probleem vinden wel. AI versterkt de doorvoer, wat betekent dat bedrijven die de besluitvorming niet naar hun teams hebben verdeeld, sneller dan ooit voorbijgestoken zullen worden door bedrijven die dat wel deden.

Handelingsvermogen versus autonomie — en waarom het onderscheid ertoe doet

Gien: Iets wat ik bij bedrijven blijf horen, is dat ze willen dat teams autonoom zijn. Maar als ik naar de teams kijk, hebben ze geen budget en heeft elke aankoop van een tool drie goedkeuringen nodig. Autonomie zonder handelingsvermogen is gewoon een rekruteringsverhaal.

João Rosa: Precies. Teams hebben handelingsvermogen nodig — maar ze moeten ook het web van afhankelijkheden begrijpen waarin ze zitten. Een start-up met 20 mensen kan bijna elke beslissing vrij nemen. Een bank met 2.000 mensen is een ander spel. Een wereldwijd bedrijf met 300.000 mensen is nog een heel ander spel. De eerste stap is dat web echt begrijpen — via Wardley Maps, user need maps, value stream mapping, wat dan ook dat je waardeketens blootlegt.

Wat teams echt nodig hebben, is geen onbeperkte autonomie maar duidelijke grenzen waarbinnen ze vrij kunnen handelen. Er is een mooi voorbeeld van Boeing, uit de tijd toen het nog echt een door engineers geleid bedrijf was. Een grote luchtvaartmaatschappij vroeg om een nieuw vliegtuig 200–300 kilogram lichter te maken om brandstof te besparen. Het topmanagement zei tegen de engineers: als je een kilo kunt besparen en het kost minder dan een paar duizend dollar, doe het dan gewoon — vraag het ons niet. De enige beperking was dat de veiligheid niet in het gedrang mocht komen. De engineers leverden een vliegtuig ruim onder het streefgewicht, zonder één overbodige goedkeuring. Dat is handelingsvermogen met duidelijke vangrails. Boeing heeft die cultuur weggegooid, met gevolgen die we goed kennen.

Het equivalent in software: een goedbetaalde engineer vertellen dat die geen vijftig dollar aan een tool mag uitgeven, of die laten wachten op een laptop die 20 minuten nodig heeft om Visual Studio te openen. De beslissing om engineers ondermaatse laptops te geven lijkt misschien een besparing, tot je de verloren uren berekent — je gooit uiteindelijk zeven of acht keer weg wat je bespaard hebt. Die microbeslissingen stapelen zich op, en ze wijzen allemaal naar dezelfde oorzaak: een managementmodel gebouwd op command-and-control, dat niet aan het potentieel raakt waarvoor het betaalt.

Waarom Team Topologies

Gien: Je hebt Team Topologies al een paar keer vernoemd. Wat spreekt je zo aan in dit model?

João Rosa: Team Topologies is interessant voor mij omdat het een patroontaal is — geen framework, geen proces. Net als domain-driven design geeft het je lenzen om naar een probleem te kijken en beslissingen te nemen. Het centrale inzicht dat in 2019 de zaken veranderde, was cognitieve belasting. Daarvoor sprak men alleen over feature teams en component teams. Team Topologies zette een stap terug en vroeg: wat als we teamstructuren ontwerpen rond cognitieve belasting?

Cognitieve belasting is altijd aanwezig in softwarewerk, omdat we altijd aan het leren zijn — niet alleen over tools, maar ook over de nuances van het domein. Die beperking verdwijnt nooit. En een value stream bestaat op een spectrum: sommige dingen zijn goed begrepen en grotendeels mechanisch, andere zijn erg experimenteel. Hoe meer je bezit, hoe hoger de cognitieve belasting. Dat vormt je architectuur: je moet geen eigen CRM bouwen als een marktoplossing 90% van je noden dekt — bouw alleen de 10% die echt onderscheidend is. In Amsterdam neem je misschien een standaard SAP-logistiekplatform en bouw je de speciale routering voor straten die 's avonds afgesloten worden, omdat dat het stukje is dat echt uniek is.

Wat Team Topologies ook goed doet, is bottlenecks blootleggen. Soms zit de bottleneck in je pipeline, soms in hoe je clouddiensten gebruikt, soms in de teamorganisatie. Het geeft je een visuele taal voor die gesprekken — vooral nuttig als je meer dan vijf teams hebt en probeert te redeneren over flow.

Enabling teams en de lerende organisatie

Gien: Een van de Team Topologies-concepten waar ik het vaakst naar grijp, zijn enabling teams — een tijdelijk team dat andere teams helpt om bij te leren of nieuwe tooling in gebruik te nemen. Zelfs als de klant nog nooit van Team Topologies heeft gehoord, introduceer ik dat patroon.

João Rosa: Het sluit rechtstreeks aan bij cognitieve belasting. Het oorspronkelijke onderzoek van John Sweller naar cognitieve belasting gebeurde in leeromgevingen, en dat is precies wat het hier toepasbaar maakt — softwareteams zijn altijd aan het leren. Junior engineers leren hun tools, maar elke engineer leert voortdurend bij over het domein. De beperking is nooit de code zelf; het is de nuances beheersen van het probleem dat je oplost.

Enabling teams doen ertoe op twee niveaus. Op teamniveau helpen ze groepen om nieuwe praktijken op te nemen — testautomatisering, cloudmigratie, containerisatie, wat de huidige golf ook is. Op organisatieniveau zijn ze een deel van wat een bedrijf tot een lerende organisatie maakt. Bedrijven die stoppen met leren, worden kwetsbaar. Toen Broadcom VMware overnam en de prijzen drastisch verhoogde, zaten veel bedrijven vast — deels omdat ze gestopt waren met experimenteren met alternatieven. De organisaties die goedkope experimenten waren blijven draaien op Kubernetes, OpenShift en verschillende cloudworkloads, stonden er veel beter voor. Enabling teams zijn een van de mechanismen die dat vliegwiel aan het draaien houden.

De fout die ik zie, is dat bedrijven enabling teams behandelen als een stok achter de deur voor compliance — ze zijn er om standaarden af te dwingen, niet om leren te verspreiden. Dat keert het hele doel om. Een enabling team bestaat om cognitieve belasting te verlagen en capaciteiten te verspreiden, niet om te controleren.

De rant: middenmanagers die hun koninkrijkjes beschermen

Gien: Wat frustreert je nog het meest aan teamorganisatie?

João Rosa: Middenmanagers die hun koninkrijkjes beschermen. Dat ene gedrag ontmantelt het teamconcept sneller dan bijna al het andere. Wanneer individuen boven de teams optimaliseren voor hun eigen positie in plaats van voor flow, loopt alles vast. Het komt neer op incentives: het managementmodel beloont de verkeerde dingen, dus krijg je het verkeerde gedrag.

Wat ik heb zien werken, is individuele middenmanagers vervangen door middenmanagementteams — kleine, cross-functionele groepen die zelf als team werken, in plaats van één persoon bovenaan een hiërarchie. Dingen beginnen anders te stromen wanneer de managementlaag ook een samenwerkende eenheid is.

Dit wordt urgenter, niet minder urgent. Technologie versnelt. Teams moeten naar productie kunnen pushen, observeren wat er gebeurt, aannames valideren of ontkrachten, en zich aanpassen — zonder een vergunning te hoeven vragen om te handelen. Elke overbodige poort in die cyclus maakt het bedrijf trager. Als organisaties die blokkades niet wegnemen, is het innovatietempo dat nodig is om concurrentieel te blijven gewoon niet haalbaar.

Wat betekent satisfying software voor jou?

João Rosa: We zien de enshittification van software in realtime gebeuren — platformen die advertenties en gamificatie blijven opstapelen tot ze ondraaglijk worden in gebruik. Dat is het tegenovergestelde van satisfying software. Satisfying software doet één ding goed en gaat dan uit de weg. Ze is onzichtbaar.

Ik werk met veel banken en ik zeg het hun onomwonden: niemand wil tijd doorbrengen in een bankapp. Mensen willen tijd doorbrengen met hun familie. Voor grote beslissingen — een huis kopen, grote investeringen — ja, dan wil ik een goede adviseur. Voor al de rest wil ik dat de software mijn leven automatiseert, alles wat verdacht is signaleert, en me verder met rust laat. Een bank verkoopt vertrouwen. De taak van de software is dat vertrouwen waar te maken en dan te verdwijnen.

Dat is de externe blik. Intern betekent satisfying software dat teams makkelijk dingen naar productie kunnen pushen, experimenten naast elkaar kunnen draaien, signalen uit de echte wereld oppikken en zich snel aanpassen. In plaats van eindeloos te discussiëren over welke architecturale aanpak de juiste is, zet je ze allebei in productie en kijk je wat overleeft. Kill your darlings en ga verder. Zo zijn de beste e-commercebedrijven in Nederland gegroeid — Bol.com, Coolblue, Booking.com — voortdurend A/B-testen, beslissingen bij de teams gelegd, continu leren uit productie. Dat kan alleen als je de besluitvorming naar de mensen duwt die het dichtst bij het werk staan.

Satisfying software, vanuit beide richtingen: onzichtbaar en vertrouwd door de mensen die ze gebruiken; makkelijk en versterkend voor de mensen die ze bouwen.