One of the most difficult aspects of line managing a team of developers in more established organisations is trying to change people’s salaries. Large established organisations tend to have an annual pay cycle, and changing pay outside of this cycle is a bureaucratic nightmare. Additionally, those organisations that aren’t naturally digital too often anticipate a salary increase in line with inflation (1% to 4%), which is almost always an inappropriate reflection of developers’ worth. The digital world moves quicker than annual cycles, and developers’ value often increase quickly.
Why do developers’ salaries increase at odd times? And why is inflation too often insufficient? One HR exec asked me this in a friendly conversation. Here was my view…
1. Developers’ worth increases fastest in the early stages of their careers
A developer’s value is not a gradual, flat, incline over the course of their career. As soon as they emerge from full time education and get exposure to real world problems, and work with colleagues with more experience than them, so their skill and capability increases dramatically. Consequently salary jumps that are multiples of our 1% to 4% rate of inflation should be a reasonable expectation for companies employing developers in the early stages of their career. (And they probably employed them in the early stage of their career because they looked relatively inexpensive and promising. Well, there are consequences…)
I’ve found plenty of developers to be 30% to 50% more valuable over the first 1-4 years of their career. Really good developers will be more so.
2. A good environment releases people’s value
People’s effectiveness is not just about their innate skills, and indeed some would say that’s a tiny part of the equation. I’ve certainly found that improving people’s environment and working practices makes them much more effective, much more valuable, and therefore gives them a much greater sense of their self-worth.
Software development is a discipline still in its infancy, and there is no single accepted way to structure such an environment which results in wonderful effectiveness. Therefore it’s somewhat common to find a team transformed in its effectiveness not through personnel changes, but through changes in working practices and environment.
One would hope that improving someone’s environment and job satisfaction would endear them to you, and would not result in them demanding more money. But it can’t be avoided that when someone’s true capability is found to be greater than what was previously assumed then at some point that has to be reflected in their remuneration.
3. Training people increases their value
Simply switching to a popular technology can increase developers’ value in the marketplace. A C++ developer is probably working in a relatively niche, established space, but by switching to the very sexy and not entirely dissimilar Objective C, the language of Apple iOS apps, they will suddenly increase their market desirability dramatically.
In the early days of any technology demand outstrips supply. It happened also in the early days of Java in the enterprise. If you are cross-training your own staff to fill a supply shortage in the market then factor in the consequences of giving them such a skill. Once again, one would hope they’d be grateful for the training. But don’t count on love and inflationary increments to be sufficient.
And it all happens out of sync
As frustrating as it may be to corporate natives, all this learning and change in the technology team happens entirely independently of any annual financial cycle. New joiners are more likely to come in at a level that reflects their skill and value (once they’ve got up to speed), but existing staff are too often neglected. As one said to me as he faced another inflation-only increase, “So, basically, I’m being penalised for loyalty”. Too often, that is the case.
niksilver.com 
Very logical Nik, but the same influences on ‘value’ can be applied to many other careers/professions from bricklaying to sales. The difference being that bricklayers and sales people get ‘incentivised’ on output. Perhaps developers would benefit from being rewarded in a similar way, on top of their basic salary?
Tony, bricklayers and salespeople have easily measured goals, and to some extent have a large amount of drudgework to be ‘incentivised’ through. How do you plan to measure the output of a single developer in a team? And how will you do that in a way that can’t be gamed?
That’s leaving aside the incredibly destructive way in which extrinsic incentives can harm productivity in knowledge workers, see e.g. Dan Pink’s work http://www.ted.com/talks/dan_pink_on_motivation.html or http://www.youtube.com/watch?v=u6XAPnuFjJc
Tony, I couldn’t comment on bricklayers or sales people, having not spent too much of my career employing and managing them. If there are similar arguments there then I’d be interested to hear them.
Overall I think people should be paid what they’re worth — I’m sure we’d both agree on that — I could not claim developers are special because I don’t know about all other professions. My point was to explain why annual 4% increments is too often far from appropriate for the kinds of people I know. If a company doesn’t factor that into their financial calculations, or if they can’t react accordingly when they learn it, then they are bound to lose their best talent sooner or later.
I also think there is a problem with incentivising people on output. Measuring the output of a developer is very difficult. As Tom says, if you’re a developer working in a team then how is your output measured? And at which point is your output considered valuable? When you send it for testing? When it passes testing? Only on the condition that the test users like it? When it’s released? After it’s released and starts earning money? Assuming your product’s value can be measured in that way. And if the product was badly conceived in the first place, are you penalised for having worked on it?
And here I do see the parallel there with sales people (and disagree with Tom). Sales people do have easily measured goals, and they’re too often the wrong ones. Technologists have too often been in situations when their company’s sales person, motivated by the target of a signed contract, sells something that’s difficult, impossible or very costly to deliver. Their goal was the wrong goal. In those situations, if their goal was further down the stream — a delivered product, or a paid invoice — then there would be better sales and happier customers. The point of their measured value moves downstream, but is more meaningful to the organisation.
I agree that salespeople often end up selling something that can’t be delivered or the wrong thing to a customer who will end up unhappy in order to hit the salespeople’s goals, Nik. I was just pointing out that developers don’t even goals (for better or worse) that are as easy to measure as the ones that Tony had mentioned.
@ewtom, indeed, easily-measured goals for developers are certainly missing. Apologies for misunderstanding you.
I suspect that easily-measured-but-wrong goals are probably more damaging to the organisation than no-easily-measured goals.
Right, because easily-measured-but-wrong goals encourage behaviour to satisfy the goal which is nonetheless negative overall. And this happens whether there are financial incentives attached to the goals or not.