Time to Read: ~3 min
Whether you are a graduate or junior, mid or intermediate, senior, principal or staff software engineer (or developer) is mostly up to the business that employs you. Although there are common themes, there is no accepted industry standard. Instead, companies often have internal, formal career frameworks and some, like DropBox, go so far as to publish theirs publicly.
These frameworks can become rather involved as you try to capture the nuances in expectations between various skill levels, breadth and depth of experience, and responsibilities and, in my experience, most of the confusion falls on the boundary between Intermediate and Senior. Although the length of experience cannot be disqualified as a helpful indicator of seniority, it certainly isn't an accurate measure of the individual. Someone may have ten years of experience on paper but, upon digging, you realise it was really the same year, ten times. Another may only have five years of experience but was so immersed in every aspect of a complex environment that the breadth of their expertise is unmatched.
A more helpful guideline than years of experience is how you think about a role's expectations and its contribution to your team and business.
Here is my take on it.
Junior Engineer
I think of Juniors as an investment in the future and also as a business's way of "giving back" (we all need to start somewhere, and someone must carry that cost).
The primary responsibility of Juniors is to learn. That's pretty much it. Of course, they can and must contribute with guidance and support, but they are primarily here to learn how software development works in the real world.
Intermediate/Mid-Level Engineers
The central focus for the Intermediate level is technical. They must be proficient enough to complete most software related tasks without help and keep up with developments in the industry, expanding their skills to include software architecture in the process.
Although their main contribution is technical, they should also be growing in the areas of product and process. As a result, their understanding of business requirements should improve as they start to develop a product mindset.
Intermediate developers are the "meat and potatoes" of every team, the core cohort. They're the builders that get the job done.
Senior Engineers
At this level, technical proficiency is assumed. Whether the job is architecting complex solutions, rapidly ramping up in new technologies, or dealing with unforeseen technical challenges, a Senior must be able to handle all of it.
Senior engineers have a strong product and mentorship focus (the primary output of Senior engineers should be more Seniors). They understand the cost-benefit trade-offs of every technical decision and how the product adds value to your clients.
When considering promotions to Senior, remember that individual contribution has a hard limit - there is only so much that one person can achieve or contribute. Promotion to Senior should, therefore, NOT be a reward for time served. It is NOT an inevitable outcome of developing technical proficiency and expertise, but rather a recognition of a person's leverage.
Seniors are force multipliers for their teams; their job is to maximise the benefit from everyone else's contributions.
Principal/Staff Engineers
Principal engineers are the technical Yodas of your business. They're the ones that everyone goes to with every technical challenge they can't solve themselves or don't know where to start, and must embody technical leadership excellence.
Not only are they at the forefront of engineering efforts, but it's also a requirement of their role that they remain there; their breadth and depth of skill and expertise make them core contributors to your strategic technology planning.
If Senior Engineers are the force multipliers for your software engineering teams, Principal Engineers are the force multipliers for your entire software engineering division.
There isn't much that falls outside the scope of what's expected of them.
When in Doubt
Thinking hard about career frameworks and job descriptions are necessary. It is crucial to get the details right for your business to ensure fair treatment and pay, and to provide clear expectations for a role and the requirements for progression. Unfortunately, it's hard to get this right, and the fact of language is, the more words you put into writing, the more likely you are to introduce ambiguity, misinterpretation, and cognitive overhead.
Whenever you find yourself lost in the weeds, consider a return to the basics: Where is your focus and what is the scope of your influence and impact?
If your goal is promotion, remember that the best way to get promoted, is by acting in the capacity of the role you are after. This takes the conversation around your ability to succeed in the new role out of the realm of the hypothetical.
Proving you can do it, beats claiming you can do it every time.
Happy coding!
Will
Psssst! If you haven't subscribed yet, you can do so here. It's completely free and you can unsubscribe any time! You can also find me on Twitter @frontleftwill or connect with me on LinkedIn if you like.