De echte spanning zit zelden in de regel
In veel teams ontstaat spanning niet op het moment van besluiten, maar later: wanneer iemand vraagt waarom iets destijds is goedgekeurd, aangepast of uitzonderlijk behandeld.
De recente berichtgeving rond ASML is vooral een actuele herinnering aan dat soort dossiers. Niet als conclusie over jouw organisatie, wel als context: zodra een technisch of commercieel besluit onderwerp van gesprek wordt, verschuift de vraag snel van “wat is er afgesproken?” naar “waar ligt de onderbouwing?”
De vraag die ik dan als eerste zou stellen
Voordat iemand begint over een brede audit, een nieuw beleid of extra tooling, zou ik één concrete beslissing uit de afgelopen maanden pakken.
Eén case waarin commercie, engineering en legal samen iets hebben vrijgegeven, aangepast of uitzonderlijk hebben gemaakt.
En dan stel ik drie nuchtere vragen:
- wat was hier precies de claim of uitzondering?
- wie heeft uiteindelijk de knoop doorgehakt?
- waar ligt de onderbouwing die je een maand later nog snel terugvindt?
Dat klinkt klein. Maar het zegt veel. Want in veel organisaties zit de frictie niet in een gebrek aan beleid. De frictie zit in de afstand tussen besluit en bewijs.
Een deal loopt via Slack. Een classificatie staat in een bijlage. Een uitzondering wordt besproken in een call en zakt daarna weg in iemands geheugen. Drie weken later vraagt iemand: waarom mocht dit ook alweer?
Als je dat moet reconstrueren, weet je meestal al waar de spanning zit.
Wat er vaak ontbreekt in software- en hardwareteams
De meeste leiders die ik spreek werken niet met onwil. Ze werken met versnelling.
Een roadmap schuift. Sales wil een klant niet verliezen. Product wil een release niet vertragen. Support krijgt een vraag die “nu even” opgelost moet worden. En ergens in die stroom wordt een besluit genomen dat later uitlegbaar moet zijn.
Daar ontstaat druk, ook buiten compliance alleen: bij productbeslissingen, partnerafspraken, demo-omgevingen, toegang tot data, leveringsvoorwaarden en exportgevoelige componenten.
Wat vaak ontbreekt, is niet informatie in abstracte zin. Wat ontbreekt is de korte bewijsketen die een beslissing stevig en terugvindbaar maakt:
- wat was de claim of uitzondering;
- wie gaf akkoord;
- waar ligt het bewijs.
Als je dat niet per beslissing kunt terugvinden, krijg je later geen helderheid maar reconstructie. En reconstructie kost aandacht, tijd en rust.
Eén beslissing testen zegt meer dan een groot programma
Ik geloof steeds minder in grote startpunten voor dit soort onderwerpen.
Niet omdat ze onbelangrijk zijn, maar omdat ze vaak te veel tegelijk willen oplossen. Dan gaat het over beleid, tooling, training, uitzonderingen, rapportage en eigenaarschap in één keer. Dat voelt grondig, maar het maakt zelden snel zichtbaar waar het echt schuurt.
Wat ik als eerste zou checken, is kleiner.
Pak één recente high-stakes beslissing. Bijvoorbeeld:
- een leveringsafspraak met een ongebruikelijke clausule;
- een klantcase met exportgevoelige componenten;
- een productrelease waarbij data, partnergebruik of regio’s beperkt moesten worden;
- een uitzondering die in de praktijk snel is goedgekeurd.
Vraag daarna alleen dit:
Kunnen we de claim, de eigenaar en het bewijsstuk binnen vijf minuten terugvinden?
Als dat soepel lukt, is dat geruststellend. Als dat nog zoeken wordt, weet je waar de route breekt. Niet als oordeel, maar als feit. Misschien zit de onderbouwing in een contractbijlage die niemand snel vindt. Misschien zijn er feitelijk drie eigenaren. Misschien is de beslissing prima genomen, maar nooit netjes vastgelegd.
Dat is geen ramp. Dat is bruikbare informatie.
Waarom dit juist voor leiders een nuttige lens is
Voor CTO’s, founders en eigenaren is dit geen administratieve oefening. Het is een vraag naar bestuurbaarheid.
Hoe weet je of een beslissing echt gedragen wordt als iemand later doorvraagt?
Hoeveel van je organisatie draait op impliciete kennis in hoofden, en hoeveel op een korte bewijsroute die overeind blijft als iemand weg is of tijd verstrijkt?
Ik zie vaak dat leiders pas laat merken hoe fragiel die route is. Alles werkt zolang iedereen in dezelfde ruimte zit. Pas wanneer iemand vraagt “waar staat dit?”, wordt zichtbaar hoeveel er in losse gesprekken en geheugen zit.
Dan is het meestal niet verstandig om breed te beginnen. Dan is het zinvoller om één beslissing te testen op drie dingen: claim, eigenaar, bewijs.
Dat geeft geen spektakel. Wel eigenaarschap.
Een kleine Pathfinder Signal-route
Als ik dit in een team zou willen verkennen, zou ik het niet als programma starten. Ik zou het starten als een compacte check op één beslissing.
Kies een recente case die voor jullie echt gewicht had. Trek de lijn van claim naar akkoord naar bewijs. Kijk waar die lijn direct loopt en waar hij breekt.
Daarna pas beslis je of er meer nodig is.
Dat is de route van Pathfinder Signal: één beslissing, één eigenaar, één bewijsketen. Klein genoeg om snel te doen. Groot genoeg om zichtbaar te maken waar de volgende stap logisch wordt.
Als je dit vandaag wilt toepassen, pak dan één case en beantwoord alleen die ene vraag: kunnen we de claim, de eigenaar en het bewijs snel terugvinden? Als dat nog niet scherp is, ligt daar meestal de meest bruikbare volgende stap via Pathfinder Signal.