How do I demonstrate the broader impact expected when moving from mid-level to senior?

Short answer: “broader impact” isn’t more code or bigger features; it’s your impact reaching past the boundary of the code you personally write and making the people and systems around you better.

Short answer

Scope is a radius of influence, not a line count. This is a behavior question, not a code one; what has to change isn’t the amount of work you ship but how you take ownership of it. I wrote at length about this responsibility that doesn’t arrive with the title in the seniority post.

Why

1. The difference isn’t the task, it’s the ambiguity. Mid-level closes well-defined tasks well. A senior takes a fuzzy, undefined problem: defines it themselves, breaks it down, coordinates across people, and manages the ambiguity. That’s the shift from “tell me what to do” to “I’m taking this problem”.
2. A multiplier beats one person’s throughput. A senior’s code gets copied by the team. The work five people now do faster because of you counts as much as the work you did yourself.
3. Seniority isn’t knowing the right answer. It’s asking the right question and defending the decision in writing; someone who shows up with “what should I do?” doesn’t get a seat at the decision table, however good their code is.
4. Doing good work quietly doesn’t earn a promotion on its own. Invisible impact doesn’t exist when promotions get discussed — and framing impact in business terms rather than technical ones is the shortest path to making it visible.

What to do

1. Own outcomes, not tickets. On the next fuzzy piece of work, go to your lead and ask “should I own this?”; once you get a yes, keep progress visible with a short weekly update. Those two sentences are exactly what most people never do.
2. Be a multiplier. Reviews that teach, patterns others follow, docs that unblock juniors — raise the team’s throughput, not just your own.
3. Bring decisions with tradeoffs. Instead of going to your lead with “what should I do?”, go with “there are two options, here are the pros and cons, I recommend B because…”. Write short design docs and ADRs.
4. Take operational ownership. Own the on-call story, the toil and the incidents of an area. Frame impact in business terms, not technical ones: not “I cut p99 latency by 40%”, but “I cut checkout latency and reduced cart abandonment”. Reliability is one of the most visible forms of scope.
5. Make your impact legible. Keep a “brag doc” and tie your work to metrics. The most practical step: ask your lead for a concrete example — “in your eyes, what’s one thing that would demonstrate ‘scope’?” — then turn that into a project.

Bottom line: personally I wouldn’t chase the promotion as an abstract goal; I’d turn it into a concrete move — pick one fuzzy problem that nobody owns and everybody complains about, and own it end to end for a quarter: its definition, its solution, and its rollout across the team. That is your promotion packet. Scope is never handed to you one day; it gets noticed once you start filling it.