Deze week heb ik (bescheiden) geholpen met het opstarten van twee nieuwe initiatieven waarbij engineers en beleidsmedewerkers samen aan de slag gaan. Nu we onze manier van werken beginnen uit te breiden naar meerdere beleidsdomeinen en meer engineers aanhaken, word ik steeds vaker gevraagd: hoe doe je dat? Hoe overbruggen we de kloof tussen beleid en techniek? Wat werkt wel, en wat werkt niet?

Van abstract naar concreet

Binnen het kerndepartement van BZK zijn we nu op tenminste 4 plekken bezig met een cruciale vertaalslag: het omzetten van abstracte ideeën over hoe systemen voor een digitale overheid eruit zouden moeten zien naar tastbare, werkende demonstraties.

Deze vertaling is niet alleen technisch, maar vooral conceptueel. We herformuleren de vraag van “Hoe zou het moeten zijn?” naar “Kijk, zo zou het kunnen werken”. Die verschuiving maakt alle verschil. Het brengt discussies van het abstracte naar het concrete, van theorie naar praktijk.

Verschillende snelheden

Met onze PoC Machine Law hebben we al geruime tijd een werkende demo. We kunnen deze natuurlijk steeds verder ontwikkelen, maar dat brengt een risico met zich mee: hoe verder onze proof-of-concept vooruitloopt op de daadwerkelijke implementatie, hoe groter de kloof wordt.

De organisatorische implementatie komt zeker - er zijn veel mensen mee bezig! - maar het tempo ligt ordes van grootte lager dan wat technisch mogelijk is. Het blijft een uitdaging om te innoveren zonder het contact met de organisatie te verliezen.

Hier zijn we zoekende en hebben we eigenlijk de volgende stap nodig: Simon Wardley’s System of Theft, waarbij een organisatie denkt: “die Machine Law PoC van hen, dat kunnen wij veel beter”, en er dan mee aan de haal gaan.

Werkvormen die werken

Het blijft een uitdaging om de juiste balans te vinden tussen makers-tijd en manager-tijd. We experimenteren met standups en planning in een beleidsteam - iets wat vrij uniek is in deze omgeving. Tegelijkertijd ontkomen we niet aan de realiteit van nog steeds veel traditionele vergaderingen.

De standups brengen ritme en focus, terwijl de traditionele vergaderingen vaak nodig blijven voor afstemming in de bredere organisatie. Het is een hybride model dat probeert het beste uit beide werelden te halen.

Demo’s vs. nota’s

Een blijvende uitdaging is ook de verschillende documentatieculturen. Waar beleidsmedewerkers gewend zijn aan uitgebreide nota’s en beleidsstukken, werken wij liever met werkende demonstraties zoals de NeRDS principes (zie ook Heimwee).

Deze verschillende benaderingen weerspiegelen verschillende denkkaders: het verschil tussen beschrijven wat zou moeten zijn en laten zien wat kan zijn. Beide hebben hun waarde, en de uitdaging ligt in het verbinden van deze twee werelden.

De kracht van prototypes

Misschien wel het belangrijkste inzicht is hoe een werkend prototype de communicatie verandert. Dit gebeurt constant: vóór een demo zijn gesprekken over het onderwerp vaak ongericht en abstract. Na een demo worden ze plotseling concreet en gericht op mogelijkheden.

Een prototype doet iets wat geen beleidsdocument kan: het maakt het abstracte tastbaar. Het verplaatst de discussie van “wat als” naar “wat nu”. Elke keer dat we een demo laten zien, zien we dezelfde reactie: mensen willen er meteen mee aan de slag.

Samen, niet apart

Een cruciaal inzicht is dat deze manier van werken niet functioneert als een “opdracht” die op afstand wordt gegeven aan een team of een (solo1) engineer. Het moet samen gebeuren - engineers en beleidsmedewerkers die gezamenlijk aan een oplossing werken.

Dit samen-ontwikkelen doorbreekt de traditionele scheiding tussen “denken” en “doen”, tussen beleid en uitvoering. Het creëert gedeeld eigenaarschap en begrip, en leidt tot oplossingen die zowel technisch solide als beleidsmatig relevant zijn.

De weg vooruit

Nu we onze manier van werken uitbreiden naar meer plekken, wordt het delen van deze lessen steeds belangrijker. Het kernpunt blijft simpel: engineers en beleidsmedewerkers moeten samen optrekken, niet in gescheiden werelden werken. De techniek wordt beter als het beleid wordt begrepen, en het beleid wordt praktischer door de technische blik. Dat samenspel is waar de echte meerwaarde zit.

Voetnoten

  1. Doordat van Proof of Concepts (PoCs) van nature throw-away-code2 zijn, zijn ze heel erg geschikt voor vibe coding, daarmee staat de deur open naar solo-engineers die nauw samenwerken met een beleidsteam en een heel eind kunnen komen. ↩

  2. Het idee om code te schrijven die je weer weg gooit kan counter-intuïtief zijn. Maar het kan de ontwikkeling juist versnellen en kosten verlagen, omdat prototypes niet bedoeld zijn voor het definitieve systeem en ontwikkelaars zich kunnen focussen op de functionaliteit zonder zich zorgen te maken over onderhoudbaarheid of testbaarheid. ↩