How Do You Measure IT Admin Productivity?

A key part of my job is to carry out operational maturity assessments for different organizations. This helps me understand where a given IT admin team (usually DBAs, sys admins or app support teams) currently is (chaotic, reactive, proactive, etc.), where the business needs them to be, and how to bridge the gap in the shortest amount of time.

During the course of these assessments, I run into two kinds of IT administrators – the folks that view the extent of automation I (or their managers) advocate as a somewhat scary proposition and state that they wouldn’t want to jeopardize their environment by automating beyond a certain (rather basic) level. They claim to take complete personal responsibility for their environment and do what it takes to minimize risk in the day-to-day functioning of the company, by manually performing tasks that are considered critical to keeping the lights on. Let’s call this group the reluctant automators.

Then there are the folks that are eager to push the envelope to see how far and how fast their environments can embrace automation. Let’s refer to this group as the eager automators.

The latter group seems to view their jobs as something beyond keeping the lights on; they view their role as that of an enabler - wherein they allow business groups to focus on the organization’s core competency. Take for instance, a brokerage firm whose primary business function is to trade stocks profitably for their customers. This creates a primary layer of business users - the traders that trade the stock, and multiple peripheral teams that support the primary users and enable them to be successful. In most organizations where technology is not the core offering, IT admins tend to be a part of the peripheral layer.

Reluctant automators often fret about formal interactions with other groups and are usually disassociated from the primary business users. They view meetings as a time-sink; something that takes them away from their “real work” – i.e., doing things on their computers – things like moving data, keeping the configuration current, viewing log files, etc. – all relevant things, no doubt. They frequently view the keyboard activities as the “brainy stuff” and a meeting tends to be an activity where they can actually space out… (you know what I’m talking about, you have run into those folks with the vacant stares in meetings…)

The eager automators on the other hand, often state that repeatable things (the same ol’ stuff like moving data around, viewing log file output and updating configuration) leave them brain-dead and hence they can’t wait to automate them off their day-to-day workload (or at least semi-automate them such that they can be reliably offloaded to less senior people!) They manage the mundane by exceptions and use the freed up time to instead work on defining crisper user requirements and service levels, measuring deviations in performance and managing them. These kinds of activities require them to spend a lot of their time in meetings – with users, project teams and infrastructure peer groups. Even though some of these meetings are badly run (and are indeed boring), they have learnt to embrace these as opportunities to get better aligned with the business, understand growth trends , share insight and influence behavior.

So here’s the paradox that I (and I’m sure, countless IT managers) frequently run into. Given these two IT admin profiles, who is more productive? There is often a tendency in corporate America to mistake hard-work for higher productivity. But here, I don’t necessarily mean more hard-working in the sense of someone working 80 hours a week. Rather, who gets more stuff done? (Assuming there is a standard and reasonable expectation of “stuff” or job output/quality, in the first place.)

Both groups comprise ethical, hard-working people who usually put in way more than 40 hours per week to earn their salaries. However both camps are equally adamant that their outlook is the right one for the company.

I have my own thoughts on the matter (will post them in a future blog), but which school of thought do *you* subscribe to? And why is that appropriate? Unfortunately, there is no universally accepted HR manual that helps us decide whether one notion is better than the other.

And more pertinently, regardless of immanent viewpoints regarding individual employee performance, how can a manager quantitatively measure something as seemingly subjective as productivity? Good processes such as ITIL seem to help some by allowing work activities better documented by exposing # of service requests, # of incidents handled, etc. as well as time put in. However this information is often too uni-dimensional and does not share the complete story. For instance, it does not always take into account factors such as which incidents were truly avoidable and which service requests were redundant or occurred due to incomplete work done in the first place! And often, in many environments, IT admins get away with incomplete ticketing records. (So not all activities are logged into the ticketing system, and the information that gets logged is not always consistent or complete.)

Conventional IT management does not appear to provide an easy answer to these questions… how do you deal with it?