Slashdot Mirror
System Admin's Unit of Production?
RailGunSally writes "I am a (strictly technical) member of a large *nix systems admin team at a Fortune 150. Our new IT Management Overlord is a hardcore bean-counter from hell. We in the trenches have been tasked with providing 'metrics' on absolutely everything from system utilization to paper clip recycling. Of course, measuring productivity is right up there at the top of the list. We're stumped as to a definition of the basic unit of productivity for a *nix admin. There is a school of thought in our group that holds that if the PHBs are simple enough to want to operate purely from pie charts and spreadsheets, then we should just graph some output from /dev/random and have done with it. I personally love the idea, but I feel the need for due diligence, so I put the question to the Slashdot community: How does one reasonably quantify admin productivity?"
of Jolt Cola consumed.
They say the first thing to go is your penis. Well, it's either that or your brain. I forget which...
Unit of Productivity = 1 / (hours of down time)
They are paying you to keep bad things from happening.
You aren't building automobiles or painting teapots. You are a support function and not a line function.
You should have business plan objectives. These things are usually annual; there can be longer strategic objectives. If the person who set these things did it right, they should be measurable.
What I'm trying to say is, if you're banging your head against the wall trying to figure out how your performance should be measured, your higher up didn't set your objectives correctly.
This doesn't apply anywhere and everywhere. When the organization is in the business of IT itself, you might be measured differently since you'd then be contributing directly to the organization's core business. But from the description provided, it sounds like you're not.
The Banjo Players Must Die!
I am sure that others could find much better ways of quantifying performance, but this is something that jumped out at me. I was part of a consulting team that was asked to improve performance in a company several years back, and they came up with something similar.
If the productive workers in a company never see or need to talk to a sys admin it's been a productive day for the admins. Bingo. So here's what you do:
Leave for a week.
When you get back, after you've managed to suppress the fires and riots, fight your way to Mr. Bean's office, talk him down off of his desk, get him to put away the spear, and tell him "that's why you keep us around." If he wants it quantified, write it up as "Number of Cannibal Insurrections Suppressed Per Week (Estimated)."
Thomas Galvin
Hours of productivity per day lost to productivity measuring?
Simple answer is that you don't. Productivity in terms of IT and related fields has become a dirty little word but more than that it is a business term, not technical. If you aren't a director or higher in title, and your duties don't include justifying expenses and planning resources for solutions, then it isn't really your realm to measure something like productivity. If this guy has an MBA or similar qualifications, it is he who should know how to measure productivity. But alas the word productivity has become corrupted by half-assed business journalists trying to write articles about over all productivity and how your employees waste too much time on facebook. If this guy just wants a number and gives you no guidelines as to how to come up with the number, then my guess is that he just wants to kiss up to the CEO that "productivity" is up 40% or he wants a number to justify laying off people. Either way, if he cant tell you how he reached his number, I would suggest getting your resume ready.
Also ideally, a CTO wouldn't be asking those in the trenches how to measure productivity, but rather how to improve it. As someone in the trenches, you probably know where the snags are in efficiency, or what software you would need to purchase to help smooth things along or even where people are over worked or over looked. This is the positive way to improve productivity. Basically he should be asking you what you need in order to get your job done, and he should get it for you (within reason of course)
meep
1) Ask him what he wants to hear
2) Tell him what he wants to hear.
If you can't reasonably tell him what he wants to hear, tell him how much it will cost to produce what he wants to hear.
This is not a technical consideration. This is a political consideration. He already has an idea of how to cover his ass. Give him the asbestos he wants.
I remember an old joke about a furnace repairman coming to a home and after looking at the furnace for about a minute and a half, listening to the rumbles and gurgles. He takes his hammer out and at once precise place he hits the furnace. The furnace starts up and runs fine as if it was brand new.
The bill was $200.
The homeowner asks why so much when all he did was hit it once with a hammer?
The repairman takes back the bill, and itemizes the bill still totaling $200.
Cost of hammering, $1
Knowing where to Hammer $199
Any idiot can muck about on a UNIX box, I worked at one Fortune 500 company where everybody in the dept had Double E's. Still their main Solaris server crashed ever 3-5 hours daily and had been for months.
Took me a week to unscrew it and put everything back in order.
Me, I am high school dropout with no GED and some non-technical college courses. Still most of what I was doing was letting them do their work and not have to bother about broken systems. My value was on par with theirs as it was time they didn't lose on their work.
Nevertheless beancounters are stupid (also Beancounters are not accountants), they know the cost of everything and the value of nothing. If you really want to send their head swirling take the entire labor budget for each dept expressed as an hourly unit. Every time you work for a dept internally charge the company that much for each hour you work on a project or ticket for them or better still your company and tell them thats how much it costs. Without Sysadmins nobody does anything but fight technical fires and gets no work done.
Likely this joker found out that Auto Mechanics have a book to calculate how much to charge for each service and repair with details on how long each job should take. This doesn't work because Sysadmins are closer to being chefs or doctors then low end auto mechanics.
Even so, people who own Jaguars, Ferrari, and Maserati don't take them to Jiffy Lube.
If they complain tell them the story about about that hammer. (or better yet use on on them)
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
That's a good list. I'd add a little more, though.
Personally, I split sysadmin work up into two categories: doing something and making it so you don't have to do anything. The second is much more important, but much harder to quantify.
For the first category, you can definitely count things for managers. E.g., X accounts created, Y support requests handled. Be very careful quantifying things like this, though, or you create perverse incentives. If I make a system that's hard to use, I can receive and satisfy a lot of support requests. Or if I concentrate power rather than distributing it, then I get to look busy and important.
The other category is much trickier. Long ago I worked for a financial trading company. About 80% of the working day, the head clerk would just loiter on the trading floor, reading the paper and shooting the shit with clerks and traders. And that was exactly what his bosses wanted: they correctly saw that as a sign he kept things running smoothly. And then when problems popped up, he could give them his full attention while the rest of the operation kept running.
So I'd add two items to your list: user satisfaction, measured through surveys, and crisis preparedness, measured by speed and quality of response during drills (and actual crises, of course, but you can't wait for those to find out how ready you are).
... in my opinion, is to be as bored as possible. Everything which is done on a regular basis should be as automated as possible, and as much effort and resources thrown at avoiding potential problems as the finances and customers will allow (data backups, spare or redundant equipment, etc.).
Much of a "good" sysadmin's time should be spent doing regular, but occasional spot checks on the automation (which can also be greatly automated) to ensure everything is running as smoothly as possible.
Obviously, not all problems can be avoided, especially hardware failures, but if everything else is in place, even recovering a dead, but critical server can be fairly painless.
I am an SA who became a bean counter. One of my primary motivations was that I saw f*ck-ups getting rewarded with less work and raises while hard-working SAs suffered with more work and dead end jobs.
I think management deserves to know what is good work and what isn't. If you leave it up to them, they are going to pick something like tickets resolved or customer satisfaction and you are going to see the a**-kissers move up while the hard-working straight-shooters get the shaft.
I think the metrics described here are good ones, but I'd change #4 to the ratio of load to capacity -- which is a measure of efficiency and good planning. Overall, a good SA should be able to maximize delivery of services. I'd also change #5 to security risk measured as ELV (expected loss value). I know a lot of security professionals who hate this and think it is meaningless, but so far none has given me any better metric to show management that security risks are actually getting better managed over time.
In short, think of what a good SA does for a company and propose metrics that reflect that. Do NOT leave it up to management like some have suggested. THey are asking for your opinion as an expert. Step up and show that you are the expert by giving them an expert answer. Show them that you know the difference between a good job and a bad job.