Je functioneringsgesprek is een geheugentest

Vraag het aan elke engineering manager wie hun beste engineer is. Kijk hoe snel het antwoord komt. Geen aarzeling, geen voorbehoud, geen ‘laat me eerst iets nakijken.’ Ze weten het. Ze hebben het altijd geweten.

Vraag ze nu om het werk te laten zien.

Je krijgt een verhaal. Meestal een goed verhaal, over een incident dat iemand om 2 uur ’s nachts heeft afgehandeld, of een refactor die een kwartaal deblokkeerde, of de persoon die altijd antwoordt in het kanaal. Wat je niet krijgt is een getal, of een vergelijking, of enig verslag van de vier engineers van wie de manager het werk niet in de ruimte heeft meegemaakt. Het vertrouwen was nooit gebaseerd op meting. Het was gebaseerd op herinnering, en herinnering is een functie van nabijheid.

Hier is de stelling, en alles hierna is bewijs ervoor. Engineeringprestaties worden beoordeeld op basis van geheugen, geheugen beloont zichtbaarheid in plaats van waarde, en het ding dat je mensen eigenlijk wilt laten bouwen staat opgeschreven in een roadmap die nooit is verbonden met het ding waarop je ze beoordeelt. Die twee documenten, de roadmap en de beoordeling, hebben niets met elkaar te maken in bijna elk bedrijf dat ik heb gezien, inclusief het mijne tot voor kort.

Dus hebben we ze verbonden. Elke gemergde pull request wordt gelezen door een model, krijgt een ernst toegewezen, en wordt vermenigvuldigd met hoeveel onze roadmap geeft om de component die het aanraakte. Het resultaat is een maandelijks leaderboard, en het voedt bonusbeslissingen.

Ik ga je de onze laten zien, inclusief de delen waar het gênant is en de delen waar het fout is.

De gangbare wijsheid is dat dit niet gemeten kan worden, en de gangbare wijsheid is een schouderophalen

Het standpunt over het meten van individuele engineeringoutput is dat je het niet moet doen, omdat elke proxy een valstrik is. Regels code beloont opgeblazenheid. Commit count beloont splitsen. Story points zijn een onderhandeling, geen meting. Zelfs de goede frameworks zijn bewust op teamniveau: DORA meet vier dingen over een delivery pipeline en zegt niets over mensen, wat een ontwerpkeuze is waar de auteurs expliciet over zijn.

Dat is allemaal correct, en niets ervan is een antwoord. Weigeren te meten levert geen bedrijf op waar niemand wordt gerangschikt. Het levert een bedrijf op waar iedereen toch wordt gerangschikt, door een mechanisme zonder audittrail. De rangschikking gebeurt nog steeds bij compensatietijd. Het gebeurt alleen in een kamer, uit het geheugen, gewogen door met wie de persoon in de kamer de meeste tijd heeft doorgebracht.

Noem het de loud engineer premium: de kloof tussen hoe goed je wordt beoordeeld en hoe goed je presteerde, volledig verklaard door je afstand tot degene die je beoordeling schrijft. Het is geen karakterfout van managers. Het is de voorspelbare uitkomst van het vragen aan een mens om vijftien mensen hun technische bijdragen over een jaar te vergelijken met niets anders dan wat ze toevallig hebben opgemerkt.

De premium was onvermijdelijk tot ongeveer twee jaar geleden, omdat het ruwe materiaal voor een beter antwoord een stapel diffs was die niemand tijd had om te lezen. Die beperking is verdwenen. Een model kan elke diff in je repository elke maand lezen voor minder dan de kosten van één uur van de vergadering waar je momenteel gokt.

Ze lezen is het makkelijke deel. Bepalen wat het lezen waard is, is het hele probleem, en dat is geen technische vraag.

De hele formule past op één regel

Hier is hij, volledig, uit het scoring pad in GitRank:

final_score = is_eligible ? severity_base_points × component_multiplier : 0

Dat is geen vereenvoudiging voor de blog. Dat is de regel. Er is geen verborgen regressie, geen geleerde weging, geen reputatieterm, geen aanpassing voor anciënniteit. Ernst maal belangrijkheid, of nul.

De ernsthelft is een vaste ladder. Vier niveaus, vier puntwaarden, eenmalig ingesteld en zichtbaar voor iedereen die wordt gescoord:

Een kritieke fix is twintig laagprioritaire waard. Die verhouding is een beleidsverklaring, en we hebben het opgeschreven in plaats van het in iemands hoofd te laten.

De belangrijkheidshelft is het deel dat er echt toe doet, en het is de reden waarom ik denk dat deze aanpak generaliseert. Elke component in de repository heeft een multiplier, en de multiplier wordt ingesteld door wat het product dit kwartaal nodig heeft:

Chat is 2,0x omdat chat is waar we het product op inzetten. Authenticatie is 1,0x omdat het werkt en we willen dat het rustig blijft werken. Samenwerkingsfuncties en documentmarkering zijn 2,0x om dezelfde reden als chat. Geen van die getallen zijn technische oordelen. Het zijn de roadmap, overgetypt in een veld dat betaalt.

Dit is de zet. Niet het model, niet het leaderboard, niet de gamification. De zet is dat het strategiedocument en de compensatie-invoer hetzelfde document werden. Als de roadmap in oktober verandert, veranderen de multipliers in oktober, en verandert de prikkel in oktober in plaats van bij de volgende jaarlijkse beoordelingscyclus over veertien maanden.

Laat me dit verduidelijken, want dit is het deel dat mensen overslaan. Het echte probleem in een groeiende technische organisatie was nooit dat mensen lui zijn. Het is dat veertig slimme mensen, elk lokaal en eerlijk optimaliserend, gezamenlijk een kwart werk produceren dat niet optelt tot wat het bedrijf zei te willen. Middenmanagement bestaat grotendeels om dat op te lossen door de strategie in gesprekken rond te dragen, bureau voor bureau, met elke stap verlies aan getrouwheid. Een vermenigvuldigingstabel doet dezelfde routering in één stap en wordt niet moe, heeft geen favorieten en vergeet niet wat je in januari hebt verteld.

Een kritieke fix in chat is veertig polijstcommits in de API waard

Voer de twee helften samen en de spreiding is groot.

Een P0 in chat scoort 100 basis maal 2,0, dus 200 punten. Een P3 in de API scoort 5 basis maal 1,0, dus 5 punten. De meest waardevolle enkele pull request die je hier kunt mergen, is veertig van de minst waardevolle waard. Niet veertig procent meer. Veertig keer.

Dat getal is opzettelijk heftig, en het doet wat zachte prikkels nooit voor elkaar krijgen. Niemand herschikt zijn week om een verschil van 15%. Mensen herschikken hun week absoluut om een 40x verschil.

Kijk wat er gebeurt met een echte week onder die gewichten. Hier is de ernstverdeling over vijf weken, met de week van 13 juli uitvergroot:

188 pull requests. P2 is 59% ervan, wat is wat een normale technische week overal is: meestal middelgrote fixes met een workaround beschikbaar.

Weeg het nu. Die 111 P2’s zijn 2.220 punten waard op 1x. De 50 P1’s zijn 2.500 waard. Minder dan de helft van het aantal pull requests draagt meer dan de helft van de waarde van de week, en de enkele P0 is evenveel waard als twintig van de P3’s die een ruwe commit-telling als identiek werk zou hebben behandeld.

Dat is het hele argument voor weging, in één week echte data. Tel pull requests en je concludeert dat de week over P2’s ging. Weeg ze en je ontdekt dat de week over vijftig specifieke stukken werk ging, en je kunt noemen wie ze deed.

Twee mensen waren 58% van de output, en ik zou de volgorde niet hebben geraden

Terug naar het leaderboard, want dit is waar ik mijn eigen intuïtie niet meer vertrouwde.

Zeven ontwikkelaars, 10.415 punten over het venster van 30 dagen. De topontwikkelaar heeft er 3.530, wat 33,9% is van alles wat het team aan waarde produceerde. De top twee hebben samen 57,7%.

Ik wil voorzichtig zijn met wat dat wel en niet betekent. Het betekent niet dat de andere vijf onderpresteren, en als je het zo leest, heb je de verkeerde les uit dit bericht geleerd. Een dergelijke concentratie betekent meestal dat de top twee aan de componenten met de hoogste multiplier werken, wat precies is waar het systeem voor is ontworpen om te belonen en precies wat we hen hebben gevraagd te doen. Het getal is een beschrijving van waar waarde terechtkomt, geen oordeel over vijf mensen.

Maar kijk naar de volgorde, want die doorbrak mijn voorspelling. Hier is wie wat bezit:

Mulualem-E is de primaire expert op chat, onze 2,0x component, met 71 van de 230 pull requests. Hij is ook de primaire expert op agents, onze 1,5x component, met 86 van de 148, of 58% van dat gebied. Als je me dat had beschreven en had gevraagd wie het leaderboard aanvoert, zou ik hem zonder aarzelen hebben genoemd. Hij is tweede.

De eerste plaats gaat naar tugberkayartextcortex, met 31 P1 pull requests tegen Mulualem-E’s 12. Ernstmix versloeg componentbezit. Het bezitten van het belangrijkste gebied van het product is niet hetzelfde als herhaaldelijk hoog-impact werk daarin landen, en totdat we dit publiceerden, had ik je niet kunnen vertellen welke van die twee dingen onze beloning daadwerkelijk beloonde. Het beloonde degene die ik toevallig had opgemerkt.

Dat is de luidruchtige ingenieurspremie, op heterdaad betrapt, in mijn eigen bedrijf. Mijn intuïtie had de juiste twee mensen en de verkeerde volgorde, en de verkeerde volgorde is wat een bonus is.

De persoon die de meeste code schreef, staat op de laatste plaats

Nu de bevinding die me ongemakkelijk maakte, en die ik wil dat je echt tot je laat doordringen.

karthikmudunuri is de primaire expert op de presentation maker, met 51 van de 58 pull requests van die component. Dat is 88% van een heel productgebied. Volume is niet zijn probleem. Hij staat laatste op het leaderboard, met 300 punten.

Er is een combinatie die precies op dat getal uitkomt: vier P1 pull requests in een 1,5x component, en verder niets dat scoort. 4 × 50 × 1,5 = 300. Zijn badge zegt 4 P1, wat past. Ik kan niet bewijzen dat dat de echte decompositie is van dit dashboard, en ik wil de onnauwkeurigheid eerlijk aangeven, omdat het leaderboard 30 dagen beslaat terwijl de componentgrafieken van 6 juli tot 3 augustus lopen, dus de twee vensters liggen dicht bij elkaar maar zijn niet identiek.

Als de decompositie klopt, leverden ongeveer 47 samengevoegde pull requests nul punten op. Er zijn maar twee verklaringen. Of ze waren echt kleine verbeteringen met lage ernst, in welk geval de score correct is en het nuttige gesprek gaat over de vraag of we iemand een maand lang met 88% focus op een component moeten laten werken die we niet als belangrijk hebben gemarkeerd. Of het was echt werk dat door de geschiktheidsgate op nul is gezet, in welk geval de score fout is en de tool hem een uitleg verschuldigd is.

De scoring is alles-of-niets wat betreft geschiktheid. Als je één ingeschakeld criterium niet haalt – de standaardset is issue-koppeling, fix-implementatie, PR-beschrijvingskwaliteit, tests waar het model oordeelt dat tests vereist zijn, en een maximum van 3.000 regels – dan is de score nul, ongeacht de ernst. Een echt kritieke fix met een slechte beschrijving scoort hetzelfde als helemaal niets.

Ik weet niet welke verklaring juist is, en hier is mijn echte klacht: het dashboard zou me per pull request moeten kunnen vertellen, en nu moet ik het terugrekenen uit een totaal. Dat is een echt gat in ons product en het wordt opgelost. Het is ook precies de faalmodus die mensen vrezen bij scoresystemen, dus ik ga niet doen alsof ik het in een design review heb gevonden. Ik vond het terwijl ik dit bericht schreef.

Waar de bugs zitten is een productbeslissing, geen technische

Het andere dat voortkomt uit het scoren van elke pull request is dat je stopt met discussiëren over kwaliteit op basis van anekdotes.

740 pull requests verspreid over de tien drukste componenten. 230 daarvan, 31%, waren bugfixes in plaats van nieuw werk. Chat alleen al is 230 pull requests, nog eens 31%, wat precies is hoe een 2.0x multiplier eruit zou moeten zien als hij werkt.

Dan is er de presentatiemaker: 58 pull requests, waarvan 23 bugs. Dat is een bugpercentage van 40% in een component met vier bijdragers, tegenover 25% in chat met zeven. En betalingen is 44 pull requests met 20 bugs, een percentage van 45%, in het component dat met geld te maken heeft.

Chat en agents staan gelijk met 57 bugs elk, maar chat produceerde die over 230 pull requests en agents over 148. Hetzelfde aantal bugs, 55% meer werk achter een van beide. Dat is een signaal over agents dat geen enkele retrospectieve ooit aan het licht zou brengen, omdat geen enkel teamlid genoeg van beide heeft samengevoegd om het op te merken.

De buglijn en de featurelijn stijgen samen over het venster in plaats van elkaar af te wisselen, wat de vorm is die je wilt en niet de vorm die ik verwachtte. Ik lees die grafiek als beschrijvend, niet als een bewering dat we iets hebben verbeterd. Het beslaat vijf weken en de trend zit binnen de ruis die je zou krijgen van een enkel groot project dat landt.

Hier zit onze eigen tool momenteel fout

Als ik je alleen de delen zou laten zien die werken, zou je gelijk hebben om alles af te wijzen. Dus:

• Het prompttabblad doet niet wat het belooft in het productiepad. Er is een beheerdersscherm waarmee je de evaluatieprompt kunt aanpassen. Het stuurt de batch-evaluatierunner. Het webhook- en cronpad dat pull requests in productie scoort, gebruikt een prompt die hardcoded in de broncode staat. Als je die template bewerkt in de verwachting dat je live scores vandaag veranderen, gebeurt dat niet, en niets in de UI vertelt je dat.

• De kolom ‘PR’s’ in het leaderboard van het dashboard is geen telling van pull requests. Het is de auteurschapsscore. Je kunt het zien in de bovenstaande screenshot: de bovenste rij toont 3530 onder PR’s en 3530 onder Score. De losse leaderboardpagina doet dit correct, met aparte kolommen voor pull requests en auteurschap, dus het is een verkeerd label op het ene scherm dat iedereen daadwerkelijk opent, wat bijna de slechtste plek is om er een te hebben.

• Onze README publiceert de verkeerde puntwaarden. Er staat dat P2 25 punten is en P3 10. De database seeds 20 en 5, en de configuratiescreenshot hierboven bevestigt 20 en 5. De documentatie en de software zijn het oneens over de scoring, en de software wint.

• Het reviewspoor is zo goed als dood. Het reviewen van andermans code levert punten op op een aparte snelheidsladder, waarbij snellere reviews hoger scoren. In dat hele leaderboard heeft precies één persoon reviewpunten: 90 van de 10.415 totaal, oftewel 0,86% van alles wat gescoord is. Wat we ook denken te stimuleren met betrekking tot code review, we doen het niet. De meest waarschijnlijke reden is dat reviewsync pas recentelijk is begonnen met verzamelen, maar ik heb dat niet bevestigd, en tot ik dat doe, is de eerlijke lezing dat de functie niet landt.

• Onze eigen FAQ beweert een classificatienauwkeurigheid van ongeveer 90% en ik kan dat niet onderbouwen. Er is geen eval-set in de repository, geen benchmark-script en geen beoordeeld corpus achter dat getal. Het is een bewering die ik niet van een leverancier zou accepteren, en het staat op onze eigen marketingpagina. Het wordt verwijderd.

Een scorebord wordt misbruikt, en het onze heeft bijna geen verdediging

Ik ben door onze scoringscode gegaan op zoek naar anti-manipulatiemaatregelen. Hier is de volledige lijst van wat er bestaat.

Pull requests met meer dan 3.000 gewijzigde regels komen niet in aanmerking, wat de grofste vorm van opsmuk stopt. Zelfreviews scoren nul en worden uitgesloten van elk leaderboard-query. Reviews van accounts met [bot] in de login worden overgeslagen. Het model wordt gevraagd of de code daadwerkelijk doet wat de beschrijving beweert, wat het dichtst in de buurt komt van een onzin-detector. Beheerders kunnen elke score overschrijven, en de overschrijving vereist een schriftelijke reden van ten minste tien tekens.

Hier is wat niet bestaat. Geen wekelijkse of maandelijkse puntlimiet per persoon. Geen afnemende meeropbrengst bij herhaald werk in dezelfde component. Geen enkel soort tijdsverval, en het venster van 30 dagen op het leaderboard is een standaard datumbereik dat iedereen kan verbreden, geen limiet. Geen detectie van duplicaten of terugdraaiingen, dus het repareren van iets dat je vorige week brak scoort hetzelfde als het repareren van iets dat iemand anders brak. Geen collusiedetectie tussen reviewers. En het botfilter is van toepassing op reviewers maar niet op pull request-auteurs, dus een door een bot geschreven gemergde pull request scoort hetzelfde als een menselijke, wat in 2026 geen hypothetisch scenario is.

Iedereen die vastbesloten is om dit systeem te farmen kan dat. Verdeel werk in meer pull requests, elk met een issue-link en een schone beschrijving, gericht op de 2.0x-component. Dat is de exploit, en ik wil het precies benoemen vanwege hoe het eruitziet: het ziet eruit als kleine, goed gedocumenteerde, goed geteste wijzigingen aan het belangrijkste deel van het product. De meest effectieve manier om ons scorebord te bedriegen is om te doen wat we willen. Dat is geen toeval, het is het ontwerpdoel, en het is de enige verdediging tegen de wet van Goodhart die ooit echt heeft gewerkt. Maak de proxy duur om te vervalsen op elke manier die niet het echte werk is.

Het is geen volledige verdediging. Ernst wordt toegewezen door een model dat een diff leest, en een model kan worden overgehaald om een middelgrote bug een hoge te noemen door een voldoende dramatische pull request-beschrijving. We hebben niet gemeten hoe vaak dat gebeurt. Niemand heeft dat. Als je een tool in deze categorie evalueert, inclusief de onze, dan is dat de vraag die je moet stellen, en ‘ongeveer 90%’ is geen antwoord.

Ik ga je het uplift-getal niet geven, omdat ik het niet heb

Hier is de bewering die ik zou willen doen. Sinds we dit leaderboard maandelijks zijn gaan publiceren, is het werk zichtbaar verschoven naar de componenten die we als belangrijk hebben gemarkeerd, omdat ingenieurs de score willen.

Hier is waarom ik het niet als een getal presenteer. We hebben dit halverwege ingeschakeld, zonder schone basislijn, zonder controle-repository, en zonder vooraf geregistreerde definitie van wat ‘verschoven’ zou betekenen. De multipliers veranderden gedurende de periode. Dat gold ook voor personeelsbezetting en roadmap. Elk percentage dat ik zou publiceren, zou een getal zijn dat ik koos nadat ik de data had gezien, wat geen meting is, het is een versiering.

Wat ik je kan vertellen is kwalitatief en ik label het als zodanig. De argumenten veranderden. Mensen stopten met vragen of hun werk werd gewaardeerd en begonnen te vragen waarom een component als 1.0x werd beoordeeld. Dat is een veel beter gesprek om te voeren, en het is het enige waar ik op zichzelf voor zou hebben betaald.

Als ik ooit een echte voor-en-na heb, zal ik eerst de methodologie publiceren en daarna het getal. Als ik het andersom publiceer, geloof me dan niet.

Richt het op de roadmap, en geef mensen dan de liniaal

Ik wil eindigen boven het product, omdat het product het minst interessante hier is.

De echte functie van het organigram was nooit autoriteit. Het was routering. Het droeg het antwoord op ‘wat is er dit kwartaal belangrijk’ naar buiten, van de mensen die het beslisten, en droeg het antwoord op ‘wie heeft wat gedaan’ naar binnen, en het deed beide slecht, langzaam, en met enorme vervorming bij elke hop. Alles wat je niet leuk vindt aan bedrijfspolitiek is een compressie-artefact van die routering. Managers waren niet de oorzaak ervan. Ze waren de enige beschikbare hardware.

Ze zijn niet langer de enige beschikbare hardware. Een model dat elke diff leest plus een tabel met multipliers doet de externe routering in één hop en de interne routering in een query. Wat overblijft voor de mensen is het deel dat altijd al de eigenlijke taak was en nooit tijd had: beslissen wat de multipliers moeten zijn, en samen zitten met de mensen van wie de scores door die beslissingen veranderden.

De politiek verdwijnt niet. Laat niemand je dat verkopen. Ze verplaatst zich. Ze verplaatst zich van ‘herinnert mijn manager zich mijn kwartaal’ naar ‘waarom wordt mijn component beoordeeld als 1.0x terwijl de roadmap zegt dat het kern is’, en dat tweede gevecht is een gevecht over de daadwerkelijke strategie van het bedrijf, gevoerd in het openbaar, in een tabel die iedereen kan lezen. Ik zou dat gevecht liever elke maand voeren dan het huidige, dat één keer per jaar wordt gevoerd, in privé, door iemand die elf maanden uit het geheugen reconstrueert.

Iemand gaat dit slecht uitvoeren. Iemand gaat een scorebord aan de muur hangen zonder uitleg over geschiktheid en zonder overschrijvingsspoor en ontslaat het onderste deciel, en het zal een ramp zijn, en het zal worden toegeschreven aan het model in plaats van aan de persoon die de multipliers koos. Dat is het deel waar voor wordt betaald, en het zal niet worden betaald door degene die het heeft opgezet.

Meet mij dus met hetzelfde instrument. Als je zoiets als dit runt, publiceer dan drie dingen naast het leaderboard: de multiplier-tabel, zodat mensen kunnen discussiëren over de strategie in plaats van de score. De uitsplitsing per pull request, zodat iedereen die nul scoorde kan zien welke poort voor hen sloot en ertegen in beroep kan gaan. En het overschrijvingslogboek, omdat het getal dat een mens heeft gewijzigd het enige getal is dat de moeite waard is om te auditen.

We publiceren momenteel de eerste. We doen de derde slecht: een overschrijving schrijft de reden op de evaluatierij, en het wissen van de overschrijving verwijdert de reden ermee, dus wat we hebben is een notitie die kan worden ingetrokken in plaats van een logboek. En we publiceren de tweede niet goed genoeg, wat ik pas ontdekte omdat een ontwikkelaar met 88% van een component als laatste eindigde op mijn eigen leaderboard en ik hem niet kon uitleggen waarom.

---

*GitRank staat op gitrank.dev en is gelicenseerd onder CC BY-NC 4.0. Scoren op het productiepad draait op Claude Haiku 4.5 met temperatuur 0.3. Alle bovenstaande cijfers komen uit onze eigen platformrepository tussen 6 juli en 3 augustus 2026, sample size van één bedrijf en zeven ontwikkelaars, wat een beschrijving van ons is en geen benchmark van wat dan ook.