10x Productivity Myths: Where’s the 10x Difference in Compensation?

  1. Posted on January 22, 2011 5:42:PM by Steve McConnell to 10x Software Development
  2. 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.

Ben Tilly said:

January 22, 2011 11:16:PM

There is another important one that you miss.  Which is that productivity differences are primarily because of the programmer.  However if you look, for instance, at the results in Peopleware, you'll find that a very large part of the productivity differences that they found between programmers at different companies can be attributed to factors such as the quality of the workspace.

If the company puts out the investment in factors that enable you to produce 3 times as much, why should they also pay you 3 times as much salary?

Erik Engheim said:

January 23, 2011 6:08:AM

Very good article Steve! A lot of good points. Personally I think that in most intellectually challenging work, whether it is programmers or teachers it is almost impossible to measure value to the business accurately. E.g. I know of developers who are extremely productive but generally at the expense of others. Either by writing reams of shitty code, avoid documentation, never communicate or help fellow developers or employees.

Any proper measurement of productive should have to take into consideration long term productivity. Like how many man hours are required to maintain the code and to what extent can it be understood and reused by others to quickly build new functionality in the future.

Likewise with teachers to what extent are the result of the class due to the quality of the teacher and the quality of the students?

Theodore R. Smith said:

January 23, 2011 6:44:AM

I think there are at least 4 more-or-less rock-solid ways to gauge a programmer's efficiency relative to their peers at the same corporation:

* Total net profit directly saved by their fixing bugs that either they found or are only fixable by them (due primarily to skill / domain knowledge),

* Total net profit directly earned from features that either they predominantly contribute to,

* Total time (money) saved because of the ease of understanding, extending, and using well-written code generated primarily by the coder

* Total time (money) saved because of less QA and troubleshooting needed because the coder created unit tests with a high level of code coverage.

subtracted by

* Total amount of bugs and time (and money) spent fixing them generated by the coder

* Total amount of time (money) needed to rewrite/refactor caused by code generated by the coder.

* Total time (money) wasted because of the difficulty in understanding, extending, and using poorly-written and largely undocumented code generated primarily by the coder

* Total time (money) wasted because of more QA and troubleshooting needed because the code is far more brittle and unstable

When you factor in all the above, I would wager the extremes are FAR more than 10x cost factor basis that can be readily determined with proper and honest word-of-mouths from the other coders.

For instance, I can readily tell you who's code I never have to fix, and who's code I always have to, as well as who's code I really admire and find easy to read.

John said:

January 23, 2011 8:50:AM

I think there's another side to the productive programmer myth that isn't being discussed. I've seen a lot of supposed productive programmers who turn out a lot of code but it's crap. It's actually an interesting dynamic. You show up early on a project. Crank out a bunch on crappy code but it sort of works. The bugs are of course due to technical problems not a result of shoddy work. How do we know? Because we asked the productive programmer that's how. He's the expert. Now programmer number two to the project has to expend 9x just to understand the 10x of crap the first programmer wrote just to contribute 1x which usually just ends up being bug fixes because refactoring anything our productive programmer wrote would piss the hell out of him and send him crying to management who would instantly take his side because they can't piss off the productive programmer, he's the only on who really knows how this stuff works.

For the productive programmer this is a nice place to be. He has job security. Management can't fire him because he's the only one who understands the crap he wrote. He has power. He can effectively isolate other programmers by withholding information or manipulating management and he has complete design control over the entire project.

What incentive does the #2 programmer on the project have even if he was more productive. It requires a massive amount of energy to engage our productive programmer and what are the benefits of winning? You get to actually do your job? It's usually just better to find another project to work on.

Jeddy said:

January 23, 2011 9:43:AM

Compensation actually reflects the value of the *other* jobs that the individual is giving up; if you have job options that are very valuable to you, a company would have to pay you a lot to prevent you from pursuing those other job options. This explains why firefighters are poorly compensated despite providing a very socially valuable service -- they typically do not have many other valuable job opportunities. This is also why programmers, despite productivity differences, will not have significant compensation differences: most have similar opportunities for other jobs that require significant math skills, logic, thoughtfulness, and focus.

Steve McConnell said:

January 23, 2011 10:44:AM

@Theodore -- good list. The challenge is that some of the items on the list can't be measured until months or years until after the work is done, so as bases for compensation, even if they're theoretically correct, they can't be used for practical reasons.

Steve McConnell said:

January 23, 2011 10:47:AM

@John, I've seen both extremes -- the programmers who codes like hell and whose code looks like hell, and the programmer who's really fast *because* he's producing really clean code that allows him to not spend much time bug fixing.  

Organizationally, I think this problem is actually pretty easy to address -- you just set up a feedback loop that requires developers to to fix their own bugs. It's good feedback, and it prevents the "fast but crappy" coder from appearing to be fast but really just creating a lot of work for others.

Steve McConnell said:

January 23, 2011 10:49:AM

@Jeddy, Yes, I think this is another way of phrasing the "market value" argument. I'd call it "opportunity cost" to the programmer of taking the job he takes vs. some other job. You describe the potential opportunity cost pretty broadly by bringing in other kinds of jobs. I think in most cases companies don't consider other kinds of jobs -- they more narrowly just consider what a person could earn in a similar job but at a different company.

neilj said:

January 23, 2011 11:24:AM

@Theodore R. Smith

I think that even if it were possible to measure these points accurately and promptly, tying them to compensation would drive some pretty toxic behaviour.

e.g.

"* Total net profit directly saved by their fixing bugs that either they found or are only fixable by them (due primarily to skill / domain knowledge),"

is unlikely to foster collaboration or mentoring, why would I share my domain knowledge if it means less compensation? Or as a junior dev I might spend hours figuring out how to fix something rather than the 10 minutes it might take after talking to the expert. By asking their advice I am penalised.

Larry OBrien said:

January 23, 2011 12:00:PM

Oh nuts... it looks like your blog software explodes if a name contains an apostrophe and loses the several minutes worth of writing submitted... *sigh*

Anyway, I think Myth 5 ("Companies can tell") deserves deep reflection. If companies CANNOT tell what productivity is, does that not raise the specter that our profession's internal quibbling is just arguing about how many angels can dance on the head of a pin?

Steve McConnell said:

January 23, 2011 2:14:PM

@Larry, Myth 5 isn't "companies can tell" it's "companies can *measure*." I think most companies CAN tell who is more productive and who is less productive--subjectively--at least to some degree.

Let me put it to you this way: Have you ever been part of a team where the team members didn't have at least a loose consensus about who the stronger performers were and who the weaker performers were? Not an exact ranking, maybe, and certainly not quantitative, but at least some kind of common view? The teams I've been a part of have always had a good idea of who the solid performers were and who the marginal performers were -- even if they couldn't measure it.

Doug in Seattle said:

January 23, 2011 3:30:PM

I once worked for a startup where me and two others were mainly responsible for one big project. About 1/2 way through we all got a big raise, despite the fact that one of the devs and I were constantly fixing the f*ckups caused by the third. Yet we all got the same $$$. I went back to contract work and have never gone back to being an employee.

Vin D'Amico said:

January 23, 2011 7:27:PM

Excellent article! Companies hire with a performance level in mind. If someone fails to achieve that level, he'll receive smaller salary increases or none at all. Lowering someone's salary to match their poor performance almost never happens. Very hard to do.

If someone exceeds the expected level of performance, that person is rewarded with salary increases, promotions and/or bonuses. Such rewards take many months, if not years, to play out.

In the end, programmer productivity and associated quality of work are notoriously difficult to measure. You may write code 10x faster than me but I might write technical documents 10x faster than you. Who is more productive?

Consider another angle: You write code 10x faster but my code is simpler and easier to maintain. Who is creating more value for the company?

Ultimately, I think all of us would be better served if the software industry could define and adopt a few standard performance metrics. Sounds like we need a standards committee!

Bas Hamer said:

January 23, 2011 8:26:PM

Productivity is always interesting.

As mentioned before there is a question of “what is productivity”?

For instance what is the productivity of a person that introduces data access generation tools? What is the productivity of a developer that resolves a conflict between two others? For the one that asks the right question to the customer? The one that trains the others?

To get to 10x you have to do very little in most organizations; you can probably do it w/o a computer.

People don’t get paid based on their value; that would not be very politically correct. Just look at the outrage at CEO pay where as it makes perfect sense if you consider the value of a .1% efficiency gain across the organization would be.

Income is closer linked to risk thank productivity. Accept more risk, get more income.

czrpb said:

January 24, 2011 10:11:AM

Uggh .. nice apologia for the status-quo.

What is annoying is that you just will not accept the answer that you yourself know (of course neither will anyone else); take this comment (January 23, 2011 2:14 PM) of yours for example: "Let me put it to you this way: Have you ever been part of a team where the team members didn't have at least a loose consensus about who the stronger performers were and who the weaker performers were? .. The teams I've been a part of have always had a good idea of who the solid performers were and who the marginal performers were -- even if they couldn't measure it."

Others have also alluded to it:

 * Theodore R. Smith (January 23, 2011 6:44 AM): "When you factor in all the above, I would wager the extremes are FAR more than 10x cost factor basis that can be readily determined with proper and honest word-of-mouths from the other coders."

 * John (January 23, 2011 8:50 AM): "I've seen a lot of supposed productive programmers who turn out a lot of code but it's crap."

 * Erik Engheim (January 23, 2011 6:08 AM): "I know of developers who are extremely productive but generally at the expense of others. Either by writing reams of shitty code, avoid documentation, never communicate or help fellow developers or employees."

I would be quite happy to be 'rated' (hence compensated) by my team. Even further, I would be just fine with them 'rating' me lower because of non-technical things such as difficult to work with (arrogant, rude, snide, ...), unhelpful, smelly, etc, if they were to believe them. And, if you are NOT willing to be 'rated' by your team, what does that say about you, them, the environment, the culture, etc?

Or do I have a reading comprehension problem and you or someone here did in fact write and have such an opinion?

Steve McConnell said:

January 24, 2011 10:50:AM

@czrpb -- It sounds like you're referring to "360 degree reviews." Some companies do use those. My company used them for awhile when we were doing outsourced software development. They work OK. They don't provide a *measurement*, but they help provide a more accurate, albeit subjective sense of what people's relative contributions are.  

czrpb said:

January 24, 2011 11:32:AM

Hi! Thx for reading my (gruff?) reply and responding.

But, I am curious: Why not go all the way and consider said team members' feedback the measurement(s) you seem to want, in fact *need*?

My worry here is that your desire for "measures" is fear based; that you must have "numbers". I find it curious that "data" makes you feel better than human opinion, especially here: If the team tells you I suck and ought to be fired and they would perform better, why would you not believe them? How is it you (or a manager) is in a better position to know the impact of me on the team?

Steve McConnell said:

January 24, 2011 1:45:PM

@czrpb -- You sound like you think you're disagreeing with me, but I don't think you are :-)

I don't think you have to measure, and I'm not saying "data" makes me feel better than human opinion. I think you should measure if the thing you want to measure is amenable to being measured. Numeric measures would be nice for salary review purposes because you're ultimately trying to define a numeric quantity (salary).

BUT, as I tried to say in the blog entry, I don't think individual performance in a real-world setting is amenable to being measured. So in the case of programmer performance, being carefully subjective is preferable to fooling yourself into thinking you can measure something that you can't.

In the absence of good measures, I agree that 360 degree feedback can be useful for helping define a basis for salaries. Team members often have a better understanding of each others' contributions than their manager does, which is why my company used 360 degree reviews when we had those kinds of teams.

czrpb said:

January 24, 2011 2:33:PM

Hi! Thx again! I know you are busy so I can not expect this to become a long discussion: So thanks for post and replies!

(Plus, if I keep responding I will certainly seem like an obstinate troll!! Which is something we obstinate trolls try hard to hide! grin!)

Jim Gomes said:

January 26, 2011 3:13:PM

Calculating compensation is extremely easy.  You get paid exactly equal to the amount you are willing to accept.  Don't whine about it.

human mathematics said:

January 27, 2011 8:29:AM

I agree with all the myths you pointed out. But - isn't $125k enough for any person to live on? If they're going to be lazy on measuring productivity and pay you only the minimum to retain you, you can retaliate by getting the bare minimum done to not get fired in as quick a time as possible, and then heading off to the golf course.

Martin said:

January 27, 2011 4:06:PM

A sweet article.

But more emphasis should be put on the word 'quality' instead of productivity. You do not define productivity, but what a average coder imagines under productivity is plain number of lines written. Writing more difficult parts of systems, taking part in technical and architecture desicions instead of just copy pasting and writing well thought before code and proper testing is something very different. Also communication skills, and I do not mean those as being patient with customer, but inter developer communication is even harder to measure as a value as it is also about making other guys' lifes easier and enhancing productivity of your hole team or even the company, not just yourself.

I believe a good developer may often be recognized by solely him being able to think in these terms.

James Birchall said:

January 28, 2011 1:28:PM

From a business perspective, productivity is pretty easy to define:  profit / people / time

If the 10x programmer is, directly and individually, adding to the bottom line then it's easy to compensate them for their work.  Contractors and many software entrepreneurs get paid this way.  Most programmers, however, don't work alone and aren't competent enough at the other parts of the profit equation (logistics, sales, marketing, accounting, etc...) to make a go of it.  

If you work in an area where you can see the contribution (like sales), productivity is easy to measure and compensate (commission).  In a support area (like Logistics or Accounting) or a team area (like R&D), it's harder to see what's due to individual effects vs. collective effects (like the documentation + coder pairing described above).  In the latter case, you compensate the whole team with a share of the profit (profit sharing) so that people are encouraged to work together rather then at odds with each other.  Many software companies do this, though there's probably room for more individual reward (royalties from successful projects for instance).

As for measuring team productivity, they've got a metric in Hockey (yes, I'm Canadian) known as the plus/minus which measures the number of goals scored on the opposing team when the player is on the ice minus the goals scored on the player's own team during the same time period.  It's not unheard of for a star player to have a negative indicator for the team.  It's surprisingly accurate at capturing the mythical multipliers that affect team performance vs. individual performance.  

Hope this helps.

Post a Comment:

 
 

Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he consults to a broad range of industries, teaches seminars, and oversees Construx’s software development practices. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds.

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His books twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year.

Steve has served as Editor in Chief of IEEE Software magazine, on the Panel of Experts of the SWEBOK project, and as Chair of the IEEE Computer Society’s Professional Practices Committee.

Steve received a Bachelor’s degree from Whitman College, graduating Magna Cum Laud, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve