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

> "Broader impact" isn't bigger features; it's your influence reaching beyond the code you personally write, into the team and the systems. Own one ambiguous, unowned problem end to end.

- Asked: 2026-07-24
- Answered: 2026-07-28
- Asked by: Deniz
- Tags: career, growth
- Source: https://www.muhammetsafak.com.tr/en/just-ask/how-do-i-demonstrate-the-broader-impact-expected-when-moving-from/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** I ship features reliably, I don't get stuck in sprints, and my code quality is good. But my lead keeps telling me I need to show "more scope" and "broader impact" to make senior.

Honestly, I can't quite work out what that means in practice. Should I take on more work, write bigger features, or is something entirely different expected? Concretely, which behaviors do I need to change?


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. Scope is a radius of influence, not a line count.

1. **Own outcomes, not tickets.** 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. **Be a multiplier.** A senior's code gets copied by the team. Reviews that teach, patterns others follow, docs that unblock juniors — you raise the team's throughput, not just your own. The work five people now do faster because of you counts as much as the work you did yourself.

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. Seniority is less about knowing the right answer and more about asking the right question and defending the decision in writing.

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.** Doing good work quietly doesn't earn a promotion on its own; 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.

This is a behavior question, not a code one, so here's the behavior: on the next fuzzy piece of work, go to your lead and ask "should I own this?", and once you get a yes, keep progress visible with a short weekly update. Those two sentences are exactly what most people never do.

**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.