Engineering ladders are the best-written documents of the four, and the ones companies actually run contain the worst structural mistake in the set. Seven titles on one line, three of them management and a fourth that leads without managing. An engineer who wants more scope has exactly one door, and it leads away from building.
That is the mistake, and it is worth stating plainly at the top because everything else about these documents is better than the equivalents in design or product. They are more concrete, stricter about evidence, and less prone to the vague scope language that makes a design ladder unusable in a calibration room. The failure is structural rather than editorial, which is why good writing did not catch it.
What the field has to work from
The published ones
Engineering publishes more of these than every other function combined, and has for a decade. swyx keeps an index of them; progression.fyi keeps another.
Medium’s Snowflake is the interesting fork, and it is open source: it refuses the single line altogether and draws a person as a shape across sixteen tracks. It solves the problem below better than anything else on this list, and it trades away the thing a ladder is for, which is being able to say two people are at the same level and mean it. Note, too, that every document on this list forks the management track. The single line is what survives the trip from a published ladder to a company’s spreadsheet.
The good document, and the bad habit
Rent the Runway's ladder, posted by Camille Fournier in March 2015, is the first that was widely shared and it is still the one most others descend from. It drew a clear line between the individual and management tracks, which is worth saying now because the failure below is not hers. Four pillars: technical skill, getting things done, impact, and communication and leadership. Dropbox organizes seven tiers around impact. CircleCI runs one framework for every engineer rather than splitting by specialism, which is closer to what I would argue for than anything in design.
Fournier has also made the sharpest criticism of the genre, and it did not come from design: ladders fail when they reward output instead of scope and influence. That was true when she wrote it and the last two years have made it the whole problem.
What companies copy is not the document. It is the level names, and the level names are where the flaw lives. Almost every engineering ladder I have run or read, including the one I inherited, goes: junior, mid, senior, tech lead, engineering manager, director, VP. The canonical ladders fork. The ones on the wall of the average company do not, because a list of seven titles is easier to type into a spreadsheet than a fork is.
Three of those seven are management roles and a fourth is the door to them, all on one line with three individual ones. An engineer who wants more scope has exactly one door, and it leads to managing people.
Design ladders forked the management track off decades ago and are smug about it. Engineering has the better documents in every other respect, and then flattens them at the point of use. The result is a profession that converts its strongest builders into adequate managers and calls it a promotion, and it does it without anybody deciding to.
The fix is not complicated. The tracks fork at the third level, they run in parallel, and a manager and a principal at the same level are paid the same and are equally hard to replace. If your management track reaches higher than your individual track, you have already decided which one is the real one, and everybody on the team can read that decision.
One door, or two
The ladder we ran put seven titles on a single line, four of them on the management side of the fork. The fix is not more titles. It is a fork, at the level where a person first has a choice to make, with neither side outranking the other.
What we ran
One line. The only way up after senior is through other people.
A staff engineer has nowhere to appear on this document. The best builder in the company is a Tech Lead, one row below a job that is not building.
What it should be
Same six levels, forking at three. Same pay band on both sides of the fork.
The titles are conventional and mostly do not matter. What matters is that E5 on the left and E5 on the right are paid the same and are equally hard to replace.
The part nobody's ladder scores
An engineer working on anything user-facing makes interface decisions constantly. What the empty state says. Whether that is a modal or a page. What happens on the slow connection, on the failed request, on the third attempt. Where focus goes after the thing submits. Most of these are made in the moment, most are never reviewed by anybody, and most of them are correct.
Not one of them is scored anywhere. The engineering ladder measures technical skill, delivery and system design. The design ladder, at least the one I wrote, listed front-end development as one of twelve craft skills a designer could be capable in. Between the two documents, the work happening exactly on the line between them is credited by neither.
I have watched this from both directions. When we moved Grammarly from a browser extension to native Mac and Windows applications, the interesting question was not a design question at all: it was where writing actually happens, and whether we could be there. Most of the cost of answering it landed on engineering, and most of the decisions that determined what the thing felt like were made by engineers, at speed, inside implementation. Their ladder had nothing to say about any of it.
Later, working as a design engineer embedded into other companies' teams, I saw the mirror image: designers shipping production code that their own ladder scored as a nice-to-have. Same seam, two blind documents.
The clearest lesson I have on this came from a room with twenty people in it. Lyft's multimodal project had designers, researchers and product managers producing excellent work and no decision, and when I cut it to seven I did not select for seniority. Two of the seven were mid-level. I selected for the willingness to hold a position in a room where the CEO might disagree. Nothing on the engineering ladder, or the design one, would have told me which seven to pick. The document scored how much people had shipped. What I needed was how many of them could end an argument, and that number was written down nowhere.
What changed, and why it is now urgent
This was a slow leak until implementation got cheap. Now two thirds of designers do work that used to belong to product and engineering. The share of designers taking part in development doubled in a year, to 41 percent, and developers doing design work went from 44 to 60. Half of designers have pushed generated code to production. And almost none of those companies have changed a word of how any of it is evaluated.
The wall between design and engineering was never really about skill. It was about implementation cost. A designer could not ship the thing, so somebody else did, and the ladder recorded a handover. That cost is what fell, and the handover is what disappeared with it.
Which leaves engineering ladders measuring, with some precision, a division of labor that has partly stopped existing.
The next division is already visible. When The AI Daily Brief laid out the team roles of a shop running on agents this July, two of the ten were routinely staffed by agents themselves, and one of the human ones was new: the orchestrator, who runs a fleet and keeps the output coherent. Nothing on any engineering ladder scores the decision an orchestrator actually makes, which is what an agent may decide without a person looking. That is a decision right, it is graded on the axis above, and it is going to be the level-defining decision for a lot of engineers within a couple of cycles.
What I would score instead
Decision rights, not seniority in the stack. What does this engineer decide alone? Which architectural calls, which interface calls, which trade-offs against a product goal? Write it as a list of decisions. If a promotion does not lengthen that list, it is a retitle.
Judgment density. Whether adding them to a room adds throughput or adds decisions. This is the axis that catches the most common false positive in engineering: the person who owns the highest-traffic service, whose uptime is perfect, who reviews every significant change personally, and whose team cannot decide anything without them. Everything visible looks excellent. What they have built is a system that requires them, which is the opposite of the level they are usually arguing for.
Range, replacing the specialism ladder. Not whether they can do design, which is not the question, but which decisions they are trusted to make outside their own lane. An engineer who can see the funnel does not need a product manager to justify a decision. That is a level, and no ladder currently records it.
What survives them. Not documentation. What is in the system: the constraint that holds when they are on leave, the default that another engineer follows without asking, the thing that makes a bad change hard to merge.
And opinions held. Named, contestable positions about what should exist, defended when defending them cost time or scope. Anybody can now generate a plausible implementation of almost anything. What is scarce is somebody who will say which one should exist and put their name on it.
The six axes, in engineering’s language
Three of the six levels. Each cell is a decision rather than an artifact, which is what lets the same six axes serve a designer, a researcher and a product manager without being rewritten.
The E4 column is the one worth staring at. Every cell in it describes a refusal, and none of them appear on a ladder that levels on scope. The E5 column is the other tell: every cell is something that works while the person is absent, which is the exact inverse of the false positive above.
What this costs to get wrong
A single-door ladder does not announce itself. Nobody decides to turn their best builders into adequate managers; the document simply offers one route and people take it, and two years later the deepest technical judgment in the company belongs to somebody spending their week on headcount plans.
The unscored seam is the same shape. Nobody decides that the most valuable work in the organization should belong to no one. It happens because every ladder was written when that work sat clearly inside one lane, and none of them were rewritten when it stopped.
Both are cheap to fix and expensive to leave.
The whole system
You can read the argument for free. Running it is the hard part.
An essay can tell you the six rows stopped working. It cannot sit in the room in November when two managers disagree about the same person and neither can say why. That is what the workbook is for: one shared core across Engineering, Product, Research and Design (EP(R)D), six levels defined by what a person decides, and the mechanics to grade against them without the cycle turning into a negotiation.
Six levels defined once, by what a person decides alone. The shaded band is the overlap, where most of the work now belongs to no single lane. The marks to the left of each cell are doors: a move sideways at the same level, which is a transfer and not a demotion.
Written to be opened during a cycle rather than read once: on the page, as a PDF set to print, and with the templates as a spreadsheet.
Define it
Grade against it
Run the cycle
Or read section two, free.
v1. The cycle, the calibration room and the evidence standard are the ones I have run at companies of 25, 250 and 2500 people; the six axes are new. One payment, every revision by email.
One of four, each taking a function through the same framework; the system they share is set out in full in the workbook. The others are on design, product and research. Written from having inherited, run and rebuilt leveling and review cycles at three companies of very different sizes, and against the public frameworks that preceded them: the levels framework in Org Design for Design Orgs by Peter Merholz and Kristin Skinner, Rent the Runway’s engineering ladder, and Ravi Mehta’s product competency toolkit. Figures from the AI in Design Report 2026 and Figma’s State of the Designer 2026.
© 2026 Renato Valdés-Olmos