AI voor engineering managers: kom binnen met de oorzaak, niet met een excuus

Toegezegd versus opgeleverd ging weer de verkeerde kant op, en je weet ruwweg waarom: een afhankelijkheid bij een ander team, een specificatie die te laat kwam, twee mensen op storingsdienst. Het MT hoort zes redenen en boekt het weg als een tempoprobleem. Wat je nodig hebt is de dominante oorzaak met zijn werkelijke aandeel, en het spoor eronder (welke tickets, welke labels, welke sprints), want op het moment dat je een oorzaak noemt die bij een ander team ligt, wordt je gevraagd het aan te tonen. Kom je binnen met een verhaal en kun je geen filter laten zien, dan wordt een echt afhankelijkheidsprobleem genotuleerd als jouw team dat onderpresteert.

De cloudkosten kruipen omhoog, in de cijfers staat het onder techniek, en de vraag komt de week voor de budgetronde. Het eerlijke antwoord gaat meestal over iets ongetagds: een testomgeving zonder eigenaar, sinds een livegang blijven draaien, die volgende maand net zoveel kost. Het totaal vind je in een minuut in de console. Wat je een middag kost die je niet hebt, is de uitsplitsing per tag en omgeving: het bedrag in euro's, sinds wanneer hij draait en wie hem heeft aangezet. En dat is precies wat de CFO gaat vragen.

Gepland werk schoof op omdat incidenten de capaciteit opslokten, en iedere engineer in de kamer weet dat. In het MT leest het alsnog als een gemiste sprint. Om dat te veranderen heb je incidenturen als aandeel van je sprintcapaciteit nodig, plus een eerlijke uitsplitsing naar oorzaken, met de dominante bij naam en de rest zichtbaar in plaats van weggerond. Een te schoon antwoord ("het was allemaal één storing") verliest de kamer sneller dan helemaal geen antwoord, want iedereen die ooit storingsdienst heeft gedraaid weet dat echte incidentdata rommeliger is dan dat.

Vraag waarom de release uitliep en je krijgt toegezegd versus opgeleverd over de laatste sprints, de dominante oorzaak met het percentage van de uitgelopen scope dat daaronder valt, de rest van de verdeling in plaats van één nette schuldige, en de tickets en labels per bak zodat je ze vóór het overleg kunt openen. Daarna de consequentie vooruit: wat er met het volgende kwartaal gebeurt als die afhankelijkheid nu niet geëscaleerd wordt. Het oordeel over de oorzaak blijft van jou. Wat verandert is dat je het filter kunt laten zien zodra het MT terugduwt.

Richt het op de kostenexport per tag en omgeving en je krijgt de concentratie in plaats van het totaal: welke omgeving de stijging aanjaagt, hoeveel van de maand dat verklaart, het bedrag in euro's, sinds wanneer hij aanstaat en welke eigenaar of laatste committer eraan hangt. Dat is een actie met een deadline vóór de budgetronde, geen alarm. Is de tagging te dun om een deel van de uitgaven toe te wijzen, dan zegt het dat, met het ongetagde aandeel erbij, en dat is op zichzelf de bevinding die je meeneemt.

Vraag wat de storingsdienst de sprint heeft gekost en je krijgt incidenturen als aandeel van de capaciteit, uitgesplitst naar oorzaken met de dominante bij naam en zijn werkelijke percentage, het terugkerende label eronder, en de koppeling naar geleverde scope zodat het MT bedrijfsimpact hoort in plaats van een klacht uit de techniek. Het rapporteert de verdeling die de log werkelijk bevat. Waar de log incompleet is of tickets niet getrieerd zijn, wordt dat gemeld in plaats van gladgestreken, want een verdedigbare 60% is meer waard dan een ongeloofwaardige 100%.