This conversation seems to keep coming up – “how do we give software engineers (in the widest sense – DevOps, QA, etc.) a career ladder that allows them to progress, and keep up with market pay rates?”. A friend recently asked for advice – his team was consistently being raided by better-paying companies, but his HR policy had pay scales linked to seniority, and he couldn’t match the higher pay even if he wanted to.
The other common problem is that hands-on engineers often reach a pay ceiling, and feel they have to turn to “management” to earn more money in the same company. Especially in organisations where software development is not (considered to be) a core competency, there’s often a fairly low ceiling on earnings for technical people.
And of course, many people like to see their career progression reflected in a better job title, additional perks, and/or greater authority . They rightly consider the right job title to be a springboard to new jobs in the future – a CV with impressive job titles opens more doors.
There are lots of ways to address this problem. Construx have a very detailed professional development ladder – but they all end up taking you away from the hands-on work and into “management” roles. I quite like the Shuttl model – it shows a divergence between “people and projects” (traditionally associated with management roles), and “systems and services”. This allows people to progress up to the highest levels (VP Engineering and CTO) via either track. However, if salary and other benefit levels are coupled to the ladder, you risk losing people because the market for their skill is hot.
The way I’ve addressed this question in the past is to have a consistent ladder in terms of job titles; the job title reflects the degree of authority and autonomy an individual has.
|Associate||Works under supervision. Follows guidelines and processes already defined|
|Senior||Works independently. Follows guidelines and processes, and helps to improve them.|
|Lead||Can take team-level (5-15 people) decisions. Selects guidelines and processes from agreed list, or works to define new ones|
|Principal||Can take group-level (up to around 50 people) decisions. Defines selection criteria for guidelines and processes|
|Director||Can take department (up to around 300 people) decisions.|
|Chief||Can take organisation-level decisions.|
Within each discipline, those levels have their own skill and experience level expectations. A “discipline” might be “mobile development”, “back-end development”, “QA”, “business analysis”, “delivery lead” etc. Not every organisation will need the full ladder of roles – but it’s better to be honest about that fact, rather than suggest you can work your way up to Chief QA Engineer (for instance).
An unexpected benefit was that it allowed us to reflect realistic expectations of experience – new languages, frameworks and processes are introduced all the time, and insisting on 6 years experience in a brand new framework was obviously ridiculous.
When we introduced this, there was a fair amount of pushback – some individuals felt they matched higher levels in the ladder, others felt the ladder did not recognize their combination of skills. But by bringing it back to the level of authority and autonomy, we could have reasonable conversations. “So, you think you’re a principal software engineer – can you give us some examples of where you’ve taken group-level decisions on software engineering?”.
We then made the salary bands pretty wide – especially at the “associate”, “senior” and “lead” levels, and we varied the salary bands to reflect market pay rates (we paid a consulting firm to provide benchmarks).
It wasn’t perfect – some people really wanted a better job title, and felt that the ladder didn’t provide the flexibility they wanted. Others (rightly) felt the opportunity to demonstrate wider decision making experience was lacking, so they got stuck at their current level for too long.
But the benefits were clear – we had a simple, flexible way to define levels of seniority, and it was easy to communicate. It allowed us to distinguish pay based on what the market was looking for, and we could explain to the rest of the business that we had independent confirmation that mobile developers _really_ were paid that much.