Engineering Levels

The ladder is one trunk that forks, then rejoins at the top. Up to Senior, everyone climbs the same rungs: intern, junior, mid, senior. Each is defined by what you can handle independently, not by years of experience or the tools you know. At Lead the path forks: scale through engineering depth (the IC track: Staff, Principal, Architect, the best engineer) or through people (the management track: Manager, Director, VP, the best manager). The two meet again at the top in the CTO: the one best at building product.

The progression is about one thing: how much raw material you can work with before you need structure or direction, and how much leverage your output carries. Through the trunk, the type of work stays the same and only the ambiguity you absorb grows. At Lead and above, the work itself changes: you stop doing it and start platformizing it, building the systems, or the people, that make it happen without you.

At a Glance

The ladder is one trunk that forks, then rejoins. Up to Senior everyone climbs the same rungs; at Lead the path forks, scaling either through engineering depth (IC) or through people (management). The two tracks rejoin at the top: the CTO is the one best at building product. The unit of leverage grows at every step.

        Intern → Junior → Mid → Senior → Lead
                                           │
             ┌─────────────────────────────┴───────────────┐
       IC:   Staff → Principal → Architect   ·  best engineer
       Mgmt: Manager → Director → VP          ·  best manager
             └─────────────────────┬───────────────────────┘
                                  CTO   ·  best at building product

Level	Track	Unit of leverage	What “good” looks like
Intern	trunk	A task	Given a clear problem, solution, and guidelines, executes the task and ships it.
Junior	trunk	A task, end to end	Owns a scoped task without step-by-step direction.
Mid	trunk	A problem	Turns a symptom into a problem and a Build-ready definition.
Senior	trunk	A direction	Finds the right problem from vague direction; shapes the process, not just their own output.
Lead	fork point	A team’s output	Multiplies a team: platformizes how the work gets done, accountable for its throughput and quality, not their own tickets.
Staff	IC	A system across teams	Turns a recurring class of problem into a platform others build on; sets technical standards beyond one team.
Principal	IC	A technical domain	Owns the hardest technical bets in a domain and sets direction within it.
Architect	IC · top	The whole system	Best engineer: owns the architecture end to end and the technical bets that shape the entire product; the standard everyone builds to.
Manager	Mgmt	A team of people	Owns delivery and the growth of each report; turns direction into goals and clears blockers.
Director	Mgmt	Multiple teams	Owns outcomes across teams, the org design, and the managers under them.
VP	Mgmt · top	The function’s people	Best manager: owns the management chain, org health, and delivery across the whole function.
CTO	apex	The whole product	Best at building product: owns how the company builds, the synthesis of engineering depth and leadership.

The spine down the leverage column is the whole story: task → problem → direction → team → systems (IC) or teams (management), then the whole product at the CTO. “Platformize” is the hinge at Lead and above: you stop doing the work and start building the thing, the systems or the people, that makes it repeatable without you.

The Capability Matrix

This is the part you grow against. The ladder tells you your altitude; this tells you your shape.

It is capability-focused, not level-focused. You are not “a Mid”. Within a stage you are a profile: maybe Senior at framing the problem, Junior at getting to the root cause, Mid at backing it with data. Find the role that is honestly you in each capability, and the line comes out jagged. That jaggedness is the point: it shows exactly where to push next.

It is a mirror, not a scorecard. Nobody is graded or ranked here. Each role down is a place to grow into, and the Takeaway says what that role looks like in this stage at a glance.

How to read it. One table per stage of the journey. Rows are roles, columns are the capabilities that matter in that stage. Most engineering craft caps at Lead: past there you do not get better at framing a problem, you grow by setting direction and building the systems that let a whole team do it well. So each table runs Intern to Lead, with a line for what Staff and above do, where leverage moves from doing the work to shaping how the org does it.

Planning

Shaping the quarter: deciding which problems are worth the next 13 weeks. (Quarterly Planning)

Surfacing problems — bringing real, well-formed problems to the planning table.
Sizing — a rough read on how big a problem is to solve.
Sequencing — deciding what to do first, usually by risk and dependency.

Role	Surfacing problems	Sizing	Sequencing	Takeaway
Intern	Sits in to see how bets get made	Does not size yet	Follows the agreed order	Watching how a quarter gets shaped
Junior	Brings a problem they have felt firsthand	Rough gut-feel size on a familiar item	Names an obvious dependency	Adds a problem and a rough size
Mid	Brings a few well-formed problems with impact	Sizes non-trivial items; names the Define-and-test effort	Spots dependencies between items	A real voice in what makes the slate
Senior	Surfaces problems the team has not noticed yet	Sizes confidently; flags what is still unknown	Orders by uncertainty, riskiest first	Shapes the quarter’s priorities, not just their own work
Lead	Runs the problem-sourcing sessions	Calibrates everyone’s estimates	Owns the slate and the capacity split	Owns how the team plans the quarter

Staff and above set the capacity strategy and decide which bets the org makes at all.

Story Mapping

Keeping the living picture of the product: who it is for and what is in flight. (Story Map)

Initiative ownership — being the DRI who drives an initiative to shipped.
Map structure — keeping the board’s backbone and breakdown coherent.
Keeping it honest — making the board reflect reality, not wishful status.

Role	Initiative ownership	Map structure	Keeping it honest	Takeaway
Intern	Updates status on stories they own	Reads the board to place their work	Marks a story done only when it ships	Keeps their own corner current
Junior	DRI on a small initiative, with support	Adds stories under the right activity	Keeps their initiative’s status truthful	Runs a small initiative with help
Mid	DRI end to end; posts the weekly update	Breaks an initiative into sensible stories	Keeps releases matching reality	Owns an initiative from problem to shipped
Senior	Owns a complex initiative across activities	Shapes the backbone; sees when to split a board	Keeps the whole board trustworthy	Trusted with the map’s hardest pieces
Lead	Assigns DRIs and unblocks them	Owns board structure across the product	Holds the team to an honest map	Owns how the team uses the map

Staff and above decide how the org structures its journeys and what a board is allowed to be.

Discover

Finding the real problem before anyone builds. (Discover)

Problem sourcing — finding problems early from data, tickets, and team signals.
Problem framing — writing a sharp, specific, solution-free problem statement.
Getting to the root — going past the first answer to the real cause, and questioning the assumptions baked into the problem.
Backing it with data — proving the problem is real with actual numbers, not intuition.

Role	Problem sourcing	Problem framing	Getting to the root	Backing it with data	Takeaway
Intern	Pulls a specific metric or log when asked	Writes up a problem, but a solution is still hiding in it	Stops at the first plausible cause	Repeats the number they were handed	Learning the moves; give them a question, they bring findings
Junior	Spots recurring patterns in data and tickets	Writes a clear statement once handed the symptom	Asks “why” a few times, to a contributing factor	Pulls the query to check whether a claim is true	Reliable inside a framed problem
Mid	Brings framed candidates before users get loud	Turns a vague symptom into a sharp, specific statement	Reaches the system-level cause, not the event	Backs every claim with real numbers; rewrites it if they disagree	Owns a problem from symptom to clean statement
Senior	Reads the signals continuously; catches what others miss	Frames the right problem out of fuzzy direction	Reframes when the real cause sits higher up	Knows which number would change the call, and gets it	Hand them a fuzzy direction, they return the problem worth solving
Lead	Builds the team’s habit of sourcing from data, not noise	Gives the team the template and examples so everyone frames well	Coaches it in reviews; catches shallow answers	Sets what “checked against data” has to mean before Discover ends	Makes the whole team good at Discover

Staff and above point the org at which problems matter most; the discovery craft itself is assumed.

Define

Designing the solution as a team, PM, PD and PE together. (Define)

Solution design — the shape of the fix: the simplest approach that fully solves the problem.
Build vs buy — write it, buy it, or use open source; proven tech over novel.
Definition doc & green light — the spec the engineer owns, and the sign-off to start Build.
Scoping — what’s in, what’s out, and how big.

Role	Solution design	Build vs buy	Definition doc & green light	Scoping	Takeaway
Intern	Contributes ideas in the session	Learns why we buy instead of build	Follows the doc; does not write the engineer section	Sees what is in and out once told	In the room, learning how solutions get shaped
Junior	Proposes a workable approach	Reaches for a library over custom code	Writes the engineer section, reviewed	Flags an edge case that is out of scope	Writes their part of the design, reviewed
Mid	Finds a simple approach; cuts to the core	Argues build vs buy with real reasons	Owns the engineer section; gives the green light	Draws the in/out line and sizes it	Owns the engineering side of a Define
Senior	Strips the problem to fundamentals and designs the smallest thing that solves it	Picks boring tech and the least code that works	Co-leads; sets the performance bar up front	Reshapes scope to ship value sooner	Co-leads Define; the solution is sound and small
Lead	Pushes back on over-built solutions in review: ‘what’s the version half the size?‘	Sets defaults for the common build-vs-buy calls	Reviews others’ docs and lifts their quality	Coaches scoping so items stay shippable	Makes the whole team better at Define

Staff and above design how whole areas and the overall system fit together, and make the build-vs-buy bets that decide what the product can become.

Build

Directing AI to implement, and making sure the output is right. (Build)

Driving AI — directing AI to produce the implementation, and correcting it.
Standards & quality — making the output consistent, maintainable, and right.
Ship discipline — small PRs, behind flags, instrumented and watched.
Delivery — keeping work time-boxed and milestones honest.

Role	Driving AI	Standards & quality	Ship discipline	Delivery	Takeaway
Intern	Drives AI against explicit acceptance criteria	Follows the patterns already in the codebase	Ships a clearly-scoped task; learning the rollout flow	Completes a given task on their own	Given a clear task and guidelines, executes and ships it
Junior	Drives AI on a scoped story	Matches the codebase’s conventions	Small PRs when reminded	Hits a scoped task; escalates on scope change	Ships scoped work on their own
Mid	Drives AI through complex, ambiguous work	Output is consistent and maintainable	Small PRs behind flags, instrumented, by default	Time-boxes; surfaces slippage early	Ships complex work cleanly, unsupervised
Senior	Gets strong output from messy context	Reviews others’ output for correctness	Watches what ships; mitigates fast	Unblocks others; keeps milestones honest	Directs the build and unblocks the team
Lead	Builds the team’s prompting and knowledge-base habit	Sets the coding standards	Makes flags and instrumentation the default	Owns the team’s delivery cadence	Makes the whole team ship well

Staff and above set the standards, shared libraries, and rollout platform that every team builds on.

Launch

Shipping with discipline, then making sure it landed. (Launch)

Release ownership — owning the rollout plan and getting it out cleanly.
Watching & mitigation — watching what shipped and fixing fast when a number moves.
Confirming impact — checking the feature is used and moved its metric.

Role	Release ownership	Watching & mitigation	Confirming impact	Takeaway
Intern	Executes the release steps assigned	Does not check after shipping	Does not track usage yet	Helps a release go out
Junior	Follows the release plan reliably	Checks the metric and errors when reminded	Confirms the feature is live	Runs a release to plan
Mid	Owns a feature’s rollout behind a flag	Mitigates before investigating when a number moves	Checks the feature is actually used	Owns a feature’s launch end to end
Senior	Owns the release end to end; de-risks ahead	Owns the alerts and dashboards	Ties the launch back to the metric it was for	Nothing about the launch surprises anyone
Lead	Sets the team’s release discipline	Builds the mitigation playbook	Holds launches to a measured outcome	Makes the team’s launches calm and measured

Staff and above own the release and observability platform, and the standard for what “safe to ship” means.

Learn

An honest retro: did it work, and what do we do differently? (Learn)

Outcome review — did it actually solve the problem and move the metric.
Quality review — is what we built maintainable and will it hold under load.
Knowledge capture — leaving a record the next engineer can rely on.

Role	Outcome review	Quality review	Knowledge capture	Takeaway
Intern	Reflects on their own work	Notices what was hard to build	Notes what they did	Learning to look back honestly
Junior	Writes a retro for their own work	Flags the rough spots in what they built	Writes the area’s knowledge note	Records their own lessons
Mid	Checks the feature hit its metric	Reviews maintainability and performance; names regressions	Writes the doc the next engineer relies on	Honest about whether it worked and held up
Senior	Separates “wrong problem” from “wrong execution”	Judges whether it will hold as usage grows	Captures the non-obvious constraints	Turns a result into a real lesson
Lead	Connects results to how the team works next	Sets the quality bar the retro checks against	Makes knowledge capture a team habit	Turns lessons into how the team operates

Staff and above turn patterns across many projects into how the org builds.

Across every stage

These show up everywhere, not in one stage.

Communication — being clear and timely, written and verbal.
Ownership & follow-through — every loose item has an owner and a next action.
Mentoring & raising others — making the people around you better.

Role	Communication	Ownership & follow-through	Mentoring & raising others	Takeaway
Intern	Updates say “making progress”	Leaves loose items without an owner	Focused on their own growth	Learning to work in the open
Junior	Updates say done, next, blocked	Carries their items to a next action	Helps peers when asked	Communicates and follows through on their own work
Mid	Surfaces material changes immediately	Every thread ends with an owner and a next action	The designated reviewer for newer folks	Trusted to keep things moving and clear
Senior	Writes so the reader gets it the first time	Holds themselves to it rigorously	Transfers patterns, not just answers	Raises the clarity and follow-through around them
Lead	Sets the team’s communication norms	Holds the team to clear ownership	Grows several engineers deliberately	Makes the team communicate and own well

Staff and above set how the org communicates and how it grows its people.

This is still a draft: the cells will keep getting sharper, and the management track’s people-leadership stages join next.

Intern

An intern executes. Given a clear problem, a chosen solution, and the technical guidelines, they produce reliable output inside well-defined scope. The goal at this stage is not just to ship: it is to see the full shape of the work, how Discover connects to Define, how Define shapes Build, and how Learn feeds back into the next cycle.

Getting to Junior: The move is from executing tasks to owning them. You are ready when you can take a scoped problem and bring it to completion without being told each step — when you stop needing acceptance criteria spelled out and can derive it yourself from the definition doc.

Junior

A junior can own a task end to end. They work within a well-defined problem and produce consistent output. They ask good questions — not because they are lost, but because they are filling gaps before those gaps become blockers. The distance to mid is not skill. It is how much ambiguity they can absorb before needing the problem clarified.

Getting to Mid: The move is from working within a defined problem to defining the problem yourself. Practice by taking ownership of Discover on smaller problems before the Define session. You are ready when you can take a reported symptom and produce a clear problem statement without being handed one.

Mid

A mid-level engineer can take a problem from symptom to solution. They do not need the problem handed to them — they can frame it, own the definition, and produce a Build-ready doc. They are reliable without supervision and can unblock themselves and others.

Getting to Senior: The move is from framing clear problems to finding the right problems from vague direction. A senior does not wait to be given a problem. Push yourself earlier in Discover: before a problem is brought to you, find and frame it yourself. You are ready when you can receive an abstract direction and produce the problem worth solving.

Senior

A senior engineer operates from direction, not from defined problems. They receive an abstract goal and produce the clarity the rest of the team needs to move. They do not just execute the process — they shape it. They make the work easier for everyone around them.

Beyond Senior the ladder forks, as shown at the top. The detailed expectations for Lead, the IC track (Staff, Principal, Architect, the best engineer), and the management track (Manager, Director, VP, the best manager), broken down by stage and competency, live in their own track docs (in progress). The two tracks rejoin at the CTO, the one best at building product. What they all share is the shift from individual execution to leverage: raising the ceiling for the whole team, through systems or through people.