Den dyraste raden i din leverans är ”vi väntar på X-teamet”
Det är sprintdemo. En kollega delar skärm för att visa veckans funktion, men allt som kommer upp är ett timeout-fel. Koden är klar sedan i fredags. Den når bara inte databasen den behöver, eftersom en firewall-regel saknas. Ticketen ligger någonstans i nätverksteamets backlog. Ingen höjer på ögonbrynen, för alla har sagt exakt den meningen någon gång: ”vi väntar på X-teamet.”
Den meningen är den dyraste raden i din leverans. Den syns bara inte.
Väntan står inte i budgeten
När ett projekt drar över förväntar man sig en svår förklaring: en trasig integration, en underskattad komplexitet, en bugg som gömmer sig. Men oftast är svaret tråkigare än så, och de som väntar kan säga det direkt. De är klara, men kommer inte vidare för att ett annat team måste göra en liten sak först. En miljö ska sättas upp. En access ska godkännas. Ett cert ska utfärdas. Leveransen står stilla, inte för att något är svårt, utan för att arbetet ligger i någon annans kö.
Det här är den dyraste tiden i ett projekt. Ingen levererar, men alla betalar. Ändå dyker väntan aldrig upp som en rad i någon budget, så den får fortsätta.
Överlämningsskatten
Ta något så vardagligt som att rulla ut infrastruktur med Terraform. Innan pipelinen ens får köra terraform apply en enda gång ska sex team ha gjort sitt. Cloud-teamet skapar en subscription. Nätverksteamet reserverar ett nät i IPAM. DNS-teamet lägger upp records. Network security skapar firewall-reglerna. Infrateamet sätter upp lagringen för tfstate. IAM ordnar en service principal.
Själva arbetet tar kanske tjugo minuter per sak. Men var och en är en egen ticket i en egen kö, och kön mäts i dagar, inte minuter. Koden var klar i fredags. Teamet som skulle leverera lösningen fick vänta på sex andra teams kalendrar.
Jag kallar det överlämningsskatten: varje gång arbete byter team betalar du i ledtid, oavsett hur snabbt själva arbetet går. Du kan ha de skickligaste utvecklarna och den modernaste stacken. Det spelar ingen roll om varje förändring måste stå i sex köer på väg ut. Tempot bestäms inte av hur snabbt teamen kan arbeta, utan av hur länge de tvingas vänta på varandra.
Det är inte teamen, det är strukturen
Det lätta är att skylla på det långsamma teamet. Nätverksteamet borde prioritera bättre, driftteamet borde svara snabbare. Men nätverksteamet gör inget fel. De optimerar för sin egen kö, för det är den de mäts på. Att låta arbetet ligga kostar dem ingenting, eftersom fördröjningen drabbar ett annat team än det som orsakar den.
Ett tydligt exempel är change-processen. På en bank eller hos en myndighet får en ändring inte bara gå live, den ska bli en CHG, godkännas i ett CAB och vänta på nästa change-fönster. Och det är av goda skäl, revision, spårbarhet, risk. Men lägg märke till vem som bär vad. CAB:et äger godkännandet men inte ledtiden. Teamet som väntar äger ledtiden men inte godkännandet. Kontrollen och kostnaden sitter på olika ställen, och då växer kön.
Det är hela poängen, och den är obekväm: överlämningsskatten är osynlig för den som tar ut den. Teamet som låter en ticket ligga i tre dagar känner ingenting. Det är teamet i andra änden som blöder lead time. Så länge ingen äger helheten kommer varje team rationellt att optimera sin egen del, och summan blir en leverans som kryper fram.
Det enda som flyttar en ticket ur backlogen är en eskalering: pinga en chef, dra i rätt kontakter och höja prioriteten på just din ticket. Det funkar en gång. Men eskalering skalar inte. Den som skriker högst går först, och alla kan inte skrika högst.
En plattform tar bort överlämningen
Det är vad en intern plattform faktiskt är till för. Inte att lägga till ännu ett lager teknik, utan att ta bort steget där ett team måste vänta på ett annat. Nyckeln är att flytta förmågan att agera till teamet som bär ledtiden.
Det börjar med att teamet kan beställa det vanliga själva, direkt, i stället för att ställa sig i någon annans kö. Behöver de en testmiljö ska de inte skriva en ticket och vänta tre dagar, de ska kunna skapa den själva och ha den på tio minuter. Slutresultatet är detsamma, men väntan är borta.
Nästa steg är att bygga in expertisen i förväg. När nätverksteamets och säkerhetsteamets krav redan ligger som färdiga, säkra standardvägar behöver produktteamet varken uppfinna lösningen eller be om lov varje gång. Granskningen har skett en gång, när vägen byggdes, i stället för manuellt vid varje leverans. Och den säkra vägen är den med minst friktion, så folk följer den frivilligt, inte för att de tvingas.
Det här gäller även där kontrollen måste vara stenhård. I en reglerad miljö är change-processer och spårbarhet ett krav, och lösningen är inte att slänga dem. Den är att automatisera den säkra vägen: förgodkända standardändringar och spårbarhet som genereras som en biprodukt av flödet, i stället för att ligga som en kö framför det.
Lägg märke till vad allt det här har gemensamt. Ingenting handlar om att teamen ska springa fortare. Allt handlar om att de ska sluta vänta.
Tekniken är medlet, flödet är målet
Verktygen är inte poängen. Terraform, Kubernetes och GitOps är medel. Målet är ett snabbt, oavbrutet flöde där team får det de behöver utan att stå i kö hos någon annan.
Så nästa gång ett projekt halkar efter, leta inte först efter den svåra kodraden. Lyssna efter meningen ”vi väntar på X-teamet” och räkna hur ofta den sägs. Där, inte i koden, ligger oftast den dyraste tiden.
Bygger ni en plattform som ska göra teamen autonoma, eller sitter ni fast i väntan mellan team? Så jobbar jag.