Case Study 2: The Promotion That Took Three Cycles

"Every cycle the feedback was the same three words — 'more strategic impact' — and every cycle I responded by shipping more. It took two years to understand that I was answering a different question from the one being asked."

Executive Summary

A mid-level data engineer was declined for senior promotion three times over two years, with consistent feedback: "strong execution, needs more strategic impact."

Their response each time was to ship more and faster, which is the §40.3 stall exactly.

cycle   what they did                          outcome
1       shipped 11 models, 2 pipelines         declined
2       shipped 14 models, 3 pipelines,        declined
        reduced build time 40%
3       shipped 6 models -- and did four       PROMOTED
        other things

Cycle 3's output was smaller by every conventional measure and it was the one that succeeded, because the four other things were the evidence §40.3 describes and the first two cycles contained none of them.

The most important of the four was a thing they did not build.

Skills applied: §40.2's levels as questions; §40.3's four kinds of senior evidence; the running document; and the honest question of whether the senior work exists at all.

Background

The engineer was good at the mid-level job, and that is not faint praise: they owned three pipelines end to end, carried their on-call, wrote tests, and their models did not break.

The promotion criteria at their company, as written:

"Senior engineers demonstrate impact beyond their immediate scope, influence technical direction, and raise the effectiveness of those around them."

Which is accurate, standard, and nearly useless as a guide to action — a complaint the engineer made loudly and which was fair.

What they heard in each debrief:

cycle 1  "the work is strong. We need to see more strategic impact."
cycle 2  "same feedback. Try to influence outside your own scope."
cycle 3  -- promoted

The Problem

The engineer's model of the situation was that they needed to do more of what they were doing.

⚠️ Failure Mode — hearing "more impact" as "more output"

The word "more" is doing the damage, and the feedback is partly to blame for using it.

What "more strategic impact" is asking for is a different kind of evidence, not a larger quantity of the existing kind — §40.2's levels: the mid engineer is judged on the component and the senior on the outcome. Fourteen models instead of eleven is more of the component.

The engineer's cycle-2 response makes the mistake visible. They shipped 14 models, 3 pipelines, and reduced the nightly build time by 40% — which is a genuinely good piece of work and is still the mid-level job done extremely well. Nobody had asked whether the build should be faster; it was slow, they made it fast, and it was the right thing to do.

Compare it to the cycle-3 item that mattered most, which took two weeks:

```text cycle 2: made the nightly build 40% faster -> a component, improved. Nobody asked. Real value.

cycle 3: established that a requested real-time dashboard was not needed, using Chapter 29's four questions, and wrote up why -> a thing NOT built. A decision changed. Nobody asked for that either -- and it is a different category. ```

Both are unrequested initiative. The difference is that one improved something the team had decided to do and the other changed what the team decided to do, which is the boundary between the two levels.

The reason this is hard to see from inside: the first one is more satisfying, more measurable, and more clearly yours. A 40% improvement is a number. "We did not build the thing" is an absence, and absences do not appear in any system that tracks output.

The Analysis

Between cycles 2 and 3 the engineer did one thing differently, and it was not technical: they asked their manager for an example.

"Can you show me something a person did that got them promoted here? Not the criteria — an actual thing somebody did."

The manager produced three, and all three were the same shape:

- someone who stopped a six-month project by showing the requirement
  had changed
- someone who wrote the standard that three teams now follow
- someone who noticed two teams building the same pipeline and got
  one of them cancelled

🔎 Read the Plan — ask for an instance, not a criterion

The written criteria and the actual bar are different documents, and this is not cynicism — the criteria are necessarily general because they apply to everyone, and the bar is a set of remembered examples in the heads of the people who decide.

"Show me something a person did" converts one into the other in about four minutes, and it works for three reasons:

  • It is answerable. Managers can recall specific promotions easily and struggle to operationalize the criteria on demand — the same asymmetry as Chapter 39 §39.10's "what is the last thing you deleted?"
  • It is not a negotiation, so it does not trigger a defensive answer. You are asking for information, not for a decision.
  • And it reveals the pattern rather than the rule. All three examples were about something not happening — a project stopped, a duplication cancelled, a standard that removed a class of decisions. No amount of reading the criteria produces that observation.

The engineer's reaction was that the examples felt unfair, because all three depended on circumstance: you cannot stop a six-month project unless there is one to stop. That objection is half right and worth taking seriously (§"The Honest Part" below), and the half that is wrong is that the opportunities are more common than they look once you are watching for them.

Ask this question of your manager. It costs one meeting.

Then they went looking, and the running document (§40.3) is what made it possible.

They had been keeping one for four months, without a promotion in mind, and it turned out to already contain two of the four items — a design review where they had changed someone's approach, and a question they had asked that stopped a metric being defined twice. Neither had felt significant at the time.

The Decision

Cycle 3's four items, none of which is a shipped model:

One: a thing not built. A real-time dashboard request, examined with Chapter 29 §29.11's four questions. The answer was that hourly was sufficient, the requester agreed once the cost was stated, and the engineer wrote a one-page note saying so. Two weeks, and it saved a quarter.

Two: a standard that removed a class of decisions. After the third argument about whether a business rule belonged in silver or gold, they wrote the two-paragraph test (Chapter 34 §34.3) and got it into the pull-request template. Three teams now use it.

Three: a problem nobody had asked about. Running Chapter 30's grep for metric definitions, unprompted, and finding two metrics defined three ways.

Four: someone else's outcome. They spent about an hour a week for a quarter with a new joiner, and the new joiner's onboarding document (§40.6) was the artifact that got cited.

📐 Design Decision — write it down as it happens, because you will not remember what you prevented

The running document is the mechanism, and the engineer is emphatic that cycles 1 and 2 probably contained some of this evidence and it was lost.

The asymmetry is memory, not effort:

text at review time you will remember what you shipped you will NOT remember the meeting where you changed somebody's design the question that stopped a bad decision the thing you talked someone out of

Shipped work leaves artifacts — a pull request, a dashboard, a model. Prevented work leaves nothing at all, which is exactly why it is undervalued and exactly why it must be recorded manually.

The format that worked, and it is deliberately low-effort:

text 2026-04-14 design review: argued against the extra join in fct_session; the author agreed; would have been a fan-out. ~2h saved x N runs, and a wrong number avoided. 2026-04-22 asked "who consumes this?" on the churn export request. Nobody. Request withdrawn.

Two lines, written the same day, taking ninety seconds. The engineer's rule is that anything that made them think "hm, that was useful" goes in the file within the hour, without judging whether it counts.

And the second use, which they did not anticipate: it is the source for Chapter 39's behavioral round. Four stories with numbers, already written down, which is otherwise the hardest part of interview preparation.

The Honest Part

Cycle 3 succeeded partly because the opportunities existed.

The real-time dashboard request happened to arrive. The silver-versus-gold argument happened for a third time. A new joiner happened to join.

🏭 From the Pipeline — when the level does not exist, and how to tell

The engineer's objection — that the examples depended on circumstance — is half right, and §40.3 names the case where it is entirely right: some organizations do not have senior work available.

How to tell the difference, because "there are no opportunities" is also what it feels like when you are not looking:

```text THE WORK EXISTS AND YOU ARE NOT DOING IT requests arrive with room to question them there are arguments about how things should be done somebody occasionally cancels something new people join

THE WORK DOES NOT EXIST every request arrives fully specified, from outside the team architectural decisions are made elsewhere or were made years ago nothing has been cancelled in memory the team's roadmap is somebody else's backlog ```

The second column is Chapter 39 Case Study 2's company, and it is also §40.9's negative signals arriving from the inside.

The test the engineer used, and it took one attempt: pick the next request that arrives and ask what decision it serves. If the question is welcomed, the work exists. If it is treated as obstruction, you have your answer — and in that case, per §40.3, you cannot demonstrate a level the job does not contain, and the correct response is to leave rather than to try harder.

Their team passed. The dashboard requester was pleased to be asked, and that single interaction is what told them cycle 3 was worth attempting.

What Happened

Cycle 1 Cycle 2 Cycle 3
Models shipped 11 14 6
Pipelines 2 3 1
Things not built 0 0 1
Standards written 0 0 1
Unprompted problems found 0 0 2
Someone else's outcome 0 0 1
Running document kept no no yes
Outcome declined declined promoted

Cycle 3 shipped 57% fewer models than cycle 2 and was the successful one.

Two things the engineer says in retrospect:

"The feedback was accurate and unusable." "More strategic impact" was a correct description of the gap and gave no instruction. The instruction came from asking for an instance, and it took four minutes.

And: "I was not underperforming for two years." Cycles 1 and 2 were good work. They were evidence for a level they already had, which is the trap: doing your current job excellently is the default strategy, it is genuinely valuable, and it is not evidence about the next one.

Lessons

  1. ⚠️ "More impact" is asking for a different kind of evidence, not a larger quantity of the existing kind. Fourteen models instead of eleven is more of the component.

  2. Cycle 2's 40% build-time improvement was good work and the wrong category. It improved something the team had decided to do; cycle 3's item changed what the team decided to do — and that boundary is the two levels.

  3. The first is more satisfying, more measurable, and more clearly yours. A 40% improvement is a number; "we did not build it" is an absence, and absences appear in no system that tracks output.

  4. 🔎 Ask for an instance, not a criterion. "Show me something a person did that got them promoted." It is answerable, it is not a negotiation, and it reveals the pattern rather than the rule — all three of the manager's examples were about something not happening.

  5. The written criteria and the actual bar are different documents, and that is not cynicism: the criteria are general because they apply to everyone, and the bar is a set of remembered examples.

  6. 📐 Write it down as it happens. Shipped work leaves artifacts; prevented work leaves nothing, which is why it is undervalued and why it must be recorded manually. Two lines, ninety seconds, within the hour, without judging whether it counts.

  7. The running document's second use is Chapter 39's behavioral round — four stories with numbers, already written.

  8. 🏭 Distinguish "the work exists and I am not doing it" from "the work does not exist." The test: ask what decision the next request serves. If the question is welcomed, the work exists; if it is treated as obstruction, you cannot demonstrate a level the job does not contain.

  9. The feedback was accurate and unusable, and the instruction came from a four-minute question.

  10. Two years were not underperformance. They were evidence for a level already held — which is the trap, because doing your current job excellently is the default strategy and is genuinely valuable.

Questions for Discussion

  1. The feedback "more strategic impact" was accurate and gave no instruction. Write a version that would have been actionable without being a checklist to game.

  2. Cycle 2's build-time improvement was unrequested, valuable, and the wrong category. Was it wasted?

  3. Ask your own manager for an instance rather than a criterion. What did you learn, and did the examples share a shape?

  4. Start the running document today. In two weeks, how many entries does it have — and how many would you have remembered without it?

  5. Run §"From the Pipeline"'s test on your next incoming request. Was the question welcomed?

  6. The engineer's cycle 3 depended on a dashboard request arriving. How much of a promotion is circumstance, and what does that imply about timing a move?

  7. Is "a thing you did not build" a fair promotion criterion? It is unmeasurable, unverifiable by anyone not in the room, and this chapter calls it the strongest artifact. Argue against.