Wat dertig minuten wachten per engineer per dag echt kost

Een half uur per dag. Zo weinig lijkt het.

Je wacht op een build. Je wacht tot iemand je pull request bekijkt. Je wacht op een omgeving die vrijkomt, op een goedkeuring, op een pipeline die twaalf minuten doet over iets wat in twee zou moeten. Niemand noteert het, want het voelt niet als tijd die je kwijtraakt. Het voelt als het werk.

Reken het door en het is €5.000 per engineer per jaar. Bij honderd engineers een half miljoen euro. Elk jaar, en op geen enkele regel van je P&L.

Er zit geen truc in. Je kunt hem zelf natrekken met je eigen cijfers:

• Een half uur per werkdag is 2,5 uur per week.
• Bij ongeveer 220 werkbare dagen per jaar is dat 110 uur per engineer per jaar.
• Reken je met een belaste kostprijs van zo’n €45 per uur, dan kom je op €4.950 — afgerond €5.000.
• Honderd engineers: €495.000 per jaar.

Vul gerust je eigen tarief in. Het punt verandert niet: dit is geen randverschijnsel, het is een salarispost ter grootte van een klein team, en er staat geen factuur tegenover.

Als je erop gaat letten, blijkt het bijna nooit één groot blok te zijn. Het zijn kleine stukjes die zich opstapelen:

• Wachten op builds en tests. Een pipeline van acht minuten die je vijf keer per dag draait, is veertig minuten. Draait hij niet betrouwbaar, dan draai je hem vaker.
• Wachten op review. Meestal de grootste post, en bijna nooit apart gemeten. Je pull request staat klaar; je collega zit in een meeting.
• Wachten op omgevingen. Één staging, drie teams.
• Wachten op goedkeuring. Iemand moet een vinkje zetten en die iemand heeft vandaag iets anders te doen.
• De verborgen kosten van het schakelen. Dit is de pijnlijkste. Vijftien minuten wachten kost je zelden vijftien minuten: je begint aan iets anders, en de weg terug naar waar je was kost nog eens tien.

Cloudkosten zie je, want er komt een factuur. Licenties zie je, want er komt een factuur. Wachttijd komt van niemand, dus komt hij nergens binnen.

Er is ook geen moment waarop iemand een besluit neemt. Niemand heeft ooit goedgekeurd dat de pipeline acht minuten duurt; hij is er in de loop van twee jaar naartoe gegroeid, stap voor stap, en elke afzonderlijke stap was verdedigbaar.

En de mensen die er het meest last van hebben, zijn precies de mensen die het het minst snel melden. Wachten voelt niet als een probleem dat je escaleert. Het voelt als hoe het werk nu eenmaal is.

Dit is het deel dat de meeste teams verrast.

Als code sneller geschreven wordt, wordt er niet minder gewacht — er wordt méér gewacht. Meer wijzigingen bereiken sneller de wachtrij voor review. Meer pull requests concurreren om dezelfde reviewers. Meer builds vechten om dezelfde runners. De bottleneck verdwijnt niet, hij verschuift naar de plek waar geen model bij kan.

Dat is precies waarom code goedkoper maken de kosten niet wegneemt maar concentreert. We hebben dat argument uitgewerkt in onze kijk op AI in softwareontwikkeling: zodra schrijven niet langer je beperking is, wordt alles eromheen je beperking — en dan pas blijkt of je dat ooit gemeten hebt.

Je hoeft hier geen groot programma voor op te tuigen. Drie dingen brengen het grootste deel in beeld:

• Splits je lead time op in fases. Eén getal van commit tot productie verbergt precies wat je zoekt. Zodra je schrijven, wachten op review, testen en uitrollen apart ziet, springt de grootste post er meteen uit.
• Meet review-latency apart. De tijd tussen “klaar voor review” en “iemand kijkt ernaar”. In de meeste teams is dit de grootste enkele post, en bijna nergens staat hij op een dashboard.
• Meet de doorlooptijd van je pipeline, niet alleen of hij slaagt. Slagingspercentage zegt niets over de tijd die je eraan kwijt bent.

Meet een maand voordat je iets verandert. Zonder nulmeting kun je achteraf niet aantonen dat je iets verbeterd hebt, en dan wint degene met de sterkste mening.

De ingrepen zijn zelden spectaculair, en dat is precies waarom ze blijven liggen.

• Spreek een reviewtermijn af. “Pull requests onder de 300 regels worden binnen 24 uur bekeken” haalt vaak meer weg dan welke technische ingreep ook.
• Maak je pull requests kleiner. Kleinere wijzigingen worden sneller bekeken, en de wachttijd daalt harder dan de omvang.
• Versnel je pipeline met caching en parallelle tests. Acht minuten naar drie is over honderd engineers een aanzienlijk bedrag.
• Geef elke wijziging een eigen omgeving in plaats van te wachten op de gedeelde staging.
• Haal goedkeuringen weg die niets tegenhouden. Een vinkje dat altijd gezet wordt, is geen controle maar vertraging.

Halveer je die dertig minuten, dan haal je bij honderd engineers een kwart miljoen euro per jaar terug. Dat is geen besparing die je hoeft te bevechten in een budgetronde — je hoeft alleen te weten dat hij er is.

Wachttijd is de grootste kostenpost die niemand op zijn begroting heeft staan.

Een half uur per engineer per dag is €5.000 per jaar per persoon en een half miljoen bij honderd. Het staat op geen factuur, niemand heeft het goedgekeurd, en het groeit vanzelf terwijl je nergens op let.

En zodra AI het schrijven versnelt, wordt dit het enige dat er nog toe doet. Meet het voordat je erin investeert, anders weet je straks alleen dat je sneller code produceert — niet of je sneller iets oplevert.