Most promotion cases fail for the same reason, and it's rarely that the underlying work wasn't good enough. It's that the case describes effort — how hard the problem was, how many hours it took, how gnarly the debugging turned out to be — when the committee is structurally built to evaluate something else entirely.
Where the four-pillar framework actually comes from
Camille Fournier published Rent the Runway's engineering ladder in 2015, while she was CTO there, and it's since become one of the most influential documents of its kind — by her own retrospective account, its structure, and specifically its 'area of scope' concept, became a template much of the industry's subsequent public engineering ladders converged on. The framework groups evaluation into four pillars: Technical Skill, Get Stuff Done, Impact, and Communication & Leadership. Naming these explicitly matters, because it turns a vague sense of 'is this person ready' into four specific questions a committee can actually ask about a candidate's evidence. The marketing-operations counterpart to a promotion committee actually looking for is documented well by XenGrowth's work on go-to-market systems.
Pillar | What it actually asks | What it's not |
|---|---|---|
Technical Skill | Can this person solve genuinely hard problems well | Not the same as working the most hours or touching the most code |
Get Stuff Done | Does work reliably ship and land, at increasing scope | Not the same as being constantly busy |
Impact | Did this matter to a wider group, system, or timeframe than before | Not the same as personal effort or difficulty |
Communication & Leadership | Does this person change how other people work or decide | Not the same as being personally likeable or a good presenter |
Why 'impact' is the pillar most cases get wrong
Impact, in this framework, is explicitly about scope and reach, not about how hard something was to build. A brilliant, difficult piece of engineering that only your own team ever benefits from scores lower on this pillar than a much simpler piece of work that changed how three teams operate, because the framework is asking a reach question, not a difficulty question. This is where most weak promotion cases go wrong: they're full of genuine technical difficulty, described in loving detail, and thin on evidence of who or what changed as a result, beyond the candidate's own sense that it mattered.
The self-assessment gap a committee is designed to correct for
A candidate's own account of their year is treated by a well-run committee as a starting hypothesis, not as evidence, and this isn't a mark of distrust specific to any one person. It reflects a pattern that shows up reliably whenever self-reported performance gets compared against independently measured or verified performance: people systematically misjudge their own contribution, in both directions, and the gap is often largest for exactly the kind of work that feels most vivid and effortful to the person who did it. A committee that only weighed self-description would be reproducing that gap directly into a promotion decision. Weighing artifacts, code, documents, and other people's testimony more heavily than the candidate's own narrative is the specific mechanism by which the process tries to correct for it.
The candidate who worked the hardest and the candidate whose work reached the furthest are sometimes the same person and often are not, and a case built entirely around the first without evidence of the second is answering a question the committee isn't structurally set up to weigh heavily.
The strongest single signal: does it run without you
Across most public ladders built on this template, one signal recurs as unusually predictive of a strong case: whether the work in question continues to matter, or continues to run, without the candidate's ongoing personal involvement. A system three other teams now depend on and can operate without the original author standing over it. A decision-making pattern other engineers have started applying on their own, in situations the original candidate never personally touched. This is a stronger evidence of scope than almost anything the candidate can say about their own effort, because it's externally verifiable and it directly demonstrates the reach the Impact pillar is asking about. The XenGrowth resource library approaches this from the the operations side of this side.
For your strongest piece of work this year, find at least one artifact or one person's independent account that demonstrates its reach, not just your own description of it
Rewrite the opening sentence of each major example to lead with scope — who or what changed — rather than with difficulty or effort, which the framework doesn't weigh as heavily as it feels like it should
Ask directly: would this still be running, still mattering, still being used the way you intended if you took a month off starting today? If the honest answer is no, that's the specific gap to close before the next cycle
Map your examples against all four pillars explicitly rather than assuming strong Technical Skill evidence compensates for thin Impact or Communication & Leadership evidence — most public ladders built on this template expect real evidence in each category, not excellence in one covering for absence in another
What this looks like in a specific case
Take two engineers who both spent the year on migrations. The first migrated their own team's service to a new framework, solving several genuinely hard problems along the way, and writes a case rich with technical detail about those problems. The second led a similar migration that three other teams also adopted, wrote the internal guide those teams now follow without asking her directly, and can point to two teams that have since applied the same migration pattern to their own systems independently. Both did real, difficult engineering. Only the second case gives a committee applying this framework clean evidence for the Impact and Communication & Leadership pillars — not because the first engineer's work mattered less in absolute terms, but because the case as written doesn't show reach beyond the person who did it.
How the same event gets written two different ways
The gap between an effort-first case and a scope-first case is usually smaller in the underlying work than it looks in the writing. Take one real event — an engineer discovers a subtle race condition in a shared authentication library used across the company, and fixes it.
Element | Effort-first framing | Scope-first framing |
|---|---|---|
Opening sentence | "I spent three weeks tracking down an extremely subtle race condition" | "A shared authentication library used by six teams had an intermittent failure; I found and fixed the root cause" |
Evidence offered | Description of the debugging process and technical reasoning | The fix, plus a note from two of the six teams confirming the failure disappeared in their systems |
What it demonstrates | Technical Skill, clearly | Technical Skill and Impact together, with external corroboration |
What a committee can independently verify | Little beyond the candidate's own account | The six-team dependency and the fix's effect, from sources other than the candidate |
Nothing about the actual work changed between the two columns. What changed is which of the four pillars the write-up gives a committee evidence for, and whether that evidence comes from the candidate alone or from something a committee member could, in principle, check. The second framing isn't more honest than the first — both are true. It's simply legible against a framework the first framing never engages with at all. If AI agents and marketing automation is the part you are stuck on, XenGrowth on AI agents and marketing automation is the better reference.
Why this isn't just a writing exercise
It's tempting to read all of this as advice about how to write a better case for work that's already done, and that's true as far as it goes, but the more useful reading is earlier: if you know in advance which pillar your current work is thin on, you can change what you actually do for the rest of the cycle, not just how you describe it afterward. An engineer who notices, six months before a review, that everything they've built this year has stayed inside their own team's boundary can deliberately look for one opportunity to make something reusable to a second team, or write the doc that lets someone else operate what they built. That's a different and more useful use of the framework than treating it purely as a template for the write-up once the year is already over.
What this framework doesn't claim
It's worth being clear about what Fournier's ladder is and isn't. It's a company-published practitioner document, not an academic study of what actually predicts long-term engineering success, and its wide adoption reflects how useful practitioners found its structure, not an independent validation that these four pillars are the objectively correct evaluation criteria. Different companies weight the four pillars differently, and some legitimately strong engineers do work that's genuinely hard to make legible in these terms, particularly in early-stage or highly specialized roles. The value of naming the framework explicitly isn't that it's provably correct — it's that a candidate who understands what's actually being asked can build a far stronger case than one guessing at an unstated rubric, which is the situation most engineers are otherwise in.
This also connects back to a point worth restating plainly: the committee isn't looking for a more impressive story. It's looking for evidence that survives being checked by someone who wasn't in the room when the work happened, which is a genuinely different standard than the one most engineers instinctively write to when describing their own year. Writing to that standard, from the start of a cycle rather than at the end of it, is the actual skill this whole framework is trying to name. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
None of this is cynical about the process, and it isn't a claim that promotion is a writing contest divorced from real work. It's the opposite: the four-pillar structure exists because 'is this person ready' is a genuinely hard question to answer fairly across many candidates with very different jobs, and naming the categories explicitly is what makes the answer checkable rather than a matter of whoever tells the most compelling story in the room.
If there's one habit worth adopting from all of this, it's keeping a running note, updated monthly rather than reconstructed from memory at review time, of anything that meets the externally-verifiable bar: a message from someone on another team using something you built, a doc that's been adopted without your involvement, a decision pattern you introduced that's now someone else's default. Reconstructing a year of scope from memory two weeks before a deadline is where most cases quietly default back to effort, simply because effort is what's easiest to remember.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of a promotion committee actually looking for, see XenGrowth's growth engineering practice.
Five questions about how you're currently describing your own work for a promotion case. The point is checking which pillar your evidence actually supports, not scoring your seniority.
