Gul kod: När verksamheten inte är perfekt

Här och varannan gång får ingenjörsteam problem av olika anledningar. Ibland är det en explosiv tillväxt som överraskar teamet. Eller så har jouren gått överstyr, med varningar som utlöses var femte minut. Eller så har utvecklings- och driftsteamen helt enkelt slutat att se varandra i ögonen. Oavsett varför är teamet i en svår situation och något måste göras för att lösa det.

Om det är ett nytt problem kan lösningen vara enkel: Lägg till några fler servrar, gå tillbaka till en känd bra programversion eller samla alla över pizza och öl för att rensa luften. Ofta smyger sig dock problemet på dig med tiden och plötsligt är hålet så djupt att du inte kan hitta vägen ut. På LinkedIn förklarar ett team som har kommit till den här punkten ofta ett tillstånd som kallas ”Code Yellow”.

Yellow Alert

En del människor antar att namnet Code Yellow är baserat på trafikljus, men mer korrekt – och med en nördigare twist – är det faktiskt från din favoritserie ”Star Trek”. Närmare bestämt är det hur besättningen på rymdskeppet Enterprise anger sitt aktuella försvarstillstånd. Hur som helst är definitionen tydlig: Något är fel, och vi måste gå framåt med försiktighet. I enlighet med båda metaforerna har vi också en röd kod. Det är bättre beskrivet som en omedelbar kris, där alla arbetar 24 timmar om dygnet tills den är löst. Den gula koden är något mer avslappnad: Detta är allas huvudfokus, men endast under kontorstid. Code Yellows tenderar också att pågå i storleksordningen månader, medan en Code Red bör pågå i storleksordningen dagar.

Andra företag kan använda en annan term än Code Yellow, men effekten är densamma: Teamet kommunicerar till resten av företaget att de har identifierat ett allvarligt problem som är prioriterat att åtgärda för att säkerställa teamets och därmed företagets framgång. Förmågan att göra detta är en viktig aspekt av öppen och ärlig kommunikation, ett värde som är avgörande för en sund kultur och som ofta kan förbises. Att tala om våra problem är lika viktigt, om inte viktigare, än att fira våra framgångar. Grupper kan lära sig mer av att åtgärda ett problem än av en total framgång.

Det här är inte ett misslyckande

Det första steget i att starta en Code Yellow är att förstå att det här inte är ett misslyckande. Det finns ingen skam i att erkänna att teamet har ett problem som måste åtgärdas. Fel inträffar, trots att vi gör vårt bästa för att undvika dem. Det enda vi kan göra är att diagnostisera problemet och åtgärda det. Den enda gången vi misslyckas är när vi blundar för dessa problem. Detta gäller för hur våra ingenjörsteam interagerar med varandra lika mycket som för den programvara och de system vi producerar och driver.

Det är dock avgörande att rätt problem åtgärdas. Oftast har vi hamnat i den nuvarande situationen på grund av en långsam kokning – ökande teknisk skuld, många små problem eller sammanbrott i en process – som så småningom byggdes upp till en kris. Målet med Code Yellow måste vara att inte bara åtgärda de nuvarande problemen (en reaktiv komponent), utan också se till att de inte upprepas i framtiden (den proaktiva komponenten).

Planering för en lyckad Code Yellow

Det finns flera komponenter som krävs för en lyckad Code Yellow, liksom nödvändiga delar för att få ett godkännande från resten av organisationen:

• Problemformulering: Det måste finnas en tydlig och överenskommen redogörelse för de problem som teamet står inför och som föranledde den gula koden. Detta bör inte bara innefatta vilka de aktuella problemen är, utan också vad den aktuella förståelsen av deras grundorsak är.

• Avslutningskriterier: Därefter måste du ha specifika mål som teamet kommer att arbeta mot för att avsluta den gula koden. Dessa bör vara traditionella SMART-mål: specifika, mätbara, uppnåeliga, relevanta och tidsbundna. Det är dessa mål som gör det möjligt för teamet att överhuvudtaget gå in i en gul kod, eftersom de täcker en fast omfattning och inte är öppna.

• Kommunikation: All information om den gula koden, inklusive tillkännagivandet (som innehåller problemformulering och utgångskriterier), den framgångsrika avslutningen och periodiska statusuppdateringar bör skickas till den större organisationen. Detta kan vara din avdelning eller hela den tekniska organisationen. Det kan till och med vara hela företaget, beroende på problemens art.

• Projektledning: Som i alla stora projekt måste det finnas någon som ansvarar för att organisera arbetet och kommunicera information. Eftersom detta är ett scenario där alla händer är på däck för det berörda teamet är det vanligtvis bra att ha en särskild projektledare (PM) som hjälper till med detta. Detta är vanligtvis en projektledare som har kunskap om teamet och arbetet, men som inte är direkt involverad i genomförandet. Detta gör att cheferna och de enskilda medarbetarna kan fokusera på det aktuella arbetet.

När man har tänkt på var och en av dessa aspekter och fattat beslut om att gå in i Code Yellow, är teamets första åtgärd att omorganisera sina prioriteringar kring exitkriterierna. Detta innebär ofta att man lägger kvartalsmålen på hyllan. Det kan också vara nödvändigt att inrätta ett särskilt möte för att diskutera statusen för utträdeskriterierna.

Rymd att andas

Det är bra att ett team går in i gul kod och arbetar med ett enda fokus på de mål som har satts upp för att ställa saker och ting till rätta, men detta är inte tillräckligt för att teamet ska lyckas. För verklig framgång måste alla som omger laget förstå situationen och ge dem utrymme att göra sitt arbete. Det är här som en sund ingenjörskultur reser sig för att möta utmaningen.

• Räkna med förseningar: Det vanligaste sättet för ett tangentiellt team att påverkas är genom förseningar. De måste förvänta sig att alla förfrågningar som har gjorts till det påverkade teamet kan fördröjas om de inte ligger inom ramen för utträdeskriterierna. Den gula koden innebär i grund och botten att prioriteringarna omfördelas för att lösa det angivna problemet. Utomstående team måste ta hänsyn till detta och förstå att deras egna projekttidtabeller kan behöva justeras.

• Minimera nya förfrågningar: Andra team bör också avstå från att be det påverkade teamet om nya saker som ligger utanför de definierade utgångskriterierna. Genom att minimera dessa förfrågningar, förutom att acceptera förseningar av befintliga förfrågningar, kan det påverkade teamet använda sina begränsade ingenjörstimmar till att ta sig över till andra sidan av den gula koden.

• Förfrågningar om hjälp från andra team: Teamet i Code Yellow kan upptäcka att de behöver hjälp utifrån för att nå sina mål. Om det till exempel sker en plötslig, explosiv ökning av trafiken kan de behöva påskynda tillhandahållandet av ny hårdvara. Om du får en sådan begäran kan du behöva ändra dina egna prioriteringar. Kom alltid ihåg att teamet är en del av samma företag, och som sådant lyckas eller misslyckas alla tillsammans.

Ingenjörsteam står sällan ensamma, och det är viktigt att alla förstår värdet av att ha dessa team som fungerar bra, och som arbetar bra tillsammans. En liten tillfällig fördröjning av målen för att försäkra sig om att så är fallet är väl värt det.

Ljuset vid tunnelns slut

Code Yellow representerar en betydande mängd högprioriterat arbete och att arbeta igenom det kommer ofta att vara stressigt för teamet. Det är svårt att säga ”nej” till medarbetare som gör en rimlig begäran, och det arbete som ingår i omfattningen innebär sällan att man ägnar tid åt intressanta nya funktioner. Om de problem som ska lösas dessutom inbegriper kommunikationsproblem mellan grupper kommer det att bli några svåra samtal som måste föras. När teamet närmar sig slutet av arbetet kommer det dock att bli mycket lättare att se igenom vad som ligger på andra sidan exitkriterierna.

Det yttersta målet med Code Yellow är att få teamet ut ur ett reaktivt läge där de springer från kris till kris och in i ett proaktivt tillstånd där de kan arbeta med de rätta stora projekten. Att uppnå utgångskriterierna kommer att innebära att ingenjörerna är mer effektiva och kan arbeta proaktivt. Det här är ett starkare team – ingenjörerna är gladare eftersom de inte är under stor stress av operativt arbete, teamet fungerar bra eftersom de pratar effektivt med varandra, och kunderna är nöjda eftersom förfrågningar hanteras antingen genom automatisering eller inom rimlig tid.

Har ditt företag en intern process som liknar hur LinkedIn gör en Code Yellow?

– Todd Palino