Er is een moment dat veel softwareleiders herkennen, ook al benoemen ze het zelden hardop. Een sales engineer demoot het product en zegt iets net iets stelliger dan de documentatie vandaag draagt. Een release note belooft een capability die intern nog discussie oproept. Een enterprise prospect stelt een redelijke vraag — hoe weten jullie dit precies? — en het blijft even stil in de Teams-call.
Niemand doet iets vreemds. Iedereen probeert tempo te houden. En toch voelt iets ongemakkelijk, juist omdat het klein is.
Dat is bijna altijd waar regulatory werk echt begint. Niet bij de audit, niet bij het juridische dossier, maar bij een claim die net iets vooruitloopt op het bewijs dat er nu al onder ligt. NOS schreef dit weekend over een opeenstapeling van incidenten in de Alpen — een nuchtere herinnering dat veel risico zich opbouwt in kleine signalen voordat het ergens samenkomt. In software is dat zelden dramatisch, maar het mechanisme lijkt erop: wat later groot voelt, begon meestal als iets kleins dat niemand expliciet maakte.
Waar de echte frictie meestal begint
Veel teams denken bij regulatory aan het latere moment: de review, de checklist, de formele vraag van een klant. Maar de vertraging ontstaat eerder. Ze ontstaat wanneer er geen gedeeld beeld is van drie simpele dingen: wat we precies claimen, welk bewijs daar nu al onder ligt, en wie eigenaar is van de eerstvolgende beslissing.
Zonder dat gedeelde beeld zie je bekende patronen. Een Slack-thread die te lang open blijft. Een founder die in een commerciële call iets probeert glad te trekken. Een productteam dat aanneemt dat legal het later wel opvangt. Een operations-collega die rust wil, maar geen handvat heeft om proportioneel te beslissen.
Het werk is zelden ingewikkeld. De onduidelijkheid stapelt zich op. Elke volgende discussie moet eerst terug naar de basis: wat zeggen we eigenlijk, waar baseren we dat op, en wie mag hier een knoop doorhakken?
Voor CTO's, founders en eigenaren is dat een lastig spanningsveld. Je wilt niet te vroeg zwaar optuigen. Maar je wilt ook niet ontdekken dat een ogenschijnlijk kleine claim later langs drie teams moet voordat iemand hem durft te bevestigen.
Kleine signalen, geen grote trajecten
De formele toets maakt vooral zichtbaar wat eerder impliciet was gebleven. Welke aannames in teksten waren geslopen. Welke productclaims al rondzwierven zonder duidelijke onderbouwing. Welke beslissing eigenaarloos was geworden.
Daarom helpt het zelden om meteen in een breed traject te denken. Nog minder om een nieuwe tool naar binnen te trekken in de hoop dat structuur vanzelf volgt. Wat meestal wel helpt, is één klein signaal serieus nemen:
- een onboardingtekst die iets belooft wat nog niet scherp gedefinieerd is
- een enterprise prospect die om onderbouwing vraagt van een productclaim
- een roadmap-item dat intern logisch voelt, maar extern regulatoir zwaarder kan landen
- een supportvraag die blootlegt dat teams niet dezelfde taal gebruiken
Zulke signalen hoeven niet groot te zijn om nuttig te zijn. Juist in het kleine wordt zichtbaar waar de volgende beslissing om helderheid vraagt.
Drie woorden die richting geven: claim, bewijs, eigenaar
Als je één zo'n signaal kiest, hoef je het niet meteen op te blazen tot programma. Meestal is het genoeg om er drie woorden naast te zetten.
Claim: wat zeggen we hier precies? Niet wat we ongeveer bedoelen. Niet wat waarschijnlijk waar is. Maar de letterlijke of operationele claim die straks iemand kan horen, lezen of toetsen.
Bewijs: wat hebben we vandaag al dat deze claim draagt? Een testresultaat. Een interne notitie. Een beslisdocument. Gebruiksdata. Een afbakening die duidelijk maakt wat je juist níet beweert. Het gaat niet om perfectie, het gaat om zichtbaarheid.
Eigenaar: wie beslist over de volgende stap? Niet wie er mogelijk bij betrokken is. Niet welk team dit ergens heeft. Maar wie nu het mandaat en de context heeft om te zeggen: deze claim blijft, deze claim wordt aangescherpt, of hier hebben we eerst één extra bewijsstuk nodig.
Zodra deze drie expliciet zijn, verandert de toon. Minder abstract. Minder defensief. De vraag is dan niet meer "zijn we compliant genoeg?", maar: is deze specifieke claim op dit moment goed genoeg onderbouwd voor de volgende stap die we willen zetten?
Dat is een rustigere bestuursvraag. En vaak eerlijker.
Wat dit oplevert: bestuurbaarheid, geen maximale zekerheid
Wat goede softwareleiders zoeken, is zelden maximale zekerheid. Het is bestuurbaarheid. Tempo houden zonder slordigheid te normaliseren. Teams beschermen tegen herstelwerk dat achteraf onnodig groot voelt. Voorkomen dat elk regulatoir gesprek meteen het gewicht krijgt van een volledig programma.
Als je werkt vanuit één claim, één zichtbaar bewijsbeeld en één eigenaar, ontstaan er meestal drie dingen. Prioritering wordt rustiger — niet alles hoeft tegelijk. Escalaties worden scherper — je kunt concreet maken waar de onzekerheid zit. En discussies worden menselijker — teams hoeven elkaar minder te overtuigen op meningen, ze kunnen samen naar een tastbare volgende stap kijken.
Een rustige eerste stap
Als je dit wilt vertalen naar je eigen praktijk, begin dan niet bij het zwaarste onderwerp op tafel. Kies het eerstvolgende beslismoment waar claim, bewijs en eigenaar elkaar nog net niet vanzelf vinden.
Misschien is dat een zin op de website. Een belofte in een demo. Een release die deze week naar buiten gaat. Een interne aanname waar opvallend veel mensen omheen praten.
Pak dat ene moment erbij en maak alleen dit expliciet: wat claimen we hier precies, wat draagt die claim vandaag al, en wie beslist over de volgende proportionele stap?
Meer hoeft het in het begin niet te zijn. Dat is ook de route van Pathfinder Signal: niet vertrekken vanuit een allesomvattend programma, maar vanuit één concreet signaal dat laat zien waar aanscherping, bewijs of eigenaarschap als eerste nodig is. Klein beginnen is hier meestal de beste plek om te beginnen.