Op jacht naar spoken: wat ontwikkelaars werkelijk bijdragen

‘Ghost engineers’ — één op de tien ontwikkelaars doet vrijwel geen nuttig werk en wekt vooral overtuigend de indruk het razend druk te hebben. De echte oorzaken van die inactiviteit — bijverdienen voor een ander, een burn-out of gewoonweg lanterfanten — kunnen heel lang verborgen blijven voor het management. (Stanford-onderzoek uit 2024: oorspronkelijke thread)

Ontwikkelaars vinden het niet prettig wanneer hun prestaties ter sprake komen. Na een lange ‘gouden eeuw’ voor het vak ontstond in de sector een taboe rond één simpele vraag: rechtvaardigt het resultaat van de ontwikkeling de tijd en het geld die erin zijn gestoken? Maar spookontwikkelaars frustreren ook hun collega’s — en meestal merkt het team, niet het management, het probleem als eerste op.

Hier in Rusland wordt ‘klikken’ van oudsher afgekeurd. Veel mensen kunnen dus van een probleem weten zonder dat iemand er iets over wil zeggen. Waarom zou je je in andermans ellende mengen? Alles komt pas boven water wanneer ieders geduld al lang op is.

Maar misschien moeten we ze gewoon met rust laten, die spoken. Het is immers niet alsof het bedrijf dat geld zal missen.

Alleen zit daar nu juist het probleem…

Wanneer ik het over lage prestaties heb, bedoel ik niet dat Alex zich in het zweet werkt en tien procent minder gedaan krijgt dan Ben. Ik bedoel iets anders: tijdens elke stand-up moet het hele team naar het volgende tranentrekkende verhaal luisteren — het andere team liet hem zitten, het ticket was vaag, de sterren stonden verkeerd. Maar morgen is de taak echt klaar. Op mijn erewoord.

Alleen was dat ‘morgen’ gisteren en eergisteren ook al — en inmiddels is het een traditie geworden.

Teams merken zoiets snel. De mensen die het werk werkelijk verzetten, vragen zich vanzelf af: waarom zou je jezelf uit de naad werken als je ook sterke verhalen kunt vertellen zonder dat daar gevolgen aan zitten?

Maar het probleem opmerken is niet genoeg. Zonder cijfers en feiten bij de hand verandert het gesprek al snel in een ruzie: het team zegt ‘hij presteert te weinig’; de ontwikkelaar antwoordt ‘ze laten me mijn werk niet doen’. Meestal begint niemand iets uit te zoeken voordat het geduld op is en het team de manager vraagt de ontwikkelaar te vervangen.

Dan begint de lange soap: feiten verzamelen, beide kanten aanhoren, feedback geven en de persoon tijd gunnen om de situatie te verbeteren. In mijn ervaring eindigt die meestal met het vertrek van het spook naar een nieuwe — en bijzonder gelukkige — werkgever.

Het probleem is niet alleen dat één persoon minder doet. Het bedrijf betaalt twee keer: eerst voor werk dat nooit wordt gedaan, daarna voor de tijd die collega’s en managers besteden aan extra controles, gaten dichten en uitzoeken hoe dat komt. Uiteindelijk presteert niet langer één ontwikkelaar onder de maat. Het hele team doet dat.

Kan een manager het probleem eerder zien — de afwijking opmerken, naar de context vragen en onderzoek doen voordat het team zijn geduld en het bedrijf tijd en geld verliest?

Met voldoende ervaring kun je dit soort situaties vaak vooraf herkennen aan een paar kenmerkende gedragspatronen:

• Elk succes is van mij; elke mislukking is jouw schuld.
• Excuses voor het mislukken van een taak voordat het werk eraan überhaupt is begonnen.
• Gebrek aan deskundigheid wordt gecompenseerd met buitensporig veel praten.
• Na verloop van tijd wordt vooral de manager als de ‘schuldige’ neergezet.
• Anders dan bij iemand die werkelijk moeite heeft, verbetert dit gedrag zelfs na directe feedback niet.

Maar vermoedens hebben een digitaal spoor nodig.

Laten we de meest gebruikte hulpmiddelen voor het meten van ontwikkelprestaties bekijken en nagaan of ze kunnen helpen om spoken op te sporen.

Voordat ik ze vergelijk, moet ik het voor de hand liggende belangenconflict benoemen: je leest de officiële DevGhost-blog en ik ben de oprichter van het product. Dit is het perspectief van een auteur, geen onafhankelijk onderzoek.

Om softwareontwikkeling zelf te beoordelen — niet het bedrijf of het product als geheel — gebruik ik een eenvoudige drieslag: snelheid, kwaliteit en volume. DORA-metrics vertellen ons iets over snelheid; tests en defecten over kwaliteit. Volume is lastiger. Dit terrein is het minst verkend — en juist hier verstoppen de spoken die we zoeken zich meestal.

DORA: snelheid en betrouwbaarheid van releases

DORA laat zien hoe snel en betrouwbaar een team wijzigingen in productie brengt. Het model gebruikt vijf metrics: de tijd van commit tot productie, deploymentfrequentie, het percentage deployments dat tot storingen leidt, de hersteltijd en het aandeel ongepland herstelwerk.

Dat is een goede maatstaf voor het deliveryproces, maar niet voor de individuele bijdrage. Als één persoon het werk van drie doet terwijl een ander zich achter het gezamenlijke teamresultaat verschuilt, vertelt DORA je dat niet.

Deze metrics zijn bovendien heerlijk handige KPI’s. Bij een bedrijf waar ik werkte, melkten we ze sinds 2018 uit — elk dashboard werd keurig groen gekleurd en iedereen bleef tevreden. Het huidige DORA-model.

Tests en defecten: hoe goed is het werk uitgevoerd?

De methoden zijn beproefd en werken in de praktijk. Kwaliteit wordt bewaakt met codereviews, tests en statische analyse; de gevolgen worden gevolgd via defecten en incidenten.

Maar deze signalen zeggen niets over volume. Eén piepkleine, foutloze patch zet iedere indicator op groen — en het spook blijft onzichtbaar.

Jira en story points: hoeveel tickets zijn afgerond?

Jira toont afgeronde tickets en story points, maar de schattingen komen van het team zelf. Hetzelfde werk kan op drie of dertien punten worden geschat, over vijf tickets worden verdeeld of in één ticket worden gebundeld.

Story points zijn nuttig voor planning, maar onbetrouwbaar als maat voor de individuele bijdrage. Zodra punten het doel worden, gaan mensen optimaliseren voor punten.

Ook dit zijn handige KPI’s. Gegevens worden ingevoerd en tickets worden verschoven, alleen om de quality gates te halen. Een hoop zinloos handwerk.

Commits en regels code: feiten zonder context

Git hangt niet af van teamschattingen, dus is het verleidelijk om commits en regels te tellen. Maar vijf commits kunnen samen één piepkleine patch zijn, terwijl één squash commit een week werk kan vertegenwoordigen.

Opmaak, gegenereerde code, kopiëren en verplaatsen drijven het aantal regels op, terwijl een moeilijke oplossing uit slechts tien regels kan bestaan.

Swarmia, LinearB en Waydev: het hele engineeringsysteem op één plek

Swarmia, LinearB en Waydev brengen Git, issuetrackers en CI/CD samen. Managers zien DORA-metrics, wachtrijen voor reviews, doorlooptijden van wijzigingen en onderzoeksresultaten.

Ze geven een bruikbaar beeld van het engineeringsysteem — en laten vaak zien dat het probleem in het proces zit in plaats van bij een persoon. Maar het werkvolume van een individuele ontwikkelaar meten op een vergelijkbare schaal is niet de centrale vraag die deze platforms proberen te beantwoorden. Swarmia, LinearB, Waydev.

GitClear: wat overblijft na de coderuis

GitClear maakt onderscheid tussen toegevoegde, verplaatste en gekopieerde code, sluit gegenereerde bestanden uit en houdt er rekening mee of nieuwe code later is herschreven of verwijderd.

Dat levert Diff Delta op — GitClears eigen eenheid voor betekenisvolle wijzigingen die in de codebase blijven bestaan. Gekopieerde code of code die snel weer wordt weggegooid, telt minder zwaar dan een compacte wijziging die in productie blijft werken. Zo werkt Diff Delta.

Diff Delta beantwoordt niet hoeveel werk er nodig was. Het vertelt hoeveel betekenisvolle verandering er na de ruis en het herstelwerk overbleef. GitClear is vooral sterk in het meten van de houdbaarheid en kwaliteit van code en in het analyseren van de invloed van AI.

Nu komen we in de buurt. De dienst publiceert benchmarks, maar Diff Delta blijft een eigen eenheid: een getal als 10.000 zegt weinig zonder de juiste vergelijking en begrip van de methode. Er is geen helder ijkpunt zoals ‘100% is normaal’. Diff Delta-benchmarks.

BlueOptima: dezelfde vraag op ondernemingsschaal

Ik ken BlueOptima uit eigen ervaring. In 2019 begon ik met het platform te werken. Die ervaring inspireerde me om mijn eigen product te bouwen.

Het Coding Effort-algoritme analyseert iedere wijziging in de broncode met een reeks statische metrics en houdt rekening met omvang, complexiteit en samenhang met de rest van de code. Vervolgens drukt het de uitkomst uit in uren.

Daardoor kunnen ontwikkelaars uit verschillende teams en technologiestacks worden vergeleken, ook met een wereldwijde benchmark. Voor mij was dit de eerste overtuigende poging om niet de vraag ‘Hoeveel regels schreef deze ontwikkelaar?’, maar ‘Hoeveel inhoudelijk werk vertegenwoordigen deze wijzigingen?’ te beantwoorden. De methodologie van BlueOptima, wereldwijde benchmark.

In mijn geval vereiste toegang tot die enterprise-mogelijkheden een vrij zware invoering: er moest een agent binnen een gesloten netwerkomgeving worden geïnstalleerd, de prijs was hoog en de resultaten vereisten deskundige interpretatie.

Voor een bedrijf met duizenden ontwikkelaars kan dat gerechtvaardigd zijn. Voor een startup of klein team waarschijnlijk niet. Die kloof werd later een van de redenen waarom DevGhost bestaat.

Dezelfde meetlat, zonder aanbesteding

Toen ik DevGhost bouwde, wilde ik niet nog een alles-in-één-platform maken dat vol zat met elke denkbare engineeringmetric.

Ik wilde hetzelfde antwoord dat BlueOptima gaf — hoeveel inhoudelijk werk er achter de wijzigingen zit — maar in een vorm die een startupoprichter of klein team kan gebruiken zonder aanbesteding, langdurige invoering of een ploeg consultants.

De logica is eenvoudig: DevGhost analyseert de wijzigingen zelf — wat is toegevoegd, verwijderd en geherstructureerd, en hoe moeilijk het was om het resultaat te maken en te verifiëren. Opmaak, codeverplaatsingen, grootschalige automatische vervangingen en gegenereerde code worden gescheiden van inhoudelijk werk.

Het resultaat is een inspanningsschatting in equivalente uren: hoelang een medior ontwikkelaar die de codebase kent en zonder AI werkt, nodig zou hebben om dezelfde code te schrijven. Het is niet de werkelijk aan het toetsenbord bestede tijd en ook geen beoordeling van de kwaliteit of bedrijfswaarde van de code. Het is één gezamenlijke meetlat om wijzigingen te vergelijken. Lees meer over de methodologie van DevGhost.

Ghost% vergelijkt die schatting met de verwachte productie van een medior ontwikkelaar en houdt rekening met hoeveel van iemands tijd werkelijk aan ontwikkeling wordt besteed. Een resultaat van 100% betekent dat diegene volgens de norm presteert. Een lager resultaat is reden om onderzoek te doen; een hoger resultaat is het bestuderen waard en kan misschien een best practice worden.

De benchmark gaat bewust uit van werk zonder AI. DevGhost probeert niet te bepalen wie een bepaald stuk code heeft geschreven — een mens, Copilot of een autonome agent. Het beoordeelt de uiteindelijke wijzigingen: hoeveel inspanning zou een medior ontwikkelaar nodig hebben gehad om ze zonder AI te maken en te verifiëren?

Daardoor verdwijnt het effect van AI niet in de metric. Het wordt zichtbaar. Als een ontwikkelaar in één periode werk maakt en verifieert dat vroeger twee of drie keer zoveel inspanning had gekost, weerspiegelt Ghost% dat. Opmaak, grootschalige codegeneratie en andere vormen van coderuis zouden niet hetzelfde effect moeten hebben.

Wie beoordeelt de beoordelaar?

De meest voor de hand liggende vraag is: waarom zou iemand een door een machine gemaakte schatting vertrouwen? Het korte antwoord is dat niemand die blind zou moeten vertrouwen.

De moeilijkheid van werk beoordelen is per definitie subjectief. We testten dit door meerdere ervaren ontwikkelaars dezelfde wijzigingen te laten schatten — en kregen merkbaar verschillende cijfers. Iedereen heeft een ander tempo, andere ervaring en een eigen beeld van wat moeilijk is.

Ook DevGhost kan ernaast zitten. Het voordeel is niet dat het toegang heeft tot een absolute waarheid. Het voordeel is dat iedere wijziging langs dezelfde meetlat wordt gelegd — zonder voortrekken, vermoeidheid of een vooraf gevormde mening over de auteur.

Daarom is Ghost% een signaal, geen oordeel. Een laag resultaat kan wijzen op een geringe bijdrage, maar ook worden verklaard door verantwoordelijkheden als teamlead, architectuurwerk, mentoring, incidenten of blokkades.

Het getal vertelt je waar je een vraag moet stellen. De manager moet het antwoord nog steeds zelf vinden — maar heeft nu een onafhankelijke tweede mening in plaats van alleen intuïtie.

‘Ik weet toch al hoe iedereen in mijn team presteert’

Een klant van DevGhost leidt de engineeringafdeling van een snelgroeiend AI-bedrijf. Aanvankelijk stond hij sceptisch tegenover het hele idee om engineeringprestaties te meten. Zijn standpunt was eenvoudig: een goede engineeringleider weet ook zonder dashboard hoe iedereen presteert.

We analyseerden de geschiedenis van een repository die hij goed kende. Over drie ontwikkelaars bestonden al zorgen: hun tickets bewogen langzaam, maar ze werkten aan een afzonderlijke service, waardoor vergelijking met de rest van het team lastig was. DevGhost liet voor alle drie ongeveer zes maanden lang consequent lage resultaten zien.

Later, toen de ontwikkelaars begonnen te vertrekken, bleek dat ze al die tijd ook eigen producten hadden gebouwd. DevGhost kon de reden niet kennen. Het bracht alleen iets aan het licht dat aantallen commits, pull requests en dagelijkse gesprekken in Slack niet hadden laten zien: hun werkvolume lag duidelijk lager dan verwacht.

Maar de analyse veranderde niet in een ontslaglijst. Bij twee andere ontwikkelaars maakte een laag resultaat het mogelijk om concrete feedback te geven, de oorzaken te onderzoeken en de prestaties te verbeteren. Beiden bleven in het team.

De ontwikkelaars die hij sterk vond, stonden ook precies waar hij ze verwachtte. En nu kon hij niet alleen zien wie boven verwachting presteerde, maar ook hoe consequent.

Eén geval bewijst natuurlijk niet dat de methode nauwkeurig is. Wat de klant verraste, was hoe sterk het totaalbeeld overeenkwam met wat voordien alleen op basis van intuïtie bekend was — en in sommige gevallen pas achteraf duidelijk werd.

Wat als één ontwikkelaar het resultaat van drie levert?

Op spoken jagen is het opvallendste deel van dit verhaal. Maar de bovenkant van de grafiek kan nog nuttiger zijn.

Als een ontwikkelaar consequent een veelvoud van de gemiddelde productie levert, is het de moeite waard om precies uit te zoeken hoe dat lukt.

Tegenwoordig is de vraag niet meer óf een ontwikkelaar AI gebruikt — voor velen is het een normaal onderdeel van het werk geworden. De vraag is hoe effectief iemand agents omzet in extra leveringscapaciteit.

De één komt niet verder dan automatisch aanvullen. De ander weet agents de juiste context te geven, duidelijke regels te formuleren, meerdere taken parallel uit te voeren en het resultaat zorgvuldig te controleren. Dezelfde toegang tot AI kan daardoor radicaal verschillende productiviteitswinsten opleveren.

Een hoge Ghost% helpt ontwikkelaars te vinden die al sterke resultaten boeken met die samenwerking tussen mens en agent — en te begrijpen welke werkwijzen de rest van het team kan overnemen.

Als het hoge resultaat wordt bevestigd door de kwaliteit van het werk en het oordeel van de manager, moet die ontwikkelaar worden gewaardeerd, behouden en voor promotie in aanmerking komen. Het team moet diens werkwijzen bestuderen en verspreiden.

Maak van de meetlat geen wapen

Iedere metric ondergaat hetzelfde lot: vroeg of laat probeert iemand er een KPI van te maken. Ghost% is daar niet geschikt voor.

Maak Ghost% tot team-KPI en mensen gaan hun werk erop afstemmen. Publiceer een ranglijst en het vertrouwen verdwijnt. Verander de score in een ontslagknop en fouten worden onvermijdelijk.

Ik zou vier regels vastleggen:

• Trek geen conclusies uit één meting of een korte periode.
• Houd rekening met iemands rol, het aandeel van de tijd dat aan ontwikkeling wordt besteed en werk dat buiten de code plaatsvindt.
• Laat het resultaat aan de ontwikkelaar zien en geef diegene de kans om de context uit te leggen.
• Gebruik Ghost% niet als enige grond voor een personeelsbeslissing.

Als een laag resultaat aanhoudt, moet de manager eerst de oorzaken onderzoeken. Misschien heeft de persoon werkelijk moeite om te presteren. Of misschien werkt diegene aan architectuur, handelt incidenten van anderen af of wordt door de teamprocessen geblokkeerd.

Als het probleem wordt bevestigd, moet er een concreet verbeterplan komen en na een afgesproken periode een nieuwe beoordeling.

Metrics afwijzen maakt geen einde aan de beoordeling van mensen. Het laat je alleen achter met onderbuikgevoelens, verhalen uit stand-ups en de persoonlijke voorkeuren van de manager.

Snelheid, kwaliteit en volume vragen om verschillende hulpmiddelen. DORA laat zien hoe wijzigingen in productie terechtkomen. Tests en defecten tonen de kwaliteit. DevGhost voegt een schatting toe van het werk achter de codewijzigingen.

Geen van deze metrics zou beslissingen voor de manager moeten nemen.

De waarde van een getal is niet dat het een oordeel velt. De waarde is dat een moeilijk gesprek eerder begint — en op feiten is gebaseerd.

Hoe beoordeel je het werkvolume van ontwikkelaars, en waar trek je de grens tussen nuttige transparantie en surveillance?