Code Geel: When Operations Isn’t Perfect

Elke keer komen engineeringteams om verschillende redenen in de problemen. Soms wordt het team verrast door een explosieve groei. Of de aanwezigheidsdienst is uit de hand gelopen, met waarschuwingen die om de vijf minuten afgaan. Of ontwikkel- en operationele teams zijn het gewoon niet meer met elkaar eens. Wat de reden ook is, het team staat er slecht voor en er moet iets gebeuren om het op te lossen.

Als het een nieuw probleem is, is de oplossing misschien eenvoudig: voeg een paar extra servers toe, ga terug naar een bekende goede applicatieversie of roep iedereen bij elkaar voor een pizza en een biertje om de lucht te klaren. Vaak echter, besluipt het probleem je na verloop van tijd en is het gat plotseling zo diep dat je de weg naar buiten niet meer kunt vinden. Bij LinkedIn zal een team dat op dit punt gekomen is, vaak een toestand afkondigen die bekend staat als “Code Geel.”

Geel Alarm

Sommige mensen denken dat de naam Code Geel gebaseerd is op verkeerslichten, maar nauwkeuriger – en met een nerdachtigere twist – is dat het eigenlijk uit je favoriete “Star Trek” serie komt. Meer precies, het is hoe de bemanning van de Starship Enterprise hun huidige defensieve toestand aangeeft. Hoe dan ook, de definitie is duidelijk: er is iets mis, en we moeten voorzichtig verder gaan. Trouw aan beide metaforen, hebben we ook een Code Rood. Dat is beter te omschrijven als een onmiddellijke crisis, waarbij iedereen 24 uur per dag aan het werk is tot het is opgelost. De Code Geel is iets rustiger: Dit is ieders primaire focus, maar alleen tijdens kantooruren. Een Code Geel heeft ook de neiging om maanden te duren, terwijl een Code Rood in de orde van dagen zou moeten duren.

Andere bedrijven gebruiken misschien een andere term dan Code Geel, maar het effect is hetzelfde: het team communiceert aan de rest van het bedrijf dat ze een serieus probleem hebben geïdentificeerd dat met voorrang moet worden opgelost om het succes van het team en, daarom, het bedrijf te garanderen. De mogelijkheid om dit te doen is een belangrijk aspect van open en eerlijke communicatie, een waarde die cruciaal is voor een gezonde cultuur en die vaak over het hoofd wordt gezien. Praten over onze problemen is net zo belangrijk, zo niet belangrijker, dan het vieren van onze successen. Teams kunnen meer leren van het oplossen van een probleem dan van een totaal succes.

Dit is geen mislukking

De eerste stap bij het starten van een Code Geel is te begrijpen dat dit geen mislukking is. Het is geen schande om toe te geven dat het team een probleem heeft dat opgelost moet worden. Bugs gebeuren, ondanks onze inspanningen om ze te vermijden. Het enige wat we kunnen doen is een diagnose stellen en het probleem verhelpen. De enige keer dat we falen is wanneer we onze ogen sluiten voor deze problemen. Dit geldt voor de manier waarop onze engineeringteams met elkaar omgaan, net zo goed als voor de software en systemen die we produceren en draaien.

Het is echter van cruciaal belang dat de juiste problemen worden aangepakt. Meestal zijn we in de huidige situatie terechtgekomen door een langzame ophoping van technische schuld, veel kleine problemen of storingen in een proces, die uiteindelijk uitgroeiden tot een crisis. Het doel van de Code Yellow moet niet alleen zijn om de huidige problemen te verhelpen (een reactieve component), maar ook om ervoor te zorgen dat ze in de toekomst niet worden herhaald (de proactieve component).

Planning voor een succesvolle Code Yellow

Er zijn verschillende componenten nodig voor een succesvolle Code Yellow, evenals noodzakelijke stukken om buy-in te krijgen van de rest van de organisatie:

  • Probleemstelling: Er moet een duidelijke en overeengekomen verklaring zijn van de problemen waarmee het team wordt geconfronteerd en die de aanleiding voor de Code Geel vormden. Dit zou niet alleen moeten inhouden wat de huidige problemen zijn, maar ook wat het huidige begrip van hun grondoorzaak is.
  • Exit Criteria: Vervolgens moet u specifieke doelstellingen hebben waar het team naar toe zal werken om de Code Geel te verlaten. Dit moeten traditionele SMART-doelen zijn: specifiek, meetbaar, haalbaar, relevant en tijdgebonden. Deze doelen maken het voor het team überhaupt mogelijk om een Code Geel in te gaan, omdat het een vast toepassingsgebied bestrijkt en geen open einde heeft.
  • Communicatie: Alle informatie over de Code Geel, met inbegrip van de aankondiging (die de probleemstelling en exit criteria bevat), de succesvolle afronding en periodieke status updates moeten worden verzonden naar de grotere organisatie. Dit kan uw afdeling zijn, of het kan de hele engineering organisatie zijn. Het kan zelfs het hele bedrijf zijn, afhankelijk van de aard van de problemen.
  • Project Management: Zoals bij alle grote projecten, moet er iemand verantwoordelijk zijn voor het organiseren van het werk en het communiceren van informatie. Aangezien dit een “alle hens aan dek” scenario is voor het getroffen team, is het meestal nuttig om een speciale projectmanager (PM) te hebben om hierbij te helpen. Dit is typisch een PM die kennis heeft van het team en het werk, maar niet direct betrokken is bij de uitvoering. Dit maakt de managers en de individuele medewerkers vrij om zich te concentreren op het werk bij de hand.

Als over elk van deze aspecten is nagedacht, en de beslissing is genomen om Code Geel in te gaan, is de eerste daad van het team om hun prioriteiten te reorganiseren rond de exit-criteria. Dit betekent vaak dat de kwartaaldoelstellingen op de plank moeten worden gelegd. Het kan ook nodig zijn om een speciale vergadering in te stellen om de status van de exit-criteria te bespreken.

Ruimte om te ademen

Het is allemaal goed en wel voor een team om Code Geel in te gaan en te werken met een enkele focus op de doelen die zijn gesteld om dingen recht te zetten, maar dit is niet genoeg voor het team om te slagen. Voor echt succes moet iedereen rondom het team de situatie begrijpen en hen de ruimte geven om hun werk te doen. Dit is de plaats waar een gezonde engineering cultuur opstaat om de uitdaging aan te gaan.

  • Verwacht vertragingen: De meest voorkomende manier waarop een tangentieel team zal worden beïnvloed is door vertragingen. Zij moeten verwachten dat alle verzoeken die aan het getroffen team zijn gedaan, vertraging kunnen oplopen als deze niet binnen het toepassingsgebied van de exit-criteria vallen. De code geel houdt in de kern in dat de prioriteiten worden herschikt om het genoemde probleem aan te pakken. Externe teams moeten hiermee rekening houden en begrijpen dat hun eigen projecttijdlijnen mogelijk moeten worden aangepast.
  • Minimaliseer Nieuwe Verzoeken: Andere teams moeten ook afzien van het vragen aan het getroffen team om nieuwe dingen die buiten het toepassingsgebied van de gedefinieerde exit-criteria vallen. Het minimaliseren van deze verzoeken, in aanvulling op het accepteren van vertragingen op bestaande verzoeken, stelt het getroffen team in staat om hun beperkte engineering-uren te besteden aan het bereiken van de andere kant van de Code Geel.
  • Verzoeken om assistentie van andere teams: Het team in Code Geel kan merken dat ze hulp van buitenaf nodig hebben om hun doelen te bereiken. Bijvoorbeeld, als er een plotselinge, explosieve groei in het verkeer is, kan het nodig zijn om de levering van nieuwe hardware te versnellen. Als je aan de ontvangende kant van zo’n verzoek komt te staan, moet je misschien je eigen prioriteiten bijstellen. Onthoud altijd dat het team allemaal deel uitmaakt van hetzelfde bedrijf, en als zodanig slaagt of faalt iedereen samen.

Engineering teams staan zelden op zichzelf, en het is belangrijk dat iedereen begrijpt hoe waardevol het is om die teams goed te laten werken, en goed samen te laten werken. Een kleine tijdelijke vertraging in doelstellingen om ervoor te zorgen dat dit het geval is, is de moeite waard.

Light at the End of the Tunnel

Code Yellow vertegenwoordigt een aanzienlijke hoeveelheid werk met een hoge prioriteit en het doorwerken ervan zal vaak stressvol zijn voor het team. Het is moeilijk om “nee” te zeggen tegen collega’s die een redelijk verzoek doen, en het werk dat binnen de scope valt gaat zelden over het besteden van tijd aan interessante nieuwe functies. Bovendien, als de problemen die worden aangepakt communicatieproblemen tussen groepen bevatten, zullen er enkele moeilijke gesprekken moeten plaatsvinden. Naarmate het team echter het einde van het werk nadert, zal het veel gemakkelijker zijn om door te zien wat er aan de andere kant van de exit-criteria ligt.

Het uiteindelijke doel van de Code Geel is om het team uit een reactieve modus te halen waarin ze van crisis naar crisis rennen, en in een proactieve staat te brengen waarin ze in staat zijn om aan de juiste grote projecten te werken. Het bereiken van de exit criteria zal betekenen dat de ingenieurs effectiever zijn en in staat om pro-actief te werken. Dit is een sterker team-engineers zijn gelukkiger omdat ze niet onder een zware stress van operationeel werk staan, het team werkt goed omdat ze effectief met elkaar praten, en klanten zijn tevreden omdat verzoeken worden afgehandeld door middel van automatisering of in een redelijke hoeveelheid tijd.

Heeft uw bedrijf een intern proces dat vergelijkbaar is met hoe LinkedIn een Code Geel doet?

– Todd Palino

Plaats een reactie