IT-roller: Produktivitet og tilgjengelighet

Som IT-ledere møter vi behovet for å håndtere to svært ulike typer tekniske fagpersoner. Disse to typene fagpersoner er skilt, ikke av personlighetstyper eller arbeidsstiler, men av selve naturen til jobbrollene deres. Å forstå de unike behovene til disse to jobbtypene er avgjørende for å effektivt lede tekniske arbeidere, men få IT-avdelinger tar seg virkelig tid til å forstå og verdsette nyansene som er iboende i disse to ulike jobbrollene.

Den første typen, og langt den best forståtte, vil jeg kalle «ingeniøren». Denne ingeniørrollen omfatter et massivt spekter av jobbfunksjoner, alt fra programvareutviklere og designere, arkitekter, systemingeniører, nettverksingeniører eller hvem som helst hvis primære funksjon er å kreativt designe eller implementere nye systemer av noe slag. Begrepet ingeniør er løst, men relativt meningsfylt.

Den andre typen teknologiarbeiderrolle kan generisk omtales som «support»-rollen. Supportyrker kan inkludere helpdesk, systemadministrasjon, desktop-support, nettverksovervåkning, kommandosenter osv. Det som skiller supportfagpersoner fra ingeniørfagpersoner er at de ikke har til oppgave å utføre kreative prosesser som involverer nye design eller implementasjoner, men i stedet arbeider med eksisterende systemer og sikrer at de kjører ordentlig og blir fikset raskt når noe er galt.

Det sier seg selv at ingen ekte menneskelig person sannsynligvis noensinne vil være fullstendig i bare én kategori eller den andre, men nesten alle jobbfunksjoner i IT fokuserer svært sterkt på én eller den andre. Det er ganske trygt å anta at nesten enhver rolle vil være eksepsjonelt tyngdevektet mot én av rollene. Det er svært sjeldent at en enkelt stilling er delt jevnt mellom disse rollene.

Der denne identifiseringen av roller spiller inn er i å vite hvordan man måler og leder teknisk stab. Å måle og lede ingeniører, fra et overordnet nivå, er ganske godt forstått. Konseptet produktivitet er svært enkelt og meningsfylt for ingeniørroller. Målet med å lede en ingeniørperson eller et ingeniørteam er å la og oppmuntre den rollen til å produsere så mye kreativt design eller implementasjon som mulig. Konseptet kvalitet eksisterer selvfølgelig også, men vi kan fortsatt tenke generelt om ingeniørroller i relativt konkrete termer, som antall funksjoner skrevet, antall distribusjonspakker produsert, størrelse på nettverket designet, osv. Måleparametere er en uklar ting, men vi har i det minste en god idé om hva effektivitet betyr for en ingeniør, selv om vi ikke nødvendigvis kan måle det nøyaktig.

Supportroller har ikke det samme konseptet. Selvfølgelig kan du bruke en kunstig måleparameter som «lukkede saker» for å måle produktivitet i en supportrolle, men det ville være svært misvisende. En sak kan være triviell og den neste en stor forskningsutfordring. I mange tilfeller kan det hende det ikke er noen saker tilgjengelig på lenge, og deretter ankommer mange på én gang som ikke kan behandles samtidig. Produktiviteten er sannsynligvis sporadisk og ikke-bærekraftig og er til syvende og sist ikke i det hele tatt meningsfull å måle.

Ingeniørstillinger tjener sin plass ved å produsere resultater effektivt over en ganske lang tidsperiode, ofte til og med strekker seg inn i måneder og år for store prosjekter. Målet med ingeniørstillinger er derfor å tilby et miljø som oppmuntrer til bærekraftig produktivitet. Det er velkjent at ingeniører ofte vil øke produktiviteten ved å jobbe kortere eller alternative timer, ta regelmessige ferier osv. Ikke bare øker dette ofte produktiviteten, men forbedrer også ofte kvaliteten på resultatet betraktelig.

Supportstillinger tjener til livets opphold ved å «være der» når det trengs. Hvis en supportperson forsøker å jobbe med maksimal effektivitet, er det en naturlig antakelse om at det er en kontinuerlig kø av supportproblemer som venter på supportteamets oppmerksomhet, og at det er mange mennesker som trenger support som må vente på det for å danne en kø. Ved å alltid ha en kø på plass betyr dette også at supportpersonell kontinuerlig tar arbeid av bunken i stedet for å løse aktive elementer – enten ignorere høyprioriterte elementer eller bli regelmessig avbrutt – noe som forårsaker kontinuerlig kontekstbytte som betydelig reduserer evnen til å håndtere køen effektivt – hvis hele hensikt med å eksistere var å skape utseendet av kunstig produktivitet i utgangspunktet.

Supportroller er «hendelsesdrevne». Jeg liker denne terminologien fordi jeg synes den mest nøyaktig beskriver den modusen som nesten alle supportfagpersoner arbeider i. Enten en hendelse genereres av en telefonsamtale, en direktemelding, en e-post eller en sak, er det en «hendelse» som starter overgangen for supportpersonen fra inaktiv til handling eller, i noen tilfeller, fra et lavprioritetselement til et høyprioritert element. Uansett representerer en hendelse et «kontekstbytte» for supportfagpersonen. Uten en hendelse er det ingenting for en supportfagperson å gjøre. Selv om «hendelsen» er representert ved en sakskø eller en e-postbacklogg, er det fortsatt en form for hendelse.

Å ha en virkelig effektiv supportdesk krever nøye styring av hendelsesprosessen. Å ha en uendelig kø av supportproblemer er utmattende for supportfagpersonene, og det betyr også at ingen mengde stab noensinne er i en «inaktiv» tilstand som venter på høyprioriterte elementer. På grunn av dette adresseres enten ikke høyprioriterte elementer så raskt som de burde, eller så blir pågående elementer forsømt.

Å forstå den hendelsesdrevne naturen til supportstab er avgjørende for å forstå hvordan man skal nærme seg ledelsen av disse teamene. Det er ingen enkle svar, og måleparametere for supportstab er ofte enda mer meningsløse enn de for ingeniørstab – så bruk med ekstrem forsiktighet, men ved å sette oss inn i supportrollen kan vi begynne å se hvor vår rolle som supportleder spiller inn i det større bildet av å støtte og fremme supportteammedlemmene.

Det viktigste konseptet, ut fra mine erfaringer, er å sørge for en god flyt av avbruddene som går til supportteamet. Ofte håndterer supportteam en rekke ulike kanaler for support, som e-post og telefon. Å begrense og kanalisere hendelser til passende kanaler er avgjørende.

Problemet med telefoner er at de er aggressive og krever et umiddelbart kontekstbytte, enten mottakeren er inaktiv eller om de for øyeblikket støtter det mest kritiske produksjonsstoppet i bedriftshistorien. Personen som ringer, gjetter at hans umiddelbare behov oppveier de nåværende behovene til hvem enn supportpersonen for øyeblikket støtter. Telefoner skaper dette problemet overalt de brukes.

Tenk på sist gang du var på en pizzeria og la inn bestillingen ved kassen. Du ventet tålmodig i kø mens hver person ble betjent. Du gjorde det riktige. Du ankommer forsiden av køen. Du begynner å legge inn bestillingen din når telefonen ringer. Personen som tar bestillingen din setter deg på «vent» selv om du står rett der, tar telefonen, tar bestillingen, legger på og vender tilbake til deg. Det dette sier er at personen som ringer, som «det knirkende hjulet», er viktigere for restauranten enn de menneskene som faktisk er i restauranten. Den samme effekten skjer på mange supportdesker – pågående arbeid avbrytes av samtaler som går til en gruppetelefon eller direkte til supportpersonen. Dette er i beste fall ineffektivt, og i verste fall kan det forstyrre kritiske supportprosesser for svært kritiske problemer.

Så når du tenker på hvordan du skal lede IT-fagpersoner, tenk på formålet med deres rolle. Målet for en ingeniør er produktivitet. Målet for en supportfagperson er tilgjengelighet.