10x Productivity Myths: Where’s the 10x Difference in Compensation?
- Posted on January 22, 2011 5:42:PM by Steve McConnell to 10x Software Development
- productivity, Management, 10x, compensation
In response to my recent blog post on the research support for 10x productivity differences among programmers, Pete McBreen made the following comment:
"One point in his article that McConnell did not address--programmer compensation does not vary accordingly. This is a telling point--if the difference is productivity can be 10X, why is it that salaries rarely fall outside the 2X range for experienced developers?" [emphasis in original]
This is a good question. It’s timely because the Software Engineering Productivity group on LinkedIn has recently had a 130-comment discussion on the question of “Should pay be tied directly to productivity?” It's also a question that I wrestled with personally for about the first 10 years of my career. Indeed, it's part of the original reason I decided to became self employed back in 1989 and eventually founded my own company in 1996.
The Intuitive Version of the Question
I started my personal “10x compensation quest” from the point of view of, “I know I’m 3-5x as productive as the guy sitting next to me. Why am I not making 3-5x as much money?” Over a period of many years I found that this formulation of the question embodied several assumptions that were naïve or just plain wrong from a business perspective.
Six Myths of 10x Compensation
Let’s look at each of these myths of 10x compensation.
Myth 1. The guy next to me is getting paid what he’s worth. If I’m really 5x as productive as the guy sitting next to me, part of that is that I’m really productive, and part of that is the guy next to me is not very productive. Let’s say that we’re both first-year programmers and both making $65,000 (i.e., pretty typical first-year programmer comp in major markets these days). Me being 5x as productive as the other does not mean I should be making 5 * $65,000. It probably means something more like the other guy should be making $20,000 and I should be making $100,000. Part of the issue is that I’m underpaid a little; a bigger part of the issue is the other guy is overpaid a lot.
My personal observation is that average company has something like 20% of its programmers that aren’t contributing anything meaningful to the business and whose compensation should really be zero. In many companies, star performers’ low compensation is essentially subsidizing poor performers’ salaries.
Some people think, “If I’m a 10x programmer, I should be making 10x the average compensation.” But the 10x ratio is not 10x from best to average; it’s 10x from best to worst. If you think you should be making 10x what the worst programmers make, and the worst programmers should be making nothing, be careful what you wish for!
Myth 2. “Programming productivity” = “value to the business.” When someone says, “I’m 10x as good a programmer, therefore I should be paid 10x as much,” they’re assuming that their value to the business is based on their programming capability/contribution. That is part of the story, but not the whole story. Some mediocre programmers might be better at interacting with customers. Some might have better potential to move into management. Some might have less personal output but a wonderfully positive influence on overall team output. There are lots of other factors that influence “value to the business” besides raw programming output.
Myth 3. High output should be rewarded with high salary. What’s mythical about this statement depends on understanding the difference between salary and compensation. When a business sets a salary (as opposed to a bonus – i.e., “fixed comp” vs. “variable comp”), the business is recognizing a person’s current contribution to the business, and it’s also making a calculated bet about the person’s contribution to the business in the future and over time. If I’m 5x as productive as the next guy this year, there’s no guarantee that I’ll be 5x as productive again next year. My motivation on the next project could be lower. I could be distracted by new girlfriend, new wife, new baby, parent’s health issues, personal health issues, new release of Call of Duty, etc. Most businesses won’t lower salaries except in extraordinary circumstances, so businesses are very conservative about increasing their employees salaries.
The same basic reasoning applies to salary offers to new employees. If I’m looking at a guy with a 20 year track record of uninterrupted outstanding performance, I’ll make one kind of a bet about his future productivity when I offer him a salary. If I’m looking at a guy with a 2 year track record, no matter how outstanding those 2 years have been, I’ll make a different kind of bet about his future productivity when I offer him a salary.
These issues are related to rewarding output with high salaries. Rewarding high output with high bonuses brings up different issues.
Myth 4. Businesses try to pay people based on what they’re worth to the business. This is true only in the most approximate sense. I used to think that the ideal business would go through the thought process of, “This person is contributing $Y in value to our business, so we can pay them some fraction of Y and still make a profit.” That isn’t how businesses work. In my experience, businesses don’t make any attempt whatsoever to figure out on a person-by-person basis how much each person contributes to the bottom line. At best, a business might go through an exercise of defining how much each job is worth (not each person) – but those exercises don’t account for whether the person in each job is a 1x performer or a 10x performer. For the reason, any analysis of “this job is worth Y” without considering the level of performance of the person doing the job is a meaningless exercise.
Since businesses almost never know what a specific person doing a specific job is worth, businesses generally pay people based on their market value, not on any calculation of their monetary contribution to the business. Businesses pay people whatever they need to pay them in order to attract the people they want to attract and retain the people they want to retain. Businesses aren’t going to pay any more than they have to to fill any particular job, and so they’re not going to pay above market if they don’t have to. If a business can attract and retain a 10x developer for a 2x salary, that’s what it will do.
As McBreen pointed out, the market salary structure for programmers is relatively flat. In the local executive discussion group I host, earlier this month we discussed “Job Market 2011,” including compensation issues. In our area (Seattle), starting salaries are running about $50-$65K for people with less than 1 year of experience. Top end salaries are in the $125-$150K range for senior, star technical performers with no management responsibilities. McBreen stated that he saw less than a 2x difference in compensation in his area. The situation is actually worse than he described. In our area, there is approximately 2.5x difference in the total range, including from most junior to most senior.
Myth 5. If a business wanted to pay based on productivity, it could measure individual productivity meaningfully enough to support its compensation decisions. As I discussed in a blog post in early 2008, measuring a 10x productivity difference in a research setting is one thing. Measuring productivity of specific individuals in a live production environment, on an ongoing basis, is a totally different challenge. The research measurement is possible and practical and has been done several times. The live, on-the-job measurement is subject to numerous “measurement error” issues that in my view make such measurements extremely impractical, if not downright impossible.
My first job after college I worked as a programmer at a company that tried to tie pay to productivity. We had a "billing hour bonus." There was a formula for calculating the bonus, and there were lots of anomalies in the formula. To get over the anomalies, the boss tweaked the formula almost every month. By the time I left that company there were 17 variables in the formula and almost all the programmers thought it was a joke. It mostly rewarded one guy who liked to work long hours, even though we all knew he was the least productive person there (both in terms of individual contribution and in terms of impact on others).
If we can’t meaningfully measure differences in performance, we’re left with more subjective assessments of programmers’ contributions to the business, which actually is how most businesses operate.
Myth 6. Companies don’t adjust pay for differences in productivity. Good companies do try to recognize differences in productivity. They have technical ladders that parallel their management ladders so that really good technical people can make salaries comparable to managers. Good companies attempt to pay based on very rough approximations of productivity over time. That's what different pay grade levels are for, and that's what performance reviews are for.
Your reaction to that is might be something like, "Yeah right. Performance reviews. Those are a joke. My boss doesn't really have any idea what I'm doing. I usually write my own review, or my boss just spouts generalities." That's right. Those are common problems with performance reviews. And with that common experience, why would anyone think that "measuring productivity" would be any more reliable than that? We have decades of experience via performance reviews that says it wouldn't be.
In Summary, Is All This “Right,” or is This Just the Way it Is?
I think it’s a little of both. I agree with the ideal of matching total compensation (not salary) to performance. But implementing that in practice is terribly challenging. The only practical way I can think of to truly tie pay to performance would be to move all employees to a contractor model and then pay them for well-defined pieces of work on a contract basis, with defined acceptance criteria and so on. I don't think that's practical, though, and it would undermine collaborative approaches like Scrum and also create some teamwork dynamics that I personally would rather not deal with. My overall conclusion is that paying for productivity on any more than a very-rough-approximation basis is a panacea that cannot practically be achieved.
As I’ve commented previously, the discrepancy between capability differences and compensation differences does create opportunities for companies that are willing to hire from the top of the talent pool to receive disproportionately greater levels of output in exchange for only modestly higher compensation.
This is not the answer I expected to find when I began asking the question almost 25 years ago, but I can see the reasons for it. Gerald Weinberg describes a pattern he describes as "Things are the way they are because they got that way." I think this is one of those cases.