It’s time to do my team’s annual salary review.
I have been given a chunk of money I can distribute through the team and it’s up to me how much each person actually gets. I’ve got a spreadsheet to fill out. Against everybody I have the basics you’d expect:
- Name
- Job title
- Current salary
If you’ve done this kind of thing before, or you’re thinking ahead, perhaps you’ve also guessed I have:
- Last year’s salary increase
- Number of years they’ve been employed
But I’ve also got some columns you might not have expected:
- “Normalized” job title. My “Head of Backend Applications” has become “Senior Software Developer” and my “Client-Side Developer” has become “Front-End Developer”
- Years of experience
- Market Salary‽
- A suggested pay rise based on how much under or over the Market Salary each person is
For each person in my team, someone has tried to work out what they should be getting paid based on our location, an approximated job title, and their years of experience!
Welcome to the world of salary benchmarking…
Salary is difficult
Companies have a dilemma.
If they offer too little money to current and future staff, those staff won’t accept the jobs, or will take jobs elsewhere. That’s pretty straight forward.
But if they offer too much money, it’s very difficult to reduce someone’s salary if they turn out not to be worth the premium price tag. What’s more, for every four developers they’re paying 25% more than the market rate, they’re not able to hire a fifth potential developer.
If they’re in a competitive market, then their competition can get more done at the same price. If they’re a company with shareholders, they open themselves up to challenge from those shareholders on why they’re paying their developers more than the market rate.
Companies may have a lot of reasons they decide they’re going to under or over pay. Perhaps they think working at the company or the perks they offer make up for a smaller salary, or perhaps their systems take a long time to learn and once someone’s on board they don’t want them tempted away with a larger paycheck elsewhere. But in either case, unless they know what the market rate for their people is, they can’t effectively do either.
A salary benchmark allows them to compare their staff to the market rate, and guide decisions about who should be getting paid more, or less.
Where the data comes from
There are a number of places companies can get this data. On the smallest scale, a company trying to fill a job may just ask their friendly local recruiter what kind of salary range they should be offering. Recruiters are incentivized to push that number upwards because they’ll get a bigger commission and the job will be easier to fill — there’s no downside to them if the company overpays!
Larger companies will buy the data from companies like Payscale, who allow them to specify all sorts of factors — educational attainment, skills, office location, auxilliary benefits like pension and healthcare — to find out how their staff rate against the market.
Very large companies may even have dedicated staff to do this, especially for more senior staff — a remuneration committee, or dedicated people in HR whose job it is to come up with benefits packages and salary bandings for different roles.
What you can do
Besides this process being simply interesting in its own right (to me, anyway), there’s an actionable point here as well for the developer who wants to get paid more.
The basic principle is: you want the salary benchmarking process to make it look like you’re currently underpaid, to encourage the levels of management above you to try and fix that, so you don’t get poached by another company.
The person creating the salary benchmarks probably doesn’t know you, and will be simply guessing on what job you’re actually doing based on your job title. Or maybe they do know you, and they’re searching a long list of job-titles they’ve never seen before from the salary benchmarking data. They have to take a guess on what exactly the “Widget Team Manager” or “Data Extraction Lead” maps to in the data they have.
So it’s worth making sure your job title adequately reflects your current seniority. Programmers often think that quibbling about titles is below them, but if you’re mostly doing architecture work, or you’re leading a team, or you’re one of the senior members of a team, having a job title that reflects that will make the magic Market Salary number higher.
Smaller companies will often be pretty flexible with job titles – as long as it’s not something ridiculously senior (most companies will only allow for one CTO, for example), adequately describes the work you do, and won’t cause too much resentment with your team mates, then it’s pretty reasonable for you to ask for a review of it.
Larger companies will have their own internal hierarchies or what constitutes a “Senior” or “Junior” developer. Are you familiar with what it’d take for you to get the next job title up? Not all managers are on the ball with career development, but if you start bringing this up at your one on one with your manager, you should at least get the ball rolling by eliciting what you’d need to do to move up.
Even larger companies may well have official internal levels: “Software Engineer Grade 3” and so on, and these will generally come with pay brackets attached. It’s reasonable and well within your rights for you to express to your manager that you’d like to move up to the next level, and for concrete steps you’d need to take to do so.
Job titles are more important than you think
The exact characters that comprise your job title can cause all sorts of unexpected effects on your salary range. Many developers consider them unimportant, or as I mentioned earlier think that thinking about them or discussing them too much is beneath them.
Most, however, are interested in being paid more for their existing work. Once you understand the processes involved it becomes easier to see which levers are available for you to pull to start getting paid more.
