IT-roller: Produktivitet og tilgængelighed

Som IT-ledere står vi over for behovet for at håndtere to meget forskellige typer tekniske professionelle. Disse to typer professionelle er adskilt, ikke af deres personlighedstyper eller arbejdsstile, men af selve karakteren af deres jobroller. At forstå de unikke behov ved disse to jobtyper er afgørende for effektiv ledelse af tekniske medarbejdere, men få IT-afdelinger tager sig virkelig tid til at forstå og sætte pris på de nuancer, der er iboende i disse to forskellige jobroller.

Den første type, og langt den bedst forståede, vil jeg kalde “ingeniøren.” Denne ingeniørrolle omfatter et enormt udvalg af jobfunktioner, der spænder fra softwareudviklere og -designere, arkitekter, systemingeniører, netværksingeniører eller enhver, hvis primære funktion er kreativt at designe eller implementere nye systemer af enhver art. Betegnelsen ingeniør er løs, men relativt meningsfuld.

Den anden type teknologisk medarbejderrolle kan generisk betegnes som “support”-rollen. Supportprofessioner kan inkludere helpdesk, systemadministration, desktopsupport, netværksovervågning, driftscenter osv. Det, der adskiller supportprofessionelle fra ingeniørprofessionelle, er, at de ikke er ansvarlige for kreative processer, der involverer nye designs eller implementeringer, men i stedet arbejder med eksisterende systemer og sikrer, at de kører korrekt og hurtigt bliver repareret, når noget er galt.

Det siger sig selv, at ingen reel menneskelig person sandsynligvis nogensinde vil være fuldstændigt i kun én kategori eller den anden, men næsten alle jobfunktioner i IT fokuserer meget kraftigt på den ene eller den anden. Det er ret sikkert at antage, at næsten enhver rolle vil være exceptionelt vægtet mod én rolle eller den anden. Det er meget sjældent, at en enkelt stilling er jævnt fordelt mellem disse roller.

Hvor denne identifikation af roller spiller ind, er i at vide, hvordan man måler og leder teknisk personale. Måling og ledelse af ingeniører er på et meget overordnet plan ganske velforstået. Konceptet om produktivitet er meget enkelt og meningsfuldt for ingeniørroller. Målet med at lede en ingeniørperson eller et team er at tillade og tilskynde den rolle til at producere så meget kreativt design eller implementering som muligt. Konceptet om kvalitet eksisterer selvfølgelig også, men vi kan stadig generelt tænke på ingeniørroller i relativt konkrete termer såsom antal skrevne funktioner, antal producerede deployment-pakker, størrelse af designet netværk osv. Målinger er en fuzzy ting, men vi har i det mindste en god idé om, hvad effektivitet betyder for en ingeniør, selv om vi ikke nødvendigvis kan måle det nøjagtigt.

Supportroller har ikke dette samme koncept. Selvfølgelig kunne man bruge en kunstig metrik såsom “lukkede tickets” til at måle produktivitet i en supportrolle, men det ville være meget vildledende. Én ticket kan være triviel og den næste en stor forskningsudfordring. I mange tilfælde er der måske ingen tickets tilgængelige i lang tid, og derefter ankommer mange på én gang, som ikke kan håndteres samtidigt. Produktivitet er sandsynligvis sporadisk og ikke-bæredygtig og i sidste ende slet ikke meningsfuld at måle.

Ingeniørstillinger tjener deres plads ved at producere output effektivt over en ret lang periode, der ofte strækker sig over måneder og år for store projekter. Målet med ingeniørstillinger er derfor at tilvejebringe et miljø, der tilskynder bæredygtig produktivitet. Det er velkendt, at ingeniører ofte vil øge produktiviteten ved at arbejde kortere eller alternative timer, tage regelmæssige ferier osv. Dette øger ikke kun ofte produktiviteten, men øger også ofte kvaliteten af outputtet markant.

Supportstillinger tjener deres brød og smør ved at “være der”, når det er nødvendigt. Hvis en supportperson forsøger at arbejde med maksimal effektivitet, er der en naturlig implikation om, at der er en kontinuerlig backlog af supportproblemer, der venter på supportteamets opmærksomhed, og at der er mange mennesker, der kræver support, som er nødt til at vente på den for at danne en kø. Ved altid at have en kø på plads betyder det også, at supportpersonale kontinuerligt tager arbejde fra stakken i stedet for at løse live-elementer – enten ignorerer højprioriterede emner eller bliver regelmæssigt afbrudt – hvilket forårsager kontinuerlig kontekstskift, som betydeligt reducerer evnen til at håndtere køen effektivt – hvis hele formål med at eksistere var at skabe udseendet af kunstig produktivitet i første omgang.

Supportroller er “hændelsesdrevne.” Jeg kan lide denne terminologi, fordi jeg tror, den mest præcist beskriver den tilstand, hvori næsten alle supportprofessionelle arbejder. Uanset om en hændelse genereres af et telefonopkald, en chat-besked, en e-mail eller en ticket, er det en “hændelse”, der kickstarter overgangen af supportpersonen fra inaktiv til handling eller i nogle tilfælde fra et lavprioriteret emne til et højprioriteret emne. På den ene eller den anden måde repræsenterer en hændelse et “kontekstskift” for supportprofessionellen. Uden en hændelse er der intet for en supportprofessionel at gøre. Selv om “hændelsen” er repræsenteret ved en ticketkø eller en e-mail-backlog, er det stadig en form for hændelse.

At have en virkelig effektiv supportdesk kræver omhyggelig styring af hændelsesprocessen. At have en aldrig sluttende kø af supportproblemer er udmattende for supportprofessionelle, og det betyder også, at ingen mængde personale nogensinde er i en “inaktiv” tilstand og venter på højprioriterede emner. På grund af dette adresseres højprioriterede emner enten ikke så hurtigt, som de burde, eller også forsømmes igangværende emner.

At forstå den hændelsesdrevne natur af supportpersonale er afgørende for at forstå, hvordan man griber ledelsen af disse teams an. Der er ingen simple svar, og målinger af supportpersonale er ofte endnu mere meningsløse end dem for ingeniørpersonale – brug dem derfor med ekstrem forsigtighed, men ved at sætte os i supportrollens sted kan vi begynde at se, hvor vores rolle som supportleder spiller ind i det større billede af at støtte og fremme supportteammedlemmerne.

Det vigtigste koncept, ud fra mine erfaringer, er at sikre en god strøm af afbrydelser til supportteamet. Supportteams håndterer ofte en række forskellige supportkanaler, såsom e-mail og telefon. At begrænse og kanalisere hændelser til passende kanaler er afgørende.

Problemet med telefoner er, at de er aggressive og kræver et øjeblikkeligt kontekstskift, uanset om modtageren er inaktiv eller i gang med at understøtte det mest kritiske produktionsnedbrud i virksomhedens historie. Den person, der ringer, gætter på, at deres øjeblikkelige behov overstiger de aktuelle behov hos den person, supportpersonen i øjeblikket hjælper. Telefoner forårsager dette problem overalt, hvor de bruges.

Tænk på sidst du var på et pizzarestaurant og bestilte ved disken. Du ventede tålmodigt i kø, mens hver person blev betjent. Du gjorde det rigtige. Du ankommer forrest i køen. Du begynder at afgive din bestilling, da telefonen ringer. Personen, der tager din bestilling, sætter dig “på hold”, selvom du står lige der, tager telefonen, tager bestillingen, lægger på og vender tilbage til dig. Det, der siges her, er, at den person, der ringer, den “pirende hjul”, er vigtigere for restauranten end de mennesker, der faktisk er i restauranten. Den samme effekt sker på mange supportdesks – igangværende arbejde afbrydes af opkald til en gruppelinje eller direkte til supportpersonen. Dette er i bedste fald ineffektivt og kan i værste fald forstyrre kritiske supportprocesser for meget kritiske problemer.

Så når man tænker på, hvordan man leder IT-professionelle, skal man tænke på formålet med deres rolle. Målet for en ingeniør er produktivitet. Målet for en supportprofessionel er tilgængelighed.