Autonomie vs. externe sturing

Vrijwel elk groot technologiebedrijf is inmiddels op de trein gesprongen van zelfsturende, betrokken/stabiele, cross-functionele en goed samenwerkende productteams – en ik denk dat dat een goede zaak is. Je ziet nauwelijks nog een bedrijf dat de oude modellen gebruikt (voornamelijk het pool-model). Toch is het soms niet eenvoudig om de juiste balans tussen autonomie en sturing van buitenaf te vinden.

De resultaten spreken weliswaar voor zich, maar ik schrijf de meeste voordelen toe aan de verhoogde motivatie en het echte gevoel van eigenaarschap dat ontstaat wanneer teams het gevoel hebben dat ze zelf over hun werk kunnen beslissen.

Maar ook al vertellen teamleiders mij meestal dat hun teams zelfsturend en zelfstandig zijn, veel teamleden zien dat vaak anders. Als dat het geval is, probeer ik te achterhalen wat het team precies niet zelfstandig kan beslissen of waarin het zich beperkt voelt.

Waar ligt de grens tussen autonomie en sturing van buitenaf?

Meestal komt het neer op een van de volgende twee antwoorden:

Of het team geniet nog niet volledig het vertrouwen van het management en daarom wil het management de teamleden niet echt de vrije hand geven.

Of het team wil iets veranderen wat het management beschouwt als onderdeel van de basisafspraken.

In principe zullen alle teams het erover eens zijn dat er zowel dingen zijn die ze volledig zelf kunnen beslissen, als andere gebieden die deel uitmaken van de gemeenschappelijke basisvoorwaarden voor alle teams.

Een voorbeeld

In dat laatste geval zou het bijvoorbeeld zeer ongebruikelijk zijn als elk team een eigen versiebeheertool zou kiezen. Als het ontwikkelteam bijvoorbeeld GitHub als standaard heeft vastgesteld, wordt dat normaal gesproken gezien als onderdeel van de basisvoorwaarden. Zelfs als een team een sterke voorkeur voor een ander tool zou hebben, zouden de kosten de voordelen voor het bedrijf ruimschoots overtreffen.

Dit voorbeeld is vrij duidelijk, maar er zijn ook veel andere gevallen waar het niet zo helder is.

Zou elk team bijvoorbeeld testautomatisering op zijn eigen manier mogen aanpakken? Zouden teams individueel de programmeertaal mogen kiezen? Hoe zit het met het framework voor de gebruikersinterface? Hoe zit het met browsercompatibiliteit? Hoe zit het met dure features zoals 'offline-ondersteuning'? Zouden ze zelf mogen beslissen hoe 'agile' ze werken? En moet elk team echt bij meerdere productinitiatieven binnen het bedrijf betrokken zijn?

Zoals vaak het geval is bij producten, komt het uiteindelijk neer op een compromis – in dit geval een compromis tussen eigenaarschap en het naleven van de vastgestelde basisafspraken.

Hoewel ik in principe het principe van autonome en onafhankelijke teams sterk onderschrijf, ben ik toegegeven ook een groot voorstander van investeren in een goede basis. Met een solide gemeenschappelijke basis kunnen teams namelijk veel sneller geweldige producten en ervaringen creëren.

Ik wil dit compromis wat nader toelichten. Maar ik wil ook benadrukken dat ik niet beweer dat er maar één antwoord op deze vraag is, maar dat het bij elk bedrijf en elk team anders kan zijn. Alles hangt af van verschillende factoren die ik hier zal bespreken:

Punten om rekening mee te houden:

– De competentie van het team:

Daarbij zijn er grofweg drie verschillende situaties:

A-team – een ervaren team met slimme en creatieve mensen, waarbij je er volledig op kunt vertrouwen dat ze goede beslissingen nemen.

B-team – deze mensen hebben de juiste intenties, maar in veel gevallen nog niet de benodigde ervaring om goede beslissingen te kunnen nemen, waardoor ze nog wat ondersteuning nodig hebben.

C-team – een juniorteam dat misschien niet eens weet wat het niet weet. Zonder intensieve begeleiding kunnen deze teams onbedoeld voor grote problemen zorgen.

– Snelheid:

Een van de belangrijkste argumenten voor vaste richtlijnen is snelheid. De logica erachter is dat teams in staat moeten zijn om voort te bouwen op het werk van hun collega's, zodat ze geen tijd verspillen aan het opnieuw uitvinden van het wiel. In sommige gevallen is het echter algemeen geaccepteerd en gebruikelijk om teams toe te staan wat langzamer te werken en eventueel iets dubbel te doen, als daarmee de zelfstandigheid wordt bevorderd. Soms is het echter essentieel voor de business dat de richtlijnen worden nageleefd.

– Belang van integratie:

Bij sommige bedrijven bestaat het portfolio uit gerelateerde maar grotendeels onafhankelijke producten, waarbij integratie en richtlijnen niet bijzonder belangrijk zijn. Bij andere bedrijven gaat het portfolio om sterk geïntegreerde producten, waarbij bepaalde algemene richtlijnen onmisbaar zijn. Uiteindelijk komt het erop neer of een team zich op één specifieke oplossing moet richten of dat het een optimale oplossing moet vinden met het oog op het hele bedrijf.

– Bron van innovatie:

Als de belangrijkste bronnen voor toekomstige innovaties al bij de basis te vinden zijn, zouden teams meer vrijheid moeten krijgen om deze fundamentele elementen te heroverwegen. Als de oorsprong van innovaties echter op het oplossingsniveau ligt, zou het team zich minder op de basis en meer op creatieve innovaties op toepassingsniveau moeten richten.

– Bedrijfsgrootte en locaties:

Autonomie wordt vaak lastig wanneer er problemen bij het opschalen optreden. Wanneer bedrijven groeien en hun teams over verschillende locaties verspreid zijn, wordt het moeilijker maar ook belangrijker om bepaalde basisrichtlijnen vast te stellen. Sommige bedrijven proberen dit probleem op te lossen met het concept van een 'Center of Excellence' (competentiecentrum), waarbij een team dat samen aan een taak werkt, op één locatie wordt samengebracht. Anderen proberen het met meer holistische rollen. En weer anderen voegen processen toe.

– Bedrijfscultuur:

Ook bij de teamcultuur speelt de verhouding tussen autonomie en sturing van buitenaf een belangrijke rol. Hoe meer richtlijnen een bedrijf oplegt, hoe meer teams het gevoel hebben beperkt te worden in hun zelfstandigheid. Voor B-teams en C-teams is dat misschien nog acceptabel, voor A-teams is dat echter al wat problematischer.

– Volwassenheid van de technologie:

Te vroeg een uniforme basis voor iedereen willen vastleggen is een veelvoorkomend probleem. Als de basis namelijk nog niet volwassen is, kan deze niet de ondersteuning bieden waarvoor ze eigenlijk bedoeld was. Te hard aandringen op het naleven van richtlijnen voordat de basis echt af is, kan de teams die op die basis moeten vertrouwen echt schaden. Dat is hetzelfde als iets willen bouwen op een wankel kaartenhuis.

– Zakelijk belang:

Als we ervan uitgaan dat de basis solide is, zijn er meer risico's bij een team dat deze basis niet gebruikt. In sommige gevallen is dat niet zo erg. Maar als het gaat om producten of initiatieven die cruciaal zijn voor de business, moet je goed nadenken over waar je je op moet richten.

– Mate van verantwoordelijkheid:

Een andere factor is de mate van verantwoordelijkheid die gepaard gaat met zelfbeschikking en onafhankelijkheid. Als teams geen eigen verantwoordelijkheid dragen – en vooral als er geen sterke A-teams zijn – hebben de teams ook geen echte reden om bijzondere aandacht aan dit compromis te besteden. Maar je wilt wel dat teams nadenken over dit compromis. Als ik weet dat het team sterk is en volledig op de hoogte is van de risico's en consequenties, en toch een wezenlijk onderdeel van de basis wil negeren of vervangen, dan steun ik de teamleden in die beslissing.

Samenvatting

Zoals je ziet, zijn er veel punten waar rekening mee gehouden moet worden. Naar mijn mening zijn de meeste teams echter zeer redelijk als je deze onderwerpen openlijk bespreekt. Soms helpen een paar fundamentele vragen over de gevolgen het team al om betere beslissingen te nemen met betrekking tot dit compromis.

Als teams echter permanent slechte beslissingen hierover nemen, zou je nog eens moeten nadenken over het ervaringsniveau binnen het team en misschien meer tijd moeten investeren om ervoor te zorgen dat de teamleden ook echt alle zakelijke samenhangen begrijpen.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.