I see this question asked a fair amount, and as CTO, this question is something I deal with regularly.
I replied to a tweet about it, and I gave an answer in short form:
someone over retirement age
but on a serious note, it's someone that I would trust to "own a task", and operate with minimal supervision, while producing a technically sound solution. i.e: should be self-managing, guiding others), and strongly technically adept
two examples of what's NOT a senior dev:
- let's say someone is extremely skilled, but they fight with other devs, and disappear for weeks to do things their own way. This is not a senior dev, this is a wildcard. A high-management overhead liability
- let's say someone takes interest in their peers' work and doesn't hesitate to help, communicates well, is organized, but doesn't have much experience with the technology. This is not a senior dev (yet) on technical skill grounds, they might also succeed on a management track
so really, seniority is a combination of several different factors (capability, reliability, understanding of business goals, teamwork, leadership, etc). The "senior" title we give is for the purposes of recognizing/rewarding someone who has these or empowering them to use them
The last point is important: empowerment. The term "empower" is often overused in business, and a lot of the time used as a buzzword devoid of any real meaning. However I use it without irony here.
Empowerment is the antidote to imposter syndrome
Empowerment (in the context that I'm using it) simply means "giving someone the authority to do something". Many (I could say "most") people who are early in their career assume that they need permission, or to be asked, before they can do something.
Perhaps it's from years of conditioning in schools, where one has to ask to even use the toilet during class, or just as young people living in a world of adults. Asking for permission is something we actually have to unlearn in our careers.
So, to me, empowerment in the context of career development means giving someone the authority and confidence to take charge of a task or a team, and let them lead it. This could mean giving someone the confidence that their technical contribution to a task is valid. It could mean giving someone the confidence that I (as their manager) trust their judgement and abilities to lead a team.
That is an important function of the "senior" title. Those with it should feel empowered to lead, in all senses of the world. And for those with a case of imposter syndrome (and I think most people get this feeling, even those with years of career experience), this is an antidote. Think of it as a permanent reminder that "You have demonstrated your capability, and people trust you to use your experience to lead the team and mentor others".
That being said, I think in most companies, lack of the "senior" title should not prevent anyone from contributing their knowledge and experience to a task, or contributing any ideas they have, or constructive criticism. But we can't give out titles to everyone, it would dilute their meaning. Instead there are many other ways to encourage team members to contribute, that's the important job of line managers and mentors within the business, and that should be built into the structure of how day-to-day business is carried out: the planning processes, the check-ins, as well as embodied within the engineering culture of the team and the company. Simple example: you know the culture is missing this if junior employees feel afraid of speaking their mind for fear of being shot down or told that they don't know enough).
Criteria for Seniority
Different companies will have different criteria that define what makes a senior developer. Most companies should have a formal (and transparent) performance review process that embodies these criteria. The purpose of the performance review process is to decide when an employee has reached a stage of their personal and career development that could count as "senior", and this also has a lot of impact on remuneration.
The criteria is almost always not purely based on technical skill. The criteria for a developer at a tech company might include some (or variations on) the following:
- Technical Skill/experience. This one is the obvious one
- Understanding of company strategic goals and product aims. This is related to how well the developer understands and executes tasks against what the company is really about. Or put another way, when faced with tradeoff choices, will this developer make the decisions that are most in-line with what is best for the company?
- Reliability/consistency. There's usually something here about how reliable the developer is, it could be a euphemism for attendance and punctuality, it could be about work output. There's some debate about whether this is a good criteria or not given our natural ups and downs in life, but it's not surprising if a company wishes to focus on this.
- Communication. This is to do with how proactive ad how effective someone is with communication: do they get the message across easily and early? Do they not inform people of issues until it's too late (or not at all)?
- Leadership. This is to do with how well a developer leads (and empowers) others. You don't have to have a title to lead, for example, if there's a technical issue to be solved, nothing should stop a junior developer from gathering the people to solve it. They should be empowered to do so.
The list goes on. Usually earning any title should involve achieving well in all of the criteria. Someone with exceptionally strong technical skills doesn't automatically make them a "senior" if they can't also do the other things expected of them; and the employee performance review is a tool that tries to assess an employee's performance against the things expected of them.
Not all companies have this process though, and not all companies have implemented this process well. Smaller companies tend not to need or have one that's formalized. But all good managers should have a sense of how employees are doing against what their, and the company's, criteria are for career growth, whether they have this formal document and process or not (and if they don't...how are they setting your salary?)
Cover Photo by Standsome Worklifestyle on Unsplash
Top comments (0)