We hebben het er hier al vaker over gehad: door IT te automatiseren schakel je rework uit en dring je tijdverlies terug. Maar wat doet je team met die gewonnen tijd? We moeten namelijk ook rekening houden met de mentale belasting van het team. Wat zijn de gevolgen wanneer die ‘cognitive load’ te zwaar doorweegt? En hoe verander je dat, zodat je teams weer doen wat ze moeten en willen doen?
Laten we de full-stack developer als voorbeeld nemen. Alle respect voor wie die job doet, want hij of zij moet in heel uiteenlopende domeinen beslagen zijn. Dat is niet alleen heel moeilijk, het is eigenlijk ook gewoon een slecht idee. Want eerlijk, een mens houdt dat niet vol. Vroeg of laat ervaart de full-stack developer een te zware mentale belasting.
Wat zijn de gevolgen?
Die te zware cognitive load is vrij makkelijk te herkennen. Je merkt het aan medewerkers die van de hak op de tak springen, zich van hot naar her haasten, door de bomen het bos niet meer zien. Je merkt het aan developers die de hele dag druk in de weer zijn, maar tegelijk erg weinig gedaan krijgen, omdat ze zich met veel te veel nevenzaken moeten bezighouden.
Die zware mentale belasting zorgt ervoor dat mensen geen plezier meer vinden in hun werk. Ze halen er geen energie meer uit. Op de lange duur zijn ze alleen nog met nevenzaken bezig, komen ze niet meer aan het echte werk toe. En als je daar als werkgever niets aan doet, laten de gevolgen zich raden: mensen krijgen een burn-out of ze vermijden er één door het bedrijf te verlaten.
Wat kan je eraan doen?
Daarvoor nemen we de organisatie van teams onder de loep, geïnspireerd door het boek Team topologies van Matthew Skelton en Manuel Pais. De auteurs vertellen hoe je je business- en technologieteams optimaal organiseert. Wij focussen hierbij uiteraard op IT-teams.
Blijkt de cognitive load voor één IT-team te groot, omdat het met te veel verschillende zaken bezig moet zijn? Dan splits je dat team volgens Skelton en Pais beter op in verschillende kleinere teams, die zich elk op één domein focussen. Onder meer Spotify werkt zo. Achter de app lijkt één groot team schuil te gaan, maar in realiteit gaat het om een groep van teams. Eén team is daarbij enkel verantwoordelijk voor de player, een ander enkel voor de aanbevelingen, enzovoort. Elk team heeft één verantwoordelijkheid, waar het ten volle voor gaat. Maar het team blijft altijd binnen die grens, om de externe mentale belasting zo minimaal mogelijk te houden.
Die externe mentale belasting werk je dan verder weg door zo veel mogelijk taken te automatiseren, met name als ze niets te maken hebben met het specifieke domein van het team.
Werken de teams zo niet te veel naast elkaar?
Dat is inderdaad een risico. Vandaar dat de auteurs van Team topologies vier types teams onderscheiden. Een stream-aligned team is gefocust op één domein. Het platform-team zorgt voor het platform dat alle apart ontwikkelde onderdelen combineert en automatiseert. Enabling teams kennen de gebruikte technologie door en door, en enablen stream-aligned teams om met nieuwe features te ontwikkelen. Een complicated-subsystem team, ten slotte, specialiseert zich in technologie die de andere teams niet noodzakelijk in detail moeten kennen.
Die verschillende teams communiceren op drie manieren met elkaar: enabling en facilitating, maar ook collaborating en zo veel mogelijk in termen van ‘X-as-a-Service’. Elk team bouwt zijn deel van de oplossing, documenteert alles en biedt het resultaat als een dienst aan de andere teams. Als elk team zo zijn verantwoordelijkheid opneemt, kom je snel tot resultaten, zonder het risico op overdreven externe mentale belasting.
Geef eerst je communicatie vorm
We moeten het hier ook nog even over de wet van Conway hebben. Die beschrijft het verband tussen de communicatiestructuur van een organisatie en de systemen die zij ontwerpt. Eenvoudig gesteld, zegt de wet van Conway dat een systeem zich vormt naar het model van de communicatiekanalen binnen je organisatie.
De auteurs van Team topologies draaien dat om. Zij kijken eerst naar de communicatie en samenwerking, zodat daar uiteindelijk de IT-architectuur uit voorkomt die je nodig hebt. Als veel zaken los van elkaar moeten functioneren, stimuleer je het gebruik van ‘X-as-a-Service’. Of je stimuleert net samenwerking, als je wilt dat ontwikkelde onderdelen samenhangen. Op die manier hou je tegelijk de cognitive load onder controle.