Complexiteit herkennen en hanteren: van het waarom naar de praktijk

Op deze site staat een essay over waarom Liberating Structures in complexiteitsdenken wortelen, de organisatie als levend systeem in plaats van als machine, de waarde die tussen mensen zit in plaats van in de onderdelen, de spreeuwenzwerm als beeld voor zelforganisatie. Als je dat nog niet las, begin daar; dit stuk bouwt erop voort. Want het essay legt het waarom uit en stopt precies waar het voor een facilitator interessant wordt: hoe herken je complexiteit in een echte opdracht, en wat doe je er dan mee? Dat is de vertaalslag die ik hier wil maken.

Eerst: leren zien of je met een complex of een gecompliceerd probleem zit

Dit is de belangrijkste diagnostische vaardigheid van het vak. De meeste missers die ik ken, komen voort uit een verkeerde inschatting hier. Een gecompliceerd probleem heeft een kenbaar antwoord en een expert die het weet — de oplossing bestaat al, je moet ze alleen vinden. Een complex probleem heeft dat niet: het antwoord ontstaat gaandeweg en verandert terwijl je eraan werkt. Het praktische onderscheid dat ik hanteer: kun je vooraf beschrijven hoe "klaar" eruitziet? Bij een gecompliceerd probleem wel (de brug staat, de software werkt). Bij een complex probleem niet. Je weet pas achteraf of het gelukt is, en twee organisaties met "hetzelfde" probleem hebben elk een andere oplossing nodig. Een fusie, een cultuurverandering, een aanpak voor personeelstekort: dat zijn geen puzzels met een oplossing. Het zijn situaties waarin je manoeuvreert. Zie je een groep een complex vraagstuk aanpakken met een projectplan en een Gantt-chart? Dan kijk je naar een categoriefout in wording. De Agreement-Certainty Matrix is de structuur waarmee je een groep dit zelf laat ontdekken, in plaats van het ze te vertellen.

Waarom deze diagnose je hele ontwerp stuurt

Zodra je weet dat een vraagstuk complex is, volgt daaruit wat je wél en niet moet doen. Je gaat niet convergeren voor je gedivergeerd hebt. De oplossing zit niet klaar in één hoofd; ze moet ontstaan uit de botsing van perspectieven. Je plant geen lineair traject van A naar B. Je bouwt in kleine, veilige stappen met bijstuurmomenten. Je haalt bewust diversiteit binnen: een complex probleem dat door één type bril bekeken wordt, blijft half onzichtbaar. En je meet vooruitgang aan het draagvlak dat de groep werkelijk voelt — snelle consensus zegt weinig over wat er straks standhoudt. Dit is geen toevallige lijst voorkeuren; het volgt rechtstreeks uit wat een complex systeem is. Het essay legt dat uit. Mijn punt hier: je diagnose (complex of gecompliceerd) bepaalt je concrete ontwerpkeuzes, structuur voor structuur.

Wat dat betekent voor structuurkeuze

Een paar voorbeelden uit de praktijk. Als het vraagstuk complex is en de groep grijpt te snel naar de eerste oplossing, vertraag je bewust het convergeren. 1-2-4-All of TRIZ beschermen de variëteit aan perspectieven tegen de neiging om op de luidste stem te landen. Als een groep vastzit omdat ze het perfecte plan zoekt voor een situatie die geen plan verdraagt, verschuif je naar veilig experimenteren. 15% Solutions of het denken in pilots boven uitrol. Als niemand nog weet welk soort probleem het eigenlijk is, begin je met sorteren voor je iets anders doet. De structuur is nooit het startpunt. De diagnose van het type probleem is dat — de structuur volgt eruit. Dat is precies het onderscheid tussen een facilitator die trucs toepast en een die weet welk systeemgedrag hij probeert uit te lokken.

De valkuil waar ik zelf in trapte

Het verraderlijke aan complexe problemen is dat ze zich vermommen als gecompliceerde. Een directie presenteert "we moeten onze overlegstructuur herzien" alsof het een ontwerpklus is met een goede oplossing. Ze verwacht dat jij die oplossing komt brengen. De echte opdracht is bijna altijd complexer: het gaat over macht, vertrouwen, gewoonten, dingen die je niet kunt hertekenen maar alleen samen kunt verschuiven. Wie de opdracht aanneemt zoals ze geformuleerd is, levert een keurig plan dat niets verandert. De vaardigheid zit in het herkennen van het complexe probleem onder de gecompliceerde vraag. En in het gesprek daarover durven openen voor je aan het ontwerp begint.

Het essay geeft je de taal om aan een sceptische directie uit te leggen waaróm hun transformatieplan het probleem niet oploste. Dit stuk gaat een stap verder: het geeft je de diagnose waarmee je bij een nieuwe opdracht meteen ziet welk soort probleem voor je ligt, en dus welk soort aanpak past. Complexiteit is geen filosofie die je erbij haalt om je werk chic te maken. Het is het verschil tussen een ontwerp dat past bij de werkelijkheid van het vraagstuk en een ontwerp dat ertegenin werkt. Na al die jaren blijft dat voor mij het meest fascinerende aan het vak: dat je in één namiddag, in één kamer, met echte mensen, zelforganisatie letterlijk kunt zien gebeuren. Maar enkel als je eerst goed hebt gezien met wat voor probleem je te maken hebt. Precies dat soort verkeerde inschatting is ook de rode draad in wanneer Liberating Structures níet werkt.

Hoe maak jij het onderscheid tussen een complex en een gecompliceerd vraagstuk in een intake, en wanneer had je het achteraf mis?