Engineering
Engineering Manager
Four levels from Engineering Manager to VP of Engineering, across six management competencies.
- 4 levels
- 6 competencies
Career ladder template
Software engineer career ladder template
Five levels from Junior to Principal, across six competencies from shipping code to growing the team.
Free plan · No credit card required
This career ladder is written for product companies of roughly 20 to 200 people: engineers ship features end to end, teams are small, and nobody in HR is writing a job architecture. It describes five levels, from someone at the start of their career to someone who shapes the technical direction of the whole company. Its top level, Principal Engineer, is an individual-contributor level; managing engineers is covered by the separate engineering manager ladder.
Every level is defined by what a person does, not by years of experience. Read a row of the competency matrix from left to right to see how one expectation grows; read a level's section to see everything expected at that level at once. Use it to explain what the next level means, to structure self-assessments and check-ins, and to make promotion cases comparable across teams.
Treat it as a starting point. Rename the levels to match your titles, merge or drop competencies that do not fit your company, and rewrite the expectations in your own words before you publish the ladder to the team.
The levels at a glance
Junior Engineer
Learns the codebase and delivers well-defined tasks with guidance.
- Scope
- Individual tasks in one area of the product, usually broken down by someone more experienced.
Engineer
Delivers features independently and is a dependable member of the team.
- Scope
- Small and medium features inside one team's area, from a short design note to production.
Senior Engineer
Leads larger pieces of work and raises the standard of the team around them.
- Scope
- Projects that span several services or several people, and the technical decisions of one team.
Staff Engineer
Solves problems that cross team boundaries and steers technical decisions beyond one team.
- Scope
- Several teams or a whole product area, including problems that no single team owns.
Principal Engineer
Sets technical direction for the company and answers for its long-term technical health.
- Scope
- The whole engineering organisation and the company's technical strategy for the next few years.
Competency matrix
Each row is a competency and each column a level. Read a row from left to right to see how the expectation grows.
What each competency means
- Technical delivery
- Turning requirements into working, maintainable software and getting it to users.
- System design
- Choosing structures, interfaces and trade-offs that will hold up as the product grows.
- Quality and reliability
- Keeping the product correct, observable and available, and learning from failures.
- Collaboration and communication
- Working effectively with other engineers, product, design and the rest of the business.
- Ownership and product impact
- Understanding why the work matters and taking responsibility for outcomes, not only tasks.
- Mentoring and team growth
- Helping others improve and making the team stronger than any one person in it.
| Competency | Junior Engineer | Engineer | Senior Engineer | Staff Engineer | Principal Engineer |
|---|---|---|---|---|---|
| Technical delivery | Completes well-scoped tasks with readable code and tests, asks for help after being stuck for a few hours rather than a few days, and addresses review comments before merging. | Takes a feature from a short design note to production without hand-holding, splits it into pull requests that are easy to review, and gives realistic estimates for familiar work. | Delivers projects that span several services or contributors, sequences the work so that something useful ships early, and removes risks before they block the team. | Unblocks delivery across teams: untangles shared dependencies, builds the tooling or runs the migrations several teams need, and keeps multi-team projects on track. | Shapes how the whole organisation ships — release practices, platform choices, build and deploy tooling — so that every team delivers faster and more safely. |
| System design | Follows the existing patterns in the codebase and can explain why the code they changed is structured the way it is. | Designs components inside an existing service, writes a short design note for non-trivial changes, and compares at least two options before choosing one. | Leads the design of features that span several services, writes down the trade-offs for others to review, and reviews other engineers' designs constructively. | Defines architecture across team boundaries — shared data models, service contracts, build-or-buy decisions — and anticipates how the system must change over the next year or two. | Owns the company's technical strategy: which technologies to bet on, which to retire, and how the architecture should evolve with the business over several years. |
| Quality and reliability | Writes tests for their own changes, checks their work before release, and fixes bugs in code they touched. | Adds monitoring and alerts for the features they build, takes part in the on-call rotation, and handles routine incidents using the runbook. | Leads incident response for the team's systems, writes blameless post-mortems, and makes sure the follow-up actions are actually done. | Finds reliability and security risks that span systems, sets standards such as the testing strategy and service-level objectives, and drives the fixes across teams. | Defines what reliability, security and quality mean for the company, balances them against speed with the leadership team, and is the last escalation point for the hardest incidents. |
| Collaboration and communication | Shares progress and blockers openly, and asks clear questions when a requirement is unclear. | Works directly with product and design to clarify requirements, explains technical constraints in plain language, and writes pull-request descriptions that reviewers can follow. | Represents the team in planning, negotiates scope and trade-offs with product, and writes documents that people outside engineering understand. | Aligns several teams and functions around a technical plan, resolves disagreements between teams, and explains technical risk to leadership. | Is a trusted voice in company-level decisions, translates business strategy into technical direction and back, and represents engineering to customers, partners or investors when needed. |
| Ownership and product impact | Understands the purpose of their tasks, checks that what they shipped works for users, and follows up until it does. | Owns a feature after launch: watches its usage and errors, fixes what goes wrong, and suggests improvements based on what they learn. | Owns an area of the product end to end, challenges requirements that do not serve users, and proposes work that moves the team's goals. | Finds the highest-leverage problems across a product area — including ones no team has claimed — and makes sure they get solved. | Connects engineering investment to company results, and argues for or against major bets based on their technical and business impact. |
| Mentoring and team growth | Asks for feedback and acts on it, and writes down what they learned so that the next newcomer has an easier start. | Gives careful code reviews, helps onboard new teammates, and pairs with junior engineers on unfamiliar parts of the code. | Mentors one or two engineers deliberately, gives feedback that helps them reach the next level, and takes part in hiring interviews. | Grows senior engineers across teams, shapes the interview process and engineering practices, and is someone others seek out for advice. | Builds the company's technical culture — how decisions are made and how knowledge is shared — and develops the next generation of staff engineers. |
Scroll the table sideways to see every level.
Download as CSV Opens in Excel, Google Sheets or Numbers.
Junior Engineer: what is expected
Learns the codebase and delivers well-defined tasks with guidance. Individual tasks in one area of the product, usually broken down by someone more experienced.
- Technical delivery
- Completes well-scoped tasks with readable code and tests, asks for help after being stuck for a few hours rather than a few days, and addresses review comments before merging.
- System design
- Follows the existing patterns in the codebase and can explain why the code they changed is structured the way it is.
- Quality and reliability
- Writes tests for their own changes, checks their work before release, and fixes bugs in code they touched.
- Collaboration and communication
- Shares progress and blockers openly, and asks clear questions when a requirement is unclear.
- Ownership and product impact
- Understands the purpose of their tasks, checks that what they shipped works for users, and follows up until it does.
- Mentoring and team growth
- Asks for feedback and acts on it, and writes down what they learned so that the next newcomer has an easier start.
Engineer: what is expected
Delivers features independently and is a dependable member of the team. Small and medium features inside one team's area, from a short design note to production.
- Technical delivery
- Takes a feature from a short design note to production without hand-holding, splits it into pull requests that are easy to review, and gives realistic estimates for familiar work.
- System design
- Designs components inside an existing service, writes a short design note for non-trivial changes, and compares at least two options before choosing one.
- Quality and reliability
- Adds monitoring and alerts for the features they build, takes part in the on-call rotation, and handles routine incidents using the runbook.
- Collaboration and communication
- Works directly with product and design to clarify requirements, explains technical constraints in plain language, and writes pull-request descriptions that reviewers can follow.
- Ownership and product impact
- Owns a feature after launch: watches its usage and errors, fixes what goes wrong, and suggests improvements based on what they learn.
- Mentoring and team growth
- Gives careful code reviews, helps onboard new teammates, and pairs with junior engineers on unfamiliar parts of the code.
Senior Engineer: what is expected
Leads larger pieces of work and raises the standard of the team around them. Projects that span several services or several people, and the technical decisions of one team.
- Technical delivery
- Delivers projects that span several services or contributors, sequences the work so that something useful ships early, and removes risks before they block the team.
- System design
- Leads the design of features that span several services, writes down the trade-offs for others to review, and reviews other engineers' designs constructively.
- Quality and reliability
- Leads incident response for the team's systems, writes blameless post-mortems, and makes sure the follow-up actions are actually done.
- Collaboration and communication
- Represents the team in planning, negotiates scope and trade-offs with product, and writes documents that people outside engineering understand.
- Ownership and product impact
- Owns an area of the product end to end, challenges requirements that do not serve users, and proposes work that moves the team's goals.
- Mentoring and team growth
- Mentors one or two engineers deliberately, gives feedback that helps them reach the next level, and takes part in hiring interviews.
Staff Engineer: what is expected
Solves problems that cross team boundaries and steers technical decisions beyond one team. Several teams or a whole product area, including problems that no single team owns.
- Technical delivery
- Unblocks delivery across teams: untangles shared dependencies, builds the tooling or runs the migrations several teams need, and keeps multi-team projects on track.
- System design
- Defines architecture across team boundaries — shared data models, service contracts, build-or-buy decisions — and anticipates how the system must change over the next year or two.
- Quality and reliability
- Finds reliability and security risks that span systems, sets standards such as the testing strategy and service-level objectives, and drives the fixes across teams.
- Collaboration and communication
- Aligns several teams and functions around a technical plan, resolves disagreements between teams, and explains technical risk to leadership.
- Ownership and product impact
- Finds the highest-leverage problems across a product area — including ones no team has claimed — and makes sure they get solved.
- Mentoring and team growth
- Grows senior engineers across teams, shapes the interview process and engineering practices, and is someone others seek out for advice.
Principal Engineer: what is expected
Sets technical direction for the company and answers for its long-term technical health. The whole engineering organisation and the company's technical strategy for the next few years.
- Technical delivery
- Shapes how the whole organisation ships — release practices, platform choices, build and deploy tooling — so that every team delivers faster and more safely.
- System design
- Owns the company's technical strategy: which technologies to bet on, which to retire, and how the architecture should evolve with the business over several years.
- Quality and reliability
- Defines what reliability, security and quality mean for the company, balances them against speed with the leadership team, and is the last escalation point for the hardest incidents.
- Collaboration and communication
- Is a trusted voice in company-level decisions, translates business strategy into technical direction and back, and represents engineering to customers, partners or investors when needed.
- Ownership and product impact
- Connects engineering investment to company results, and argues for or against major bets based on their technical and business impact.
- Mentoring and team growth
- Builds the company's technical culture — how decisions are made and how knowledge is shared — and develops the next generation of staff engineers.
How to adapt this ladder
Match the levels to your titles
If your titles are Developer I, II and III, rename the levels, but keep one level for each real step in scope. Most companies with fewer than 100 engineers do not need a Principal level yet: leave it out until someone is actually doing that job.
Keep five to seven competencies
With more than seven, nobody reads them; with fewer than four, very different people look the same. Merge competencies that you always rate together, and add one only when it would change a real decision.
Rewrite expectations as things you can see
For every cell, ask whether a manager could point to an example from the last six months. Replace words like “strong” or “deep” with what the person actually does, such as “leads incident response for the team's services”.
Test it on real people before you publish it
Ask two or three managers to place their team members on the draft. Wherever they disagree, the wording is ambiguous: fix it, publish the ladder, and agree to review it again in six months.
FAQ
Questions about this ladder
How many levels should a software engineer career ladder have?
Four to six is typical for a company of 20 to 200 people. With fewer, promotions become rare and huge; with more, the difference between two levels is too small to describe. This template uses five: Junior Engineer, Engineer, Senior, Staff and Principal.
Do engineers have to become managers to grow?
No. This is an individual-contributor ladder: Staff and Principal engineers grow in scope and influence without managing people. Use it alongside the engineering manager ladder, so that moving into management is a change of track rather than a promotion.
How do we use the ladder for promotion decisions?
Promote people who already work consistently at the next level, not those who might. Ask the person and their manager to collect concrete examples for each competency of the target level, and compare every case against the same matrix so that decisions stay consistent across teams.
How does the ladder fit into check-ins and 1:1s?
Use it as the agenda of regular check-ins: the person rates themselves against their current level, the manager does the same, and the gaps between the two become a few concrete growth actions for the coming months.
How often should we update the ladder?
Review it once or twice a year, and whenever the company changes shape — for example when you create a platform team or start hiring Staff engineers. Rewrite a cell whenever assessments keep stumbling over it.
Build this career ladder in LadderKit — free
Set up its levels and skills for your team, assess people against them in check-ins, and keep promotion decisions consistent.
Free plan · No credit card required
Related templates
Engineering
QA Engineer
Four levels from Junior QA to Lead QA Engineer, across six competencies from test design to quality practices.
- 4 levels
- 6 competencies
Engineering
DevOps Engineer
Four levels from Junior to Staff DevOps Engineer, across six competencies from infrastructure to developer enablement.
- 4 levels
- 6 competencies
Further reading
- Career ladders
Dual career ladder: individual contributor vs management track
How to run an individual-contributor track next to a management track: where the two diverge, how to line up their levels, and how people move between them without losing ground.
Updated 1 October 2026
- Career ladders
How many levels should a career ladder have?
Four to six levels per track covers most companies of 20 to 200 people. How to pick the number for yours, the signs you have too few or too many, and how to add a level later.
Updated 1 October 2026