Understanding the unique needs of these two job types is critical in effectively managing them -- but few IT departments truly take the time to understand and appreciate the nuances inherent between them.
The first type, and by the far the best understood, is the engineer. This engineering role encompasses a massive array of job functions ranging from software developers and designers, architects, system engineers, network engineers. It includes anyone whose primary function is to creatively design or implement new systems of any sort.
The second type of technology worker role can be generically referred to as the support role. Support professions includes 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. Instead they 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. Its pretty safe to assume that almost any role will be exceptionally weighted to one role or the other.
Managing Engineers vs. Managing Support 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 known 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 teams 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.
Event DrivenSupport 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.