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

Ben Tilly said:

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:

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:

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:

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:

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:

@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:

@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:

@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:

@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:

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:

@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:

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:

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:

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:

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:

@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:

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:

@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:

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:

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:

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:

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:

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.