Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Not sure if this is a META question or not, but...

Anyone know of a good way to define an objective bonus structure for an I.T. manager? I've come up with the following criteria, but I'm not sure how best to evaluate the metrics:

  • Operational (network uptime, website uptime, etc.)
  • Support (helpdesk ticket turn-around times, etc.)
  • Project (on time / on budget, execution, management effectiveness, etc.)

Of course these work great in theory, but how would one evaluate these metrics in an objective / fair way?

We use a 3rd party consulting firm for monitoring our uptime / resources, which could work for 'Operational', we have a Help Desk that I could run a SQL query on to generate statistics about tickets for 'Support', and I concede that at least half of the 'Project' evaluation will have to be subjective...

In any case I thought I'd reach out and see if anyone's attempted something similar.

Thanks...

share|improve this question

4 Answers 4

up vote 5 down vote accepted

Honestly, I don't think IT Managers should get bonuses for uptime — uptime is part of our base job, and if we don't do that we shouldn't have the job. Even then, sometimes things happen outside of our control that pull this down, but that just makes it worse in terms of bonuses: we're rewarded or not for things we can't control.

I'm a little more sympathetic for support, but supporting users is really the same thing and it's just so easy to game. A manager who knows that's where his bonus comes from will have a tendency to create lots of simple tickets so that he meets his metric.

Really, when you're thinking about bonuses, you have to look at the projects. These are the areas where an IT Manager gets to be creative and show that he's worth not only what you pay him, but the bonus as well.

To evaluate projects objectively, you need to look at outcomes vs plans. For example, for next year you might plan a thin-client rollout in an area. The goals for this project are to reduce energy use and simplify management of those desktops, at a net savings of $X per year and initial cost of $Y.

To determine bonus level you might then use a formula like for X*5 - Y as total savings over a five year life of the installation, and put as much as 1/3 of that amount on the table as part of that manager's bonus for the year. Other projects would contribute other parts, and you're realizing potential savings from this project that will last longer than just the five year life of the initial installation because this service level is the new baseline for that area for the next deployment as well.

You then measure the actual costs of the implementation, actual management costs after completion, and actual energy use before and after to see how the manager did relative to the expectations for the project.

By contrast, a similar project in another area that just updated the PCs with this years equivalent model on the normal replacement cycle would not have any bonus impact, because that's just part of the normal function for that position. You want to use bonus money to reward creative work that helps the bottom line of the business.

share|improve this answer
    
Agreed. I'll be suggesting we adjust the breakout so that the bulk of the bonus is based on Projects, with the other two representing no more than 40% of the total bonus. I'm also going to look into using different metrics for evaluating support and operations to avoid "gaming" the structure. Thanks everyone for the input! –  I.T. Support Aug 20 '10 at 19:04
1  
I'd suggest that things like uptime should be 0% of the bonus. You'll create a much bigger sense of unfairness if someone loses their bonus due to downtime when it's nothing they could influence (e.g. powecut, or a part fails that their supervisor refused to fund the replacement of) than you would from simply not having a bonus in the first place. –  RobM Aug 26 '10 at 15:00

There is a large number of studies that seem to suggest that trying to build a bonus for objective criteria alone will just make people figure out how 'game the system' in a way to achieve the objective.

For example when people measure by ticket turn around time people a tech will just close the ticket as quickly as possible even if the problem is not solved.

Trying to measure pure uptime might encourage people to skip applying security patches or avoid required maintenance.

You might want to read 'The Upside of Irrationality', and 'Predictably Irrational' for more examples and discussions of studies that suggestion that bonuses are not as effective as management likes to believe.

If you do need to do this I am not saying objective criteria shouldn't be considered. But subjective criteria will also be necessary. Perhaps measure satisfaction with the resolution of tickets.

share|improve this answer
1  
Agreed. Ticket turn around is the dumbest criteria possible. I.e. There are tickets that literally take 10 seconds to resolve. And others that takes 3 weeks. Does the guy who only does the 10 second tickets get a bigger bonus than the one who hassles the vendor every day for 3 weeks to get a problem resolved? That someone less diligent would end up taking 6 months? –  geoffc Aug 20 '10 at 16:55

At my last company I was asked to help determine these metrics and thats about what we settled on. Unfortunately a lot of it will be subjective. The problem too is that when things are running well no one notices IT. Other factors that we worked into the bonus structure was review by other department heads (which I'm not 100% sure how I feel about, it can go either way if you don't have good department heads who don't understand what you do) and the general profit performance of the company since IT really facilitates all other departments being able to deliver on their goals.

share|improve this answer

You could split the bonus payout based on your multiple criteria:

33% of bonus if Operational targets are met 33% of bonus if Support targets are met 20% of bonus if Objective Project targets are met 13% of bonus if Subjective Project targets are met

You could break them down further if you wanted. That would allow you to minimize the subjective portions. Ideally, the manager(s) should be able to predict fairly accurately what their bonus will be, based on objective measures. In reality, the subjective stuff complicates it. If you review the subjective targets regularly (quarterly?) during the bonus period that would minimize surprises.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.