Engineering publishes better career ladders than any other field in this series. Then many companies flatten the fork when they copy them. Seven titles end up on one line, with management occupying the upper half. The engineer who wants more authority is left with one visible move: stop building and manage people.
The source documents usually avoid this mistake. They are concrete, strict about evidence and clearer than most design or product ladders. The problem appears when their titles are copied into a spreadsheet and the branch disappears.
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.
GitLab, Wise, Monzo and Block matter because they show frameworks in use rather than as finished diagrams. Wise is especially relevant to the shared-core argument: senior engineers are expected to own product as well as technical direction, which makes the overlap with Product visible rather than treating it as a soft skill. Monzo is unusually clear that evidence should demonstrate impact and scope instead of completing a checklist. Medium’s Snowflake is the other 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.
Companies often copy the titles and leave the structure behind. The ladder I inherited read: junior, mid, senior, tech lead, engineering manager, director, VP. The published frameworks branch into IC and management paths. The spreadsheet on the wall was easier to type, so it became a single line.
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.
Fork the tracks at the third level and run them in parallel against comparable authority thresholds. Matching numbers can still carry different work and pay; discipline, geography and market matter. When the management track reaches higher than the individual track, everybody can read which path the company considers the real one.
One door, or two
The ladder we ran put seven titles on a single line, four of them on the management side. Fork the track when a person first has a choice to make, and let both paths reach the same authority.
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 authority thresholds, forking at three. Each role is still priced for its discipline and market.
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.
Boris Cherny’s original post and replies describe the prototyper, builder, sweeper, grower and maintainer as working temperaments in teams that use coding agents. Engineers also need to decide what an agent may do without a person looking, how its work is checked and when it must stop. Those are decision rights. Most ladders still have nowhere to record them.
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 across lanes. Record the decisions an engineer is trusted to make outside engineering. An engineer who can read the funnel may own a sequencing call with Product. That trust can support a level; merely listing design or product skills cannot.
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.
Take the engineering argument into calibration
One ladder, two paths, and doors that stay open at every level.
The Leveling workbook defines six comparable levels before Engineering separates into individual-contributor and management work. Its guide makes decision rights concrete, keeps leadership from silently outranking building, and gives calibration a consistent evidence standard.
One of five essays taking a function through the same framework; the system they share is set out in full in the workbook. The others cover design, product, research and marketing. 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