As IT managers we face the need to deal with two very different types of technical professionals.\u00a0 These two types of professionals are separated, not by their personality types or working styles, but by the very nature of their job roles.\u00a0 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.<\/p>\n
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.\u00a0 The term engineer is a loose one but is relatively meaningful.<\/p>\n
The second type of technology worker role can be generically referred to as the “support” role.\u00a0 Support professions might include helpdesk, systems administration, desktop support, network monitoring, command center, etc.\u00a0 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.<\/p>\n
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.\u00a0 It is pretty safe to assume that almost any role will be exceptionally weighted to one role or the other.\u00a0 It is very rare for a single position to be split evenly between these roles.<\/p>\n
Where this identification of roles comes into play is in knowing how to measure and manage technical staff.\u00a0 Measuring and managing engineers, from a very high level, is quite well understood.\u00a0 The concept of productivity is very simple and meaningful for engineering roles.\u00a0\u00a0 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.\u00a0 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.\u00a0 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.<\/p>\n
Support roles do not have this same concept.\u00a0 Sure you could use an artificial metric such as “tickets closed” to measure productivity in a support role, but that would be very misleading.\u00a0 One ticket could be trivial and the next a large research challenge.\u00a0 In many cases there may be no tickets available for a long time and then many arrive at once that cannot be serviced simultaneously.\u00a0 Productivity is likely to be sporadic and non-sustainable and, ultimately, not at all meaningful to measure.<\/p>\n
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.\u00a0 The goal, therefore, with engineering positions is to provide an environment that encourages sustainable productivity.\u00a0 It is well know that engineers will often gain productivity by working shortened or alternative hours, taking regular vacations, etc.\u00a0 Not only does this often increase productivity but often greatly increases the quality of the output as well.<\/p>\n
Support positions earn their bread and butter by “being there” when needed.\u00a0 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.\u00a0 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 \u2013 either ignoring high priority items or being regularly interrupted \u2013 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.<\/p>\n
Support roles are “event driven.”\u00a0 I like this terminology because I think it most accurately describes the mode in which nearly all support professionals work.\u00a0 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.\u00a0 One way or another, an event represents a \u201ccontext switch\u201d for the support professional.\u00a0 Without an event there is nothing for a support professional to do.\u00a0 Even if the “event” is represented by a ticket queue or an email backlog it is still a form of event.<\/p>\n
Having a truly efficient support desk requires careful management of the event process.\u00a0 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.\u00a0 Because of this, high priority items are either not addressed as quickly as they should be or else in-process items are neglected.<\/p>\n
Understanding the event driven nature of support staff is critical to understanding how to approach the management of these teams.\u00a0 There are no simple answers, and metrics of support staff are often even more meaningless than those of engineering staff \u2013 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.<\/p>\n
The most important concept, from my experiences, is providing a good flow of the interrupts going to the support team.\u00a0 Often support teams are handling a number of different avenues for support, such as email and telephone.\u00a0 Restricting and funnels events to appropriate channels is critical.<\/p>\n
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.\u00a0 The person calling is guessing that their immediate need outweighs the current needs of whomever the support person is currently supporting.\u00a0 Telephones cause this problem everywhere that they are used.<\/p>\n
Think about the last time that you were at a pizza parlor placing your order at the counter.\u00a0 You waited in line patiently as each person was served.\u00a0 You did the right thing.\u00a0 You arrive at the front of the queue.\u00a0 You begin to place your order when, the phone rings.\u00a0 The person taking your order puts you on \u201chold\u201d even though you are standing right there, picks up the phone, takes the order, hangs up and returns to you.\u00a0 What this says is that the person calling, being the \u201csqueaky wheel\u201d, is more important to the restaurant than are the people actually in the restaurant.\u00a0 This same effect happens on many support desks \u2013 in process work is interrupted by calls going to a group line or directly to the support person.\u00a0 This is, at best, inefficient and at worst may disrupt critical support processes for highly critical issues.<\/p>\n
So when thinking about how to manage IT professionals, think about the purpose of their role.\u00a0 The goal of an engineer is productivity.\u00a0 The goal of a support professional is availability.<\/p>\n","protected":false},"excerpt":{"rendered":"
As IT managers we face the need to deal with two very different types of technical professionals.\u00a0 These two types of professionals are separated, not by their personality types or working styles, but by the very nature of their job roles.\u00a0 Understanding the unique needs of these two job types is critical in effectively managing … Continue reading IT Roles: Productivity and Availability<\/span>