IT-rollen: productiviteit en beschikbaarheid

Als IT-managers staan we voor de noodzaak om met twee zeer verschillende soorten technische professionals om te gaan. Deze twee soorten professionals worden niet onderscheiden door hun persoonlijkheidstype of werkstijl, maar door de aard zelf van hun functierollen. Het begrijpen van de unieke behoeften van deze twee functietypen is cruciaal om technische werknemers effectief aan te sturen, maar weinig IT-afdelingen nemen werkelijk de tijd om de nuances die inherent zijn aan deze twee verschillende functierollen te begrijpen en te waarderen.

Het eerste type, en verreweg het best begrepen, zal ik de “engineer” noemen. Deze engineeringrol omvat een enorme reeks functies, variërend van softwareontwikkelaars en -ontwerpers, architecten, systeemengineers, netwerkengineers tot iedereen wiens primaire functie het is om op creatieve wijze nieuwe systemen van welke aard dan ook te ontwerpen of te implementeren. De term engineer is een ruime, maar relatief betekenisvolle.

Het tweede type rol van technologiewerker kan in algemene termen worden aangeduid als de “support”-rol. Supportberoepen kunnen onder meer helpdesk, systeembeheer, desktopondersteuning, netwerkbewaking, commandocentrum, enzovoort omvatten. Wat supportprofessionals onderscheidt van engineeringprofessionals is dat ze niet belast zijn met creatieve processen rond nieuwe ontwerpen of implementaties, maar in plaats daarvan werken met bestaande systemen om ervoor te zorgen dat deze naar behoren draaien en snel worden gerepareerd wanneer er iets mis is.

Het spreekt voor zich dat geen enkele mens in de echte wereld waarschijnlijk ooit volledig in slechts één categorie of de andere zal vallen, maar bijna alle functies in de IT leggen de nadruk zeer sterk op de een of de ander. Het is vrij veilig om aan te nemen dat vrijwel elke rol uitzonderlijk sterk naar de ene of de andere rol zal overhellen. Het is zeer zeldzaam dat een enkele functie gelijkmatig over deze rollen is verdeeld.

Waar deze identificatie van rollen een rol gaat spelen, is bij het weten hoe technisch personeel te meten en aan te sturen. Het meten en aansturen van engineers, op zeer hoog niveau, is vrij goed begrepen. Het concept van productiviteit is zeer eenvoudig en betekenisvol voor engineeringrollen. Het doel van het aansturen van een engineeringpersoon of -team is om die rol in staat te stellen en aan te moedigen zoveel mogelijk creatief ontwerp of implementatie te produceren. Het concept van kwaliteit bestaat uiteraard eveneens, maar we kunnen nog steeds in het algemeen over engineeringrollen denken in relatief concrete termen, zoals het aantal geschreven functies, het aantal geproduceerde deploymentpakketten, de omvang van het ontworpen netwerk, enzovoort. Metrieken zijn een vage aangelegenheid, maar we hebben ten minste een goed idee van wat efficiëntie voor een engineer betekent, ook al kunnen we het niet noodzakelijkerwijs nauwkeurig meten.

Supportrollen kennen dit zelfde concept niet. Natuurlijk zou u een kunstmatige metriek zoals “gesloten tickets” kunnen gebruiken om de productiviteit in een supportrol te meten, maar dat zou zeer misleidend zijn. Het ene ticket kan triviaal zijn en het volgende een grote onderzoeksuitdaging. In veel gevallen zijn er mogelijk gedurende lange tijd geen tickets beschikbaar en komen er dan ineens vele tegelijk aan die niet gelijktijdig kunnen worden afgehandeld. De productiviteit zal waarschijnlijk sporadisch en niet-duurzaam zijn en, uiteindelijk, helemaal niet betekenisvol om te meten.

Engineeringfuncties verdienen hun bestaansrecht door gedurende een vrij lange periode effectief output te produceren, vaak zelfs uitlopend in maanden en jaren voor grote projecten. Het doel met engineeringfuncties is daarom om een omgeving te bieden die duurzame productiviteit aanmoedigt. Het is welbekend dat engineers vaak productiviteit zullen winnen door verkorte of alternatieve uren te werken, regelmatig vakantie te nemen, enzovoort. Dit verhoogt niet alleen vaak de productiviteit, maar verhoogt vaak ook de kwaliteit van de output aanzienlijk.

Supportfuncties verdienen hun brood door “er te zijn” wanneer dat nodig is. Als een supportpersoon probeert op maximale efficiëntie te werken, is er een natuurlijke implicatie dat er een voortdurende achterstand aan supportkwesties is die op de aandacht van het supportteam wacht, en dat er veel mensen zijn die support nodig hebben en daarop moeten wachten, waardoor een wachtrij ontstaat. Door altijd een wachtrij paraat te hebben, betekent dit ook dat supportmedewerkers voortdurend werk van de stapel afnemen in plaats van actieve items op te lossen – ofwel items met hoge prioriteit negerend, ofwel regelmatig onderbroken wordend – wat voortdurend contextwisselen veroorzaakt, wat het vermogen om de wachtrij efficiënt af te handelen aanzienlijk vermindert – terwijl het hele doel van haar bestaan in de eerste plaats was om de schijn van kunstmatige productiviteit te wekken.

Supportrollen zijn “gebeurtenisgestuurd”. Ik houd van deze terminologie omdat ik denk dat zij het meest nauwkeurig de modus beschrijft waarin vrijwel alle supportprofessionals werken. Of een gebeurtenis nu wordt gegenereerd door een telefoontje, een instant message, een e-mail of een ticket, het is een “gebeurtenis” die de overgang van de supportpersoon van inactief naar actie inluidt of, in sommige gevallen, van een item met lage prioriteit naar een item met hoge prioriteit. Op de een of andere manier vertegenwoordigt een gebeurtenis een “contextwisseling” voor de supportprofessional. Zonder een gebeurtenis is er niets voor een supportprofessional om te doen. Zelfs als de “gebeurtenis” wordt vertegenwoordigd door een ticketwachtrij of een e-mailachterstand, is het nog steeds een vorm van gebeurtenis.

Het hebben van een werkelijk efficiënte supportbalie vereist zorgvuldig beheer van het gebeurtenisproces. Een nooit eindigende wachtrij aan supportkwesties is uitputtend voor de supportprofessionals en het betekent ook dat geen enkele hoeveelheid personeel zich ooit in een “inactieve” toestand bevindt die op items met hoge prioriteit wacht. Hierdoor worden items met hoge prioriteit ofwel niet zo snel afgehandeld als zou moeten, ofwel worden lopende items verwaarloosd.

Het begrijpen van de gebeurtenisgestuurde aard van supportpersoneel is cruciaal om te begrijpen hoe het beheer van deze teams te benaderen. Er zijn geen eenvoudige antwoorden, en metrieken van supportpersoneel zijn vaak nog betekenislozer dan die van engineeringpersoneel – gebruik ze dus met uiterste voorzichtigheid, maar door ons in te leven in de supportrol kunnen we beginnen te zien waar onze rol als supportmanager past in het grotere geheel van het ondersteunen en bevorderen van de leden van het supportteam.

Het belangrijkste concept is, vanuit mijn ervaringen, het bieden van een goede doorstroming van de onderbrekingen die naar het supportteam gaan. Vaak handelen supportteams een aantal verschillende kanalen voor support af, zoals e-mail en telefoon. Het beperken en in goede banen leiden van gebeurtenissen naar de juiste kanalen is cruciaal.

Het probleem met telefoons is dat ze agressief zijn en een onmiddellijke contextwisseling eisen, ongeacht of de ontvanger inactief is of dat hij op dat moment de meest kritieke productiestoring uit de bedrijfsgeschiedenis aan het afhandelen is. De beller gokt erop dat zijn onmiddellijke behoefte zwaarder weegt dan de huidige behoeften van wie de supportpersoon op dat moment ook aan het ondersteunen is. Telefoons veroorzaken dit probleem overal waar ze worden gebruikt.

Denk eens terug aan de laatste keer dat u in een pizzeria aan de toonbank uw bestelling plaatste. U wachtte geduldig in de rij terwijl ieder werd bediend. U deed het juiste. U komt vooraan in de rij aan. U begint uw bestelling te plaatsen wanneer de telefoon gaat. Degene die uw bestelling opneemt zet u “in de wacht” ook al staat u daar pal voor hem, neemt de telefoon op, neemt de bestelling op, hangt op en keert naar u terug. Wat dit zegt, is dat de persoon die belt, het “piepende wiel” zijnde, belangrijker is voor het restaurant dan de mensen die daadwerkelijk in het restaurant zijn. Ditzelfde effect doet zich voor bij veel supportbalies – lopend werk wordt onderbroken door oproepen die naar een groepslijn of rechtstreeks naar de supportpersoon gaan. Dit is op zijn best inefficiënt en kan op zijn slechtst kritieke supportprocessen voor uiterst kritieke kwesties verstoren.

Dus wanneer u nadenkt over hoe u IT-professionals aanstuurt, denk dan na over het doel van hun rol. Het doel van een engineer is productiviteit. Het doel van een supportprofessional is beschikbaarheid.