Vijf dynamieken van een goed functionerend team

Uit een onderzoek van Google uit 2015 blijken de volgende vijf dynamieken het meest bij te dragen aan een goed functionerend team: (1) psychologische veiligheid; (2) betrouwbaarheid; (3) structuur en helderheid; (4) betekenis, en (5) impact. De dynamieken zijn geordend in aflopende volgorde van belangrijkheid.

Veiligheid en betrouwbaarheid

Psychologische veiligheid wil zeggen: de mate waarin iedereen in het team zich vrij voelt risico te nemen en zich kwetsbaar op te stellen. Denk aan: een junior ontwikkelaar durft de beslissing van een senior ontwikkelaar in vraag te stellen. Of: een ontwikkelaar durft toe te geven dat deze een fout heeft gemaakt die impact heeft gehad op productie. Of: een teamlid – elk teamlid – durft toe te geven dat hij of zij iets niet weet.

Psychologische veiligheid wil niet zeggen: afwezigheid van conflict. In teams waarin nooit conflict is, worden meningsverschillen onder het tapijt geschoven, waar ze gaan etteren en op termijn grotere problemen opleveren. In psychologisch veilige teams worden conflicten juist openlijk uitgevochten – op de inhoud, niet op de persoon.

Betrouwbaarheid wil zeggen: het team levert op tijd kwalitatief hoogwaardig (genoeg) werk op. Als het team zegt: gaan we doen, dan gaan ze het doen. Als het team heeft gezegd dat ze het gaan doen, maar ze blijken het niet te kunnen doen, dan geven ze dat tijdig aan.

Structuur en helderheid

Structuur en helderheid wil zeggen: teamleden hebben duidelijke rollen1, plannen en doelen. Het team weet wat er van haar verwacht komt en hoe daar te komen. Wanneer iets onduidelijk is, dan weet het team hoe duidelijkheid te scheppen. Het is duidelijk wat de gevolgen zijn wanneer er niet aan de verwachtingen wordt voldaan.

Maar structuur en helderheid wil niet zeggen: iedereen heeft zijn toegewezen verantwoordelijkheid en interesseert zich alleen voor dat stukje. Het hele team deelt verantwoordelijkheid voor de uitkomst en dat betekent dat de een soms de taak van de ander overneemt. Het punt is: het team weet dat en stemt continu met elkaar af.

Het proces van softwareontwikkeling is inherent onzeker – we weten per definitie niet of de oplossing die we programmeren, de juiste is. Maar die onzekerheid kan alleen worden gedragen tegen een achtergrond van zekerheid – we weten wie wat wanneer moet doen om te valideren of onze oplossing de juiste is.

Betekenis en impact

Betekenis wil zeggen: de teamleden halen iets uit het werk.2 Dat kan van alles zijn: het plezier van het analyseren, coderen of testen; het gevoel onderdeel te zijn van een groter geheel, financiƫle zekerheid. Het werk is meer dan een pijnlijk laat-kapitalistisch ritueel om de tijd mee te vullen tot je pensioen.

Impact wil zeggen: het werk van het team maakt een verschil, of het team heeft op zijn minst het idee dat het dit doet. Als het werk gedaan is – de feature opgeleverd, de bug gefixt –, dan is het leven van de relevante gebruikers een stukje beter geworden.

Betekenis en impact hangen vaak samen. Werk met weinig impact wordt vaak als weinig betekenisvol ervaren.

Vragen

Hoe scoort mijn team op deze dynamieken? Voelt iedereen zich veilig genoeg om zich uit te spreken? Waarom hoor ik sommige mensen minder tijdens refinements? Zou ik vaker mijn mond moeten houden en hun om hun mening moeten vragen? Vinden onze stakeholders dat we goed werk leveren? Ze knikken beleefd tijdens de Reviews, maar zijn ze ook echt blij met ons werk?

Wat als we een incident hebben op productie? Weet iedereen dan wat hij moet doen? En als we er een gehad hebben, dan zou ik een post mortem verwachten. Ben ik de enige die er zo in staat? (We hebben – ondanks of dankzij het feit dat we dagelijks meermaals uitrollen – gelukkig maar zelden incidenten op productie.)

Waar haalt iedereen betekenis uit in zijn werk? Weten we dat van elkaar? Voeren we dat gesprek ooit? En als we dit doen – of juist niet –, wat gebeurt er dan? Op wie heeft dit invloed? Wat is hun rol in het systeem waar onze software onderdeel van is? Weten we dat? Kunnen we dat uittekenen?

Een team is nooit af – een goed functionerend team al helemaal niet, dunkt me.


  1. Eenvoudige labels als ontwikkelaar, tester of architect geven niet of nauwelijks richting aan de vraag hoe deze ingevuld dienen te worden; zie ook deze blog. ↩︎

  2. Boekentip in deze hoek: Being at Work van Mark Cole, waarin de auteur werk analyseert vanuit een existentialistische lens. Klik hier voor mijn recensie. ↩︎

betekenis · psychologische veiligheid · teamcultuur