There was another thread on Slashdot today that caught my attention:
http://ask.slashdot.org/askslashdot/07/08/25/1753220.shtml
The asker asked:
Productivity at its most abstract is the rate at which an employee adds value to an organization. The tricky part is determining how to measure that rate and the value itself. In manufacturing, it is easier as 'widgets-per-hour' is generally OK. IBM and Microsoft attempted to do this to programming back in the development phase for OS/2, and the infamous "KLOC", or, "thousand lines of code."
System Administration is something that doesn't lend itself well to such quantification. A significant part of our job is quite literally, fire-watch; do nothing until something breaks and then spring into action to contain and correct the damage. While we're waiting for something to break, we're also working on projects to get new or upgraded systems online.
What I have seen done is to have to account for every minute of my day. Every moment of my day has to be chargable against something; a project, a department, or other time-tracking tool. It is also my experience that such managers take a dim view of entries such as these:
9:50-10:00 Bathroom
11:45-12:00 Time-sheet entry
15:45-16:00 Time-sheet entry
The questioner asked, "what is the basic unit of productivity for an *nix admin?"
I could come up with a funny name for this fictional unit, but in essence there isn't one. To fully quantify an admin's productivity requires fully quantified metrics for:
Trying to reduce the complexity of the problem to certain 'proxy' metrics, metrics that are easy to track but also tend to mirror the much more complex metric, is the method of choice in these circumstances. Yet what proxy metric will do? Trouble-tickets resolved per week is one method, but it overlooks the differing complexity of some trouble-tickets (misplaced file versus install BlackBoard 9.4). Projects completed is another way, but as with trouble-tickets the complexity of some projects differs and projects can be canned from on-high without notice.
It is for reasons like this that Unions really like seniority. It is a simple supposition:
IF (timeAtCompany($NAME)) > (timeAtCompany($OTHERNAME)) THEN moreValuable($NAME)
Plus, it is hard for managers to game. Time of service is easy!
Yet every single tech-worker I've spoken with hates this system because we've all seen the flaw of it. If you've spent any amount of time at a company with more that 4 IT workers, there will be at least one of them that is not very good, just marking time until retirement, or is there for some reason besides to do a good job. These people have a tendency to have a lot of years of service, so are hard to get rid of. Just because you've been at a company in one general role is no guarantee of increased knowledge, skill, or value.
Sysadmin productivity is not something that can be measured easy. It is similar to trying to measure the productivity of a department-level Project Manager. It can be done, but it is a very squishy measurement.
Which just means we'll end up justifying every minute we're at work, and have the boss decide what productivity means through intuition.
http://ask.slashdot.org/askslashdot/07/08/25/1753220.shtml
The asker asked:
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?"I don't have a "bean-couter from hell" boss, but this is a topic I've spent a bit of time thinking about at my last job. How to you measure productivity of a sysadmin? The question at previous job was how do you determine which employee holds more value than another. This is not an easy thing.
Productivity at its most abstract is the rate at which an employee adds value to an organization. The tricky part is determining how to measure that rate and the value itself. In manufacturing, it is easier as 'widgets-per-hour' is generally OK. IBM and Microsoft attempted to do this to programming back in the development phase for OS/2, and the infamous "KLOC", or, "thousand lines of code."
System Administration is something that doesn't lend itself well to such quantification. A significant part of our job is quite literally, fire-watch; do nothing until something breaks and then spring into action to contain and correct the damage. While we're waiting for something to break, we're also working on projects to get new or upgraded systems online.
What I have seen done is to have to account for every minute of my day. Every moment of my day has to be chargable against something; a project, a department, or other time-tracking tool. It is also my experience that such managers take a dim view of entries such as these:
9:50-10:00 Bathroom
11:45-12:00 Time-sheet entry
15:45-16:00 Time-sheet entry
The questioner asked, "what is the basic unit of productivity for an *nix admin?"
I could come up with a funny name for this fictional unit, but in essence there isn't one. To fully quantify an admin's productivity requires fully quantified metrics for:
- The impact of server and service downtime.
- The value gained from meetings.
- The seasonal variations in business (in our case, when are classes in session? When are finals? When do grades need to be reported? When are parents on campus? Things like that.)
- Bureaucratic friction (how much 'process' is required to get things done?)
Trying to reduce the complexity of the problem to certain 'proxy' metrics, metrics that are easy to track but also tend to mirror the much more complex metric, is the method of choice in these circumstances. Yet what proxy metric will do? Trouble-tickets resolved per week is one method, but it overlooks the differing complexity of some trouble-tickets (misplaced file versus install BlackBoard 9.4). Projects completed is another way, but as with trouble-tickets the complexity of some projects differs and projects can be canned from on-high without notice.
It is for reasons like this that Unions really like seniority. It is a simple supposition:
IF (timeAtCompany($NAME)) > (timeAtCompany($OTHERNAME)) THEN moreValuable($NAME)
Plus, it is hard for managers to game. Time of service is easy!
Yet every single tech-worker I've spoken with hates this system because we've all seen the flaw of it. If you've spent any amount of time at a company with more that 4 IT workers, there will be at least one of them that is not very good, just marking time until retirement, or is there for some reason besides to do a good job. These people have a tendency to have a lot of years of service, so are hard to get rid of. Just because you've been at a company in one general role is no guarantee of increased knowledge, skill, or value.
Sysadmin productivity is not something that can be measured easy. It is similar to trying to measure the productivity of a department-level Project Manager. It can be done, but it is a very squishy measurement.
Which just means we'll end up justifying every minute we're at work, and have the boss decide what productivity means through intuition.
Accounting for nearly every minute of one's job occurs for me, although we're a slight bit lenient with it.A problem with that approach is that so much of our time and projects are variable. It's not like you can easily (or fairly) compare how AdminA performs task Z in 1 hour but AdminB last took 2.5 hours to perform task Z. Whether that be from unforseen issues, impediments, or just lack of exposure to that task in the past.It becomes very arbitrary, and puts pressure on everyone on the team to be as fast (or reckless?) as the fastest person, or risk being the inefficient cog.Yeah, it's an approach, and I've seen it done in my past two jobs, but I don't think any tech (even overachievers like I was at my last one) really likes it or feels happier at work for it.