Should executives receive incentive pay? Should anyone?
Last week’s KJR explored the logic behind incentive pay, and concluded it doesn’t hold up to scrutiny (I nearly said “close scrutiny,” which contrasts with the distant scrutiny that’s so popular these days).
Incentive pay shares a characteristic with at least four other well-established business practices — recruiting, performance appraisals, outsourcing, and software development — namely, the widespread certainty that when they don’t work, the problem is with the details of execution, not the fundamental concept:
Recruiting: As my friend Nick Corcodilos of Ask The Headhunter fame has been pointing out for years, the industry-standard recruiting practice of posting a position description, screening resumes based on skill-to-task matching, and so on fills fewer than one out of every ten open positions. And yet, most companies continue to pretend it works, even though, based on the numbers, it’s obviously broken.
Performance appraisals: Okay, I don’t have any documented numbers to back this opinion. Based on what I’ve seen, over the past few decades the performance appraisal process (really, practice) has become increasingly bulky and time-consuming for both managers and those they manage.
The payoff for the additional time and energy diverted to this activity? So far as I can tell, managers hate it, few employees find it valuable, and there’s no evidence that better employee performance correlates with more extensive and intensive performance appraisals.
Outsourcing: As documented in Outsourcing debunked (me, 2011), the only constant in the outsourcing industry is its failure rate. Commonly, three years into most outsourcing deals the contracting company finds itself either renegotiating their contract or terminating it altogether. Overall the numbers seem to show that between 30% and 70% of all outsources fail, depending on whose numbers you’re reading and the type of outsource they’re writing about.
But the numbers you read almost certainly underestimate the failure rate. Here in the Minneapolis/St. Paul metro, for example, it’s widely known that Best Buy is quietly unwinding its high-profile outsource to Accenture, but nobody in either Best Buy or Accenture publicly admits the whole venture was a failure.
Software development: For at least two decades, waterfall development wasn’t a way to develop software. It was the way, even though the way that preceded it (or at least one of the ways) — frequent informal conversations between business managers and programmers, with programmers showing business managers their results as soon as there was something to show and the business managers providing feedback that led to quick course-corrections — demonstrably worked.
I say demonstrably because the near-universal pre-waterfall outcome was stable, tailored-to-the-business, feature-rich applications, unlike waterfall, with its notorious 70% across-the-board failure rate.
Isn’t it interesting that when you read the Agile Manifesto, it sounds a whole lot like nostalgia for the pre-waterfall days?
At least with software development, as an industry we finally acknowledged that waterfall doesn’t work, although we needed a couple of decades dominated by dismal failure to accept this.
Too bad the Agile Manifesto hasn’t kept up with the times. It’s about software delivery to customers at a time when (1) there are no internal customers, and (2) the point isn’t software delivery, it’s successful, designed, planned business change.
Incentive pay, recruiting, performance appraisals, outsourcing, and software development. Five very different concepts. In all five cases, the business community has spent decades assuming the problem was with execution, not in fundamentally flawed concepts.
Here’s the irony: If an assumption was to be made, flawed execution was the right one. It’s the Edison Ratio in action.
Edison, you’ll recall, explained genius as being one percent inspiration and ninety-nine percent perspiration. Given this 99:1 ratio, logic dictates that when something goes wrong, it’s 99 times more likely to have been with the sweat than with the idea … with the execution, not the concept.
So the issue isn’t that business leaders, faced with failures, focused their attention on execution. Quite the opposite, this was admirable. It means they recognized that there’s no substitute for sweating the details.
No, the issue is how long it should take to figure out that the problem is the core concept after all.
In this, business leaders would do well to accept the advice of the source of so much wisdom, W.C. Fields: “If at first you don’t succeed, try, try again. Then give up. There’s no use in being a damn fool about it.”
Bob:
I think that the poor track record of “incentive pay” depends strongly on just what is meant by the term. In a different context, I found a case of “incentive pay” which seemed to work extremely well. A factory offered a reasonable base hourly wage to all its hourly workers. It also offered a premium rate to every worker based on meeting given rates of production of acceptable parts at the end of the line. However, each worker was authorized to reject parts arriving at the worker’s station NOT meeting the quality requirements the part should have when reaching that point in production. Hence, a worker had no incentive to pass along a shoddy part, as the next person down the line would not want to be unable to do the work on the part required at that station. If a sufficient number of acceptable parts didn’t make it through the line, NO ONE got the incentive rate. Hence, there was enormous peer pressure NOT to goof off or do shoddy work, at least not more than once! When the kinks got worked out of the system, the workers found that it offered them a really good wage, when they did good work.
Now admittedly, this doesn’t map easily to the work of executives, but if one can’t describe what it is about their work that constitutes “quality,” then I don’t think I’d rush to invest in their companies.
As Daniel Pink points out in Drive, incentive pay seems to work with menial tasks that require effort but not much in the way of cognition. The more the task calls for creativity, analysis, and judgment, the more incentive pay seems to cause performance to deteriorate.
At least, that’s what the evidence seems to show.
One of the greatest positives of working freelance is that I will never again have to give or receive a performance appraisal. These time-consuming, pointless and bureaucratic procedures exist only to create work in for HR staff. Performance coaching needs to be continuous (but preferably not continual) to be effective.
Bob,
Your comments on software development are interesting. I am old as the hills, but the only way my previous employers did software development was the Waterfall method, although they didn’t call it that. My department did software development using the sub rosa method, that is the effort was unfunded. I developed a methodology that I called Top-Down software development. I had my programmers write a “user manual” first – they hated it; the grammar was useless, and the prose terrible, but they had to think in terms of the user in order to do it at all. Then we prototyped the software in a high level language starting with the user interface, which was usually a GUI. We backfilled the GUI with data drawn from a static database until it worked correctly. Then we developed the software to fill the database from a live real-time system. At each stage, we discussed the software with Marketing to fine-tune our design.
At the end, when all was working well, we offered the opportunity to increase performance by re-writing in the system’s preferred source code. Many times, performance was good enough that we never implemented in a systems programming language.
Our major discovery was that Marketing actually had no idea what customers really wanted or needed in the abstract. However, once they could see the prototype, they could make intelligent comments, and/or actually bring in a customer focus group.
Previous management concentrated on developing software the “right way.” My group focused on developing “the right” software.
Yup. I did a lot of systems like this, more or less. Glad to know I wasn’t alone. This sort of thing works great when the user-interface is the most complicated part of development, which in my experience, in business at least, is most of the time. As the complexity shifts to logic and algorithms, a more waterfallish approach seems to be needed.
Anyway, thanks for sharing your experience with this. Iterative prototyping rarely gets the exposure it deserves.
Great article! So sad and so true about the time wasted and effort expended on bad concepts. I’d like to offer another quote that I think applies, “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” Mark Twain
I spent a lot of years in various aspects of insurance agent commissions — administration, implementation, design, even led introductory meetings. Incentive pay can work to drive behavior if: 1) the payee believes that the amount of incentive is worth the effort, 2) the payee can see a direct link between behavior and the amount of compensation, and 3) the plan is easily understood. Then, the plan designer has to be smart enough to create a plan that aligns company strategic goals, customer value, and the payee’s compensation.
That was exceedingly difficult for insurance agents on commission — where we had details of every policy event and agent action. I see no possible way to meet all these criteria for executives.