Where do you see yourself in five years’ time?
That must be one of the most dreaded questions in job interviews, especially for people in the software engineering industry. Without even taking into account the uncertainties of today’s world, in which we’re all fighting an unexpected pandemic, how can you make five years’ worth of plans when technology evolves at such a rapid pace? I remember when the first iPhone came out in 2007, completely changing the technological landscape and, with it, my career. Within four years, I had moved countries, leaving the United Kingdom for Hong Kong, and I was working with an entirely different stack. iOS and Android became my bread and butter, while Microsoft-based web development had become a thing of the past.
Perhaps, then, it’s more interesting to take the “five years question” and turn it on its head. As a hiring manager, where do you see your candidate in five years’ time? Where does the role you’re recruiting for lead to? As managers, we are often so focused on figuring out whether the prospective new employee is a job hopper that we risk forgetting the role a manager plays in somebody’s decision to leave their job. A talented engineer isn’t going to stick around if they aren’t constantly growing, and it’s our job as managers — and especially as servant leaders — to create these growth opportunities.
For their part, engineers need to be able to see how the growth opportunities that their managers set up are going to improve their own skill sets and further their careers. They need a map that spells out unequivocally how to get promoted so that they can focus on growing the skills required. Only then will they be able to figure out a multi-year plan within the company and be able to answer the dreaded question at the beginning of this piece.
In short, we need to define the requirements for each of the roles on our team and work out a roadmap that structures them into a coherent journey. What does that mean in practice? Let’s take a look.
Junior Software Engineer Career Path and Roles
Perhaps it’s easier to illustrate this roadmap through an example. This one is pretty close to the reality of one of the teams I most recently managed. Let’s imagine a fresh grad joining your team as a junior engineer, and let’s call her Sarah. What does Sarah’s career path look like in your organization?
Perhaps when she joins, she can start working on bug fixes and small features with a lot of supervision from more experienced engineers. As she gets more familiar with the codebase and builds her confidence, she can then take on more complex work with less supervision.
Eventually, Sarah becomes independent enough to be able to tackle fairly complex work on her own. In fact, she can even point more junior members of the team in the right direction when they get stuck. She can correctly estimate how long it will take her to complete small-to-medium tasks, and she can submit pull requests that are generally good. At this stage, Sarah’s no longer a junior member of the team, so we can promote her to the next level in our career ladder: engineer.
As her understanding of the product and the codebase continues to develop, Sarah might start building a sense of how to best implement new features. She can now define the task breakdown of a complex piece of work and lead a small team to implement it. Thanks to her understanding of the code, she can also provide insights on technical solutions by other team members. In other words, she’s become a senior member of the team. As she has demonstrably outgrown the engineer’s role, we can now promote her further up to the next level: senior engineer.
This is a simple, linear career progression for a full-time contributor on an engineering team. Their responsibilities grow over time as they get more familiar with the product they’re developing and its codebase.
Define Roles at Every Level of a Career Path
Turning this roadmap into a document, we can start by defining three roles — junior engineer, engineer, senior engineer — and list the key requirements and responsibilities for each. We can then illustrate how someone could go from one level to the next by highlighting the increased visibility and responsibility within the team. An engineer seeing this document would then be able to immediately identify where they stand and what they need to do to get to the next level.
Similarly, you can create journeys for other functions on your team, such as quality assurance and release management. You can even define how an employee can move between loosely related roles if you so desire, e.g., going from QA automation to DevOps. Mapping all this out depends heavily on how your team is structured internally and how it operates. Because each team’s situation is unique, we won’t cover this topic in depth here, but it remains a question you should consider.
Returning to our example of a generic engineer, let’s say that Sarah has been with us for four years, and she’s now a senior engineer. What’s next for her on our team? At this point, problems start to arise.
Senior Software Engineer Career Path and Roles
One of the most common misconceptions I have seen time and again in this industry is the assumption that any decent career progression needs to culminate in a people management role. In other words, you must either become a supervisor or see your career stagnate. In the software engineering world, that translates to the senior engineer becoming a team lead, then a junior manager, and so on.
In actuality, setting up a career progression in this way severely limits team members. For one thing, it’s not sustainable. You can’t have your whole engineering team eventually becoming hands-off managers, even if you have a healthy supply of engineers constantly joining your company. The need is simply not there.
Create Career Paths for Different Skill Sets
Perhaps more importantly, though, management and engineering demand very different skills. Management requires a tremendous amount of negotiating acumen and people skills. Further, although it requires some technical understanding in order to make the right decisions, that’s not the job’s main focus. Engineering, on the other hand, is all about the technical details. It’s a creative discipline steeped in specialized knowledge and great problem-solving skills.
Some senior engineers might be interested in learning management skills, but others might not. Sarah, our fictional example engineer, might prefer database performance optimization over resolving conflict between her team members. A senior engineer might prefer becoming an expert in their field and creating increasingly complex solutions over time, growing their technical acumen and learning the latest frameworks.
If we only offer a management career path, these engineers will get stuck at the “roof” that is the senior engineer position. Eventually, they’ll be forced to leave our organization for other workplaces where they can further their engineering skills.
Offer People Management and Technical Tracks
To make them stay, we should offer an alternative career path to management. We might offer a technical track where the person tackles more and more complex problems, perhaps from a higher-level perspective than a senior engineer would, while still raising their profile and responsibility within the company.
This track could, for instance, cover technical architecture or solution design. Whereas a manager would lead increasingly larger teams, the equivalent role on the technical path would design and define solutions that the aforementioned larger teams would then implement. To look at Sarah once again, let’s say she decided to take a role called “junior technical architect” over a team lead. In this case, she’d likely spend most of her time designing how the more complex features of our product are supposed to work, and how they slot into the overall architecture, instead of leading a team of three to five engineers.
In other words, if the management path culminates in a VP of engineering position, the technical one leads to CTO. Again, not all engineers will eventually become VP of engineering or CTO, but the talented ones should be given the option to choose where their career leads. That choice should be theirs to make, not their manager’s.
Final Thoughts on the Software Engineer Career Path
Setting up a clear and well-documented career ladder for your team won’t ensure that your staff will never leave, but it gives them a chance to know where their career is headed as long as they stay with you. It also gives you an opportunity to discuss promotions and growth goals with a formal, objective scale that is the same for everyone whenever you do a one-on-one career review or performance assessment.
What’s more, the career ladder is also a useful tool in a job interview, both for the interviewer and the prospective hire. It helps to frame the question about the longer-term aspirations of the candidate and offers transparency about the opportunities at hand on your team. Showing that your company provides both a technical growth path as well as a managerial one at this stage can truly make a difference. It shows prospective hires that you care deeply about engineering practice and that you give the best talent a real chance to shine and develop their skills without forcing them down a career path that they might not be keen on.
