Hoe je je besluitvormingsprocessen verbetert, met Andrea Magnorsky

Satisfying Software – Andrea Magnorsky - Transcriptie

Waarom bedrijven moeite hebben om goede beslissingen te nemen

Gien: Waarom denk je dat bedrijven slecht zijn in beslissingen nemen?

Andrea: Ik vraag me af of bedrijven hun beslissingen wel goed genoeg begrijpen om te weten of ze goede beslissingen nemen. Ze hebben misschien uitgebreide processen, maar de echte redenen achter die beslissingen gaan vaak verloren in de vertaling — of er wordt iets anders vastgelegd. Of de grote beslissing wordt opgesplitst in zoveel kleinere decision records dat je door de bomen het bos niet meer ziet. Mij interesseert vooral hoe je die bomen van beslissingen kunt opvolgen.

Gien: Ik heb gelijkaardige dingen gemerkt. Bedrijven hebben soms een framework en denken: dat volstaat. We hebben een proces, we volgen het, en op het einde komt er een goede beslissing uit. Maar het proces stuurt maar een klein deel ervan. De analyse, het genereren van opties — dat is er gewoon niet. Of het probleem klopt helemaal niet: de beslissing die je probeert te nemen is op zich prima, maar ze lost je probleem niet echt op.

Andrea: En het begint niet bij het probleem. Tegen de tijd dat je met iemand over een beslissing praat, vraag je waar het probleem besproken werd — en dan blijkt dat John een document van 35 pagina's schreef, maar dat niemand het gelezen heeft. Er is een neiging om problemen op te splitsen en te delegeren om efficiënter te zijn, maar zo verdwijnt het gedeelde begrip van de probleemruimte, het genereren van opties en de eigenlijke beslissing zelf. Een beslissing die niet uitgevoerd wordt, is niet echt een beslissing. En als ze "genomen" is maar niemand er gevolg aan gaf, dan hebben verschillende mensen totaal verschillende versies van wat er gebeurd is. De waarheid leeft uiteindelijk alleen nog in de software — begrepen enkel door mensen die ver van de oorspronkelijke besluitvorming af staan.

Decision records: nuttig maken in plaats van ceremonieel

Gien: Een beslissing achteraf communiceren — op zijn minst zorgen dat iedereen die het moet weten geïnformeerd is — schiet erg tekort. En als ik naar Architectural Decision Records in bedrijven kijk, dan is er vaak geen enkele richtlijn over hoe je een probleem eigenlijk analyseert, opties genereert en toewerkt naar een uiteindelijke keuze. De ADR-template is er, maar zegt niets over het proces om tot een beslissing te komen.

Andrea: Het probleem wordt erger in grotere bedrijven, waar mensen een framework krijgen met de opdracht het te gebruiken — zonder enig idee van de granulariteit waarop ze moeten werken of hoe ze er zinvol mee aan de slag gaan. Wat ik heb zien werken, is decision records invoeren niet als een formulier om in te vullen, maar als een iteratief proces. Je schrijft een ontwerp, voegt toe wat je weet over de context, lijst voor- en nadelen op, stelt vragen en nodigt de mensen uit die erdoor geraakt worden. Itereer. Gebruik een of ander forum — synchroon als het kan, zeker in het begin — waar mensen met het document aan de slag kunnen en opmerkingen behandelen voor het aanvaard wordt. En wees expliciet over de schaal van de beslissing die je documenteert: een beslissing binnen een team ziet er anders uit dan een die meerdere teams raakt, ook al is het skelet gelijkaardig.

Gien: Iets wat ik vaak hoor, is dat teams die verantwoordelijk zijn voor een beslissing wél input van anderen willen — het gaat hen raken — maar dat ze nooit een reactie krijgen. En als ik vraag hoe ze feedback gezocht hebben, zeggen ze dat ze een link naar de pagina gestuurd hebben en om opmerkingen gevraagd hebben wanneer mensen tijd hadden. Dat is zo vaag dat het bijna gegarandeerd mislukt.

Andrea: Precies daarom denk ik dat je synchroon moet beginnen. Overschakelen naar asynchroon werkt zodra mensen weten hoe goed eruitziet — zodra ze geleerd hebben om zinvol met een decision record om te gaan. Als je meteen asynchroon gaat zonder voorbeeld van hoe nuttige feedback eruitziet, verlies je alles in de vertaling. De template en de naamgeving doen er minder toe dan je denkt; of het nu een ADR, een RFC of het eigen formaat van je bedrijf is, maakt niet uit. Wat telt, is dat het genoeg context bevat zodat iemand die het over zes maanden leest, kan inschatten of de omstandigheden genoeg veranderd zijn om het te herbekijken. Dat betekent niet tien pagina's — het betekent de juiste inhoud.

Gien: En beknopt schrijven is echt moeilijk. Ik gebruik visualisatietechnieken — pro-con mapping en een paar andere frameworks — zodat tegen de tijd dat we de beslissing doorgewerkt hebben, het grootste deel van de inhoud er al is en ik ze rechtstreeks in het record kan gieten zonder veel extra werk. Maar het blijft werk.

Andrea: Zelfs met een framework kost het tijd om het grondig te doorlopen. En hoe meer mensen erbij betrokken zijn, hoe langer alles duurt — niet alleen om hen erbij te betrekken, maar ook omdat een beslissing die veel mensen raakt, doorgaans ook langer duurt om uit te voeren.

De juiste mensen betrekken — en niet meer dan dat

Gien: Mensen kunnen vaak geen onderscheid maken tussen de verschillende niveaus van betrokkenheid. Sommige mensen hebben essentiële kennis — zonder hun input kun je echt geen goede beslissing nemen. Anderen kunnen asynchroon iets nuttigs bijdragen. En sommigen moeten gewoon achteraf geïnformeerd worden. Maar organisaties hebben de neiging om die categorieën op één hoop te gooien en iedereen op dezelfde manier te betrekken.

Andrea: En de verkeerde stakeholders betrekken kan een beslissing volledig laten ontsporen. Als er iemand van de C-suite opduikt — misschien omdat je hoopte dat hun aanwezigheid zou helpen met invloed — verschuift de dynamiek in de zaal. Mensen vallen stil, of ze schikken zich naar de meest senior stem. De discussies die moeten plaatsvinden, vinden niet meer plaats. Het is het HIPPO-probleem: de Highest Paid Person In the room heeft de neiging gesprekken te doen krimpen, of dat nu door instemming of door stilte is.

Gien: En soms voelt de HIPPO druk om een mening te hebben omdat mensen dat van hem verwachten — zelfs als de reden voor de uitnodiging enkel was om geïnformeerd te worden. In dat geval kun je die persoon uit de hele discussie halen en gewoon achteraf een e-mail sturen.

Andrea: Hun positie is wel echt moeilijk. Senior leiders nemen veel beslissingen onder grote onzekerheid, en ze zijn gewend om zeker over te komen — of toch minstens vertrouwen uit te stralen — wat heel anders kan overkomen op een zaal vol mensen die hun denkwerk zorgvuldiger willen valideren.

Gien: De feedbackloops zijn ook totaal verschillend. Als softwaredeveloper push je naar productie en zie je vrij snel wat je beslissing opgeleverd heeft. Als architect wacht je misschien jaren voor je weet of je de juiste richting bent ingeslagen. Iemand die uitstekend was in beslissingen nemen als developer kan volledig de weg kwijt zijn wanneer die in een rol terechtkomt met langere horizonten en meer onzekerheid.

Andrea: Het is een heel andere vaardigheid. Bij kortere feedbackloops geven experimenten sterke signalen — duidelijk juist, duidelijk fout. Bij beslissingen die langer meegaan, zijn de signalen moeilijker te lezen. En organisaties leggen vaak te veel nadruk op metrieken die de voorkeursoptie bevoordelen. Als iedereen beslissing A liever had dan beslissing B, dan zien de metrieken van A er prachtig uit en vraagt niemand zich af wat ze misschien over het hoofd zien.

De Decision KP Map

Gien: Dit is een van de redenen waarom ik je Decision KP Map zo goed vind. Je kunt er visueel mee tonen waar de kennis zit — of niet zit. Als we event-driven architectuur overwegen en je zet het op de map, en er is bijna niemand met echte ervaring, dan is dat meteen zichtbaar. Eén persoon die er ooit aan gewerkt heeft, vijf jaar geleden, met senior mensen die de dingen rondom hem opzetten — dat is geen kennis waarop je kunt bouwen. En het wordt duidelijk dat die optie kiezen een kost heeft: je moet investeren in opleiding, tijd en budget.

Andrea: Ja — en ik wil iets verduidelijken: KP staat voor twee dingen. Knowledge-Power, maar ook Key People. Het is de praktijk van het mappen zelf waar het echte rendement vandaan komt. Wanneer je de map maakt voor één specifieke beslissing — geen project, geen team, gewoon die ene beslissing — begin je de dingen helder te zien. Dezelfde persoon die in het algemeen heel machtig lijkt, heeft in de context van deze specifieke keuze misschien heel weinig macht of kennis. En omgekeerd: iemand zonder formele autoriteit kan in een positie van echte invloed terechtkomen, gewoon door op het juiste moment de juiste vragen te stellen.

Gien: Heb je gemerkt dat in losser gestructureerde organisaties de mensen met meer macht ook vaak meer kennis hebben?

Andrea: Niet als consistent patroon. Ik heb teams gezien waar iemand helemaal geen autoriteit had, maar zulke scherpe vragen stelde dat die persoon feitelijk opschoof naar de as "kan verandering teweegbrengen". En wanneer je dezelfde beslissing over de tijd opvolgt — ze opnieuw mapt naarmate de dingen evolueren — zie je mensen verschuiven. Er komt iemand bij de groep, en de hele map schudt zich opnieuw. Dat is de waarde van het beslissingsspecifieke en iteratieve karakter ervan.

De rant: recepten versus oplossingen op maat

Gien: We zijn aan het einde van de podcast. Waar ben je nog altijd gefrustreerd over als het over beslissingen in bedrijven gaat?

Andrea: De algemene versie van mijn frustratie is deze: de meeste mensen willen een recept om hun probleem op te lossen, en tegelijk willen ze een volledig op maat gemaakte oplossing. Die twee dingen staan fundamenteel op gespannen voet. Een oplossing op maat kost meer — zoals een handgemaakte schoen tegenover drie paar teenslippers voor tien euro. Je kunt proberen het gesprek te herkaderen rond waar het echte onderscheidende vermogen van een bedrijf zit en daarin investeren, maar de aantrekkingskracht van een silver bullet is heel sterk. En het is vooral moeilijk wanneer je iets probeert aan te leren — mensen blijven vragen waarom het niet eenvoudiger kan. De ondertitel van het DDD-boek gaat letterlijk over complexiteit. Dat zou geen verrassing mogen zijn. Je moet je comfortabel leren voelen bij het ongemak. Ik heb het gevoel dat onze sector hier al jaren rond cirkelt, en ik zou het geweldig vinden als we er eindelijk voorbij raken.

Wat betekent satisfying software voor jou?

Andrea: Satisfying software is kunnen vertrouwen, en ergens werken waar vertrouwen echt de standaard is. Ik heb in zulke omgevingen gewerkt, en ik denk dat je daar echt satisfying software kunt bouwen — omdat mensen jou vertrouwen, en jij hen. Vertrouwen dat ze weten wat ze doen. Vertrouwen dat je het mag zeggen als je iets niet weet, en dat dat oké is. Satisfying software betekent werken met mensen die je vertrouwt, en die jou vertrouwen.