A little while ago I came across this post on stack overflow asking about experience ‘levels’ in software development – https://workplace.stackexchange.com/questions/158329/how-exactly-experience-level-is-determined-in-software-industry
The asker was looking to apply to a company advertising multiple software developer jobs – junior, mid-level and senior and wasn’t sure which position was most suitable for them. Predictably, this being the internet and all, the replies got a little heated over whether the answer should be related to years in industry or in technical ability (which is one of the reasons I’m answering here rather than there). As is usually the case in these situations, both points of view are right, for a given value of ‘right’ and they’re also both wrong.
Yes, years experience counts in that it’s unlikely that someone who’s been working in the software industry for 10 years will still have the job title of ‘junior’ and equally you’re unlikely to have much success applying for a ‘senior’ role straight out of school. Yes again, technical ability counts. The demands and expectations on someone in a senior role will be significantly greater than those on someone in a junior role, both in technical ability (as in understanding of the languages and technologies used ) and in ‘soft skills’ (ability to work with stakeholders, take the lead on the direction of a project, support more junior team members etc). However, in the end, both of these are secondary factors – the most important factor is the perception that your (current or potential) employer has of you and your abilities.
What is a job title?
At the end of the day your job title is agreed by negotiation between you and your employer. A company might have a general idea of what, for them, constitutes a developer at various seniority levels (and that may be very different between companies), but so long as you can convince your employer that your job title should include ‘senior’, ‘lead’, ‘super-awesome’ or whatever you like, then regardless of how many years experience you have, or what your technical or soft skills are like, on paper that is your job title, and on paper is really the only place where it matters.
The reason companies even have these distinctions between experience levels is to help them group similar employees together for appraisal and remuneration purposes. It doesn’t make sense to compare the performance of a lead developer to a junior developer – the former should clearly be providing more business value than the other, even when comparing an exceptional junior to a mediocre lead. Comparing like-for-like is the only way to work out how well a given employee is performing and whether they require further support and training, or should be considered for recognition or reward. Grouping similar employees also allows the company to work out what the average salary for someone in the group is. This is useful when recruiting as they can see what sort of salary someone in that group will accept and, if a candidate supplies salary requirements, let them judge where in the group that would put them (or whether it would put them in a different group entirely!). It’s also useful when reviewing existing employee salaries and working out whether to award pay rises. If an employee is performing towards the top of the group but being paid towards the bottom then the employer has much more incentive to raise their salary than if the reverse is true!
So this means that your level is based on the value you provide to the company? Well, kind of, but not necessarily. Imagine that a high performing junior developer has an appraisal and gets a promotion to mid-tier developer. Great! The system works. But perhaps there’s another junior developer in the team who isn’t performing as well and perhaps they’ve been at the company even longer than the first developer. The problem with job titles are they’re very public and that second developer will quickly notice that they’ve been passed over and won’t be happy. So should the company promote them too (possibly with a lesser corresponding pay rise) to avoid the potential team friction? Well that doesn’t seem very fair, but maybe that’s easier than risking inter-personal problems in the team. Perhaps even if they decide not to, a few days later developer 2 storms into their managers office and insists that they would be performing better if it wasn’t for the blatant favouritism that the company has always shown for developer 1. Now what do they do?
Next imagine this – that exceptional junior is, instead, working for a manager who’s a bit of a cheapskate and doesn’t want to give them the corresponding pay rise that comes with the promotion. The junior doesn’t want to risk leaving or causing a fuss and so stays a junior for a number of years. And now imagine (I promise I’ll stop soon) that in this universe the disgruntled, lower performing, junior developer got a promotion 6 months into their first job by storming into their managers office and kicking off. Now we have a universe with a technically adept junior developer with years of experience, and a weak mid-level with only months of experience. Oh no! What a nightmare place that would be! Well, sorry to break it to you, but this happens in our universe. I’ve seen it.
So what am I trying to say? A job title (junior, mid, senior, lead, etc) is an indicator of how long you’ve worked in the industry, it’s also an indicator of your level of technical and business ability, but ultimately all it really means is that at some point in your career, you and your employer agreed (explicitly or implicitly) that that should be your job title. Once someone’s had a promotion once, well deserved or not, it’s much easier to convince future employers that they should have a similar or better job title. Demotions are rare, so ultimately all you need to do is persuade one person that you deserve that job title (or, more cynically, that they’ll have an easier life if they give you that job title than if they don’t) and it’s almost certainly yours for life (until you get a better one).
Making your job title work for you
There are 2 times when your job title matters – first is in your appraisal with your current company, the second if when you’re trying to switch jobs. It matters to you for the same reason it matters to the company – so that your performance and remuneration can be compared to people doing similar roles.
At appraisals, you should be able to go in knowing who in the company you’re being directly compared with, as it’ll be the people with the most similar job title to you. Therefore it’s important that you have a reasonable idea of how well you’re doing in comparison to them. Are you generally performing better? Are you finishing tasks quicker? Are you picking up the harder projects? Are you the one people come to for help in preference to the others? If so, great! Now is definitely the time to ask about a pay rise or perhaps a promotion (if you want one). Are you performing about the same or worse? Well, you can still ask for a pay rise but perhaps it would be better to focus on how you can improve and push yourself to the front of the pack for the next appraisal. In addition it’s worth checking out what other companies are advertising for roles at a similar level. You should bear in mind that often companies advertise roles at higher salaries than they’re actually prepared to pay (and your manager will know this too), but if there’s a big discrepancy between your current salary and those advertised locally for roles at a similar level that can be a good reason to ask for a pay rise (regardless of how well you think you’re doing).
When looking for a new job, knowing what your job title is allows you to either focus on jobs at the same level (which should be relatively easy to get) or at the next level up (which will be harder). If you choose to go for the next level up, be prepared to be asked why you think you’re ready for the next level. Hopefully you’ve been in the current role a while and can talk about examples of when you’ve performed at the next level up, however, as I mentioned earlier, different companies have different views on what constitutes the different levels of seniority so it’s possible that for the new company, everything they require at e.g. a senior level is the same as what your current company requires at a mid level. If that’s the case you might find that getting the interview is tricky (as the recruitment agent and/or HR representative will probably not read past the job title) but once you’re there you should find it easy to demonstrate that you’re capable of doing the job.
Levelling up (or not)
You may think you want to advance through the levels as fast as possible in order to up your earning potential but that can be a double-edged sword. While it’s true that on average senior developers will earn more than mid-level developers and so on, that doesn’t mean it has to be the case for every individual situation. Some companies may have rigid rules around what the salary band can be for each level but in most there will be some flexibility, especially if you push, and if your company won’t budge then there are always other companies out there.
So why wouldn’t you want to move up a level? Two reasons really. Firstly, as I mentioned earlier, the expectations on you go up every time you move up a level, there will be more pressure and a greater risk of failure. Much better to spend another couple of years as a junior developer than to move to mid before you’re ready and risk the embarrassment of being demoted again, or, more likely, having your career stall as you struggle to stand-out at your new level and the training opportunities you previously enjoyed are no longer available to you. The second is that you might find that you just don’t like the work. The higher you go the less time you’ll spend actually dealing with code and the more time you’ll spend dealing with people. By the time you get to senior or lead, in some companies you might find that you’re not actually writing any code at all and spending most of the time in meetings and dealing with people management. If that sounds good to you then great, go for it! but most software developers I’ve worked with are more interested in technology than people. I’ve known more than one person who took a promotion to lead developer but left the company within a year for a more junior position after realising that they missed working with code and didn’t want to do the lead job any more (companies are rarely accommodating to voluntary demotions).
Hopefully this article has given you some idea of what a job title really means, why you should care and how you can use your job title, and the job titles of those around you to help you as you progress through your career in software. Hopefully it hasn’t been too cynical, life is generally good, but sometimes you have to accept that occasionally it isn’t completely fair. If nothing else, hopefully you at least now know enough to stay out of internet arguments over whether job title relates to years experience or technical ability!
