IT Roles: Productivity and Availability

As IT managers we face the need to deal with two very different types of technical professionals.  These two types of professionals are separated, not by their personality types or working styles, but by the very nature of their job roles.  Understanding the unique needs of these two job types is critical in effectively managing technical workers, but few IT departments truly take the time to understand and appreciate the nuances inherent to these two different job roles.

The first type, and by the far the best understood, I will call the “engineer.” This engineering role encompasses a massive array of job functions ranging from software developers and designers, architects, system engineers, network engineers or anyone whose primary function is to creatively design or implement new systems of any sort.  The term engineer is a loose one but is relatively meaningful.

The second type of technology worker role can be generically referred to as the “support” role.  Support professions might include helpdesk, systems administration, desktop support, network monitoring, command center, etc.  What separates support professionals from engineering professionals is that they are not tasked with creative processes involving new designs or implementations but instead work with existing systems ensuring that they run properly and get fixed quickly when something is wrong.

It goes without saying that no one real-world human is likely to ever be completely in only one category or the other, but almost all job functional in IT focus very heavily upon one or the other.  It is pretty safe to assume that almost any role will be exceptionally weighted to one role or the other.  It is very rare for a single position to be split evenly between these roles.

Where this identification of roles comes into play is in knowing how to measure and manage technical staff.  Measuring and managing engineers, from a very high level, is quite well understood.  The concept of productivity is very simple and meaningful for engineering roles.   The goal of managing an engineering person or team is to allow and encourage that role to output as much creative design or implementation as possible.  The concept of quality exists as well, of course, but we still can think generally about engineering roles in relatively concrete terms such as number of functions written, number of deployment packages produced, size of network designed, etc.  Metrics are a fuzzy thing, but we at least have a good idea of what efficiency means to an engineer even if we cannot necessarily measure it accurately.

Support roles do not have this same concept.  Sure you could use an artificial metric such as “tickets closed” to measure productivity in a support role, but that would be very misleading.  One ticket could be trivial and the next a large research challenge.  In many cases there may be no tickets available for a long time and then many arrive at once that cannot be serviced simultaneously.  Productivity is likely to be sporadic and non-sustainable and, ultimately, not at all meaningful to measure.

Engineering positions earn their keep by producing output effectively over a rather long period of time often even spanning into months and years for large projects.  The goal, therefore, with engineering positions is to provide an environment that encourages sustainable productivity.  It is well know that engineers will often gain productivity by working shortened or alternative hours, taking regular vacations, etc.  Not only does this often increase productivity but often greatly increases the quality of the output as well.

Support positions earn their bread and butter by “being there” when needed.  If a support person is attempting to work at maximum efficiency there is a natural implication that there is a continuous backlog of support issues awaiting the support team’s attention and that there are many people requiring support who have to wait for it in order to form a queue.  By having a queue always in place this also means that support personnel are continuously taking work off the stack instead of resolving live items – either ignoring high priority items or being regularly interrupted – causing continuous context switching which significantly reduces the ability to efficiently handle the queue – whose entire purpose for existing was to create the appearance of artificial productivity in the first place.

Support roles are “event driven.”  I like this terminology because I think it most accurately describes the mode in which nearly all support professionals work.  Whether an event is generated by a phone call, an instant message, an email or a ticket it is an “event” that kicks off the transition of the support person from idle to action or, in some cases, from a low priority item to a high priority item.  One way or another, an event represents a “context switch” for the support professional.  Without an event there is nothing for a support professional to do.  Even if the “event” is represented by a ticket queue or an email backlog it is still a form of event.

Having a truly efficient support desk requires careful management of the event process.  Having a never ending queue of support issues is exhausting for the support professionals and it also means that no amount of staff is ever in an “idle” state awaiting high priority items.  Because of this, high priority items are either not addressed as quickly as they should be or else in-process items are neglected.

Understanding the event driven nature of support staff is critical to understanding how to approach the management of these teams.  There are no simple answers, and metrics of support staff are often even more meaningless than those of engineering staff – so use with extreme caution, but by empathizing with the support role we can begin to see where our role as a support manager plays into the bigger picture of supporting and promoting the support team members.

The most important concept, from my experiences, is providing a good flow of the interrupts going to the support team.  Often support teams are handling a number of different avenues for support, such as email and telephone.  Restricting and funnels events to appropriate channels is critical.

The problem with telephones is that they are aggressive and demand an immediate context switch whether the recipient is idle or if they are currently supporting the most critical production outage in corporate history.  The person calling is guessing that their immediate need outweighs the current needs of whomever the support person is currently supporting.  Telephones cause this problem everywhere that they are used.

Think about the last time that you were at a pizza parlor placing your order at the counter.  You waited in line patiently as each person was served.  You did the right thing.  You arrive at the front of the queue.  You begin to place your order when, the phone rings.  The person taking your order puts you on “hold” even though you are standing right there, picks up the phone, takes the order, hangs up and returns to you.  What this says is that the person calling, being the “squeaky wheel”, is more important to the restaurant than are the people actually in the restaurant.  This same effect happens on many support desks – in process work is interrupted by calls going to a group line or directly to the support person.  This is, at best, inefficient and at worst may disrupt critical support processes for highly critical issues.

So when thinking about how to manage IT professionals, think about the purpose of their role.  The goal of an engineer is productivity.  The goal of a support professional is availability.

3 thoughts on “IT Roles: Productivity and Availability”

  1. what is your gripe here?

    if you have chosen IT services you need to be availalbe and reactive at all times and the pizza analogy is simply not suited for getting a fast efficient service

  2. I think that you’ve missed the entire point of the article. First, there is no gripe, the point is to educate people as to two different types of IT roles. One is about availability, the second is about productivity. Many IT jobs are not about being available or reactive, only support jobs, but there are many, many engineering style IT jobs (the bulk of development, platform engineering, architecture, design, etc.) where availability is not important but productivity is.

    The goal of this article is to help IT managers and business people understand the critical differences between these two types of workers and not mistake one for the other.

  3. This is an article I wish managers would read. It made me understand my job a little better. I’ve been suffering from an overload of uncompleted tickets with constant interruptions, issues with actually “finishing” completely a task before being rushed on to the next and following-up on tasks, especially if waiting for information from the requesting party. It’s SAP for them when they input the request but it takes forever to get additional information from them. This gets so bad that it could be months before an issue is resolved. Of course, it often happens that the SAP issue is no longer required and the user can’t remember why they requested it in the first place.

    My previous manager recently left and during the interim between when he left and the new one started I was able to reduce my ticket queue from 270 to 160 and now it’s down to 135 and that’s with working currently tickets at the same time.
    The ticket mix was a combination of research issues, projects and software help desk items.

    My previous manager thought it looked good to take tickets out of the unassigned queue and immediately assign them, even if this meant it could be a month before someone actually looked at it.

    I don’t think this was the best way to manage the work or the IT personnel.

    Combine this thread with the one titled “The less obvious IT acronym – ADD” that I read this morning and it really makes you think.

    We only get a few minutes, if that, to actually concentrate on 1 issue before being redirected to the next issue regardless of whether or not the first one has been resolved. I used to be very good at handling multiple items at the same time but it’s deteriorated over the years.

    I hate the IT Hunt line phone line since it always interrupts current concentration on an issue but then I don’t want users getting into the habit of calling me personally for everything little thing.

    The paragraph in this article about the efficient management of the help desk “Having a never ending queue of support issues is exhausting for the support professionals and it also means that no amount of staff is ever in an ??idle? state awaiting high priority items. Because of this, high priority items are either not addressed as quickly as they should be or else in-process items are neglected.” hits home big-time. The last sentence applies to me and I don’t like it one bit.

    Thanks for the post and I’m going to keep it to hand to my supervisor if/when the company starts getting on IT about the help desk issues.

Leave a Reply

Your email address will not be published. Required fields are marked *