How should software developers be paid? – By the line?

The success of any software development organisation depends on balancing a whole range of factors from the skill sets through tool sets to the way in which everything is managed. Over the past few weeks, you had your say on a lot of this stuff in the reader workshop we’ve been running.

One of the sentiments that has emerged is the view that there needs to be a bit of give and take between those running the show and individual developers. No developer wants to work in a completely locked down environment in which they have little freedom to optimise they way they work and exercise a little creativity. On the other hand, the general consensus is that there needs to be some consistency in terms of process, approach, standards and tooling, otherwise collaborative team working is undermined, productivity suffers, and what’s ultimately delivered is more difficult and expensive to maintain.

One way of achieving balance is to define policies and procedures laying out the way things should be done, making it clear where developers are allowed some freedom and where they are expected to toe the line. But the challenge is that you can never be exhaustive in terms of the rules you lay down, and developers will always find ways of working around constraints that they cannot see the point of or simply don’t like. Then what do you do – discipline them or dock their pay?

While threatening to beat people with the metaphorical stick if they don’t comply might work in some circumstances, encouraging the desired behaviour in other professions tends to be achieved through the offering of rewards for results achieved. The most obvious here is the paying of commission to salespeople or bonuses to managers who meet the business objectives they have been charged with achieving.

Common though it is, however, this kind of approach doesn’t always work. The recently highlighted disparity between performance bonuses paid by banks to senior executives in the months, sometimes weeks, immediately prior to the business imploding is perhaps the most prominent example of ineffective reward systems currently. On a more mundane level, most of us at one time or another have probably been a victim of call centre agents who are clearly targeted on the number of cases closed, rather than problems solved or customers satisfied. The point is that reward systems only work if they are based on the right measures.

Coming back to software development, it is interesting to consider whether remunerating developers on behaviour or results might be a way of encouraging that all important balance and driving overall performance of teams and projects. But if you go down this route, what would bonuses or other reward schemes be based on? Raw productivity measures such as lines of code cut or time to produce a deliverable are dangerous unless quality is taken into account. Then what about the guy who sits there thinking or experimenting for ages without actually producing anything, then suddenly produces one of the most creative, elegant or efficient solutions to a problem that exceeds all expectations?

We would be really interested in your views and experiences in this area. Does your organisation pay developers bonuses? If so, what are they based on and do they work at an individual, team, department or overall company level? More importantly, do you think the scheme is effective? And if developers in your organisation simply receive a flat salary at the moment, what are your views on if and how a developer reward scheme might be applicable?