Provoking IT from Good to Great
Pay IT per caravan not per hour
Undercover Boss
Channel 4 has been running a new program called Undercover Boss where the top dog goes all anonymous on his staff and finds out some surprising things.
Recently the Undercover Boss, who ran caravan parks, joined the cleaning staff (sans suit and tie) and he found out that the cleaners who got paid per caravan worked better than the workers who got paid per hour.
Why was this? It’s obvious, in my humble opinion, and it’s very applicable to IT:
- Pay per hour rewards incorrect behaviour. Whilst the rate per caravan was initially set so that if you cleaned a couple a day that over a week you earned the same as a 40-hour paid person – by being paid per caravan you could earn more money by cleaning more than two per day and directly increase the business benefit: cleaning more caravans is directly good for business; working more hours is not. You might say that this is equivalent to working more hours (overtime) – but to then earn money, you have to work more than 40 hours per week (who wants to do that?). Pay per caravan means more money in <40 hours per week – if the quality is still good.
- Per per work package rewards efficiency and effectiveness. If you follow the Smart and Lazy principle (give a lazy person a job if you want it doing efficiently, but make sure they’re smart if it’s difficult), then each caravan is a series of problems to solve and improve: each hour is not!
- Pay per hour requires more governance. There are more simpler checks and balances: instead of clocking in and clocking off, like when you are paid per hour, you are instead measured on how many caravans you clean each day with spot quality checks and balances with customer satisfaction. The cleaning procedure per caravan is like a Toyota Production Line procedure – timed, unambiguous, and the incentive is on the worker to do a more efficient and effective job. How does one tie hours worked to customer satisfaction: Impossible.
- Pay per work package requires less management overhead: which means the workers get more money! Who writes the work packages? The whole team – managers, supervisors and workers: but they are not static, and are continuously improved.
- Pay per hour is for Idiot Managers; pay per Work Package is for brilliant managers. Controversial, I know, but how many middle managers have you known that couldn’t find their butt with both hands? I think paying staff per hour is a smoke-screen for managers who can’t articulate what they want, or what the business needs: brilliant managers (often the owner of the business, and/or a rare gem of a manager) seek to empower and reward their staff (sometimes, doing themselves out of a job).
The equivalent of a caravan in IT is the Work Package (read Prince2). Similar to the Toyota Production System where workers do packages of work (procedures) to build a larger system, IT is building IT systems, maintaining them, and decommissioning them – a constant flow of work packages. Work packages can cover the full lifecycle – I’ve picked ten groups that might be equivalent to “Clean Caravan”.
- Business justification
- Proof of concept
- Pilot implementation
- Testing
- Go live procedure
- Patching
- Upgrading
- Fault Isolation
- Root Cause Analysis
- Decommissioning
Of course, just like in “Clean Caravan” work packages there are “Clean Kitchen” and “Clean Bedroom” procedures, it’s the same for IT where “Business Justification” might contain “TCO”, “ROI”, and “Payback”.
Imagine this:
Each IT person is paid according to three criteria:
1) Work packages delivered (different values for different packages?)
2) Specific quality targets – standards, availability, compliance
3) Customer satisfaction
This isn’t a wild thought: most IT staff are paid by MBOs, so what I’m suggesting is just a good2great evolutionary step, let’s upgrade and evolve the MBOs to something more rewarding for the IT guy and the business guy.
What I’m suggesting is that instead of some bogus “knowledge worker” MBO (e.g. get VCP qualification – how does that sell more caravans?), instead the MBOs are based on throughput, efficiency and effectiveness.
There will be howls of protests from all quarters, no doubt, that “IT is more complex than that”, and “there are too many work packages to define”, etcetera: but aren’t these objections similar to MPs voting against their pay reform, and voting for bigger pay and pensions – when actually they could earn the same (or more) by doing a better job by being rewarded for throughput, efficiency and effectiveness instead of Old World measures of days attended at Parliament, regardless of contribution made?
I envisage two IT camps:
- The Status Quo: pay me per hour, and pay me more, regardless of what I do for your business.
- The Good 2 Great: my success depends upon your business’s success, pay me for my contribution to your success.
Which camp are you in?
No related posts.
| Print article | This entry was posted by Steve Chambers on 19 June, 2009 at 00:12, and is filed under good2great. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
about 1 year ago
I like this in theory, but I have a hard time imagining it working in practice outside of shops that have a high level of very similar, repetitive tasks. In my company, the complexity and effort required for things which would ostensibly be the same work package take vastly different amounts of time and effort. By the time you had most of the corner-cases covered, the management overhead would be tremendous. In the right environment, with the right supporting tools, this could be a big win though. I personally hate having any value at all tied to amount of time I spend sitting at a desk. I’m paid to sit at a desk, I paid to make sure things remain functional and improvements are being made when and where needed.
about 1 year ago
@Quentin Hartman Thanks for the feedback! I wonder where the “sweetspot” is between < - completely custom work-> and < - completely repetitive work -> ?
We know from the IT Process Institute and Visible Ops that process cultures = high performance; we know that Work Packages in Prince 2 work really well in hosting environments.
Is too much custom = too much complexity = too much variance? Is that why virtualization is helping?
So many questions – but I think the prize is huge! Thanks, Quentin! Let’s keep talking
about 1 year ago
@Steve Chambers
In a perfect world, the “sweetspot” is the break between the Jr Sysadmin tasks and the Sr Sysadmin tasks. Assuming of course you have more than one sysadmin…
I think that if an organization were to seriously want to implement this in a practical way, you’d have to go with a hybrid solution. You have certain classes of tasks that are paid per work unit, and certain ones that are hourly.
To extend the caravan metaphor, the normal day to day cleaning can be paid per unit. But when your cleaning crew goes in and discovers that the plumbing in the bathroom is thrashed and needs to be replaced, you call in a plumber who gets paid hourly.
As the program was implemented, which task goes into which category could be shaken out. Maybe even paying bounties for the creation of tools that convert “hourly” tasks into “work unit” tasks. I’m thinking automation here.
Another important point is that I think this is likely to only be accepted in organizations that have a large number of contractors and/or work remotely. People who are salaried and spend their workday in the office are unlikely, in my opinion, to want to convert to this model. In organizations where the workload is appropriately distributed, this is unlikely to present much of a tangible benefit to those people.
wrt to custom = complexity = variance, that’s just sort of the nature of our business. Everything we do is custom. I’ve managed to reduce a lot of complexity and variance since I’ve been here (our infrastructure was like a particularly ugly Katamari when I got here…) but I’m starting to see diminishing returns from that. As far as operations is concerned, we just have to kind of accept that the inputs to our processes are going to vary widely. Virtualization is helping with that somewhat, but it’s not the panacea that a lot of people like to claim!
about 1 year ago
I agree with Quentin on a lot of what he is saying. But, I do see the golden ticket here. To completely tie efficiency to pay at the worker level and abstract the need for management (performance evals, etc) would be streamline a department.
But to reinforce Quentin’s point, the need for this to be repetitive is paramount to simple implementation. Similar to estimation in a Scrum-based system there needs to be an iteration of the process to allow the participate to improve end over end (Kaizen?). No one gets anything right the first time and the majority of business value projects/processes within an org rely on departments outside of just IT. The people cleaning the caravans are very much in control of their own destiny. As long as they have caravans (planned work) and supplies (tool sets) they can perform their job. The ability to do more (complete deliverables) is within their control. If you required them to rely on external silos to complete individual tasks within the caravan (Marketing, Finance, Compliance, Legal) then they lose control of improvement cycle.
You could back up and include everyone involved in the goal including external silos, but at what point does this model become inefficient? It is the personal responsibility that creates the motivation and rewards effort – Damn, that stinks of capitalism
When things become more focused on ingenuity and specialized skills, i.e. going where no one has gone before, then the process may never iterate. This may work in the case of an external firm hired to complete a project where they have proven experience. But with an internal department that is blazing a trail towards the unknown it would be difficult or impossible to provide clear deliverables and time frames that would be attainable.
In the modern era (at least in the states) most of the work is done by salaried employees as opposed to hourly. We hire line workers (IT engineers) to work with the process to achieve a goal. We hire project workers (ScrumMasters, PMs) to manage the work goals, stories, phases, etc (line of caravans). We hire line managers to ensure make sure that the line workers are completing the work the project workers queue up. The line managers at this position use their cognitive human ability to input multiple dependencies, exceptions, experiences, and external factors and determine a line workers performance. The pay for work package idea eliminates the need for the line manager (Great!) but can’t completely replace the need for cognitive and human interaction within a complex matrix of inputs and outputs.
I also see this as a sliding scale with two axes (right side benefits from pay per work package):
<(big scope)more ext. dependencies less ext. dependencies(silo)>
<(more risk)less iterative more iterative(less risk)>
I didn’t even bring up the complexity of managing compensation in the modern world of labor laws. Don’t know if a hybrid would work too well. A very large shop with very specialized roles could do both. Smaller shops with sharing of roles would be difficult to integrate.
my two pence
about 1 year ago
This could have a huge impact on Customer Support/Help Desk within organizations.
Using your existing ticket/trouble tracking system you can assign a weight to each category of ticket and pay Support Representatives based on what they deliver.
This is preferable to evaluating tech support based on call times, number of calls, and hours worked. Even salary employees in customer service are paid hourly (if it only be in their minds). They punch the clock, take lunch and breaks at scheduled times, and would refer to working after hours as working for free. The current system provides them no incentive to be better and gives management no good way to evaluate talent or judge effectiveness.
Why should the guy that told 100 people to reboot get higher “stats” versus the guy that spent hours solving a complex problem especially if the problem is truly resolved. Additionally, why would the next guy that solves the before mentioned complex problem in half the time be penalized when he can provide twice the business impact as his slower counterpart?
If paid based on problem solved – the motivated, intelligent and efficient workers will separate themselves from the rest of the pack. These are the rising stars of your organization and it would do you well to be sure they stay happy.
So practically a password reset would be worth a fraction of say identifying and repairing a strange software bug.
So to bring it pack to the cleaning metaphor in the original post, get paid more for the more cleaning you do and more for how much dirt you had to clean.
about 1 year ago
Exactly – in The Goal, the factory workers didn’t realise the value/impact of what they did on the business. For example, the guy in QA had no idea that if he moved his position BEFORE the expensive, single-threaded oven then they would reduce waste and increase the efficiency through the furnace. The IT corollary is filtering tickets before they go through the expensive humans: your password reset is a fantastic example. Great organizations use an automated facility; good/ok organizations don’t.