Why Aren't We Paid Like Basketball Stars ... Essays Home
A discussion on software motivation and renumeration ...
One of the strongest findings that comes from "real-world" research into software development, is that is a difference between software people. In fact the difference in productivity can be significant, with not just 25% to 50% between star and also-ran, but many times the difference. But in general, we don't see a renumeration following a similar pattern. This essay explores why this might be so.
Super-stars and also-rans ...
One thing that "real-world" investigation teaches about software production, is that differences between people are very significant. Study after study has shown that some stars can develop software many times faster, with fewer errors, that people at the bottom end of the spectrum. Yet, in almost all cases that I know about, the reward system in medium to large companies does not reflect this established fact. We would expect that a basketbell star who scores five times the points per game than another player would get paid significantly more; but we don't expect that the programmer who writes five times the SLOC count to be paid five time the amount. I believe that I have some answers to this curious mismatch.
The first reason is the usual response to quality failures: failures in management. In basketball, it is clear to all (fans and coach alike) who was most effective in a game. Most software development management doesn't even bother to keep score! Management in general do not invest in any metrics collection effort that would answer the questions;
Even worse, some companies can't tell how much software was written, or by who.Who was the best estimator in the company?
Who was the best programmer (fastest, least errors)?
Who was the best tester?I think this is part of a wider problem, in that management in general are very reluctant to gather this type information for two reasons. It requires some up-front capital investment, and more importantly, it requires some commitment to use the information. Now of course, any sales oriented company knows who its best sales-people are, and rewards them accordingly. However, the culture that manages sales-people is very different to (and much realistic than) the culture that manages programmers and other technical staff.
Why Aren't We Paid Like Basketball Stars? ...
In the technical area, there seems to be a desire to push people into neat little categories, that are then used for reward purposes. This is the case even when companies have escaped the formal use of job titles like Engineer Grade 1, IT Grade 2, etc. Part of this might be that this approach minimises conflict, and saves on the management effort in identifying and rewarding "high flyers". It certainly makes life easier for the HR people, who can now align the pay rates in the technical area with those in other parts of the company.
It also makes life easier and more rewarding for managers if the company ethos is that rewards (pay, big offices, etc) go to the manager with the largest organisation chart. There is a sociological Iron Law that says that "Organisation equals Oligarchy". Even if there is lip service to a parallel reward structure for technical people, this will be administered by (of course) managers, and so we should not be surprised to see position within the management hierarchy consistently correlated with reward, while technical proficiency is weakly correlated with reward.
The other reason that might be advanced is "Of course, some people are five (or ten) times faster at programming than others, but they don't spend all their time programming". I suggest that is is also a response that indicates management failure. The reason they don't spend the bulk of their time doing what they do best, is surely because management has not structured their environment to best use their talents. Imagine the reaction to a coach that took his best player of of the game for significant periods to sit in innumerable pointless meetings, or to collect mail. Yet this is the usual approach that management takes to technical people.
Why Aren't We Paid Like Basketball Stars? ...
However, even in the entrenched opposition, market forces come into play. In Australia at least, the best employees do gain more renumeration than other, because they cease to become employees! The market rates for contractors (especially contractors with a good reputation) do seem to match the reality of prigramming ability. As might be expected, there is usually some opposition to the use of contractors: "They'll get paid more than our staff!", "The use of contractors will lead to unrest in our staff!", "We will become reliant upon them!". All these responses (while true) indicate a management failure in the usual management approach to technical staff.
In America, I suspect that venture capital start-ups also represent an alternative avenue for reward being aligned with contribution, but these are sadly largely absent from the Australian scene.
So what's a manager or programmer to do in the face of these facts:
First, managers and technical people should always be up-to-date with the latest industry awards rates (especially in the contracting game). Technical people should always have the option of going contracting ready at their finger-tips (private company set up ready, source of professional indemnity insurance costed, etc). Managers should refrain from recoiling in horror at realistic pay demands, or treating them as an attempt at blackmail. It always amuses me that managers who would delight in using market power over a customer, take it very personally when it happens to them.Managers should try to match reward to contribution. The worst system I have seen was to verbally promise that if a six year project came in ahead of budget (and it was bid low to get the business), then the people who had recorded the most (unpaid) over-time would be first in line for a bonus! I suggest that managers are almost always out of touch, and that reward should be based upon secret ballot of the front-line troops at no more than six montly intervals, seeking to get their opinion as to who has contributed most to the project.
© Don Cameron. www.net-analysis.com