Sommige besluiten voelen in eerste instantie technisch.
Een infrastructuurkeuze. Een overname. Een verplaatsing naar een andere cloudpartner. Een productbesluit dat opeens ook governance raakt.
Tot het gesprek kantelt.
Dan gaat het niet meer alleen over performance, delivery of kosten. Dan komt een andere vraag op tafel: welke claim draagt dit besluit eigenlijk — en wie kan die claim onderbouwen?
Dat is vaak het moment waarop softwareleiders onnodig veel frictie voelen. Niet omdat het team iets verkeerd heeft gedaan, maar omdat een besluit onderweg groter is geworden dan de oorspronkelijke techniek. Wat eerst een roadmap-item leek, wordt ineens ook een bestuurlijke afweging.
Daar zit een rustige maar belangrijke keuze onder. Wacht je tot zo'n moment extra toetsing oproept? Of maak je eerder zichtbaar welke aannames, bewijsstukken en eigenaren de volgende stap dragen?
Die tweede route klinkt formeler dan hij hoeft te zijn. In de praktijk is het vaak juist de lichtere route.
De echte spanning zit vaak niet in regels, maar in uitlegbaarheid
Veel CTO's, founders en productgerichte leiders herkennen dit patroon.
Een team werkt met tempo. Er is een partnerselectie, een migratiepad, een nieuwe architectuurkeuze of een strategische deal in voorbereiding. Iedereen snapt waarom het besluit logisch voelt. In Slack zijn de argumenten bekend. In meetings knikt men snel mee. De context zit in hoofden, notities en eerdere gesprekken.
Tot iemand een eenvoudige vraag stelt.
Niet: is dit technisch mogelijk?
Maar: waarop rust deze keuze precies?
Dan blijkt hoe vaak cruciale claims impliciet zijn gebleven.
- Dat een bepaalde leverancier bestuurlijk beter past.
- Dat eigenaarschap rond data of operatie voldoende helder is.
- Dat een bepaalde afhankelijkheid acceptabel is.
- Dat de gekozen route proportioneel is gezien het publieke, contractuele of governance-belang.
Dat zijn geen exotische vragen. Ze horen inmiddels gewoon bij volwassen softwarebesluitvorming.
En precies daar ontstaat vaak onrust. Niet omdat het antwoord ontbreekt, maar omdat het antwoord verspreid ligt over mensen, documenten en aannames.
De actualiteit is vooral een signaal van wat zwaarder meeweegt
Dat maakt de recente berichtgeving rond Solvinity interessant als aanleiding, niet als één-op-één spiegel van iemands situatie.
NOS meldde dat Solvinity, het bedrijf achter DigiD, in beroep gaat tegen het overnameverbod door de staat op de voorgenomen overname door Kyndryl. Volgens de berichtgeving is dat besluit genomen ter bescherming van het publieke belang, op advies van het Bureau Toetsing Investeringen.
Over de inhoudelijke en juridische beoordeling van die specifieke zaak past bescheidenheid. Die ligt bij de betrokken partijen en de rechter.
Maar als signaal is de zaak wel relevant.
Ze onderstreept dat strategische besluiten steeds vaker niet alleen worden gewogen op marktlogica of technische haalbaarheid. Publiek belang, uitlegbaar eigenaarschap en de onderbouwing van claims wegen zwaarder mee.
Niet in elke organisatie op dezelfde manier. Niet in elke context met dezelfde gevolgen. Maar wel genoeg om een andere reflex nuttig te maken.
Niet: we lossen compliance later wel op.
Eerder: welke claims dragen ons volgende belangrijke besluit al, en kunnen we die compact zichtbaar maken voordat het gesprek groter wordt?
Twee logische routes, maar één geeft meestal eerder rust
Er zijn grofweg twee manieren waarop teams hiermee omgaan.
De eerste is de bekende route: doorwerken tot er een expliciete vraag komt. Pas wanneer legal, bestuur, een klant of een externe toets extra uitleg vraagt, ga je verzamelen. Dan trek je documenten bij elkaar, zoek je eerdere besluiten terug en probeer je achteraf een nette onderbouwing te reconstrueren.
Dat is begrijpelijk. Het houdt de vaart erin. En soms is het voldoende.
Maar het heeft een prijs. De druk verschuift naar het laatste moment. Eigenaarschap wordt diffuus. Discussies worden abstracter dan nodig. En een besluit dat eerder klein en logisch voelde, krijgt opeens meer gewicht doordat de onderbouwing nog vloeibaar is.
De tweede route is stiller.
Je kiest niet voor een groot programma, maar voor één klein beslissignaal. Bij het eerstvolgende dossier dat meer raakt dan alleen techniek, zet je op één pagina drie dingen naast elkaar:
de claim, het bewijs, de eigenaar.
Meer hoeft het aanvankelijk niet te zijn.
Bijvoorbeeld:
We kiezen deze route omdat operationeel eigenaarschap helder blijft. Welk bewijs ondersteunt dat? Een bestaande RACI, contractuele afspraak, operationeel escalatiepad. Wie bezit die claim? CTO, operations lead, of een verantwoordelijke aan businesszijde.
Of:
We vinden deze afhankelijkheid acceptabel. Waar rust dat op? Exit-aannames, architectuurnotitie, scenario-inschatting. Wie spreekt daar namens de organisatie over? Niet “het team”, maar een naam.
Dat lijkt klein. Dat is ook precies het punt.
Zo'n pagina vertraagt niet veel, maar voorkomt wel dat een later gesprek onnodig diffuus wordt.
Een klein document kan meer rust geven dan nog een extra tool
Wanneer dit ontbreekt, is de reflex vaak om groter te denken.
Meer tooling. Meer controles. Een uitgebreider programma. Een generieke scan over alles tegelijk.
Soms is dat later zinvol. Maar vroeg in het proces is het vaak te grof.
Wat teams meestal eerst nodig hebben, is geen nieuw systeem. Ze hebben een gedeeld beeld nodig van wat er in dit specifieke besluit eigenlijk beweerd wordt.
Niet alles hoeft volledig dichtgetimmerd. Niet elk dossier verdient dezelfde diepte. Het gaat om proportie.
Een founder die een strategisch partnership voorbereidt, een CTO die een platformkeuze verdedigt, een productleider die een gevoelige afhankelijkheid uitlegt — ze hebben vaak meer aan één scherpe pagina dan aan tien losse documenten en een dashboard dat vooral activiteit toont.
Dat is ook waarom de vraag naar eigenaarschap zo belangrijk is.
Zodra een claim een naam krijgt, verandert de kwaliteit van het gesprek. Dan verschuif je van algemene overtuiging naar bestuurlijke helderheid. Niet iedereen hoeft overal eigenaar van te zijn. Maar elke dragende claim hoort wel ergens thuis.
En zodra bewijs compact naast die claim staat, wordt de volgende beslissing rustiger. Niet omdat alle twijfel weg is, maar omdat het gesprek beter begrensd raakt.
De kleinste stap is vaak: kies één besluit en maak het expliciet
Als je hier iets mee wilt, hoeft dat niet te starten met een volledig traject.
Kijk liever naar het eerstvolgende besluit waar techniek en bestuur elkaar raken.
Dat kan een leverancierskeuze zijn. Een infrastructuurverandering. Een partnerafspraak. Een stap in data-opslag of operationele uitbesteding. Iets waarvan je voelt: hier zit meer onder dan alleen een technische voorkeur.
Pak dan vier eenvoudige velden:
claim, bewijs, eigenaar, beslismoment.
Niet om het perfect te maken, maar om te zien waar het nog stil is.
Vaak zit de waarde niet eens in de uitkomst, maar in wat zichtbaar wordt tijdens het invullen. Een claim zonder eigenaar. Een eigenaar zonder bewijs. Een beslismoment dat eerder komt dan gedacht.
Daar begint eigenaarschap.
En daar ontstaat meestal ook rust. Omdat je niet wacht op een groter moment van toetsing om erachter te komen welke onderbouwing eigenlijk al nodig was.
Welke claim in jullie volgende belangrijke besluit zou vandaag nog sterker worden als het eigenaarschap en bewijs expliciet op één pagina stonden?
Als je dat klein wilt verkennen voor je eigen context, is de Pathfinder Signal route een rustige eerste stap: niet om alles te beoordelen, maar om vroeg te zien welk besluit eerst om expliciete claims, bewijs en eigenaarschap vraagt.