IT-roller: Produktivitet och tillgänglighet

Som IT-chefer ställs vi inför behovet att hantera två mycket olika typer av tekniska yrkespersoner. Dessa två typer av yrkespersoner åtskiljs, inte av sina personlighetstyper eller arbetssätt, utan av själva naturen hos sina arbetsroller. Att förstå de unika behoven hos dessa två jobbtyper är avgörande för att effektivt kunna leda tekniska medarbetare, men få IT-avdelningar tar verkligen sig tid att förstå och uppskatta de nyanser som är inneboende i dessa två olika arbetsroller.

Den första typen, och den i särklass bäst förstådda, kommer jag att kalla ”ingenjören”. Denna ingenjörsroll omfattar ett enormt spann av jobbfunktioner som sträcker sig från mjukvaruutvecklare och designers, arkitekter, systemingenjörer, nätverksingenjörer eller vem som helst vars primära funktion är att kreativt designa eller implementera nya system av något slag. Termen ingenjör är en vid sådan men är relativt meningsfull.

Den andra typen av roll för teknikmedarbetare kan generiskt benämnas ”support”-rollen. Supportyrken kan innefatta helpdesk, systemadministration, skrivbordssupport, nätverksövervakning, kommandocentral och så vidare. Det som skiljer supportyrkespersoner från ingenjörsyrkespersoner är att de inte har till uppgift att utföra kreativa processer som involverar nya designer eller implementeringar, utan i stället arbetar med befintliga system och säkerställer att de fungerar korrekt och blir snabbt åtgärdade när något är fel.

Det säger sig självt att ingen verklig människa sannolikt någonsin helt kommer att tillhöra enbart den ena eller den andra kategorin, men nästan alla jobbfunktioner inom IT fokuserar mycket starkt på den ena eller den andra. Det är ganska säkert att anta att nästan varje roll kommer att vara exceptionellt tyngd åt den ena eller den andra rollen. Det är mycket sällsynt att en enskild tjänst delas jämnt mellan dessa roller.

Där denna identifiering av roller kommer in i bilden är i att veta hur man mäter och leder teknisk personal. Att mäta och leda ingenjörer är, på en mycket övergripande nivå, ganska väl förstått. Begreppet produktivitet är mycket enkelt och meningsfullt för ingenjörsroller. Målet med att leda en ingenjörsperson eller ett ingenjörsteam är att möjliggöra och uppmuntra att rollen producerar så mycket kreativ design eller implementering som möjligt. Begreppet kvalitet finns förstås också med, men vi kan ändå tänka generellt kring ingenjörsroller i relativt konkreta termer såsom antal skrivna funktioner, antal producerade driftsättningspaket, storleken på det nätverk som designats och så vidare. Mätvärden är en luddig sak, men vi har åtminstone en god uppfattning om vad effektivitet betyder för en ingenjör även om vi inte nödvändigtvis kan mäta det exakt.

Supportroller har inte detta samma begrepp. Visst skulle du kunna använda ett konstlat mätvärde såsom ”stängda ärenden” för att mäta produktivitet i en supportroll, men det skulle vara mycket vilseledande. Ett ärende kan vara trivialt och nästa en stor researchutmaning. I många fall kan det inte finnas några ärenden tillgängliga under lång tid och sedan anländer många på en gång som inte kan hanteras samtidigt. Produktiviteten kommer sannolikt att vara ryckig och ohållbar och, i slutändan, inte alls meningsfull att mäta.

Ingenjörstjänster förtjänar sitt uppehälle genom att producera resultat effektivt över en ganska lång tidsperiod, ofta till och med sträckande sig in i månader och år för stora projekt. Målet med ingenjörstjänster är därför att tillhandahålla en miljö som uppmuntrar hållbar produktivitet. Det är välkänt att ingenjörer ofta vinner produktivitet genom att arbeta förkortade eller alternativa arbetstider, ta regelbunden semester och så vidare. Detta ökar inte bara ofta produktiviteten utan ökar också ofta avsevärt kvaliteten på resultatet.

Supporttjänster förtjänar sitt levebröd genom att ”finnas där” när det behövs. Om en supportperson försöker arbeta med maximal effektivitet finns det en naturlig implikation att det råder en kontinuerlig eftersläpning av supportärenden som väntar på supportteamets uppmärksamhet och att det finns många människor som behöver support och som måste vänta på den för att bilda en kö. Att alltid ha en kö på plats innebär också att supportpersonalen kontinuerligt plockar arbete från högen i stället för att lösa pågående ärenden – antingen genom att ignorera högprioriterade ärenden eller genom att regelbundet bli avbruten – vilket orsakar kontinuerlig kontextväxling som avsevärt minskar förmågan att effektivt hantera kön – vars hela existensberättigande från första början var att skapa skenet av konstlad produktivitet.

Supportroller är ”händelsestyrda”. Jag gillar denna terminologi eftersom jag anser att den mest exakt beskriver det arbetssätt i vilket nästan alla supportyrkespersoner arbetar. Oavsett om en händelse genereras av ett telefonsamtal, ett snabbmeddelande, ett e-postmeddelande eller ett ärende är det en ”händelse” som sätter i gång supportpersonens övergång från overksam till handling eller, i vissa fall, från ett lågprioriterat ärende till ett högprioriterat ärende. På ett eller annat sätt representerar en händelse en ”kontextväxling” för supportyrkespersonen. Utan en händelse finns det inget för en supportyrkesperson att göra. Även om ”händelsen” representeras av en ärendekö eller en eftersläpning av e-post är det fortfarande en form av händelse.

Att ha en verkligt effektiv supportdesk kräver noggrann hantering av händelseprocessen. Att ha en aldrig sinande kö av supportärenden är utmattande för supportyrkespersonerna och det innebär också att ingen mängd personal någonsin befinner sig i ett ”overksamt” tillstånd i väntan på högprioriterade ärenden. På grund av detta blir högprioriterade ärenden antingen inte åtgärdade så snabbt som de borde eller så blir pågående ärenden försummade.

Att förstå supportpersonalens händelsestyrda natur är avgörande för att förstå hur man bör närma sig ledningen av dessa team. Det finns inga enkla svar, och mätvärden för supportpersonal är ofta ännu mer meningslösa än de för ingenjörspersonal – så använd dem med yttersta försiktighet, men genom att känna empati med supportrollen kan vi börja se var vår roll som supportchef spelar in i den större bilden av att stödja och främja supportteamets medlemmar.

Det viktigaste begreppet, utifrån mina erfarenheter, är att tillhandahålla ett bra flöde av de avbrott som går till supportteamet. Ofta hanterar supportteam ett antal olika kanaler för support, såsom e-post och telefon. Att begränsa och kanalisera händelser till lämpliga kanaler är avgörande.

Problemet med telefoner är att de är aggressiva och kräver en omedelbar kontextväxling oavsett om mottagaren är overksam eller om de för närvarande hanterar det mest kritiska produktionsavbrottet i företagets historia. Personen som ringer gissar att deras omedelbara behov väger tyngre än de aktuella behoven hos den som supportpersonen för närvarande hjälper. Telefoner orsakar detta problem överallt där de används.

Tänk på senaste gången du var på en pizzeria och beställde vid disken. Du väntade tålmodigt i kön medan varje person blev betjänad. Du gjorde rätt. Du kommer fram till början av kön. Du börjar lägga din beställning när telefonen ringer. Personen som tar emot din beställning sätter dig ”på vänt” trots att du står precis där, lyfter luren, tar emot beställningen, lägger på och återvänder till dig. Vad detta säger är att personen som ringer, det ”gnisslande hjulet”, är viktigare för restaurangen än vad de människor som faktiskt befinner sig i restaurangen är. Samma effekt uppstår vid många supportdiskar – pågående arbete avbryts av samtal som går till en grupplinje eller direkt till supportpersonen. Detta är i bästa fall ineffektivt och kan i värsta fall störa kritiska supportprocesser för ytterst kritiska ärenden.

Så när du funderar på hur du ska leda IT-yrkespersoner, tänk på syftet med deras roll. En ingenjörs mål är produktivitet. En supportyrkespersons mål är tillgänglighet.