Tyler Cowen asks why pay differentials in software development do not reflect the large differences in productivity across developers. James Kwak gives what would have been my answer.
the way salaries are set at companies. At a high level, they are set by management teams, headed by a CEO (who is rarely a former developer), and supervised by a board of directors. The people making these decisions do not understand the nature of software development
The challenge in an organization is to link business knowledge with software development skills. Pure coding ability is not useful if it is employed on a bad idea. Tyler’s example of a good developer is someone with business knowledge. So, if the suits do not understand what geeks do, that is problem. But if the geeks do not understand the business, that is a problem as well.
One is tempted to demand that CEO’s be experts in everything. We have seen what happens if bank CEO’s do not really understand mortgage security valuation. If they do not understand software development, they can really mess up there as well.
It is not possible for CEO’s of large organizations to have enough knowledge to oversee every aspect of the organization. Either they have to be really good at subdividing responsibility or they need to limit the scope of their businesses. Limiting scope requires humility, a trait that is not selected for in the process of filtering business executives.
READER COMMENTS
SydB
Dec 26 2009 at 6:34pm
Certainly performance standards different across companies, but I can confirm that in many top-notch software companies the performance evaluations are based directly upon a 360 degree view of the programmer and his/her productivity, reviews performed by manager-peers, these performance rankings/numbers are directly input into raise and bonus calculations, and over time the top notch programmers find themselves making significantly more than those with less abilities.
Marcus
Dec 26 2009 at 7:02pm
What metric would you use to make pay match productivity? I think the problem is a lot harder than CEO’s not understanding it.
You can’t simply pay a programmer on the amount of code they write because most of the time, shorter more concise code is better code than longer more convoluted code.
Plus, not all programmers are writing new code. Many, if not most of them, are maintaining old code. Here you might be tempted to count the number of bugs a programmer fixes. But some bugs are much more difficult solve than other bugs. Some bugs reveal a fundamental flaw in the very design of the software requiring a major component to be revamped and other bugs may be a simple one line change.
So I don’t think either of these metrics are useful.
In my experience with working with programmers (and being one myself) is there are some programmers who are your ‘go to’ programmers. They’re the ones you give a problem to and it comes back solved, period. Then there are the programmers you have to spoon feed. They’re the ones you have to sit down with and guide through the entire process of whatever problem you’ve given them.
So, perhaps, one useful measure is how much of their team lead’s time they consume.
Prakhar Goel
Dec 26 2009 at 7:20pm
There is another big problem with limiting the scope of companies.
Current US tax law effectively penalizes dividends. Thus the only other option is for companies to keep their profits. Letting these sit around would be criminally wasteful and therefore the profits must be reinvested in the business. However, there is only so much money that can be invested efficiently before the scope of the investment must be expanded. Thus, US tax law effectively encourages the growth of megacorps.
PS. Obviously this analysis is not complete. There are quite a few factors which contribute to the growth of large companies not the least of which is economies of scale etc… However, tax law does, IMO, play a significant (and detrimental) part.
Bill S
Dec 26 2009 at 7:29pm
Robert Frank has written about this general topic in his work on “the winner-take-all society:”
“Personnel textbooks have long emphasized, and even economists have recently begun to understand, that powerful social forces militate against conspicuous pay inequality among people who work closely together. Indeed, private firms routinely employ pay formulas based on easily measured characteristics like age, training, and experience, even when those formulas yield pay differences that sharply understate observable differences in productivity. Reward for performance in the private sector shows up less as differences in pay between individuals in a given work group than as differences in the rate at which people are promoted.”
http://www.prospect.org/cs/articles?article=talent_and_the_winnertakeall_society
These “powerful social forces” are reflected in studies of chimpanzees who are willing to perform work if they are rewarded with cucumbers, but then go on strike if they see another chimpanzee being rewarded for similar work with grapes.
http://blog.buzzflash.com/alerts/597
As labor economist and former Secretary of U.S. Labor John Dunlop liked to say, “the labor market is not a bourse.”
tim
Dec 26 2009 at 7:49pm
I disagree with the “answer”. Most CEO’s know very well what software development is and its role. And I would also second the comment that the majority of software developers aren’t writing new code – they are just maintaining or incrementally improving existing code. So wouldn’t that throw off pay statistics in this given area? As someone who works in IT – I always looked at software development as a commodity so i expect pay scales to be pretty static. Which is why I got out of software development a decade ago.
David S.
Dec 26 2009 at 10:01pm
Since I actually manage software development for a medium-sized ($15M/yr) line of business, I think I know something about this (or else I’m the idiot that they’re complaining about).
We do pay our top software engineers about twice what we pay our ordinary software engineers. We also give them all the best projects (best meaning most difficult and interesting). We never have them doing boring tasks like code maintenance.
Our ordinary software engineers often have to do tasks that they don’t especially enjoy doing, so they have value beyond what a strict comparison of theoretical productivity would indicate. The work needs to be done, and we’re not going to ask our top people to do it.
Below-average software engineers are sent to QA or documentation. This probably explains why documentation isn’t that good.
Many top-notch software developers go off and do start-ups for stock options and potentially make many times what other developers make. I suspect the pay statistics may not fully reflect this effect.
Dan Hill
Dec 27 2009 at 12:29pm
“It is not possible for CEO’s of large organizations to have enough knowledge to oversee every aspect of the organization.”
Well he better understand what matters. And if he’s in the software business or any business where software is a differentiator, the CEO better understand what makes the software development process tick, including knowing how to identify and reward developer talent. Do you think Jeff Bezos at Amazon doesn’t understand this – that his IT shop is full of mediocre programmers being paid the same as gun programmers? I don’t think so. But I’d bet the CEO at Barnes and Noble whose online efforts have been dismal wouldn’t know a gun programmer from a donkey.
Dave
Dec 27 2009 at 6:20pm
Like Bill S, I was also going to mention Robert Frank on this matter. His opinion is that the more productive workers basically subsidize the less productive ones in return for status in the workplace.
Brent Buckner
Dec 27 2009 at 6:55pm
Per David S., Bill S., and Dave, I point you to Robert Frank on status, but specifically _Choosing the Right Pond_.
Robert Johnson
Dec 28 2009 at 9:54am
Prakhar,
That’s fascinating! I’ve been wondering recently about exactly this question, why do companies diversify away from their core competency. I think there was a post on this blog some months ago about the pin factory and why it does or doesn’t incorporate upstream into steel-making, or downstream into sales and distribution…or sideways into automobile manufacturing.
Where can I read more about this question? Do you have a blog or can you recommend some reading?
Colin k
Dec 28 2009 at 10:53am
Let’s not forget that developers and salespeople (where compensation is explicitly linked to performance) are often polar opposites in personality terms. Considering the degree to which developers are borderline autistic nonconformists, the surprise might be that they are relatively well paid as a group to begin with.
The big issue for me is that the value of a coder is really a matter of enterprise value. A rockstar programmer can build a product no one wants. Conversely, a rockstar salesman can blow away his quota at a weak company with a bad product. His enterprise value is quite high.
For programmers who are not too risk-averse, the easy way to obtaining more of the goodwill they generate is to start their own company. As this is so easy now, I am inclined to believe that programmers who tolerate the inequities of corporate salaries do so because they valuethe stability much more.
Scott Wood
Dec 28 2009 at 1:14pm
If Cook is right about the ease with which programmer productivity is measured, and the top programmers are 10x more productive than the median while being paid only 20% more, then a he’ll of a profit opportunity is being left on the sidewalk.
Simon K
Dec 28 2009 at 3:11pm
The measurement problem goes way beyond managers not understanding development. There simply is no good quantitative measure of developer productivity, and the problem is probably not even tractable. Real software development is intensely team based, and the product is mostly organisational knowledge – the actual code is almost a side effect.
That to one side, programmers are also basically journeymen – they’re selling their skills, those skills are tied up in their heads, and they constantly refine their skills when they’re working. So a lot of the value created during software development is tied up in the developers heads and (while they try) the organisation can’t realistically assert ownership over it. So it makes sense that a lot of “compensation” is non-monetary and dependent on staying with the orgnisation, in the form of good hours, control over your time, getting the best projects and (in extreme cases like google) free food, laundary, car services and cellphones. By a similar note, deferred compensation is usually stock and not bonuses, because ultimately you want to align developers interests with the organisation as with executives, rather than with the annual bottom line like sales and support staff.
Thomas
Dec 29 2009 at 8:23pm
The focus on comparison with the fairly simple structure of sales commissions is probably limiting the discussion. Companies already use accounting and balanced scorecard to get a more sophisticated picture of their own performance than revenue. Likewise, sports teams manage to rank the talent even though any single player cannot win a game on their own. And consultants, partners, traders, etc., manage to get widely variable bonuses and so on even though their work is often a team effort and even though they retain the knowledge they generate. In short, the problem shouldn’t be entirely intractable.
Perhaps we’re just looking at it the wrong way. For instance, is it meaningful to ask about a single, linear measure of “productivity” for this kind of work? If not, what factors drive such a metric and how do we measure them?
Or perhaps we’re just not making much of an effort to judge performance? It might in this vein be interesting to let clever statisticians loose on the problem before declaring it insoluble.
Dan Weber
Dec 30 2009 at 12:36pm
t might in this vein be interesting to let clever statisticians loose on the problem before declaring it insoluble.
You think people haven’t been trying to measure developer performance?
You can have a general distinction of who your really good programmers are, but among them it will be nearly impossible to really measure who is significantly better. The team members will have different skills, and they will teach other. If you are weak in database skills, another teammate will cover for you. If you are weak in UI design, you will learn from your teammate.
Development teams seem to have a life of about 5 years. At a certain point the developers aren’t learning new things, and they go some place where they will.
Being the smartest software developer in a company is a bad position to be in, career-wise.
Comments are closed.