Lokal helt redder dagen – men hvad med i morgen?
Klokken er 22.20. Peter sidder yderst på stolen, mens han hektisk forsøger at rulle dagens fejlede release tilbage. Det er time 8 i en neglebidende, feberagtig – og for firmaet meget kostbar – nedeperiode for produktionsmiljøet. Peter er alene på kontoret – Peters team tog hjem for længe siden. De har ikke adgang til produktionssystemerne, og Peter vil også helst selv tackle udfordringen. Det er nemmere. Hvis teamet var her, ville han konstant skulle overvåge, at de ikke gjorde problemet værre – de kender ikke systemet som han gør.
Dette er timen, hvor Peter sejrer. Releasen er rullet tilbage, og produktionssystemet er på vej tilbage til normalen. Prisen har været høj, men Peter kan sætte sig tilfreds, lettet og træt tilbage i stolen. Han ved at chefen sætter pris på feberredningen – mange tidligere bonusser var netop begrundet i Peters evne til at springe til i svære tider.
I sejrens stund ærgrer Peter sig dog lidt over at han ikke dobbelt-tjekkede teamets arbejde, men i travlheden kun lavede et overfladisk review. Han plejer altid at kontrollere alle andres bidrag, men denne uge har været særligt travl med mange sene arbejdsdage. Der har været lidt for mange travle uger i den seneste tid.
Hvor mange af jer kan genkende jer selv i den historie? Hvor mange er Peter i historien, og hvor mange arbejder sammen med en Peter?
Peter er en helt. Mange virksomheder har en Peter, som er den, man går til i svære situationer. Peter ofrer sig og træder altid til. Han bør hyldes og belønnes… eller bør han?
Heltedyrkelse er meget udbredt i it-branchen, men der er flere markante ulemper ved dette, som vi ikke ofte snakker om – for hvem kritiserer heltemodig opførsel?
Uhensigtsmæssige konsekvenser
En af de oversete dynamikker omkring helte er deres effekt på deres team. De fleste af os arbejder i teams, og hvis man arbejder sammen med en Peter, kan det have en uhensigtsmæssig konsekvens: manglende faglig udvikling og teamfølelse.
Som den, der har bedst styr på systemet, bliver opgaver løst hurtigst og bedst, hvis det er Peter, der tager dem. Folk fra andre afdelinger kender måske endda Peter og efterspørger ham til de opgaver, de skal have løst. Peter kan selvfølgelig ikke påtage sig alle opgaver, så enten påtager han sig kun dem, han har mest lyst til at løse, eller kun dem, som har ledelsens/Product Owners/teamets fokus.
Hvis man er på Peters team, men ikke er Peter, får man kun lov til at løse mindre interessante/mere rutineprægede opgaver. Det er både mindre sjovt og ikke fordrende for team-ånden, og samtidig er det spild af potentielt talent, som ikke får lov til at udvikle sig. Udfordrer man som team-medlem Peter, når der skal udveksles ideer/estimeres/testes, eller læner man sig tilbage og accepterer Peters autoritet som 'den erfarne'? Bliver man hørt, når man bidrager?
Nogle Peter'e insisterer desuden på at være 'kvalitetstjekker' for hele teamet, men hvem siger, at Peter er ekspert i alt og har ret i alt? Uanset hvor erfaren og dygtig Peter er, er det usandsynligt, at han har svaret på alt. Et mønster som ofte kan observeres er, at allround-eksperter bliver mere konservative i udkanten af deres eget ekspertise-felt, hvilket kan holde teamet fra at adoptere nye brugbare metoder og teknologier.
Stress-risiko
Peters enegang i udsatte situationer siger en del. Det fortæller at han ikke har nogen han sparrer med og ikke nogen at læne sig op af. Uanset om det er, fordi Peter ikke vil modtage hjælp, eller om det er, fordi teamet ikke tilbyder hjælp er det værd at stille spørgsmål ved. Hvis det er Peters preference at køre alene, så fratager han potentielt teamet mulighed for at lære at håndtere situationen. Hvis ikke teamet kan håndtere problemet uden Peter, har organisationen et større problem – en truckfaktor på 1.
Jobsikkerhed for Peter og en organisation i knibe – Peter kan nu opføre sig uhensigtsmæssigt eller kræve en urimelig høj løn, og organisationen vil have svært ved at sige fra. Endnu mere sandsynligt er det, at Peter kan gå ned med stress eller rent faktisk blive kørt over efterladende et team i problemer. Hvis det derimod er teamet, der lader Peter stå alene med det hele, fortæller det en historie om et usolidarisk team, som ikke vil løfte sin del af arbejdet, og så er der ikke meget 'team' over det.
At stå alene med de store problemer er helt åbenlyst problematisk. Det kan være sjovt at være helten indtil det ikke er. Stress og udbrændthed er ikke så sjældne fænomener som de burde være – og at acceptere et arbejdsmiljø, hvor de forekommer er helt utilgiveligt. Der findes meget få job, som er ens helbred værd, og afhængighed af helte-indsats er ikke holdbart i længden. Dertil kommer, at ingen er tilstrækkelige til at være alt for alle. Individet kommer til kort. Så bliver man i stedet en flaskehals, som forhindrer skalering, og ens blinde vinkler bliver tydelige, da der ikke er andre til at kompensere for dem.
Andre ser flaskehalsen og begynder at arbejde udenom. Løsninger som åbenlyst hører til i et bestemt system, bliver nu i stedet udviklet i et andet (løst relateret) system for så kan opgaven varetages af et andet team. Indviklet arkitektur, unødvendige systemafhængigheder, svær vedligehold og andre domino-effekter følger.
Hvad er løsningen?
Så hvad gør vi, hvis vi har et problem med en lokal helt?
Hvis man har en mentor-rolle over for helten, kan man forsøge at få helten til at indse problemet. Det er ikke et problem i sig selv at være dygtigere og mere erfaren end resten af sit team, hvis man er villig til at lære fra sig og dele kongedømmet med andre. Som helt har man mulighed for at stille krav til sin organisation, og et af disse krav kunne være, at man altid skal have nogen at sparre med. Tid til overlevering af viden kan være et ufravigeligt krav. Hvis ikke der bliver lyttet, kan det bedste være at finde nye græsgange – det er ikke lige så virksomt at stille krav, hvis man ikke er villig til at gennemføre konsekvenser, når kravene bliver ignoreret.
Hvis man er team-medlem på et team med en helt, men ikke selv er helten, kan man i stedet se, om man kan overbevise helten om, at det er bedst at dele ud af viden. Efter en situation hvor helten har ofret sig, kan man studere, hvad der egentlig skete, så man kan træde til en anden gang eller om muligt helt undgå en gentagelse. Det er sjældent, man finder en helt, som ikke gerne fortæller om heltegerningen. Det kan være svært at få lov til at blive inkluderet i de svære situationer, hvis man kan være 'i vejen' – men man kan forsøge. Man kan f.eks. love at være en flue på væggen og ikke forstyrre.
Som chef for en helt kan det være fristende at underlægge sig heltens ønsker til arbejdsmiljøet og belønne helte-opførsel. I stedet bør man overveje, om det er nu, man skal lægge sig i selen og bruge tiden på at få videndeling øverst på prioriteterne … og hvis ikke det virker, så kan det være, at man skal rive plasteret af og tage helten af teamet og se, om resten af teamet vokser med opgaven. Opgaven med at forøge truck-faktoren skal tages seriøst, og det er trods alt bedre at sætte teamet i gang under kontrollerede forhold frem for at vente, til der ikke er andre muligheder.
Har I helte i jeres organisation? Er det dig?
