There are a lot of good articles about possible career tracks that you can pursue in IT. I haven’t seen many that might be used as actual guidance to move up the career ladder. In almost any more or less mature IT company a common career track for a software engineer is linear. The further career track will depend on your inclinations, what you enjoy doing, and whether you are ready for the shift in the way you’re working.
There are a lot of good articles about possible career tracks that you can pursue in IT, however, I haven’t seen many that might be used as actual guidance to move up the career ladder.
Currently, I am working in a company that has very clear requirements for the engineers’ promotion and what can be used as sufficient evidence of fulfillment of those requirements. A combination of these two factors gave me the idea that additional information on this topic might help other engineers who are employed by companies that do not have it to build a strategy that will allow them to get to the next level.
In almost any more or less mature IT company, a common career track for a software engineer is linear and looks almost the same:
Associate Software Engineer is optional and may or may not be presented in the common IT department structure for a very simple reason: it’s net-negative for the first 12 months as it requires a lot of hand-holding so not all companies have resources and time to allow such positions in their structure.
The further career track will depend on your inclinations, what you enjoy doing, and whether you are ready for the shift in the way you’re working.
There’s nothing wrong with staying a senior software engineer if you like to allocate the majority of your time to coding. However, if you feel the need to empower others and lead that’s the right moment to weigh all expectations for each role, your strengths, the things that drive you, and pick the most suitable track for yourself.
Despite the visual simplicity of the tracks above, it’s not clear how to get closer to the right end. The following insights will apply to the companies that have:
a hierarchical structure where each employer has a line manager
a genuine interest in employee development
Why is the above-mentioned is important?The answer is quite simple: from day one you have an ally - your line manager.
Each line manager’s efficiency is based on the output of each person reporting to them: the faster you grow - the bigger your output - the better the line manager’s efficiency. Given all this, sooner or later, after you have joined your company, your line manager will approach you with the question: “Where do you see yourself after a certain time?” If it is not happening and you have regular one-to-ones, feel free to add this as a topic for discussion in the agenda.
Voicing your intentions and setting a goal is just the first step of your way. The next step is to gather the list of requirements for the higher role and compile a list of achievements that can serve as evidence of your qualifications that you can use as a guide that you should follow to get from point A to point B. In companies with transparent promotion processes, this should be already in place.
If this is not the case, you and your manager could compose one. Remember that this process is beneficial for both sides: you are getting an agreement that after certain achievements, you will be praised with the promotion and your line manager can get increased output from the team, so it’s a win-win case.
Different companies may have different requirements for certain positions, and I won’t claim that the ones below are universal and will suit everyone. The main purpose is to give you an idea it might look like if you need one that can be further tailored to your needs.
Guidelines for evidence can be used as a roadmap that brings you to the desired destination. The next steps for the common track might be
Check the team’s roadmap for suitable projects or change requests that might fit the purpose of the evidence.
Voice up your intentions to the line manager so they can assist with the suitable project allocation and provide information about its priority, business value, and when it can be picked up for development.
Spot any potential areas for improvement in code, observability, extensibility, and security perspectives and raise them as ownership tickets.
Familiarize yourself with the current recruitment process in your company and ask for shadowing during recruitment sessions. Ask to switch roles where someone more senior will shadow you and ask for feedback.
This is a short list of the roles that will be covered from requirements/guidelines for evidence perspectives:
Common Track
Junior Software Engineer Requirements
Software Engineer Requirements
Senior Software Engineer Requirements
Engineering Track
Lead Engineer Requirements
Senior Engineering Lead Requirements
Management Track
Engineering Manager
Engineering Director
Junior Software Engineer Requirements
Area
Requirements
Guidelines for evidence
Delivery
Delivers tasks · Clear requirements are needed (business and system) · Designs/implements limited-scope technical solutions · Limited guidance is required
1. List of tasks completed o Tasks should be complex enough to mention them o Deadlines are met o No major quality issues o Tasks were completed with no handholding 2. Input from the line manager confirming that all the requirements are met.
Quality
Applies best practices · Learns and constantly applies best practices · Proficient with various dev tools · Investigates and fixes complicated problems/bugs
Feedback from the line manager and peers confirming that all the requirements are met.
Software Engineer Requirements
Area
Requirements
Guidelines for evidence
Delivery
Delivers change requests (features) · Takes business requirements as input · Breaks work into tasks with a sufficient level of detail on the solution (what needs to be done and when it’s done) and the implementation (how it should be done) · Provides accurate estimates on a task/user story level · Pairs with other engineers to deliver faster
List of change requests delivered, conforming to the following requirements: 1. The change request has been fully delivered and the deadline was met. 2. The discovery part was completed by the employee (tickets, estimates). 3. The change request is complex enough from a technical perspective (more than 2 man-weeks for 1 engineer to implement it). 4. The change request provides a meaningful impact on the business. 5. The change request is signed off by the business and is running in production. 6. The employee has demonstrated a sufficient level of autonomy and quality (based on the feedback from the tech lead and the engineering manager).
System design
Designs services · Designs and implements smaller services while taking into account all of the non-functional aspects (extensibility, security, observability, etc) · Writes high-quality code with full adoption of engineering practices and methodologies · Participates in code reviews to enforce best practices · Fixes the root causes behind bugs and problems encountered
At least two services designed conforming to the following requirements: 1. It can be a new service or a complete redesign of the existing service. 2. It can be a standalone service, a library, or a component consumed by other services. 3. The service shouldn’t be trivial from a design perspective. 4. The engineer should have followed the formal design process: · Obtain business and system requirements · Identify the bounded context · Identify non-functional requirements · Break down context into services · Get feedback on the solution · Implement it 5. Service is implemented and is running in production.
Senior Software Engineer
Area
Requirements
Guidelines for evidence
Delivery
Delivers project phases (epics) · Takes requirements and high-level system design as input · Creates system design for the service or the component, decides on the technologies and engineering practices to be used · Breaks work into tasks or user stories with a sufficient level of detail on the solution (what needs to be done and when it’s done) and the implementation (how it should be done) · Provides accurate estimates on task/user story level · Leads a small team to deliver the scope · Unblocks their team, resolves issues, and removes impediments
List of project phases/epics delivered, conforming to the following requirements: 1. The epic/project phase has been fully delivered and the deadline was met. 2. The discovery part was completed by the employee (tickets, estimates). 3. The epic/project phase is complex enough from a technical perspective (requires at least 2 engineers for >= 2 weeks). 4. The epic/project phase provides a meaningful impact on the business. 5. The functionality is signed off by the business and is running in production. 6. The employee has demonstrated a sufficient level of autonomy and quality (based on the feedback from the tech lead and engineering manager). 7. The engineer participated in the implementation as a technical lead.
System design
Designs subsystems · It is the same as for a Software Engineer but focuses on more complex services or subsystems · Proficient in the cloud and distributed systems design and implementation
At least 3 services designed conforming to the following requirements: 1. It can be a new service or a complete redesign of the existing service. 2. It can be a standalone service, a library, or a component consumed by other services. 3. The service shouldn’t be trivial from a design perspective. 4. The engineer should have followed the formal design process: a. Obtain business and system requirements b. Identify bounded context c. Identify non-functional requirements d. Break down context into services e. Get feedback on the solution f. Implement it 5. Service is implemented and is running in production.
Driving changes
Proposes changes · Challenges the status quo and the assumptions made · Find ways to improve the platform, processes, working environment, and the tech team in general
At least three significant changes were proposed, which can be any of the following: 1. Functionality: proposed a change request that was prioritized and implemented (change request should be substantial enough to be considered as a change, not a cosmetic change). 2. People: interviewed an engineer who was hired and passed probation (junior software engineer or higher, considered as a change to the team). 3. Ownership: proposed an ownership project (included in the ownership roadmap, approved by CTO).
Lead Engineer Requirements
Area
Requirements
Guidelines for evidence
Delivery
Tech lead for projects (project proposals) · Takes business requirements as input · Find the most effective solution for the business problem (research alternatives, validate solutions using no-code/low-code approaches) · Creates system design for the new service or subsystem, decides on the technologies and engineering practices to be used · Breaks work into epics with a sufficient level of detail on the solution (what needs to be done and when it’s done) and the implementation (how it should be done) · Provides accurate estimates on the project level, commits to dates · Acts as a tech lead for the entire project · Unblocks their team, resolves issues, and removes impediments · Manages technology, implementation, and operational risks
List of projects delivered, conforming to the following requirements: 1. The solution for the problem was proposed by the employee and it is considered to be effective. I.e. multiple alternatives were evaluated, and the best alternative was chosen based on the low-code/no-code validation. 2. The discovery part was completed by the employee (tickets, estimates). 3. The solution was architected by the employee. 4. The project needs to be a “feature” project initiated through a project proposal. 5. The engineer participated in the implementation as a technical lead (see requirements column for more details).
Driving changes
Drives technical changes (squad) · Proposes and implements initiatives to improve system quality and reduce technical debt · Proposes and implements changes to improve developer experience and productivity · Advocates and enforces clean code and clean architecture
List of major changes introduced (usually at least four), conforming to the following requirements: 1. The change provides meaningful improvement to system quality (e.g. platform improvements), developer experience, or developer productivity. The change affects the entire squad. 2. The engineer doesn’t have to be the one who proposed the change. The engineer should be the primary driving force behind the change (e.g. designed, acted as a tech lead, participated in the implementation). The change can be delivered by an engineer or as a team effort. 3. The change should be fully implemented and used by the squad/platform (the change should be “sticky” and provide enough value to keep it). 4. The change should be significant enough to mention.
People
Mentor · Mentors and supports less experienced engineers · Conducts technical interviews effectively · Acts as a “magnet” for great engineers during hiring (be a decisive factor where we are in competition for good talent vs. another company)
Possible evidence: 1. Engineers interviewed, who were hired and passed probation. 2. Feedback from upskilled engineers. 3. Training sessions are organized/delivered for the entire tech team (e.g. Tech Sync, Engineering Dojo). 4. When leading a working group a list of changes proposed/implemented in the scope of the working group can be used as evidence.
Senior Engineering Lead
Area
Requirements
Guidelines for evidence
Delivery
Tech Lead for complex projects (project proposals) Same as Lead Engineer, but focuses on problems that are complex from technical, organizational, or business perspectives · The project requires coordination across multiple squads · The project involves 3rd party technology provider or stakeholder (e.g. partnership) · a new product build while the product is in the discovery mode · high priority/urgency project with fixed deadlines and many unknown
List of projects delivered, conforming to the following requirements: 1. The project is considered to be complex (see examples on the left). 2. The project has been fully delivered (all deliverables + DoD) and the deadline was met. 3. The solution for the problem was proposed by the employee and it is considered to be effective (i.e. multiple alternatives were evaluated, and the best alternative was selected based on the low-code/no-code validation). 4. The discovery part was completed by the employee (system requirements, tickets, estimates). 5. The solution was architected by the employee. The project has a high complexity from a system design perspective. 6. An engineer participated in the implementation as a technical lead.
Driving changes
Drives technical changes (tech) · Same as E5 but on the tech level · System owner for at least one non-functional aspect (e.g. security, observability, etc).
List of major changes introduced (usually at least 4), conforming to the following requirements: 1. The change provides meaningful improvement to system quality (e.g. platform improvements), developer experience, or developer productivity. The change affects multiple squads (e.g. technology adoption). 2. The engineer doesn’t have to be the one who proposed the change. The engineer should be the primary driving force behind the change (e.g. designed, acted as a tech lead, participated in the implementation). The change itself can be delivered by an engineer or as a team effort. 3. The change should be fully implemented and used by multiple squads (changes should be “sticky” and provide enough value to keep it). 4. The change should be significant enough to mention. It should be tracked on the “upcoming projects” page as an ownership project (ownership in this context means changes to the platform, tooling, processes, etc, not just platform-related changes). 5. At least 2 changes should be related to the non-functional aspect owned by the individual.
People
Recognized expert · Recognized expert within a given area of expertise on a company level, acts as a technical point of contact in tech within their area of expertise · Monitors trends/technologies within the area of expertise and communicates updates and findings · Actively and regularly shares expertise with other engineers (workshops, tech talks, training) · Facilitates collaboration to find solutions for complex problems (working groups, etc) · Conducts technical interviews effectively · Mentors and supports less experienced engineers, guide their career from a professional development perspective · Acts as a “magnet” for great engineers during hiring (be a decisive factor where we are in competition for good talent vs. another company)
Possible evidence: 1. Interviewed engineers, who were hired and passed probation. 2. Feedback from upskilled engineers. 3. Training sessions are organized/delivered for the entire tech team (e.g. Tech Sync, Engineering Dojo). 4. Leading a working group, a list of changes proposed/implemented in the scope of the working group can be used as evidence.
Engineering Manager
Area
Requirements
Guidelines for evidence
Delivery
Delivers squad roadmap · Leads a squad of 3-6 engineers · Acts as a project manager for multiple concurrent initiatives · Able to deliver results having only business requirements as input (able to create and sign off system requirements) · Focuses on business impact, driven by business value · Communicates commitments, status, and risks to business stakeholders · Ensures that all squad members have all the information they need · Communicates to 3rd parties within the scope of initiatives/ownership · Finds the right balance between feature delivery and system quality · All requirements for Senior Software Engineer
New projects delivered by the squad conforming to the following requirements: 1. Project initiated through a project proposal. 2. The project has met its impact metrics, and the public commitment was met. 3. Projects reported in the previous promotion cycle can’t be included in the list.
Productivity
Drives managerial changes (squad) · Measures and continuously improves squad performance · Identifies and establishes best practices within the squad with a focus on productivity · Maintains high quality of delivery · Ensures transparency on progress, risks, results
1. Squad productivity (performance) metric values. 2. Major changes (at least 4) introduced, conforming to the following requirements: a. It solves a problem related to the owned squad or tribe, the problem needs to be included in the TOP 5 problems and agreed upon with the line manager. b. The change should be fully implemented and used by the squad (change should be “sticky” and provide enough value to keep it). c. The change should provide meaningful improvement to productivity, engagement, or quality of delivery. d. The manager doesn’t have to be the one who proposed the change. The EM should be the primary driving force behind the change. The change can be delivered by an engineer or as a team effort.
People
Line manager (>=3 direct reports) · Manages 3-6 direct reports · Coaches and supports engineers · Supports and guides career progressions · Reconciles differences of opinion and helps manage and resolve conflicts · Encourages a positive team culture and collaboration
1. Squad engagement metric values. 2. List of engineers, who were hired and passed probation (can be skipped if we are not hiring, EM should be a hiring manager).
Engineering Director
Area
Requirements
Guidelines for evidence
Delivery
Delivers roadmap for multiple squads · Ensures delivery across 2-3 squads · Fulfils Engineering Manager role in one of the squads · Owns partnerships with 3rd parties · All requirements from the Engineering Manager
New projects delivered by the squads conforming to the following requirements: 1. Project initiated through a project proposal (not a BAU activity). 2. The project has met its impact metrics and the public commitment was met. 3. Project results were presented as a Tech Feature session. 4. Projects reported in the previous promotion cycle can’t be included in the list. 5. At least 2 projects should be recognized as key projects on a company level (e.g. a new product, etc, can be confirmed with CTO).
Driving change
Drives managerial changes (multiple squads/tech) · All requirements from Engineering but across multiple squads · System owner for at least one process (e.g. support, etc)
1. Squads’ productivity (performance) metric values across multiple squads. 2. Major changes (at least 6) introduced, conforming to the following requirements: a. It solves a problem related to the squads or tribe, a problem needs to be included in the TOP 5 problems and agreed upon with the line manager. b. The change should be fully implemented and used by the squads (change should be “sticky” and provide enough value to keep it). c. The change should provide meaningful improvement to productivity, engagement, or quality of delivery. d. The manager doesn’t have to be the one who proposed the change. The Engineering Director should be the primary driving force behind the change. The change can be delivered by an engineer or as a team effort. e. At least 2 changes should be related to the process owned by the director.
People
Line manager (>=10 reports, including indirect reports) · All requirements for Engineering Manager · Coaches and supports engineers · Supports and guides career progressions · Manages churn, reduces “regrettable churn”
1. Squads’ engagement metric values across multiple squads. 2. List of engineers, who were hired and passed probation (can be skipped if we are not hiring). 3. List of engineers promoted (can be skipped if there is no business need for promotions).