Tyler Cowen asks why pay across software programmers is not more unequal. He cites John Cook, who argues that differences in programmer productivity are difficult to identify and measure. Since I do know something about this (though not a comprehensive answer), I thought I would comment.
Cook contrasts programmers to salespeople: “In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others.” Although this is the most-cited example around (except perhaps for traders), I don’t actually think it’s true.
OK, I’ll concede that sales are easy to measure. But I won’t concede that sales bear more than a loose and passing relationship to sales productivity (unless you make the circular definition of sales productivity as sales). I’ve been a part of dozens of major, high-dollar sales efforts, and there are many, many factors other than how “good” the sales rep is: the sales consultants (pre-sales, sales engineers, application engineers, whatever you call them) involved; how happy the customer is with previous products from the same company; executive involvement; random personality fit; recommendations by industry analysts (who are primed by marketing); the user group meeting; and on and on. If you simply reward successful sales, you end up rewarding people who are the best at monopolizing the best sales consultants and the best at getting top executives to come along on their deals; is that really what you want? And of course, by far the biggest factor in any big deal is luck. In enterprise software, where the deals are so big and so few that a salesperson can make his or her quota with one big deal, luck trumps everything. So yes, some salespeople are better than others, but in a given year that may have no relationship to how much they get paid.
That said, most companies do pay salespeople on commission anyway, because they can’t think of another way to do it, and the salespeople want it that way. In addition, the people in charge of most companies, at least technology companies, came up on the sales side, so they are disinclined to realize that a lot of their success was due to luck, and they are inclined to keep the same metrics that they succeeded on.
Turning back to programmers, there are a lot of reasons why differences in pay don’t match differences in ability. One is that most programs of any significance are written by teams, and the productivity of a team is to some extent limited by the productivity of its least-productive member. Another problem is that quality of code is very hard to measure up front; you really don’t know how good any component is until it’s been used by real customers in lots of ways you didn’t anticipate it being used.
That said, if you walk around any good development team and ask who the superstars are, you’ll find out that people really do know who the great programmers are. So why don’t the top people make more?
Well, to some extent they do. Although pay for employees of, say, Oracle goes pretty much by seniority and responsibility (like for most jobs), there is also a big market for independent contractors, who typically get paid much more (per hour) than employees. Second, as Cook says, “Someone who is 10x more productive than his colleagues is likely to leave, either to work with other very talented programmers or to start his own business.” There are many software programmers in the world; some do maintenance for decades-old internal systems at midsized manufacturing companies in the Midwest and some work for Google or Microsoft. The latter make a lot more than the former. Finally, historically in Silicon Valley the most sought-after jobs were not the ones with the highest salaries; they were the jobs at new hot startups, where you could get a non-trivial amount of equity as an early employee. I assure you, those jobs do not go to mediocre programmers.
But still, within a given “hot startup,” differences in pay do not fully reflect differences in ability. And I think the reasons are more sociological, or cultural, than anything else. (As I said above, not only do I think it would be easy to identify the top programmers on a given team, generally it would be completely uncontroversial who those people are.) One factor is that major pay discrepancies can have a corrosive effect on a team of people who have to work together. Most sales departments, by contrast, have such a strong individualist ethos that it’s assumed from the beginning that everyone is in it for himself, so there is nothing to corrode. In this sense, software programming is like almost every other job other than sales or trading; pay differences don’t reflect differences in ability, because the social convention is for them not to.
Another factor that is probably more important is 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, and are often prone to idiotic ideas like thinking that you can ship a product in half the time if you have twice as many people. My observation is that top executives, for all they say about the importance of people, revert to a bean-counter mentality when it comes time to deciding how much to pay those people.
Now, there are some companies that go out of their way to pay top developers more than they would make on the open market. But they don’t have to pay them very much more, because there aren’t very many of those companies. The market price is set by companies run by bean-counters, who are like the famous “noise traders” of Larry Summers, Brad DeLong, Fischer Black, and others. So a developer who is 10x as productive as the average will make 20% more than average and probably be content, because he or she doesn’t expect to make 10x the average and is happy to be recognized. If not, he or she can go be a hired gun.
This is neither an elegant nor a complete explanation, but I think it’s pretty realistic.
***
I am hoping to take a break from the Internet from Friday through Monday, so I won’t be blogging again until Tuesday (unless something compelling comes up). Happy holidays to all.
By James Kwak
The Baseline Scenario 
The model in Robert Frank’s book “Choosing the Right Pond” uses status to explain the gap. The star may be underpaid, but if star left to work at a firm full of stars the star wouldn’t be the star anymore. The star is paid part in money, part in status.
Well at last something I know a little about! In that, I started as a salesman in 1965 and until I ‘retired’ in 2008 have called myself a business-to-business salesman for all of those years.
Thus I do take issue with a number of the points you raise, James.
1. Sales success has a very tight relationship with sales productivity because the successful salesperson knows that time management is crucial and thus being more productive in terms of time spent on the ‘steps of the sale’ does make a major difference.
2. Of course, many, many factors influence whether or not a ‘suspect’ becomes a ‘prospect’ but the pro salesperson can have a huge influence on the outcome – with the premise of course that the salesperson has a ‘solution’ that meets the client’s ‘needs’.
3. Selling is a ‘numbers’ game in a way that I can’t imagine programming is.
Season’s greetings to all and a big thank you to a year’s fascinating reading of this Blog.
What, I wonder, will 2010 bring?
I’ve worked in software development in the corporate world for many years and your analysis is right-on. Many programmers like the security, perks, and team focus in the corporate environment. Those that want something else can pursue other opportunities, as you describe.
I don’t know anything about this topic. All I know is, somewhere around 1983-84 I wish I had been studying DOS in grade school. I respect programmers, and I despise salesmen’s guts. That’s about it…..
The point about teams (within the corporate settings) is the most valid. For the most part, there are not any 10x more productive programmers in terms of code output. What you find is that the quality of code produced has fewer fewer bugs, although that is open to debate. Some companies which are venture backed churn out product very quickly, just to see if there is any market acceptance. If not, the funding gets pulled on the company .. so the code quality of all the programmers is lower than it might be in a more mature corporate setting.
Really good programmers tend to go “solo” (contract), and their salaries are higher (but they generally don’t get stock options). So, if one were to look at salaries of contract and employee programmers, then the differences begin to appear.
Writing as a professional programmer: great analysis. As an armchair economist: the marginal value of labor is set by the employer, not the employee.
That’s very strong. I mean the piece about salesmen’s innards!
Care to elucidate?
P.
Great article!
One thing I disagree with here is that a team’s productivity is limited by it’s least productive member. I have found that in healthy programming teams the more productive members tend to route around (to use a networking metaphor) the least productive members (e.g. the less-productive members are assigned less-critical stuff) to avoid having them be a bottleneck.
I am thankful, each and every day, that I am neither a salesman nor a programmer.
Just a general bias. Stop, you’re gonna crack me up dude.
I’m not criticizing, this is a good post, but you know it never ceases to amaze me how bloggers choose their posts. A huge hurdle on healthcare was passed this morning, you have a lot of great work by Gretchen Morgenson over at NYT in today’s paper, and we’re talking about computer programming and ineffectually b__ch slapping Bernanke for the millionth time. I guess it’s Christmas and Johnson and Kwak work harder in a day than I probably do in a year, so I should keep my big mouth shut.
Aren’t wealthy, successful software engineers high-paid consultants or business owners, rather than salaried employees?
Besides, if the people who make the world work got the money, Dennis Ritchie (operating systems), the Sutherland brothers (graphics), Grace Murray Hopper (programming languages), and so on would be the rich ones, and Bill Gates would be a successful salesman. There is a huge problem of revenue capture in software development, and it’s so bad that a lot of us just give work away rather than worry about it.
…who else here has heard of the Sutherland brothers?
the thing is, being 10x better at programming or whatever your job is does not make you 10x more productive as an employee.
or something like that. what am i actually trying to say?
you think ESCC due for a january effect bounce?
It’s really quite simple…because you don’t have to.
very true. been doing programming for long time. never noticed that they paid more for more productivity but they pay more for what you know or can do. old days they just wanted projects done. didn’t care how well so much. today still want projects done. got to be right the first time (but that secondary to getting it done on time). then they added the cost factor to it. then we added project management to improve productivity. now today’s code is normally much more complex than it was in the past. but now you get to compete with those in other countries!
I have run several large software teams. There are programmers who are 10x as productive, but usually not with someone else on the same team. Teams would not stand for that. But a Google hot shot is much more than 10x better and faster than a starting programmer in a non software business in china. Starting engineers is China and India make $1000 a month, and Google pays some of their principal and distinguished engineers as much as top surgeons.
Large software in a corporate environment is full of a lot of molasses, because consensus decisions are required for the benefit of the larger teams. Over time there are better standard interfaces and standard approaches which require less consensus (think of the wide use of the 2×4 in structures as a way to empower the carpenter). This necessarily is an equalizer for programmers. Companies respond by either always hiring the best(Google and others) and paying for them, or always hiring the mediocre or always hiring the beginners. A lot depends on their technology goals.
I have recently been working with a Chinese company on modifying software in a commodity medical product. I have spent close to 40 hours on the phone with various people over 200 lines of free standing software. There are people in start ups spitting out 1000 lines of production code a day.
All of the truly superb developers I have known have either found happiness with good pay and a great group, or have built businesses. None of them feel like gears in a machine. Which is saying a lot in our world.
Hee. But see also 1, 2, 3.
Programmers would be better paid by learning to create synthetic CDO’s.
Interesting article in the NYTimes.
“But Goldman and other firms eventually used the C.D.O.’s to place unusually large negative bets that were not mainly for hedging purposes, and investors and industry experts say that put the firms at odds with their own clients’ interests.”
“The simultaneous selling of securities to customers and shorting them because they believed they were going to default is the most cynical use of credit information that I have ever seen,” said Sylvain R. Raynes, an expert in structured finance at R & R Consulting in New York. “When you buy protection against an event that you have a hand in causing, you are buying fire insurance on someone else’s house and then committing arson.”
Today’s code is more complex? We made it to the moon with full simulation on computers that had about as much computing power as your watch.
Money is generally not the prime motivating factor for programmers, where it is for salesmen. Most all stars will sacrifice money for interesting challenges. I found over the years that the programmers who chased the money were often the weakest – they would stay for 2 years, learn very little, greatly exaggerate their resumes and move on.
Sales people are sales people. Programmers are merely entities in the corporate human capital pool.
As far as I’m concerned the only reason star programmers don’t get paid 10x more is because there is no objective way to measure their contributions. Albert Pujols gets the big bucks because you can look at the numbers, and say, yeah, he produces. Albert can bring those numbers to negotiations with his current and prospective employers. I would bet that companies run by engineers — where management *knows* a good programmer when they see one — have much greater salary variation than in those run by MBAs.
Except. as you didn’t note, going independent isn’t always possible in a world where some people may not be able to get health insurance without a big corporation.
I had pneumonia a few years back, and even with health insurance, the copays nearly bankrupted me, without insurance would be insolvent, and I know I can’t get insurance as an individual. So, even though I was one of those “super-star” programmers, the contracting option isn’t an option.
That said, the story about start-ups is interesting; I noticed that the dot com crash had an unusual effect in Silicon Valley. Start-ups attracted many of the best and brightest. Some were highly successful. Some were unlucky. When the crash happened, the unemployment then fell disproportionately on those who went to the startups, who were disproportionately the better software engineers. For a period of time from about 2002-2006, I felt that the median quality of engineer had dropped significantly, and yet there were many good engineers who lost jobs at unsuccessful startups who couldn’t find work.
Recessions historically culled from the lower performers on average, the dot com crash culled from the higher performers.
excellent comment.
sometimes really good programmers get paid very well to do something else, like, as you said, build companies.
James Kwak
In most sales organization the top producers are the same people year after year so I guess that they are consistently lucky. Sales managers recognize this and work hard to recruit those lucky souls. Amazingly. their streak of luck continues at their new company.
Until you define “productivity” as it applies to programmers your claim that some are 10x more productive than others is all hot air. Can you cite a case where a 10x programmer left a company which replaced him/her with ten ordinary programmers? If there are 10x productive programmers, why isn’t a company willing to pay 2x salary to fill its cubicles with these valuable people? It’s either because there are no 10x programmers or nobody has yet found a way to quantify programmer productivity — which is beyond reason.
In capitalism, a person’s compensation is directly related to how much money you move through your hands. That is how salesmen are measured, how traders are compensated, even how senior executives are paid. Unfortunately, programmers can’t be measured in such way. (Maybe a closer scenario is how many clicks your website receives.) To a large part, programmers are high-paid manufacturing labors. They don’t touch money, so of course, their pay is just average salary.
I hear Marx laughing off stage.
“Until you define “productivity” as it applies to programmers your claim that some are 10x more productive than others is all hot air. Can you cite a case where a 10x programmer left a company which replaced him/her with ten ordinary programmers?”
Riddle: If it takes one man one day to dig a ditch, how long does it take ten men?
Answer: Probably forever.
;)
James, on the off chance you’re not already familiar with this set of arguments, check it out.
There’s another characteristic of these “highly-productive” programmers that’s only sort of been touched on. I’ve worked in the field for nearly 20 years, and nearly without exception the superstar programmers share one particularly irritating characteristic – they love to move on to greener pastures when their work is about half done. This leaves a bunch of “less productive” folks to spend the bulk of their time cleaning up the mess left behind and doing the other work necessary to actually ship the product. Superstar programmers who will actually stick around to finish a job do exist, but they are very, very rare. Those are the guys that can demand a multiple of the average salary and get it, and in fact their peers typically won’t have any problem with that. The rest of the time, your superstar programmer actually achieves some goodly portion of his/her 10x productivity by making everyone else on the team *less* productive, and trust me, the less productive people are painfully aware of it.
I have been programming for over 20 years, most of them in small startups. My pay is well below my peak which was in SF during the dot com boom. But I am well paid. I work at home 3 days a week, I am working with some really good people in a startup that is profitable and growing (how rare is that!). My boss and his boss are the best I have ever worked for. I still need to work but my house is paid for, my SEP IRA is fully funded, (if I could get to the money without a penalty, I could retire today) and I have a nice sail boat. Life is good.
I could make a lot more money, I have done it before but I would have to go to the office every day and/or work in place with thats not profitable which means layoffs are pending or more VC hell, and/or (much, much worse) deal with idiotic bosses. Been there done ALL of that.
There is more to compensation than salary. One of the things about being very very good at what you do is that you get to choose how you work. My income is average for a senior developer but you will never convince me that I am not ‘earning’ more than 10 x what some drone maintaining code at a large Dilbert corp is earning. Even if we are making the same salary.
well having worked on the old and new code I think i would know. and while the old machines were small if compared to todays, they didn’t have a need to be really complex
true i suspect. but as we have seen its doesn’t mean we have the best results from that do we? after all, those who made those large bets that caused this debacle made large incomes.
This is my clarion call to Mr. Johnson, Mr. Kwok et al.
It is time to step up!
Time to stop taking seriously ridiculous arguments about “too big-to-fail”.
Time to loudly, publicly, and consistently advocate for the return of Glass-Steagal.
Time to act more like Robert Skidelsky and less like Paul Krugman.
You know what to do!
Carthago delenda est
Very nice observation. I hadn’t considered these greener-pasture stars as stars at all, but I bet a lot of people in management do. The real stars I have worked with are almost unfailingly quiet, polite, and brilliant.
Not sure why Tyler Cowen stuck his foot in this one. There’s a pretty well developed literature on incentive structures, particularly in regards to measuring productivity, risk, and effort. Robert Gibbons at MIT Sloan has some fairly easy stuff to understand.
It is a common – and pretty serious – flaw to base incentive pay on final outcome. Ideally, one would link marginal incentive pay to marginal value of effort, but the latter is difficult to truly measure except in very narrow circumstances (e.g. Lincoln Electric).
Sales, it turns out, is NOT easy to measure (except over several years). There are by now dozens of case studies of failed incentive mechanisms causing all sorts of problems. Widespread gaming, for instance – cases in which salespeople accelerate deals to hit year end deadlines (even at the cost of heavy discounting or creating unbalanced workloads for the company) simply to hit high year end bonus marks. Cases in which salespeople promise stuff that can’t be delivered to close a deal, only to see the deal rebound badly later (after the bonus has kicked in).
Here’s a particularly egregious example: In many credit card companies, customer acquisition (a “sales” function) was handled by a completely different department than customer retention or risk management. Customer acquisition was rewarded by number of accounts acquired. Their reward mechanism was not tied to the default rate, or the % of cards that were never used, etc.
As to managing technical people – many managers believe that it’s critical that technical people not know how valuable they are. And many programmers believe its critical that managers never really know how hard or easy a problem really is.
So many economists who have never ventured beyond academia treat these sorts of problems as trivial nuisances that only modestly perturb their classical models. When, in fact, these information/complexity/incentive problems are central features of the landscape.
Speed,
I have seen “top sales people” shift companies, and bomb miserably, while others rebuild their numbers successfully. Many “top sales people” acquire that role due to a handful of clients (or even a single big client). When they leave a company, they may take contacts at that client with them, or they may not. Some top sales people in technical sales roles succeed because of their support team. Some build their own support teams and train them. And virtually all salespeople have good and bad years. In other words – there is such a thing as quality in a sales person, but it’s not nearly as easy to quantify as you indicate.
As to 10x programmers – yes, they exist. I know a few. I also know entire programming teams that have spent 18 months on an initiative, and delivered a mis-engineered piece of worthless junk.
As to why 10x programmers don’t get 2X salary – well, first they sometimes do. Second, even if they can prove their value internally, they may not be able to prove it externally (in which case they have no bargaining leverage). Third, workplace sociology. (Managers can’t pay a programmer more than they make, even if a manager knows a solo programmer is worth more than s/he is.
Echoed. But that frequently applies to sales people as well. Being a salesman (ex IBM) when I started my first company in 1986 was the best background I could imagine.
Hi Oldgal,
In fact, most of the top performing salespeople I have known have done it for the recognition, not the money. But, of course, the money is nice! ;-)
A common personality weakness/strength (take your pick) in successful salespeople is a lower self-worth than the average person. It’s that ‘need’ for others to recognise that you are successful that drives us to out perform. Probably applies to other professions as well but selling is the only one I know!
‘…are often prone to idiotic ideas like thinking that you can ship a product in half the time if you have twice as many people.’
A friend of mine referred to this as ‘the Mongolian Horde Theory of Software Development’. It is apparently quite common.
I maintean decades-old internal systems at a large manufacturing company in the Midwest currently, so I don’t have a lot insight into Silicon Valley practices, etc. But a friend of mine who worked at a software vendor, who was the first person who would work with customers after a sale was made, said that all of the salespeople on staff we’re surely going to hell because they misrepresented the product to such an extent that customers clearly had no concept of what they were actually buying. So perhaps you need to add ability to prevaricate into your analysis of sales compensation.
Having once been a tech supporting sales, you are dead on. Strange how I was always too busy to assist the sales people who used such practices. They would make the sale and the relationship with the company buying would end forever after the purchasing company tossed big bucks down the software black hole with poor results – the techs capable of delivering good product would avoid these salesmen like the plague. It would be much smarter to compensate the salesman on a royalty incentive rather than on the sale itself.
StatsGuy,
” … but it’s not nearly as easy to quantify as you indicate.”
I never indicated that it is easy to quantify. However, when a sales manager recruits experienced sales people he/she usually starts with those that have a documented record of success. Starts with.
“As to 10x programmers – yes, they exist.”
How do you define productivity as it applies to programmers? Taking one standard, lines of debugged documented code per day, and assuming that average productivity of successful experienced programmers is (pulling numbers out of thin air) 100 lines per day (+/- 20 lines per day SD) then your 10x programmer produces 1000 lines per day or 45 standard deviations above the mean. Surely you can see that the 10x programmer is more myth than reality.
” There are by now dozens of case studies of failed incentive mechanisms causing all sorts of problems.”
Are there any case studies of successful incentive mechanisms resulting in increased sales and customer satisfaction?
“Sales, it turns out, is NOT easy to measure (except over several years).”
Sales, it turns out, is supremely easy to measure. When the customer accepts the product and pays for it, a sale is made. FASB and GAAP include details for unusual situations and commissions can be held back as necessary and appropriate. Not everyone is selling credit cards, cell phones and no-document mortgages. Incentives to recognize bonus related year-end sales exist for all levels of management and most well run organizations with mature sales managers recognize the pitfalls of poorly designed and adminstered incentive plans.
An extreme example: People who sell corporate jets get paid when the jet is delivered — which may take several years due to development problems or long backlogs — not when the order is received. But when they get paid they get paid a lot.
I wouldn’t pretend to have the slightest expertise on this, but I would say that someone arguing the contra position would most likely say that some of the mitigating factors that you mentioned being unrelated to the sales skills of the salesmen would be presumed to be approximately equal amongst differing salesmen. For example, assuming a large enough group of customers, presumably the amount of potential clients who had bad experiences previously with the company or product would be about the same amongst two different salesmen. So that would be discounted as a facotr in the relative sales numbers.
Of course, there are a lot of caveats to that and that situation might not always hold true. But someone arguing for the relative merits of one salesmen over another would make that argument.
Yes, I second that, Keeth. The better programmers generally find a way to put the less productive, or destructive, programmers in a sand box where they can’t hurt anything or get in the way.
Some software managers have a rule of thumb about task duration estimates provided to them by programmers: always double them.
Some software developers have a rule of thumb about task duration estimates they provide to their managers: figure out how long it’s going to take (e.g. two days), increment the unit (e.g. days becomes weeks), and then double it (e.g. two weeks becomes four weeks).
And yet, software is always delivered late.
You’re utterly missing the point. Do you have any idea what programmers actually do? Measuring programmer productivity in terms of lines of code makes as much sense as judging the value of a blog posting or comment by its verbosity. Or a movie by its length.
A computer program is like a machine: you want it to run smoothly, not constantly breaking down, not prone to misfiring or malfunction (or explosion!), not constantly requiring costly repairs and labor-intensive babysitting. You want it to be robust, not held together with string and chewing gum and a prayer. Above all, you want it to actually do what it’s supposed to do. You don’t particularly care to count how many component parts it has, how many “lines of rivets” — in fact, fewer is often better. You want it to be well-designed and well-built. You want the designers, manufacturers, and the mechanics who perform routine maintenance to do high-quality work at a reasonable pace.
I worked as a programmer for a decade and was, well, adequately competent. I can think of at least one programmer who was ten times better than me. Last time I googled him, he was vice president of software development at a West Coast company you’ve certainly heard of.
anonymous,
Lots of words, no content.
How do you measure programmer productivity? Give me numbers and statistics not squishy feel-good warm and bubbly crap.
You say, “I can think of at least one programmer who was ten times better than me.” What makes you say ten times and not 11.5 times or three times? Show me the numbers. This is hard stuff but that doesn’t mean it’s OK to make things up.
Returning to James Kwak’s original post and the John Cook piece he references and my point … If you can’t define and quantify programmer productivity you can’t discuss disparities in compensation.
If you say that Bob (a programmer) is 10x as good at his job as John (a programmer) and therefore I should pay Bob 10x as much as John, then I say, “Show me the numbers.” So far I’ve seen no numbers.
There are companies which are changing this model. One of them is Topcoder.
And serious developers and managers don’t give or accept estimates of time to completion until a detailed specification and development plan (with uncertainties and risks) is complete.
Please correct me if I’m wrong.
If a programmer 1 can create the same results with half the code as programmer 2, doesn’t that mean that programmer 1 is twice as productive as programmer 2?
If so, lines of code is a perfectly lousy way of measuring a programmer’s productivity. In fact, it may be an inverse correlation that works best.
(Oversimplified, I realize, but I believe the underlying point is valid.)
Sales results, OTOH, are immediately obvious.
Also, I know that some companies tend to provide more support to the more successful salespeople. As you hit levels of production, you get preferential treatment on technical questions, back-office support, etc. Thus, if you have a good year, your chances of having another good year after that increases.
It’s simple to come up with a much better metric than nonsensical quantities like “lines of code per day” or “parentheses per line of code.” Take your best performer and an average performer. Given the same task, how long would you budget for each of them to complete it with the same level of quality? While I haven’t seen a 10x difference in one team, 5x is easily true with the teams I currently work with, and they have neither the best nor the worst people I’ve seen in industry.
This discussion seems to be divided between two groups: People who work in software and have no problem believing it, and people who do something else and are skeptical. The notion of a 5-10x faster programmer is not surprising once you’ve seen somebody struggle on a task for 2-3 weeks only to have it completely replaced by something your superstar did in parallel in 2 productive days.
I continue to ask for numbers, criteria, measures of productivity, furlongs per fortnight, ergs per cubic widget but all I get are stories. Where you say, ” … once you’ve seen somebody struggle on a task for 2-3 weeks … ” I hear you talking about someone that is not up to the task. Incompetent. You didn’t say, “once you’ve seen somebody make steady progress on a task for 2-3 weeks … ”
The only place I’ve consistently seen what might be an order of magnitude difference in ability is in early years engineering classes. Some were exceedingly slow. Others were brilliant and could instantly see problem solutions. But in the grand scheme of things school problems were almost trivial. And the exceedingly slow students never became professional engineers.
We are talking about measuring the marginal value of the salesperson to a company’s long term profits, and you are calling this easy?
Consider the following – if you took a “10X sales performer” and replaced that person with a 3X sales performer, would you see an immediate 3.3X drop in revenue?
What about a high sales performer who sells in a difficult line of work, but whose value is entirely incremental to the firm? Vs. another salesperson who is simply “tending the phones” in an established line of work?
Pay isn’t “different enough” because managers who weren’t themselves great programmers don’t know how to evaluate work product. And, so long as very few other companies hire away the best talent with appropriate pay, then most employers don’t have to actually compete on price.
To the extent possible, I will avoid working for an MBA/public/VC-run company again. My hope is that working for an engineer-owned/run company will be more satisfying.
“We are talking about measuring the marginal value of the salesperson to a company’s long term profits …”
That may be what you are talking about. I’m talking about measuring sales. Revenue. Dollars coming in the door. A 100% commission sales force is a cost accountant’s dream — all variable. And the best sales people want to be 100% commission because that maximizes their personal revenue.
A salesperson searches for leads; qualifies the leads converting them to prospects; presents the product; manages concerns; justifies the price; makes competitive comparisons; negotiates the price, terms and conditions; asks for the order; closes the sale and finally works to sell additional product to turn the new customer into a long term customer. If this person goes away and is not replaced the sales go away too.
A person who is “tending the phones” is not a sales person. He/She is an order taker.
In programming, there’s something called libraries, which is sets of known functions and procedures. The good, productive programmers have, among other skills, the ability to decompose the complex problem at hand to a tree of known ways (func-s and procs) and then use the libraries.
The productivities of programmers, with this definition of doing the same task for less time, is then a function of his knowledge, experience in the domain, and imagination.
When I studied at university, a group of 3 students do a task, and agree upon a decomposition of the job into 3 perceived to be equal parts (at the time of discussion) Later, one of them found a similar solution in a good book, wrote the code so short (<100 lines) and in 3 days, while the other two had to do somethings like 3000 lines of codes in a week at least. Tell me, who is the better one ?
In the end, it's the awareness of known precedents that counts in programming. You may be a good programmer at producing lines of codes, but that's not the true metric as many have pointed out. It's the solution that counts, and the way and time in which it's implemented.
I’ve been writing software for ~15 years and what you write rings true. Working with an offshore team in China, half my time is spent in review and gate keeping. And all the good people in our Chinese group eventually leave because their workload and pay is so crappy (even by Chinese standards).
Very good summary of the sales processes, or rather the ‘real’ sales processes not the crap that comes over the home phone uninvited in the evening.
My first years at IBM (Office Products Division in England) were 100% commission and, boy, it was great!
I have often talked about this pay gap over the past 20 years and I have been frustrated by it. It was definitely a contributing factor that caused me to start and sell my first consulting and software companies.
I find the idea “that most programs of any significance are written by teams” to be arguable. A team of two or three highly talented coders can launch a significant system and often do just that, then teams grow around that effort. I firmly believe a small but highly talented team of 2 or 3 can outperform a much larger team of average coders – superstars don’t just write better code, they see the problem more clearly, they design cleaner solutions, they manage ambiguity in the business gracefully, and they produce new intellectual property for the underlying business as well. It is rare for those latter skills to be fully compensated in a traditional business because it is rare for non-technical managers to comprehend their significance.
I am now writing a trading system by myself. The system suggests trades and it works beautifully – it is used by me and a few other traders and I am certain it outperforms many systems that have been written by large teams (consider how many “quant funds” exploded in 2008). Rather than try to find a firm and become part of a development team, I simply created the asset because I was confident that I could and I love the problem space. For “a coder” like me question of compensation/monetization often comes later.
Lighthouse, I couldn’t agree more. I’ve been “cutting code” for 30 years. I’ve seen it all. I’ve been on great teams and dysfunctional ones. I’ve been the alpha geek and just some guy in a cube. I love what I do. I have great flexibility in managing my time. I work with smart people. I am not wealthy by local standards, but I make more than 95% of my fellow citizens. I will be able to do this for as long as I want or until my brain gives out. I have no regrets.
Most of what you describe in the sales process is team work and luck. For example the presentation and the justification of the price is dependent on technical teams and managers who do the effort estimation for a project. The competitive comparisons will always be in your favour if you have a good product and vice versa.
I’ve been working as an ERP systems consultant for a few years now and I know exactly what I’m talking about because I often do pre-sales work. Whenever a new request for offers comes up I’m asked to estimate the scope of the project and the person-days required. That’s the largest part of the financial proposal. The system I currently work with is the best in the market and everyone knows that. It’s also the most expensive and everyone knows that too, yet it’s so good that it has a market share of about 40% internationally. Not very hard work for our salespersons to convince the customers for our competitive advantage.
Discovering leads and converting them to prospects is indeed a tricky part of the job, but again a salesperson is rarely alone in the task. Managers often play a significant role in creating leads. Also the people who actually do the work and the quality of the final outcome play a much more significant role in turning a new customer into a long term customer that a salesperson ever could. The negotiation is another important job but a bad negotiation may still result in a sale and often does: salespersons are notorious for selling complex projects far too cheap and dumping the responsibility for the forseeable failure to those who were assigned the impossible task of actually completing the work in too short deadlines.
Let me give you an example from my personal experience with an incompetent salesperson. I recently completed a six month project in two months by working weekends and 14 hours/day. I rarely do that anymore because I can estimate and manage my work quite well. The reason I had to do it was that the incompetent salesperson completely failed to realize that the company was a good prospect, although the general manager of that company was a personal friend of the CEO of our company(!). The result was that although the initial contact was made last spring the deal was made in September with no negotiations in between. Additionally, she didn’t ask me when she created the financial offer, resulting in a very low estimation of the overall effort required so I had to do about half the work from home. I managed to do my work and co-ordinate the (small) team into this impossible situation quite well, so well in fact that the project was successful and the financial director of the customer offered me a job (I didn’t take it). The salesperson who didn’t even try for this sale and managed to risk the project with her incompetence will get her commission. She did, after all, bring money to the company.
kyriakos,
If this sales person is incompetent, she should be fired. You, of course, told management about this situation.
If you are required to work for free (14 hour days and weekends) then you should get another job. Your company is cheating you.
The problem you describe is not one of paying sales people for sales but one of ineffective management and enabling support staff.
Speed,
It’s never that simple. She’s a personal friend of the unit manager so she could easily convince her that it was not her fault, she has done it many times in the past. She once went 3 years without bringing in a single contract. The sales manager was fired back then but she stayed. She’s also married to the general manager of a competitor and we get a lot of subcontracts from them lately. She’s successfull and makes a lot of money although she’s an incompetent idiot. Happens a lot in sales. Not likely in programming.
As for why I still work there, I do it because there’s not much point in leaving unless I go freelance, which is what i plan to do. I would have done it already but I’ll probably have to leave the country I live in and I can’t do it right now cause I have a 2 year old son and a pregnant wife.
It’s never simple.
I’ve written code/applications/systems that the client/contractor/consultant couldn’t deliver.
If you put 1 in the numerator and 0 in the denominator you get something more than 10X.
Some surgeons are 10x more effective than others–got a metric other than mortality?
Programming entry requirements have a negative threshold–that was a selling point at one time–yer bookkeeper Griselda can learn RPG in no time.
But you need to spend time in the dog lab if you’re going to be 10X better.
There’s more, but the margin is too narrow. . .
Sales is easy to measure only in the most incompetent sense, $. Sales goals are easily manipulated and gamed. Dishonesty and shady practices often the case and corruption often flows from the top. The trick is deceiving themselves into believing it is acceptable.
Hey Lord, some very sweeping comments there unless you are talking about some specific situations that you are familiar with. In which case, pray expand.
Otherwise, that is far to broad a generalisation to be true – well so far as my experiences have shown.