Engineering levels define the expectations, scope, and impact associated with each stage of an engineer's career. A well-designed levelling system provides clarity on what it means to grow, ensures fair compensation, and helps managers make consistent promotion decisions. This guide covers how to design, implement, and operate a levelling framework that works for your engineering organisation.
Understanding Engineering Levels
Engineering levels - often labelled as L1 through L7, or using titles like junior, mid-level, senior, staff, principal, and distinguished - represent a progression of scope, autonomy, and impact. At lower levels, engineers focus on well-defined tasks within a single codebase. As they advance, they take on broader scope: designing systems, influencing architecture across teams, and eventually shaping the technical direction of the entire organisation.
The distinction between levels is not primarily about technical skill. A senior engineer and a staff engineer may have similar coding abilities, but the staff engineer operates at a fundamentally different scope - thinking about organisational problems, cross-team dependencies, and long-term technical strategy. Understanding this shift from individual output to organisational impact is critical for managers who are evaluating and developing their engineers.
Most organisations maintain separate tracks for individual contributors (IC) and managers, converging at some senior level. This dual-track approach ensures that engineers do not have to move into management to advance their careers. However, the tracks should be genuinely equivalent - if your most senior IC level carries less influence or compensation than the equivalent management level, engineers will perceive the IC track as a dead end.
- Levels should reflect increasing scope, autonomy, and organisational impact - not just technical skill
- Maintain parallel IC and management tracks with genuine parity in compensation and influence
- Use five to seven levels for most organisations - too few and growth feels stagnant, too many and distinctions become meaningless
- Define clear expectations for each level across multiple dimensions: technical, delivery, communication, and leadership
- Ensure levels are consistent across teams to enable fair cross-team comparisons and transfers
Designing Your Levelling Framework
Begin by defining the axes along which engineers grow. Common axes include technical skill, system thinking, execution and delivery, communication and collaboration, and leadership and influence. For each axis, describe what proficiency looks like at every level. The descriptions should be specific enough to differentiate between adjacent levels but general enough to apply across different engineering specialisations.
Pay particular attention to the transition points that engineers find most challenging. The move from mid-level to senior typically requires shifting from 'I can build what is asked' to 'I can determine what should be built.' The move from senior to staff requires shifting from 'I lead projects' to 'I identify and drive the right projects.' These transitions involve fundamentally different ways of thinking, and your level descriptions should make those shifts explicit.
Consider how your levels map to compensation bands. Each level should have a defined salary range with meaningful overlap between adjacent levels. This allows for progression within a level (which is how engineers spend most of their career) and avoids the problem of engineers feeling they must be promoted to receive meaningful pay increases.
Calibration and Promotion Processes
Calibration is the process by which managers collectively review their level assessments to ensure consistency. Without calibration, the same performance might be rated as 'meeting senior expectations' by one manager and 'exceeding mid-level expectations' by another. Regular calibration sessions - typically quarterly or biannually - are essential for maintaining fairness and trust in the levelling system.
Run calibration sessions by having managers present evidence for their proposed ratings. Focus on specific examples of work and impact rather than general impressions. Other managers should ask probing questions and offer comparisons to engineers on their own teams. The goal is not to reach perfect consensus but to identify and discuss disagreements, which often reveal inconsistencies in how levels are being applied.
For promotions, require a written case that demonstrates sustained performance at the next level - not just a single impressive project. The promotion case should include specific examples mapped to the level expectations, feedback from peers and stakeholders, and a narrative explaining how the engineer's scope and impact have grown. Having a structured promotion process reduces bias and ensures that promotions are based on evidence rather than advocacy.
Common Challenges with Engineering Levels
Title inflation is a persistent problem, particularly in competitive hiring markets. When companies hand out senior titles to attract candidates, it devalues the title internally and creates expectations mismatches. Combat this by being transparent about your levelling criteria during the hiring process and by conducting rigorous level assessments during onboarding.
Another challenge is the 'senior squeeze' - a large concentration of engineers at the senior level with limited advancement opportunities. This happens when the bar for staff or principal is set too high or when there are not enough organisational problems to justify those higher-level roles. Address this by creating opportunities for senior engineers to take on staff-level work, even informally, and by recognising that the number of higher-level positions should grow as the organisation scales.
Engineers who have been at the same level for many years present a delicate management challenge. Some are content and performing well - not every engineer needs or wants to advance. Others are frustrated and may be under-levelled. Have honest conversations about expectations and aspirations, and avoid treating a lack of promotion as a failure. A senior engineer who consistently delivers excellent work at scope is enormously valuable.
Practical Implementation Tips
Publish your levelling framework internally and, if possible, externally. Transparency builds trust and enables engineers to self-assess and drive their own development. Include concrete examples at each level - anonymised case studies of actual promotions are far more useful than abstract descriptions.
Train all engineering managers on how to use the framework consistently. New managers in particular often struggle with level assessments. Pair them with experienced managers for their first few calibration cycles, and provide written guidance on common edge cases and how to handle them.
Revisit your levelling framework annually. As your organisation grows, the expectations at each level will naturally shift. A senior engineer at a fifty-person startup operates at a very different scope than a senior engineer at a five-thousand-person company. Your levels should evolve to reflect this reality rather than remaining fixed to the original definitions.
Key Takeaways
- Engineering levels should reflect scope and impact, not just technical ability
- Maintain genuine parity between IC and management tracks
- Calibration sessions are essential for consistent and fair level assessments
- Require evidence-based promotion cases mapped to explicit level expectations
- Publish your framework and revisit it annually as the organisation evolves
Frequently Asked Questions
- How many engineering levels should an organisation have?
- Most organisations work well with five to seven levels on each track. Fewer than five and engineers feel there is not enough room for progression. More than seven and the distinctions between adjacent levels become unclear, leading to constant debates about whether someone is an L5 or an L6. The right number depends on your organisation's size - a fifty-person startup might need only four levels, whilst a large enterprise might justify seven or eight.
- Should engineering levels be tied to specific job titles?
- Yes, but keep the titles simple and widely understood. Titles like Junior Engineer, Software Engineer, Senior Engineer, Staff Engineer, and Principal Engineer are recognisable across the industry and make it easier for engineers to understand their market positioning. Avoid overly creative or company-specific titles that confuse external recruiters and make it harder for engineers to assess equivalent roles elsewhere.
- How do you handle engineers who are strong in some dimensions but weak in others?
- Levelling decisions should be holistic, not based on the lowest or highest dimension. An engineer who excels technically but struggles with communication is not automatically held at a lower level - but they do need to demonstrate minimum proficiency across all dimensions for the target level. Use the competency matrix to identify specific gaps and create targeted development plans. Most engineers have an uneven profile, and that is normal.
- How often should engineers be promoted?
- There is no fixed cadence, but typical timelines are one to two years at junior and mid levels, two to three years at senior, and three to five years or more at staff and above. Rushing promotions leads to engineers who are unprepared for the increased scope. However, if an engineer is clearly performing at the next level for a sustained period - typically six months or more - delaying their promotion damages trust and retention.
Get the Engineering Manager Field Guide
Our field guide includes detailed levelling frameworks, promotion case templates, and calibration facilitation guides for engineering managers at every stage.
Learn More