Hoe leg je die £20M aan engineeringkosten uit?

Ik ken de pijn van het verantwoorden van softwarekosten. Of je nu bij een groot bedrijf aan financiële directeuren moet uitleggen waarom een project uitloopt, of bij een startup de burn rate moet voorspellen voor investeerders: het gesprek verloopt altijd hetzelfde.

De CFO of investeerder vraagt: “We geven £15 miljoen uit aan engineering. Wat krijgen we daarvoor?”

Je opent je spreadsheet. Je hebt aantallen mensen. Je hebt salarisschalen. Je hebt een lijst met lopende projecten. Maar als ze vragen “Wat heeft de checkout-herbouw nou echt gekost?” of “Wat levert die platformmigratie van zes maanden op?”, dan gok je.

Ik heb engineeringteams geleid bij startups en bij grotere organisaties, nooit meer dan 30 engineers tegelijk. De schaal verschilt, het probleem is overal hetzelfde: niemand kan je zeggen wat iets echt kost.

Niet de features. Niet de projecten. Niet de “strategische initiatieven” die hele kwartalen opslokken. Het geld verdwijnt in een zwart gat met het label “Engineering” en iedereen hoopt maar dat het er aan de andere kant als omzet weer uitkomt.

En het gaat niet alleen om salarissen. Die £15 miljoen omvat mensen, zeker, maar ook AI-kosten, softwarelicenties, cloudinfrastructuur en hardware. De volledige engineeringrekening. Toch kunnen de meeste organisaties er niets van uitsplitsen.

Ik ken beide werelden. Bij startups moest ik kosten voorspellen voor investeerders die de unit economics willen begrijpen vóór de Series A. Bij grote bedrijven moest ik financiële directeuren uitleggen waarom een project van zes maanden nu op twaalf maanden staat. De excuses wisselen, het onderliggende probleem blijft: we missen de basisinfrastructuur om te meten wat engineeringwerk echt kost.

Het probleem is niet nieuw, maar wordt erger

Dit hoor ik van bijna elke technologieleider met wie ik praat:

“We boeken kosten centraal op een verzamelpost, omdat we de cijfers niet binnen de maand rond krijgen.”

Vertaling: we weten niet wat we waaraan uitgeven, dus kiepen we alles op één hoop en noemen het “Platformteam Q3”. Finance haat het. Het bestuur twijfelt eraan. Maar wat moet je anders?

“Als we 20% van de mensen schrappen of teams verplaatsen, wil ik meteen de gevolgen zien.”

Maar dat kan niet. Want je “planningstool” is een spreadsheet met 47 tabbladen die kapotgaat als je een rij verwijdert. Tegen de tijd dat je het scenario hebt doorgerekend, heeft het bestuur allang op onderbuikgevoel besloten.

“We geven £20 miljoen uit aan mensen en ik moet laten zien dat dat verstandig gebeurt.”

Hier liggen CTO’s wakker van. Je weet dat je verstandig uitgeeft. Je weet dat je teams goed zijn. Maar je kunt het niet met data bewijzen, want die data bestaat niet.

“Elke paar maanden moeten we opnieuw plannen als prioriteiten of mensen veranderen.”

En elke herplanning kost je drie dagen vergaderen, weer een ronde spreadsheets en hetzelfde zure proces als vorig kwartaal.

Waarom een planning doodgaat zodra je hem uitrolt

De meeste engineeringorganisaties plannen per kwartaal. Je besteedt 4 tot 6 weken aan een plan voor het volgende kwartaal. In week zeven vertrekt iemand. In week negen duikt uit het niets een “strategische prioriteit” op. In week twaalf is je oorspronkelijke plan historische fictie.

Zo verdeelt de tijd van engineeringleiders zich echt:

Vergaderingen (planning, toewijzing, reviews): 17,9 uur/week, 7 uur meer dan individuele bijdragers
Versnipperde tijd: 7,1 uur/week, goed voor 40% productiviteitsverlies
Focustijd: 10,4 uur/week, waarvan maar 2,6 uur zonder onderbreking

Van die 17,9 uur vergaderen per week gaat een flink deel naar planning: kwartaalkickoffs die 4 tot 6 weken duren, tussentijdse reviews, gesprekken over capaciteitsverdeling, budgetverantwoording. Reken maar na: engineeringleiders besteden ongeveer een derde van elk kwartaal aan het plannen van het volgende. Je loopt permanent zes weken achter op de werkelijkheid, want als je klaar bent met plannen is de wereld alweer veranderd.

En wat plan je eigenlijk? Volgens onderzoek van McKinsey besteden engineeringteams 40 tot 60% van hun tijd aan onderhoud en beheer in plaats van aan nieuwe mogelijkheden¹. Maar kun je me zeggen welke 40 tot 60%? Kun je laten zien welke engineers aan welke projecten werken en of die projecten CapEx of OpEx zijn?

Natuurlijk niet. Want daarvoor moet je elke week een spreadsheet bijwerken, en dat gebeurt nooit.

De blinde vlek tussen CapEx en OpEx

Hier wordt het pijnlijk. Je CFO moet weten of engineeringwerk nieuwe mogelijkheden bouwt (CapEx) of bestaande in stand houdt (OpEx). Dat is geen boekhoudkundige muggenzifterij. Het bepaalt hoe werk wordt gefinancierd en gemeten.

McKinsey ontdekte dat developers bij sommige organisaties meer dan 50 procent van hun tijd kwijt zijn aan technische schuld ². Dat is het verschil tussen een strategische engineeringorganisatie en een team dat permanent brandjes blust.

Topkwartielbedrijven (volgens de Developer Velocity Index) besteden daarentegen 33 procent minder tijd aan ongedifferentieerd handwerk, zodat ze ruimte houden om te innoveren ³.

Maar het wordt nog erger: het probleem is bijna universeel. Uit een enquête van 2023 bleek dat 91% van de IT-leiders technische schuld de grootste belemmering voor innovatie vindt ⁴. Toch “reserveren veel bedrijven 15 tot 20 procent van het IT-budget om technische schuld aan te pakken”, een bedrag dat volgens McKinsey vaak te weinig is ².

Kun je je bestuur laten zien in welke categorie elke engineer valt? Kun je aantonen dat je van 50% naar 30% technische schuld gaat? Of hoop je dat niemand ernaar vraagt?

De snelkookpan van private equity

Waarom dit nu méér telt dan ooit: private equity-buyouts herstelden tot $602 miljard in 2024, een stijging van 37% op jaarbasis ⁵. De techsector was de belangrijkste motor en nam 33% van alle buyouts naar waarde wereldwijd voor zijn rekening ⁵.

Maar het spel is veranderd. Kijk hoe PE-fondsen in de loop der tijd waarde creëren:

Operationele topprestaties groeiden van 18% naar 47% van de waardecreatie. Financiële engineering, oftewel hefboomfinanciering en multiple-expansie, zakte van 51% naar 25%.

Wat betekent dat voor jou? Als je engineering leidt bij een bedrijf met PE-eigenaren, heb je 90 dagen om te laten zien hoe je het geld uitgeeft en 12 tot 24 maanden om echte efficiëntiewinst aan te tonen.

“We nemen meer engineers aan” is geen plan. “We zetten 8,5 FTE in op deze drie projecten met deze verwachte opbrengsten” is een plan.

En raad eens waar PE-operatiepartners om vragen?

De echte kosten per project (geen schattingen, geen gokjes)
De verdeling tussen OpEx en CapEx over de hele engineeringorganisatie
Bezettingsgraden
Ontwikkelkosten van features met echte cijfers
Een routekaart voor margeverbetering met de efficiëntiemotoren van engineering

De meeste technologieleiders kunnen niets hiervan beantwoorden.

De spreadsheet-foutenbelasting

Dit zou je aan het schrikken moeten maken: wetenschappelijke overzichten, waaronder een recente analyse over 35 jaar, vinden telkens dat 88 tot 94% van de spreadsheets die bij belangrijke zakelijke beslissingen worden gebruikt fouten bevat ⁶. Dat is geen typfout. Bijna elke spreadsheet waarmee je je engineeringkosten plant, zit vol fouten.

Toch meldt PwC dat 80% van de organisaties nog steeds op spreadsheets leunt voor financiële planning en analyse (FP&A) ⁷.

Dit is geen technisch probleem. Het is een organisatiecrisis. Als je CFO je cijfers niet vertrouwt omdat ze in Excel zijn gebouwd, verlies je geloofwaardigheid. Als ze om een scenarioanalyse vragen en jij drie dagen nodig hebt om tabbladen te kopiëren, verlies je invloed.

Die scheefstand zit overal. Workday ontdekte dat maar 30% van de CFO’s zegt nauw op één lijn te zitten met hun CIO’s over de digitale en technologische routekaart van het bedrijf ⁸. Hoe stem je af als je een andere taal spreekt? Finance praat over kostenplaatsen en kwartaalprognoses. Engineering praat over story points en sprint velocity.

Wat we missen: een minimaal werkbare eenheid

Het probleem is niet dat we betere Gantt-charts nodig hebben. Het is dat we geen minimaal werkbare eenheid hebben om engineeringwerk te meten.

Finance heeft een duidelijke hiërarchie:

Posten → Kostenplaatsen → Afdelingen → Totale uitgaven

Productie heeft:

Onderdelen → Producten → Productielijnen → Output

En software?

Story points (buiten je eigen team betekenisloos)
Features (te fijnmazig)
Producten (te grof)
“Platforminvestering” (kan alles betekenen)

Startups zijn er extra blind voor. Vraag een oprichter wat de nieuwe checkout-flow heeft gekost om te bouwen, niet in story points maar in contant geld aan salarissen, overhead en gemiste kansen, en je krijgt een schouderophalen.

Dit is wat we bij flowstate aanpakken. Ik noem deze discipline Workforce Engineering: bewust ontwerpen hoe een organisatie haar arbeid inzet om resultaten te leveren. Binnenkort meer daarover.

De flowstate-methode: Workforce Engineering in de praktijk

We bouwen geen zoveelste projectmanagementtool. We bouwen een raamwerk voor hoe engineeringorganisaties werk moeten plannen, volgen en meten.

Zie het zo:

Agile was de methodologie voor softwareontwikkeling
The Linear Method voor issuetracking en productworkflow
De flowstate-methode voor engineeringeconomie en kostentransparantie

Het kernprincipe: engineeringinvesteringen zijn opgebouwd rond weddenschappen, niet rond backlogs.

Projecten als minimaal werkbare weddenschappen

Hier hebben we een uitgesproken mening. In de flowstate-methode is een project:

Minimaal 1,0 FTE van de maandcapaciteit van een team
Maximaal 4 gelijktijdige projecten per team per kwartaal
Waar mogelijk van één team
Afgestemd op een kostenplaats, zodat finance het kan volgen
Op skills afgestemd, zodat teams de juiste vaardigheden hebben

Waarom minimaal 1,0 FTE? Omdat alles wat kleiner is geen weddenschap is, maar een taak die zich voordoet als strategie. Als je er niet minstens één mensmaand aan wilt besteden, meen je het niet.

Waarom maximaal 4 per kwartaal? Omdat focus schaars is. Een team dat meer dan vier zinvolle dingen tegelijk probeert te doen, doet er geen een goed.

Dat levert je op:

Echt kosteninzicht: je weet wat “de checkout herbouwen” kostte, omdat je de onderliggende projecten en hun FTE-toewijzing ziet
Scenarioplanning die werkt: verplaats je een team, dan zie je meteen welke projecten capaciteit verliezen
Echte ROI-tracking: je kunt meten of de weddenschap uitbetaalde, omdat je weet waarop je inzette
Skills in balans: je koppelt projecteisen aan teamvaardigheden, niet alleen aan aantallen mensen maar aan echte skills

Mensen zijn meer dan FTE’s

Hier vallen de meeste engineeringplanningtools door de mand: ze behandelen iedereen als inwisselbare middelen. flowstate niet.

We houden bij:

Rol (Frontend Engineer, Backend Engineer, DevOps, enzovoort)
Niveau (Junior, Medior, Senior, Staff, Principal)
Skills (React, Python, AWS, PostgreSQL, enzovoort)

Zo kun je bij het plannen van een nieuw project vragen: “Hebben we de juiste skills beschikbaar?” En niet alleen: “Hebben we capaciteit?”

Je ziet dat je team 4,0 FTE beschikbaar heeft, maar maar 1,5 FTE met de React-skills die het frontendwerk nodig heeft. Dat verandert je planning. Misschien moet je anders aannemen. Misschien moet je de projectscope aanpassen. Misschien moet je iemand bijscholen.

Maar je weet het tenminste. En dat is beter dan zes weken na de start van het project ontdekken dat de skills ontbreken.

Initiatieven breken naar beneden af, niet naar boven op

Grote strategische trajecten, initiatieven, bestaan in flowstate niet als onsplitsbare brokken. Ze vallen uiteen in afzonderlijke projecten, elk van één team met een duidelijke FTE-toewijzing.

Dus als de CFO vraagt “Wat heeft de checkout-herbouw gekost?” kun je antwoorden:

“Drie projecten, samen 12,5 FTE over Q2 en Q3. Ongeveer £340k aan volledig doorberekende kosten. Op tijd opgeleverd. We zien 15% meer conversie, goed voor £2,1M extra jaaromzet.”

Dat is geen gok. Dat is data.

Het Bet Framework

Elk project in flowstate koppelt aan:

Bedrijfswaarde: omzeteffect, kostenbesparing of strategische positie
Kostenplaats: waar de uitgave wordt geboekt
Waardestroom: welk deel van het bedrijf ervan profiteert
FTE-toewijzing: de exacte inzet van mensen in de tijd
Vereiste skills: welke vaardigheden het project nodig heeft

Als je werk zo structureert, wordt het gesprek over CapEx en OpEx eenvoudig:

Projecttype	Typische verdeling	Zakelijke impact	Boekhoudkundige behandeling
Nieuwe mogelijkheden	20-30% van de capaciteit	Omzetgroei	CapEx
Platformmodernisering	15-20%	Efficiëntie en schaal	Gemengd
Afbouw van technische schuld	15-20%	Snelheid op lange termijn	OpEx
Onderhoud en support	20-30%	KTLO	OpEx
Innovatie-experimenten	10-15%	Optiewaarde	CapEx

Door de flowstate-methode aanbevolen verdeling voor een evenwichtige engineeringorganisatie

Je houdt niet alleen tijd bij. Je houdt investering en rendement bij.

Hoe dit er in de praktijk uitziet

We werken met bedrijven als RAC aan hun planning van engineeringkosten. Zo verandert het gesprek:

Vóór flowstate:

“We hebben vijf extra engineers nodig voor het platformteam.”

Na flowstate:

“We zetten dit kwartaal 8,5 FTE in op drie projecten:

API v3-migratie (4,0 FTE, £110k, naar verwachting goed voor £2M aan operationele besparingen)

Observability-infrastructuur (3,0 FTE, £82k, verlaagt de MTTR van incidenten met 40%)

Security hardening (1,5 FTE, £41k, een randvoorwaarde voor het enterprise-niveau)

Totale kosten dit kwartaal: £233k. Huidige capaciteit: volledig toegewezen.

Als we vijf engineers toevoegen (£150k per kwartaal volledig doorberekend), kunnen we in Q4 het moderniseringsproject voor betalingen oppakken. Dat levert naar verwachting £5M aan jaaromzet op door minder verlaten winkelwagentjes en nieuwe betaalmethoden.

Wel hebben we 2,0 FTE met ervaring in betalingsverwerking nodig en 1,5 FTE met kennis van PCI-compliance. Onze huidige wervingspijplijn dekt die skills nog niet.”

Zie je het verschil? Je maakt geen ruzie over aantallen mensen. Je bespreekt investering, rendement en capaciteitslacunes.

De planningsinterface die je echt wilt gebruiken

Traditionele planningstools zijn gebouwd voor projectmanagers in 2005. Je hebt een diploma MS Project nodig om ze te snappen.

flowstate is anders:

Slepen en neerzetten van teamleden tussen projecten
Directe kostenberekening terwijl je mensen toewijst
Capaciteitsoverzichten in realtime die laten zien wat er echt kan
Skills matchen om te zien of je de juiste vaardigheden hebt
Scenarioplanning zonder spreadsheets te kopiëren
Automatische audit trail van elke wijziging en de reden

Je modelleert “wat als we volgend kwartaal drie senior engineers aannemen?” in zo’n 30 seconden. Vergelijk scenario’s naast elkaar. Zie het effect op opleverdata, kosten en capaciteit.

Als iemand over zes maanden vraagt “Waarom hebben we die engineers van het betalingsteam gehaald?”, kun je laten zien:

De oorspronkelijke toewijzing en het projectplan
Wie het wanneer heeft gewijzigd
De opmerking met de zakelijke reden
Wat het effect was op projecten verderop
Of de weddenschap uitbetaalde

Samen plannen dat echt werkt

Nu wordt het interessant. Scenarioplanning in flowstate is samenwerkend en live.

Zie het als Git voor je engineeringplan.

Je kunt:

Zoveel conceptscenario’s maken als je wilt
Scenario’s delen met stakeholders voor review
Feedback ophalen en bijsturen
Een scenario goedkeuren, waarna het het nieuwe plan wordt
Ieders concepten automatisch laten bijwerken met de goedgekeurde wijzigingen

Het is samenwerkend. Het wordt live bijgewerkt voor iedereen die meekijkt. Je kunt zoveel concepten weggooien als je wilt. Maar er is één actuele bron van waarheid, en die werkt als vanzelf ieders eigen concepten bij met de goedgekeurde wijzigingen, zodat je altijd op de nieuwste versie werkt.

Geen “naar welke versie van het plan kijken we?” meer. Geen spreadsheets meer rondmailen. Nooit meer ontdekken dat finance met de cijfers van vorige week werkte.

Commit. Merge. Rebase. Maar dan met meer toverkracht.

Herplannen zonder de pijn

De softwaremarkt verandert snel. Strategische koerswijzigingen komen voor. Sleutelfiguren vertrekken. Prioriteiten verschuiven.

In de flowstate-methode betekent herplannen niet opnieuw beginnen. Het betekent:

Projecten slepen om de planning aan te passen
Direct het effect zien op kosten en oplevering
Scenario’s vergelijken voordat je kiest
De reden vastleggen voor later
Het nieuwe plan automatisch publiceren voor stakeholders

Wat vroeger drie dagen kostte, kost nu dertig minuten.

En omdat alles netjes wordt bijgehouden, kun je “Waarom is dit project uitgelopen?” beantwoorden met echte data:

“In week 3 hebben we 2,0 FTE herverdeeld naar het securityincident”
“De API-migratie duurde 6 weken langer door datakwaliteitsproblemen die we ontdekten”
“In week 7 hebben we scope toegevoegd op basis van klantfeedback, hier is de goedgekeurde wijziging”

Geen gokwerk. Feiten.

De methode stuurt het product (niet andersom)

We bouwen niet zomaar software. We leggen de beste werkwijzen vast van technologieleiders uit verschillende sectoren.

De flowstate-methode is ons antwoord op:

Hoe structureer je engineeringwerk voor inzicht?
Wat is de minimaal werkbare planningseenheid die detail en overhead in balans houdt?
Hoe combineer je focus (weinig projecten) met flexibiliteit (wisselende prioriteiten)?
Hoe vertaal je engineeringweddenschappen naar financiële uitkomsten waar finance echt om geeft?
Hoe maak je scenarioplanning snel genoeg om bruikbaar te zijn?
Hoe houd je skills en capaciteiten bij, en niet alleen aantallen mensen?

We praten met:

CTO’s van bedrijven met PE-eigenaren onder operationele druk
Scale-ups in snelle groei met meerdere planningsrondes per jaar
Middelgrote bedrijven die voor het eerst grip op hun engineeringkosten willen
Engineeringleiders die genoeg hebben van de spreadsheethel

De problemen zijn overal dezelfde. De oplossingen hoeven niet op maat te zijn.

Hoe nu verder

De druk op engineeringuitgaven was nog nooit zo hoog. PE-fondsen eisen operationele topprestaties. Besturen dringen aan op margeverbetering. CFO’s willen realtime zien waar het geld heen gaat.

Tegelijk verandert het karakter van engineeringwerk. De productiviteitsbasis verschuift. Historische kostenmodellen voor engineering zijn binnen maanden achterhaald.

De organisaties die dit voor elkaar krijgen, die dynamisch kunnen plannen, nauwkeurig kunnen meten en snel kunnen bijsturen, krijgen een enorm voordeel. Wie nog tabbladen blijft kopiëren, blijft achter.

We hebben flowstate gebouwd omdat ik het zat was geen antwoorden te hebben. Zat van spreadsheets die kapotgaan. Zat van scenarioplanning die drie dagen duurt. Zat van het uitleggen aan besturen waarom we niet kunnen zeggen wat dingen kosten.

De flowstate-methode is onze poging om dit goed op te lossen. Niet met nog een taaktracker. Niet met nog een spreadsheetvervanger. Maar met een echt raamwerk voor hoe engineeringorganisaties in 2025 en daarna werk horen te plannen en te meten.

Help ons dit aan te scherpen

We staan nog aan het begin. De software werkt, RAC en anderen gebruiken hem vandaag al, maar we scherpen de methode aan in gesprekken met technologieleiders.

Herken je een van deze problemen? Dan wil ik met je praten:

Hoe doe je nu scenarioplanning? Als je CFO vraagt “wat als we 20% schrappen?”, wat is dan je proces? Spreadsheets? Onderbuikgevoel? Drie dagen vergaderen?

Hoe houd je de kosten van features bij? Kun je me nu meteen zeggen wat je laatste drie grote features hebben gekost om te bouwen? Geen schattingen. Echte kosten.

Hoe onderbouw je verzoeken om extra mensen? Wat is je verhaal? “We hebben meer mensen nodig” of “We hebben zes maanden lang 3,0 FTE nodig om [ding] te bouwen, dat [waarde] oplevert”?

Hoe ga je om met vaak herplannen? Als prioriteiten elke maand verschuiven, hoe houd je plannen actueel zonder weken kwijt te zijn aan administratie?

Hoe koppel je skills aan projecten? Zie je in één oogopslag of je beschikbare capaciteit de juiste skills heeft voor het komende werk?

De beste raamwerken ontstaan uit collectieve kennis, niet uit individuele ervaring. We bouwen flowstate om problemen op te lossen die ik zelf heb meegemaakt, maar ik wil zeker weten dat we ook de problemen oplossen die jij meemaakt.

Klinkt dit bekend? Neem contact op: flowstate.inc

References

McKinsey & Company, How high performers optimize IT productivity for revenue growth: A leader’s guide ↩
McKinsey & Company, Breaking technical debt’s vicious cycle to modernize your business ↩ ↩²
McKinsey & Company, Developer Velocity: How software excellence fuels business performance ↩
OutSystems, Driving IT innovation forward: 3 imperatives for success ↩
Bain & Company, Global Private Equity Report 2025 ↩ ↩²
Panko, R. R. (2008). “What We Know About Spreadsheet Errors” & Poon, J., et al. (2024). “A review of spreadsheet errors: 35 years of research.” (The foundational academic papers.) The original link for Panko’s publication is dead, but I’ll leave it here for reference: panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm ↩
PwC (2023). “FP&A Survey Results” ↩
Bruno J. Navarro, Workday (2022). “CFO-CIO Alignment Can Help Drive Digital Finance Transformation Goals, Global Research Finds.” ↩