Levels

Growing engineers to where they want to be is one of the most important jobs of an engineering manager. Why? Not creating space for growth and not clearly describing the ladder leads to attrition, and attrition is knowledge loss.

I love our engineering team at Mondoo. It's a good vibe, no politics, everyone is just here to generate good code and deliver a great product. Everyone is here to get it done.

Here's what our engineering ladder looks like. You'll notice there are only a few levels here - we don't hire more junior than level 5 right now and we haven't had anyone grow to a level 8 yet. Level 8 will be the next one to define.

Each level is defined by the size of the thing an engineer owns: L5 owns tasks, L6 owns a project, L7 owns technical direction. This covers the individual-contributor track only.

At a glance

Read across a row to see how one expectation grows from level to level.

	L5 Senior SWE	L6 Staff SWE	L7 Senior Staff SWE
Owns	Assigned tasks	A project, start to finish	Technical direction
Breaking down work	Usually needs help splitting work into shippable chunks	Breaks the project into shippable, valuable chunks and sequences them. Works across backend and UI to define the functionality needed to ship the whole thing	Breaks a large architectural change into shippable chunks and communicates those; makes the changes while keeping the product running
Design	Proposes smaller-scale changes	Designs the project, writes the ADR, and ships the whole thing on a timeline. Proposes changes that land on monthly planning	Proposes larger architectural changes, communicates about them, and drives them to completion. Proposes changes that rearchitect the product for the better and land on monthly planning as large objectives
Working with others	Works within the eng team, working with both backend and UI engineers; consults with product and UX to ship the work	Works within the eng team and works directly with UX, product and CS to not only implement but also improve designed features	Aligns several teams and stakeholders. Notices when planned work will overlap or contradict. Takes time to review work from other engineers without being prompted
Operability	Ships working, tested code	Ships docs, a Grafana dashboard and a runbook with every new feature. Code is performant and scalable.	Drives scalability and entropy improvements
Leveling others up	Reviews code, helps teammates	Helps others accomplish their work by being a source of advice and an example	Guiding voice. Builds tools, patterns and docs that raise everyone's skills

L5 — Senior Software Engineer

An L5 reliably executes the work they're given, in almost any part of the codebase.

Defining qualities

• Executes on assigned work and finishes it without close supervision.
• Can work on almost anything: backend, GraphQL, migrations, the occasional UI change.
• Usually still needs help breaking work into consumable, shippable chunks.
• Proposes small changes: a refactor, a missing test, a better query, a fix to a sharp edge they hit.

What it looks like

• Takes a well-scoped ticket from description to merged PR with tests.
• Finds the root cause of a bug instead of patching the symptom.
• Asks for help at the right time: not on day one, not on day ten.

Ready for L6 when they break down their own large work without help, and start carrying the non-code parts of a feature (talking to product, docs, the grafana dashboard) without being asked.

L6 — Staff Software Engineer

An L6 owns a larger project from beginning to end, including everything around the code.

Defining qualities

• Breaks the project into shippable, valuable chunks and decides the order.
• Works across backend and UI to define the functionality needed to ship the whole thing, decides how the rollout should happen, and works directly with UX and product to get them right.
• Writes the design up front (an ADR where the change needs one) and the docs when it ships.
• Proposes changes that land on monthly planning.
• Ships the Grafana dashboard, alerts and a runbook with every new feature, so they can tell whether it works in production and others can operate it.

What it looks like

• Product hands them a problem, not a spec, and they come back with a plan.
• Other engineers can pick up chunks of their project without a long handover.
• The project finishes: rolled out, flag cleaned up, dashboard watched, not left at "merged".

Ready for L7 when the changes they propose outgrow a single project, and other engineers start adopting their patterns and tools.

L7 — Senior Staff Software Engineer

An L7 changes how the system and the team work, beyond any single project.

Defining qualities

• Breaks a large architectural change into shippable chunks, communicates the plan, and makes the changes while keeping the product running.
• Proposes larger architectural changes and drives them to completion, across teams and quarters.
• Proposes changes that rearchitect the product for the better and land on monthly planning as large objectives.
• Aligns several teams and stakeholders, and notices when planned work will overlap or contradict.
• Reviews other engineers' work without being prompted.
• Is the driving force behind scale and entropy improvements: the hot path stays cheap, dead code and one-off janitors get retired, recurring failure classes get closed for good.
• Creates solutions that help everyone level up their engineering skills and knowledge: tools, shared patterns, docs, skills, review checklists.

What it looks like

• Spots a problem nobody assigned (a class of bugs, a cost curve, a slowing build) and fixes it at the root.
• Their designs become the default other engineers reach for.
• Leaves the codebase measurably simpler or cheaper to run than they found it.