Hoe omgaan met rotte appels binnen zelforganiserende teams?

 

Wie kent ze niet? Teamleden die niet functioneren. Rotte appels. Iedereen heeft binnen IT tegenwoordig de mond vol van zelfsturende, of zelfs zelforganiserende teams. Teams waar geen manager meer nodig is en waar (team)problemen door het team zelf worden opgelost. Als er sprake is van een high performing team dan werkt dat ook: ultieme resultaten in optimale harmonie. Maar wat nou als er een spelbreker ontstaat: iemand functioneert niet. Zij het door onvoldoende bekwaamheid, hetzij door een motivatieprobleem?

Ikzelf voetbal in een machtig mooi voetbalteam: IJsselmeervogels 6. Resultaten zijn in zekere zin ondergeschikt aan het gezellig met elkaar voetballen. Natuurlijk, je wilt altijd graag winnen, maar als het laatste fluitsignaal heeft geklonken veranderen de prioriteiten. Het gaat dan, niet zoals bij een eerste elftal of bij een profclub direct weer over de volgende wedstrijd, iedereen laaft zich in de gezelligheid van de zogenoemde ‘derde helft’. High performance is daarmee een relatief begrip, maar dit team is – in tegenstelling tot hogere teams – wel in staat om zelforganiserend te werk te gaan.

Ben je als teamspeler van een lager seniorenelftal niet goed genoeg om mee te komen met het niveau, dan is dat vooral voor jezelf vervelend. Bovendien: er is het mooie bestaan van een brede selectie. Pas je niet binnen de teamcultuur: geen zorgen, want er is bier. Kortom: problemen worden door het team zelf opgelost en daar is niet zoiets als een hiërarchische structuur voor nodig. Je hebt specialisten in je team, waarbij er een aantal capaciteiten heeft om training te geven, anderen dusdanig tactisch onderlegd zijn om een goede opstelling in elkaar te draaien en is persoon A er niet, dan wordt dat moeiteloos opgevuld door persoon B.

Echter niet alles is vergelijkbaar, want binnen IT heb je geen bank met wisselspelers die je tijdens een dood spelmoment ‘even snel’ wisselt met je startopstelling. Je hebt wel zoiets als specialisten die ‘op de bank’ zitten, maar waar je bij het voetbal makkelijk kunt wisselen, zit dat in de IT iets anders. Iets minder flexibel. Wellicht een aandachtspunt voor de Agile toekomst van IT?

Maar dan heb je dus toch ineens dat probleem van een niet functionerende IT’er. Daarin zijn twee varianten (en, om de kritische lezer voor te zijn: mengvormen en oorzaak-gevolgtrekkingen daartussen). Deze:
1. Een teamlid is niet gemotiveerd;
2. Een teamlid is niet bekwaam.

Wanneer een teamlid niet bekwaam is dan kan dat een aantal oorzaken hebben. Een teamlid is – niet conform de principes van zelforganisatie –  door de organisatie aan jouw team opgedragen óf is via een intakegesprek door de teamleden geaccepteerd, maar blijkt toch een achterstand te hebben. Wat je als team kunt doen is die persoon aan de arm nemen om hem up-to-speed te brengen met het team. We zijn als mens immers van nature behulpzaam en willen het team graag ‘laten werken’. En daar komt bij: iemand is niet 100% rot, dus gun je hem of haar vaak die kans. Hoeveel tijd trek je daar echter voor uit? In de tijd die je uittrekt om diegene op niveau te helpen kan de rest van het team immers ook alweer een niveau-stijging ondergaan hebben. En hoe motiverend is het voor de rest van het team als het uiteindelijk toch niet blijkt te lukken?

Wat nou als een teamlid niet gemotiveerd is? De kantjes er vanaf loopt, in plat Nederlands. Enorm frustrerend voor de overige teamleden en erger nog: uiteindelijk gaan die teamleden er ook anders door handelen. Ze gaan extra op hun tenen lopen om afgesproken resultaat te boeken, of ze raken dusdanig geëmotioneerd van dit onrecht dat ze willen stoppen binnen het team. Kortom: een omgeving met weinig harmonie en ook mindere resultaten.

Al snel ben je het er onuitgesproken als team over eens dat een teamlid het team uit moet. Maar dan? Wie ben jij immers om dat oordeel te vellen? Je lijdt er weliswaar zelf onder, maar wie ben jij als gelijkwaardige om te beslissen over zijn boterham van morgen? De makkelijke weg is om naar het management te stappen. Die lossen het vaak ook wel op. Echter, dat past precies niet in de systematiek van zelforganiserende teams. Die kennen immers geen manager.

De beslissing zal binnen zo’n zelforganiserend team dan ook uit het team moeten komen. Dat kan in de vorm van een retrospective. Een reflectievorm die voor Agile-Scrum-lezers vast bekend is, maar wat het best uit te leggen is als een periodiek terugkerende terugblik op de resultaten van de afgelopen periode. Qua product, maar vooral qua team en samenwerking. Een variant hiervan is de ‘Moving Motivators’, die zich erg richt op motivatie van teamleden.  Een ander alternatief is het gesprek aan gaan. Feedback geven zou moeten passen in alle situaties, zolang je het maar vertelt vanuit wat het met jou als persoon doet. Advies is ook om niet te lang te wachten met dit soort acties, want als je iets lang laat staan, dan gaat het rotten…

Voel je vrij om aanvullingen en ervaringen te delen!

Mijn dank gaat uit naar mijn collega’s van de Unit Requirements bij Ordina, die mij naar aanleiding van een presentatie waarin deze open vraag ter sprake kwam hebben geholpen met het geven van deze antwoorden. 

Stephan Nagel

Stephan Nagel

requirements analist at Ordina
Stephan (1985) is sinds 2007 werkzaam als informatie-analist in de IT. Daarnaast is hij al ruim tien jaar betrokken als communicatie-expert bij IJsselmeervogels.

Meer info: https://www.linkedin.com/in/stephannagel85/
Stephan Nagel
Hoe omgaan met rotte appels binnen zelforganiserende teams?

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *