När plattformsteamet blir den nya flaskhalsen
För ett år sedan hette flaskhalsen nätverksteamet. Nu heter den plattformsteamet. Samma mening, ny mottagare: ”vi väntar på plattformsteamet”. Ett team står med färdig kod och väntar på en publik route med TLS-cert för den nya endpointen. Ticketen ligger hos plattformsteamet, som har fullt upp.
Plattformen byggdes för att döda just den meningen. Meningen mår utmärkt.
Plattformen skulle ta bort kön, inte ärva den
Idén var rätt. Böckerna var lästa, plattformsteamet bemannat, löftet till produktteamen tydligt: sluta öppna tickets till sex olika team, gå till plattformen i stället. I början krävde bara det känsliga en granskning. Sedan blev allt känsligt. Ett halvår senare finns det bara en kö kvar. Allt går genom den.
Titta på vad en utvecklare faktiskt behöver för att få en funktion i mål. En databas till den nya tjänsten. En miljö att testa den i. En API-nyckel för att anropa ett annat system. Mer CPU och minne när tjänsten börjar skala i prod. Plattformen finns, men varje sådan sak börjar fortfarande med en ticket. Alla landar i samma backlog: plattformsteamets. Förr stod utvecklaren i kö hos nätverksteamet, DNS-teamet och IAM. Nu står hon i en enda kö. Kortare på papperet, likadan i praktiken.
Spärrvaktssyndromet
Det finns en enkel skillnad mellan en plattform och något som bara utger sig för att vara en. Jag kallar det spärrvaktssyndromet: en människa på andra sidan släpper igenom förfrågningarna en i taget, hur modernt gränssnittet framför än ser ut. På en riktig plattform passerar du själv, direkt, utan att någon behöver vinka dig förbi. Väldigt många så kallade plattformar är spärrar med finare typsnitt.
Ett self-service-formulär som ändå landar på en människas bord är inte self-service, det är en ticket i förklädnad. Lackmustestet är brutalt enkelt: kan teamet få det de behöver klockan två på natten, när hela plattformsteamet sover? Ja betyder plattform. Nej betyder spärr, hur modern stacken bakom än är: teamet väntar på att någon ska vakna.
Felet sitter i incitamenten
Det lätta är att skylla på plattformsteamet. De borde svara snabbare, prioritera bättre, säga ja oftare. Men problemet är sällan att plattformsteamet vill stå i vägen, det är att organisationen ställer dem där. De blir väckta när något de släppt igenom går sönder. Samtidigt mäts de på att plattformen är stabil och säker, inte på hur snabbt produktteamen levererar. Då är det rationellt att hålla en människa kvar i loopen. Varje ”vänta, vi tittar på den först” skyddar exakt det de hålls ansvariga för.
Kostnaden för försiktigheten betalas någon annanstans, i produktteamens lead time. Vem vaktar plattformen? Plattformsteamet. Vem bär väntan? Produktteamen. När kontrollen sitter hos ett team och kostnaden hos ett annat växer kön av sig själv. Antalet köer gick från många till en, men orsaken är densamma: en människa ligger i kritiska vägen för att ett annat team ska komma vidare.
Och du kan inte anställa dig ur det. Ett plattformsteam som är ett obligatoriskt mellansteg för allt teamen behöver är en flaskhals redan på ritningen. Så länge varje förändring måste passera samma grupp blir den förr eller senare organisationens kapacitetstak. Fler händer flyttar bara taket. De tar inte bort det. En spärr med fler vakter är fortfarande en spärr.
Bygg vägen, stå inte i den
Plattformsteamets jobb är inte att göra sakerna åt teamen. Det är att se till att teamen kan göra de vanliga sakerna själva, och sedan kliva ur vägen.
Ta databasen från listan ovan. Före: utvecklaren öppnar en ticket. Någon i plattformsteamet klickar ihop databasen i molnkonsolen, ren ClickOps, och sätter storlek, backup och access. Två dagar senare är den på plats. Efter: utvecklaren beskriver databasen i en fil och öppnar en PR. En kollega i teamet reviewar den. En automatisk kontroll ser till att ändringen håller sig innanför plattformens policy, och storlek, backup och access finns redan som vettiga defaults. Går kontrollen igenom skapas databasen vid merge, en kvart senare, utan att någon i plattformsteamet varit inblandad. Hur det sker under huven spelar mindre roll. Det som räknas är att det manuella steget hos ett annat team är borta. Plattformsteamets arbete gjordes en gång, i förväg, när reglerna och defaultsen byggdes in, inte per förfrågan.
Visst, allt kan inte gå helt utan kontroll. Förhöjd access till produktion, resurser i en region som inte är godkänd, en ändring som rör säkerheten: sånt kräver hårdare regler än en ny databas. Men hårdare regler är inte samma sak som en människa i vägen. Prod-access kan till exempel ges just-in-time mot en policy och dras in av sig själv efteråt, en känslig ändring kan kräva en extra granskare i det egna teamet i stället för en ticket till plattformsteamet. Undantagen ska styras av regler, inte av vem som råkar vara vaken. Om 90 procent av det teamen behöver kräver plattformsteamets händer har du byggt en spärr. Om 90 procent går av sig självt, och människorna bara behövs i de tunga fallen, har du byggt en plattform. Att sedan jaga de sista 10 procenten och automatisera bort även de tyngsta undantagen kommer sannolikt kosta mer än det smakar. Skillnaden är inte hur mycket plattformsteamet gör, utan hur ofta teamen tvingas fråga.
Mät därför plattformsteamet tvärtemot en service desk: inte hur många tickets det stänger, utan hur sällan någon behöver öppna en.
Målet är att göra sig onödig
Att göra sig onödig i vardagen är en obekväm ambition för ett team. Det låter som att rationalisera bort sig själv. Men det är inte plattformsteamet som ska bort, det är kön framför det. Det finns gott om arbete kvar: nästa self-service-flöde att bygga, tunga undantag att äga, guardrails att skärpa. Det som ska ta slut är att teamen köar för att få göra sitt jobb.
Så nästa gång du bygger en plattform, ställ den jobbiga frågan innan du firar: hur mycket av det teamen behöver passerar fortfarande plattformsteamet? Det talet, inte uptime, avgör om du byggt en plattform eller om den lider av spärrvaktssyndromet. Den bästa plattformen känns igen på tystnaden. Standupen där ingen längre säger ”vi väntar på plattformsteamet”.
Bygger ni en plattform som gör teamen autonoma, eller en spärr de får köa vid? Så jobbar jag.