Mapping Your Journey: Understanding Software Engineering Career Levels and Expectations
Some time ago, during a discussion with one of my former managers, we tackled the challenge of devising a hiring plan for an ambitious business strategy. Starting from scratch, we aimed to define the organization’s structure, including roles, levels, and hierarchies. It was such a disaster that I could easily write four or five articles based on the mishaps of that single 30-minute call.
Talent acquisition had asked us for help defining the differences among levels for a software development engineer. That is like an invitation to a birthday party with free pizza and drinks: pure enjoyment with no downsides. But then my manager said: easy, for juniors we want three years experience, for seniors, five. My soul wept a little.
What could I do but challenge that? In the single minute that I had the floor -as a new joiner at that time- I did my best to explain my point of view: That is not okay. There are differences in responsibilities and expectations, and we should discuss different dimensions if we want to have significant level definitions that contribute to a functional organization in the short and long term.
Years of experience are nothing alone. I recently wrote an article about this:
The Myth of Age Equals Experience
In any professional environment, it is common to talk about years of experience as an irrefutable measure of a person's ability or level of expertise or competence. Job descriptions use “years of experience” as a minimum requirement. I always think: you can have a number of years of experience, but what did you do in those years?
Even further, not even a current title means anything by itself. Validating internal or external hires based solely on their previous titles or CVs is ineffective for two reasons:
The same title can be very different across different companies,
Holding a position does not necessarily equate to being capable of fulfilling a relevant portion of its various responsibilities.
I have also written an article on this topic:
Beyond Titles: The Disconnect Between Competence and Opportunity
Some people are in certain positions in life because they deserve it. Some people are there by chance because a series of events put them in a position for which they are not qualified and objectively don't deserve. Both are fine, but you must know which one is your case.
Let’s talk about what matters per level, but before that, let’s see how many levels we can talk about.
How many levels for a role should we consider?
Talking about juniors and seniors alone, as many people do, is a gross oversimplification. There are infinite opinions about this, but certainly, there are not only two levels. We can easily talk about 4 or 5 different seniority levels that are easily applicable to any company, and that is thinking about the individual contributor path; most of those levels could branch out to an equivalent in the management side.
I will discuss levels, and I'd like to challenge myself by creating a comprehensive scale that encompasses a broad spectrum. You can combine items if you need fewer or interpolate/extrapolate if you need more. The levels I will be using are:
Entry-Level, Junior.
Mid-Level, Semi-Senior.
Senior Engineer
Principal Engineer
Senior Principal
Staff Engineer
Distinguished/Fellow Engineer
In some companies, there can be additional individual contributor roles, such as architects or enterprise architects. In contrast, in others, the architect role will be equivalent to Senior or Principal engineer, being these the teach leads taking care of solution or technical designs or review the designs of others. I don’t want to get lost in the accuracy of the naming of levels, but I primarily draw a scale and focus on describing the differences at all levels in that scale.
What are the dimensions to look at?
Here’s a list and a brief explanation of all the dimensions I consider when evaluating a person against a role and level.
Note that this is my understanding of this space; it is not what any of my current or past employers use, and I dont pretend this to be unique or the only possible way of looking at it. Of course it can be challenged so if you are missing something or see something differently, please let me know!
Problem-Solving and Complexity: The ability to identify, understand, and resolve issues, including the level of complexity of the tasks or problems handled.
Autonomy and Execution: The degree of independence in carrying out tasks and the effectiveness in completing them.
Technical Skills: The depth and breadth of knowledge in programming languages, tools, frameworks, and technologies.
Leadership and Mentorship: The ability to lead projects and teams, as well as mentor other engineers.
Impact: The extent to which the individual’s work affects the team, project, organization, or industry.
Communication: The ability to convey ideas effectively to peers, supervisors, and stakeholders.
Ambiguity: The capability to handle uncertain situations and find clarity.
Process Improvement: The ability to identify inefficiencies and implement improvements in processes.
These dimensions provide a comprehensive view of the expectations and responsibilities at each level within the software engineering career path, helping individuals understand what is required to progress and succeed in their roles.
Mapping the expectations for these dimensions according to the level
You may ask why I didn’t put this in a table format instead. I believe that going for a narrative format makes it more accessible for a blog post or newsletter, and it is especially easier to consume from mobile. Ah, yes, and Substack doesn’t support tables.
Below, I describe the expectations or calibration for every dimension at every level of a software development career. This can be used for hiring, performance reviews, promotions, etc. A specific individual can be differently calibrated in different dimensions; for example, it is normal to see employees on track for promotion who perform consistently at the next level for specific dimensions but still need to work on other dimensions and in the opposite direction: some individuals can be strong in their role but have specific weaknesses or growth areas in some of these dimension that don’t affect the overall ability to be competent in the position.
Let’s cut to the chase:
Entry-Level Engineer
Problem-Solving and Complexity: Solves well-defined problems with guidance and handles simple tasks.
Autonomy and Execution: Requires significant oversight and mentorship. Executes tasks as directed, focusing on learning and growth.
Technical Skills: Has a basic understanding of programming languages and tools, requiring guidance for most tasks.
Leadership and Mentorship: No leadership role; focus on individual contribution.
Impact: Impact is limited to individual tasks and projects.
Communication: Communicates effectively with peers and supervisors.
Ambiguity: Requires clear instructions to perform tasks.
Process Improvement: Participates in team discussions about process improvements.
Mid-Level Engineer
Problem-Solving and Complexity: Solves moderately complex problems with some guidance and handles moderately complex tasks.
Autonomy and Execution: Works independently with occasional guidance. Executes moderately complex tasks independently.
Technical Skills: Has a solid understanding of programming languages, tools, and frameworks and can work independently on most tasks.
Leadership and Mentorship: May lead small projects or teams and guide entry-level engineers.
Impact: Impact extends to team-level projects.
Communication: Communicates well with team members and cross-functional teams.
Ambiguity: Can handle some ambiguity with occasional guidance.
Process Improvement: Suggests improvements based on observed inefficiencies.
Senior Engineer
Problem-Solving and Complexity: Solves complex problems independently and manages complex tasks and projects.
Autonomy and Execution: Works independently. Executes complex tasks effectively and provides guidance to others.
Technical Skills: Expert in multiple programming languages, tools, and frameworks, and can design complex systems.
Leadership and Mentorship: Leads significant projects or teams and mentors less senior engineers. Participates in hiring and promotions and provides relevant input for appraisals.
Impact: Significant impact on projects and teams, driving key initiatives.
Communication: Excellent communication skills, presenting complex ideas to diverse audiences.
Ambiguity: Comfortable with ambiguity and finding clarity in complex situations. May mentor others in dealing with ambiguity.
Process Improvement: Identifies areas for process improvement and implements solutions.
Principal Engineer
Problem-Solving and Complexity: Identifies and solves highly complex problems and handles highly complex projects and systems.
Autonomy and Execution: Operates autonomously. Ensures successful execution of large-scale initiatives and makes critical decisions impacting multiple teams.
Technical Skills: Deep expertise in several areas, recognized for technical depth and breadth.
Leadership and Mentorship: Leads large-scale initiatives, influence engineering direction, and mentors senior engineers.
Impact: Drives organizational changes, impacting multiple teams and projects.
Communication: Influences stakeholders across the organization and is effective at all levels.
Ambiguity: Thrives in ambiguous situations, providing direction and solutions.
Process Improvement: Leads initiatives to improve processes across teams.
Staff Engineer
Problem-Solving and Complexity: Identifies and solves highly complex problems and manages highly complex tasks.
Autonomy and Execution: Operates autonomously and drives execution of organizational-level projects, aligning execution with strategic goals.
Technical Skills: Deep expertise in several areas, recognized for technical depth and breadth.
Leadership and Mentorship: Leads large-scale initiatives, influence engineering direction, and mentors senior engineers.
Impact: Drives organizational changes, impacting multiple teams and projects.
Communication: Influences stakeholders across the organization and is effective at all levels.
Ambiguity: Excels in highly ambiguous environments, setting clear paths forward.
Process Improvement: Leads and drives process improvement initiatives across the organization.
Distinguished Engineer
Problem-Solving and Complexity: Solves the most challenging problems in the field and addresses complex challenges.
Autonomy and Execution: Operates with complete independence and executes at the highest level, ensuring strategic alignment.
Technical Skills: World-class expertise in specific domains, recognized as an authority in the industry.
Leadership and Mentorship: Shapes the company's technical strategy, influences industry standards, and mentors principal engineers.
Impact: Impacts the entire organization and influences the industry.
Communication: Communicates vision and strategy at the highest levels and influences industry discourse.
Ambiguity: Masters ambiguity, defining new directions and influencing industry standards.
Process Improvement: Defines and sets best practices and processes for the entire industry.
How to use all this?
Hiring and job descriptions
Use bits and pieces to compose your job description, being specific about what you are looking for and what the role's expectations will be. This will help you target the right candidates and have a clear reference framework for the specific kind of contribution and level of performance expected in the different areas. Then, during your hiring process, you should collect relevant evidence of how the candidate operates against those dimensions.
Performance reviews
What I like to do is create a matrix with all the dimensions, and for all of them, use collected evidence to rate the specific dimension (e.g., from 1 to 5) and add some examples to justify your position. You can assign different weights to different dimensions, or consider them equally important, it is up to you. At the end of the exercise, you will have a -reasonably- quantifiable way of putting it all together. One important aspect, and not easy to master, is not to compare employees against each other but against your previously defined calibration to reduce bias and avoid comparing heterogeneous situations.
Promotions
You can define a qualitative bar for the level based on the expectations per dimension and use a process similar to that described above to translate to a reasonable quantitative measure of how the employee compares with that bar. You can consider some dimensions mandatory and others, not a promotion blocker (i.e., something that can be learned or improved later in the first months in the role), and you can assign different weights to different dimensions. Collect examples that show consistent performance at the expected level and consistency in the expected behaviors, and include them as evidence of the readiness for the role.
Conclusion
If you are looking into your own professional growth and career path, or if you are a manager looking into hiring the right talent, or helping the career growth of your teams, understanding what different aspects are relevant, how a level compares with the others, and how specifically the growth is defined, this framework with help in these ways:
You can evaluate and calibrate yourself and others with the right granularity and without ambiguity.
The granular awareness helps focus the efforts on the areas that require investment, leveraging the strengths, and finding the right challenges and opportunities for intentional, accelerated growth.