Creating an Engineering Ladder for a 20-Person Team

Your engineers are asking "how do I get promoted?" and you do not have an answer. This is not a nice-to-have HR question. It is a retention problem. Engineers who do not see a clear growth path leave for companies that have one. Building an engineering ladder does not require months of work or an HR department. It requires clarity about what good looks like at each level.

Why a 20-person team needs a ladder

At 20 engineers, you probably have a mix of junior, mid-level, and senior engineers. Without a ladder, promotions are subjective. One manager promotes someone for shipping a big feature. Another manager promotes someone for mentoring junior engineers. A third manager never promotes anyone because "titles do not matter." The result is inconsistency, perceived unfairness, and attrition.

A ladder creates a shared language for expectations at each level. It tells engineers what they need to demonstrate to advance. It gives managers a framework for making consistent promotion decisions. And it shows candidates during hiring that you take career development seriously.

Keep it simple: four levels

For a 20-person team, four levels are enough. More than that and the distinctions become meaningless. Here is a practical framework:

Software Engineer (L1): Can complete well-defined tasks independently. Writes clean, tested code. Asks good questions when stuck. Contributes to code reviews. Scope: individual tasks within a feature.

Software Engineer II (L2): Can own a feature end-to-end. Makes good technical decisions with minimal guidance. Mentors L1 engineers. Identifies and raises risks proactively. Scope: features and small projects.

Senior Software Engineer (L3): Can own a significant system or product area. Makes architecture decisions that affect the team. Influences technical direction. Unblocks others regularly. Improves team processes and practices. Scope: systems and team-level impact.

Staff Software Engineer (L4): Can own cross-team technical initiatives. Drives technical strategy for a product area. Mentors senior engineers. Resolves ambiguous problems that span multiple teams. Influences company-level technical decisions. Scope: organization-level impact.

Evaluation criteria

Each level should be evaluated across four dimensions. Technical skill: the quality and complexity of the work they produce. Execution: their ability to deliver reliably and on time. Communication: how effectively they share context, write documentation, and participate in discussions. Impact: the scope and significance of their contributions to the team and the product.

Write two to three bullet points per dimension per level. Be specific. "Writes good code" is not useful. "Writes code that handles edge cases, includes tests, and passes code review with minimal feedback" is useful. Specific criteria reduce subjectivity and give engineers clear targets to work toward.

The IC vs management fork

At L3 (Senior), engineers should have the option to continue growing as individual contributors or to move into management. Both paths should be equal in compensation and prestige. If management is the only path to higher compensation, you will end up with engineers who become managers not because they want to lead people but because they want a raise. That is bad for them and bad for their reports.

At a 20-person team, you may only have one or two management positions. That is fine. The IC track gives senior engineers a path to Staff Engineer and beyond without requiring them to manage people. This is critical for retaining your best technical talent.

Rolling it out

Map your current engineers to the new levels. Do this with your engineering managers collaboratively, not unilaterally. Share the ladder with the full team, explain the criteria, and invite feedback. Make it clear that the ladder is a living document. You will refine it as you learn what works and what does not. Schedule calibration sessions quarterly where managers discuss borderline cases and ensure consistency across teams.