Veel leiders hebben geen delegatieprobleem. Ze hebben een communicatieprobleem.

Een project loopt vertraging op.

De manager vraagt waarom het werk nog niet klaar is. De medewerker antwoordt dat hij dacht dat iemand anders een deel zou uitvoeren. Een tweede collega dacht dat het tegen het einde van de maand moest gebeuren. De manager had eigenlijk volgende week verwacht.

Iedereen heeft gewerkt.
Toch is het resultaat niet wat de organisatie verwachtte.

Dit soort situaties zie ik ook in IT. Bij infrastructuurprojecten, migraties, securityverbeteringen en architectuurtrajecten kan technisch zeer competente mensen veel werk verzetten zonder dat het eindresultaat aansluit bij de oorspronkelijke verwachting.

Mijn eerste vraag is dan vaak niet: “Wie heeft zijn werk niet gedaan?”
Ik vraag: “Wat hebben we precies afgesproken?”

Delegatie begint vóór de taak wordt toegewezen

Delegatie wordt vaak voorgesteld als een managementvaardigheid.

Je hebt te veel werk. Je verdeelt een aantal taken over je team. Vervolgens verwacht je dat die taken worden uitgevoerd.

In de praktijk begint het probleem vaak eerder.
Een opdracht als:

“Kun jij dit project verder opnemen?”

kan voor twee mensen iets totaal anders betekenen.

Voor de ene persoon betekent het dat hij de technische uitvoering moet organiseren.
Voor de andere betekent het dat hij ook de planning, communicatie, budgetbewaking en eindverantwoordelijkheid krijgt.

Beiden kunnen na het gesprek overtuigd zijn dat ze dezelfde opdracht hebben gekregen.

Harvard Business Review beschrijft een vergelijkbaar probleem bij delegatie. Onduidelijke verwachtingen, doelen en criteria voor succes maken het moeilijk voor de persoon aan wie het werk wordt overgedragen om correct te handelen.

Daarom begin ik bij delegatie liever met duidelijkheid dan met vertrouwen.

Vertrouwen is belangrijk. Duidelijkheid bepaalt waarop dat vertrouwen uiteindelijk wordt gebaseerd.

Wat betekent “klaar”?

Een van de eenvoudigste vragen die een leider kan stellen, is tegelijk een van de meest waardevolle:

“Wat betekent succes voor jou?”

Stel dat je iemand vraagt om een Microsoft 365-migratie voor te bereiden.

Wanneer is die opdracht klaar?
Is de tenant technisch voorbereid?
Zijn de gebruikers gemigreerd?
Zijn de data overgezet?
Zijn de oude systemen uitgeschakeld?
Hebben alle gebruikers getest?
Is de documentatie bijgewerkt?
Is de helpdesk voorbereid op vragen?
Zijn de back-ups gecontroleerd?

Het antwoord op die vragen bepaalt de omvang van de opdracht.

Zonder die duidelijkheid kan iemand perfect werk leveren en toch de verkeerde uitkomst opleveren.

Dat is een communicatieprobleem.

Wie bezit het resultaat?

Een tweede vraag is:

“Wie is eigenaar van het resultaat?”

Dat lijkt vanzelfsprekend. In veel organisaties is het dat niet.

Er kunnen meerdere mensen betrokken zijn bij een project. Eén persoon configureert de infrastructuur. Een andere beheert de applicatie. Een derde communiceert met de leverancier. De projectmanager bewaakt de planning.

Wie is verantwoordelijk wanneer het eindresultaat niet werkt?
Hier wordt het verschil tussen activiteit en ownership zichtbaar.

Tien mensen kunnen aan een project werken. Het eindresultaat heeft vaak één duidelijke eigenaar nodig.

Ook Harvard Business Review wijst bij delegatie op het belang van expliciete accountability en duidelijkheid over de bevoegdheid die bij die verantwoordelijkheid hoort.

Voor mij is dat een belangrijk principe binnen IT-architectuur.

Een Infrastructure Architect hoeft niet iedere configuratie zelf uit te voeren. Hij moet wel begrijpen wie verantwoordelijk is voor welk resultaat, welke beslissingen genomen moeten worden en waar de grenzen van die verantwoordelijkheid liggen.

Dat vraagt communicatie.

“Wanneer verwacht je dit?”

Een derde vraag lijkt banaal:

“Wanneer verwacht je dit realistisch te kunnen opleveren?”

Het woord realistisch is daarbij belangrijk.

Een manager kan een deadline in zijn agenda zetten.

De persoon die het werk moet uitvoeren heeft vaak informatie die de manager niet heeft.

Misschien is er nog een afhankelijkheid van een leverancier. Misschien moet eerst een firewall worden aangepast. Misschien ontbreekt documentatie. Misschien moet een collega een deel van de configuratie voorbereiden.

Een deadline die tijdens een vergadering wordt uitgesproken, is nog geen realistische planning.

Daarom vind ik het nuttiger om de uitvoerder zelf een inschatting te laten geven.

Harvard Business Review beschrijft hetzelfde principe bij delegatie: timing moet onderdeel zijn van het gesprek en de persoon die het werk uitvoert moet zijn inschatting kunnen geven.

Dat maakt een gesprek concreter.

De vraag die ik vaker zou stellen

Er is één vraag die ik bijzonder sterk vind:
“Wat heb je mij horen zeggen?”

Ik gebruik die vraag graag omdat ze een probleem zichtbaar maakt dat anders verborgen blijft.

De leider kan na een vergadering denken:
“Dat was duidelijk.”

De medewerker kan hetzelfde denken:
“Ik weet wat ik moet doen.”

Pas wanneer beide versies naast elkaar worden gelegd, wordt duidelijk of er werkelijk overeenstemming bestaat.

Je kunt deze vraag stellen zonder iemand te controleren.
Je kunt haar gebruiken om te testen of je eigen communicatie voldoende duidelijk was.

Dat onderscheid vind ik belangrijk.

Als iemand mijn uitleg verkeerd heeft begrepen, is mijn eerste reflex niet om de ander onmiddellijk als incompetent te beoordelen. Ik wil eerst weten welke informatie ik heb gegeven en welke interpretatie daaruit is ontstaan.

De bron die ik voor dit artikel als vertrekpunt gebruikte, beschrijft dezelfde aanpak: laat de andere persoon samenvatten wat hij of zij heeft begrepen.

Dat is een eenvoudige vorm van alignment.

Dit geldt misschien nog sterker voor IT

In IT werken we voortdurend met abstracte opdrachten.
“Maak de omgeving veiliger.”
“Bereid de cloudmigratie voor.”
“Verbeter de infrastructuur.”
“Zorg dat de gebruikers kunnen werken.”
“Maak een back-up.”
“Documenteer de omgeving.”

Technisch klinken deze opdrachten logisch.
Operationeel zeggen ze weinig.

Wat betekent veiliger?
Welke risico’s moeten worden aangepakt?
Welke systemen vallen binnen de scope?
Welke risico’s accepteren we?
Wat betekent klaar?
Wanneer is de migratie geslaagd?
Wie valideert de resultaten?
Wie beslist dat de oude omgeving mag worden uitgeschakeld?

Bij een cloudmigratie kunnen bijvoorbeeld ook ogenschijnlijk kleine details grote gevolgen hebben. In een eerdere migratie die ik beschreef, moesten bestandsnamen en mappenstructuren eerst worden aangepast aan de beperkingen van SharePoint. Tijdens de migratie moesten bestanden bovendien beschikbaar blijven voor medewerkers en moesten wijzigingen worden gesynchroniseerd.

Dat soort details bepaalt uiteindelijk of een project werkt.

Daarom begint een goede IT-architectuur voor mij altijd met het begrijpen van de behoefte en de randvoorwaarden.

Technologie komt daarna.

Communicatie is onderdeel van architectuur

Dat is misschien een ongemakkelijke gedachte voor technische mensen.

We praten graag over architectuurdiagrammen, configuraties, security controls, workloads, netwerken en platformen.

Maar een architectuur kan technisch correct zijn en toch mislukken wanneer de betrokken mensen verschillende verwachtingen hebben.

Dat geldt ook voor governance.

Een securitybeleid kan uitstekend zijn opgesteld. Als niemand begrijpt wie een uitzondering mag goedkeuren, wie verantwoordelijk is voor opvolging en wanneer een risico moet worden geëscaleerd, ontstaat er alsnog een probleem.

Communicatie is daarom geen zachte aanvulling op technische competentie.

Het bepaalt hoe technische beslissingen worden uitgevoerd.

In mijn eigen visie op de rol van Infrastructure Architect hoort communicatie dan ook bij de kerncompetenties. Technische kennis moet worden aangevuld met inzicht in bedrijfsprocessen, projectmanagement, documentatie en communicatieve vaardigheden.

Dat wordt belangrijker naarmate je verder van de pure uitvoering komt.

Een engineer kan een probleem oplossen.

Een architect moet daarnaast kunnen uitleggen waarom het probleem bestaat, welke keuzes beschikbaar zijn, welke gevolgen die keuzes hebben en wie welke beslissing moet nemen.

Delegatie vraagt ook ruimte

Er zit nog een tweede kant aan dit verhaal.
Duidelijke communicatie betekent niet dat de leider vervolgens iedere beslissing blijft controleren.

Wanneer iemand verantwoordelijkheid krijgt, moet ook duidelijk zijn welke beslissingen die persoon zelf mag nemen.
Dat is een punt waarop delegatie regelmatig vastloopt.

De leider zegt:

“Jij bent verantwoordelijk.”

Maar blijft vervolgens iedere beslissing zelf goedkeuren.
Dan ontstaat er een vreemde situatie. De verantwoordelijkheid ligt bij de medewerker, terwijl de beslissingsruimte bij de manager blijft.

Harvard Business Review beschrijft dit als een van de redenen waarom delegatie kan mislukken. De persoon aan wie een taak wordt toevertrouwd moet weten hoeveel ruimte hij of zij heeft om zelfstandig te handelen.

Voor een IT-project kan dat bijvoorbeeld betekenen:

• jij bent eigenaar van de migratieplanning;
• je mag leveranciers rechtstreeks aanspreken;
• wijzigingen boven een bepaald budget vereisen goedkeuring;
• security-uitzonderingen worden door de CISO of verantwoordelijke manager beslist;
• je rapporteert wekelijks over voortgang, risico’s en beslissingen.

Dat is veel duidelijker dan:

“Neem dit project maar over.”

De kosten van onduidelijkheid

Slechte communicatie verschijnt zelden als een aparte kostenpost op een factuur.

Ze verschijnt als iets anders.

Een project loopt twee weken uit.
Een engineer werkt een configuratie opnieuw uit.
Twee medewerkers onderzoeken hetzelfde probleem.
Een leverancier krijgt tegenstrijdige instructies.
Een migratie wordt opnieuw uitgevoerd.
Een securitymaatregel wordt pas ingevoerd nadat een incident heeft plaatsgevonden.
Een manager krijgt pas informatie wanneer het probleem al groot is.

De technische oorzaak kan iedere keer anders zijn.

Het patroon is hetzelfde: verwachtingen, eigenaarschap of prioriteiten waren onvoldoende afgestemd.

Dat sluit aan bij mijn eigen ervaring met infrastructuur en IT-strategie. Wanneer technische problemen zich blijven herhalen, kijk ik daarom ook naar processen, verantwoordelijkheden en communicatie. Technologie is slechts één onderdeel van het systeem waarin het probleem ontstaat.

Vier vragen die ik voortaan standaard zou stellen

Voor belangrijke opdrachten hoeft een leider geen ingewikkeld delegatiemodel te introduceren.

Ik zou beginnen met vier vragen:

1. Wat betekent succes?
Maak duidelijk wat het gewenste resultaat is.

2. Wie is eigenaar van het resultaat?
Benoem één persoon die verantwoordelijk is voor de uitkomst.

3. Wanneer verwacht je het realistisch op te leveren?
Laat degene die het werk uitvoert de haalbaarheid inschatten.

4. Wat heb je mij horen zeggen?
Controleer of de boodschap daadwerkelijk is aangekomen zoals bedoeld.

Die laatste vraag vind ik persoonlijk de krachtigste.
Omdat ze de verantwoordelijkheid voor duidelijke communicatie ook bij de leider legt.

Leiderschap wordt zichtbaar in wat anderen begrijpen

Ik geloof dat veel discussies over delegatie te snel naar medewerkers kijken.

Heeft iemand voldoende initiatief?
Is iemand wel verantwoordelijk genoeg?
Waarom moest ik dit opnieuw uitleggen?
Waarom heeft niemand dit gezien?

Soms zijn die vragen terecht.

Maar voordat ik die conclusie trek, wil ik eerst mijn eigen communicatie controleren.

Heb ik het gewenste resultaat beschreven?
Heb ik de verantwoordelijkheid duidelijk toegewezen?
Heb ik voldoende beslissingsruimte gegeven?
Heb ik de prioriteit uitgelegd?
Heb ik een realistische timing afgesproken?

En vooral:

Heb ik gecontroleerd wat de andere persoon daadwerkelijk heeft begrepen?

In infrastructuur, IT-strategie, enterprise architecture en governance zie ik telkens dezelfde relatie tussen techniek en organisatie. Mensen kunnen zeer bekwaam zijn en toch verschillende verwachtingen hebben. Het gevolg kan vertraging, dubbel werk, onzekerheid en verlies aan vertrouwen zijn.

Daarom is mijn stelling eenvoudig:

Veel leiders hebben geen delegatieprobleem. Ze hebben een communicatieprobleem.

En misschien is de beste manier om dat probleem te ontdekken verrassend eenvoudig.

Vraag na je volgende belangrijke vergadering:

“Wat heb je mij horen zeggen?”

Het antwoord kan meer vertellen over je leiderschap dan de vergadering zelf.