Overview
One of the parts of having a successful Software Engineering career is knowing the different career stages. Each company is different (particularly when you consider the size of the company) but most of them follow a similar pattern that I will guide you through. As you make your way through your career, you can think across two dimensions: years of experience and area of impact. As you climb through levels, your influence and level of impact widens corresponding with your job title. I’ll cover each stage in detail in another post, but this is an overview of the stages and what it takes to travel through each of them.
New Hire
This is the stage where you have landed your first “real” job. Be it fresh out of college, boot camp, or just your first paying gig you have to start somewhere, and this is it. Most people believe that this stage is defined by learning but in reality, every career stage and transition is filled with learning. You’ve been learning for years leading up to this. What really defines this level is learning how to reliably execute.
You are making the transition into being a professional and the most important thing in the professional world is impact, aka results. If you are at a medium or large company, you most likely won’t be expected to know much of anything useful (you know C++ and that’s cool, but do you know the super-duper custom flavor of C++ and the hyper optimized libraries we use?). When people say you “ramped up fast” they don’t mean just that you learned fast, they mean that you translated that learning into impact quickly. What good is learning everything if you aren’t able to apply them?
At this stage, your level of impact is expected to be small and really focused on yourself. That’s not to say you don’t get bonus points for helping others, but the most important thing is to focus on consistent and high-quality execution. That doesn’t mean you don’t make mistakes or that everything has to be perfectly on time (you’ll never be free of mistakes or delays in your entire career). It means that you communicate clearly with your team when there are mistakes.
There are two missteps that I see happening that can hamper people’s careers at this stage. The first is being afraid to ask questions so that they seem smart, and the second is trying to hide issues because they want to seem perfect. The reality is no one is perfect, and in a healthy organization it’s far more important to communicate clearly than it is to be error-free.
Junior Developer
Once you’ve learned to execute reliably, you’ll likely find yourself promoted to the next level of your company. The difference between a new hire and Junior Developer is independence. A junior developer no longer depends on others to hold their hand as they get work done. This doesn’t mean they don’t ask questions! It means that they know when they are stuck and to ask questions, so they are not wasting time. Also at this point, your manager or tech lead no longer needs to follow up with you, track if your work is being done, or if you are lost in the weeds. You’ll also start to “own” areas of code and develop levels of local expertise.
This is where you start to level up your technical skills and master the fundamentals of good software engineering. Use this part of your career to master the tools of your team, but also to develop a good foundation for yourself. Does your team use JavaScript? Start to make yourself an expert. Read and learn about how to make scalable software systems, this is what will push you from being a Junior Developer to a Senior Developer
You are still mostly focused on yourself, but you should start helping others, making meaningful contributions to code, and take part in design reviews. This stage should be the last time where you are judged by your code because by the time you are promoted to Senior, it is expected by default that your technical skills are up to par. (Otherwise, you shouldn’t have been promoted to senior!)
Senior Developer
An old manager of mine used to say that you could tell when a person is ready for the Senior title when a line stars to form outside of their “office” to ask them questions. In this role you move from your impact being about yourself to it being about affecting your team. You are no longer judged by how well you execute but how well you enable others to execute. This usually takes the form of taking a lead on code and design reviews, but also in setting an example for others and helping ensure the team meets some quality bar.
At most places, some tier of Senior is the first terminal level, which means it’s the first level where it is acceptable to stay at that level forever if you want. At the same time, it’s also a level where most people tend to get stuck.
The part of Senior that most people get stuck at is time management. With all of the new responsibilities they now have, they can no longer just sit at their desk and code only worrying about themselves. They now need to better manage their time and live in a new, very interruption driven world. Between answering questions, handling pull requests, and even directly mentoring members of the team, it can be a difficult balance. It can also be tricky as you become the expert and one of the most experienced members on the team because you often no longer have other teammates to rely on. As mentioned before, you are no longer judged by your code skills so your technical learning and growth at this level will come in the form of improving your design and architecture skills
Senior is generally (though not always) the fork in the road where you can decide if you want to be a people manager, which can take you down dramatically different routes in your career. Becoming a people manager generally takes at least a few years after being promoted to a senior non-manager, but you will shift your focus more towards affecting the business through others.
Principal Developer
The jump to Principal developer is a giant leap that most people don’t make. It is often a dramatic increase in responsibility. As with Senior, your coding skills are assumed but by the time you reach Principal your design skills should also be at an advanced level. Your focus shifts from being about your local team of 7-9 engineers to looking at the wider team of 30-40 depending on your tenure at Principal.
Along with the normal time management struggle, you will often find your time monopolized by meeting requests and design and architecture reviews. There will be times where you no longer have the time to contribute code yourself. An added responsibility at this level is when there is a new framework to design (or evaluate), the principal engineer will take point in the design and integration, often teaching others and leading group towards good patterns and practices. I have often found that the quality of the organization’s code is a direct reflection of the quality of their principal engineers.
What makes a good Principal Engineer is not just how well they write and design code but their ability to influence members of the team to also write high quality code. While many senior developers focus on elegant solutions to today’s problems and think about how new code impacts today’s product, principal engineers think about designing code for tomorrow. They focus on design choices and think about things such as long-term maintenance and test ability.
At many places there are a select number of elevated principal engineer jobs often referred to with titles such as Architect, Technical Director, or Technical Fellow. These engineers are at the top reaches of Principal and have shown a strong track record with designing and supporting complex systems. In contrast to most principal individual contributors, these individuals will often forgo direct code contributions entirely and focus on leading the organization’s technical design. They will often report directly to the Engineering directors of the organization.
Principal managers differ from senior managers in scope of impact. Whereas senior managers will focus on their own team, often taking direction from their manager, a principal engineering manager will influence the people management style of the peers and supply guidance and structure to the process of the greater team.
Conclusion
As you can see, the various career stages of a software engineer build upon each other, requiring both an increase in technical ability but also an increase in impact across the team. Navigating these stages requires a focus on building technical and interpersonal skills as well as being reliable and consistent.
