Span of control counts reporting relationships. It says little about whether a leader improved delivery, learning, reliability, or the environment in which teams work.
Define the system outcome
Improvement must be attached to an outcome such as shorter feedback, fewer recurring incidents, clearer ownership, stronger onboarding, or more reliable context. Broad claims about transformation are difficult to inspect and easy to overstate.
A leader should state the baseline, intended change, affected users, and evidence that would challenge the intervention.
Look beyond direct reports
Many high-leverage changes cross team boundaries: a shared review standard, a platform capability, a decision protocol, or a reusable learning stream. The leader may not manage every beneficiary.
This makes influence, stewardship, and coalition building visible parts of leadership work.
Prefer durable capability
Solving a crisis personally can be valuable. Changing the system so the crisis is less likely to recur has a larger span of improvement. Leaders create durable capability through better interfaces, ownership, context, automation, and developed judgment.
The test is whether the improvement survives the leader’s direct attention.
Avoid turning it into a vanity metric
Span of improvement is a lens, not a single score. Counting teams “impacted” encourages inflated attribution. Evaluation should combine evidence, user experience, and whether outcomes persisted.
Credit should remain shared because organizational improvement is collaborative.
A review record with shared credit
Use the fictional Northstar case. Mara proposes a clearer cross-team contract because Orders repeatedly waits for client decisions. A useful review records the intervention and its limits:
| Question | Evidence to collect |
|---|---|
| What was the baseline? | Comparable changes with timestamps for requested and received decisions. |
| What changed? | Named recipient, explicit response, escalation, and visible objection state. |
| Who contributed? | Checkout, reliability reviewers, and the owner who maintained the record. |
| What else changed? | Staffing, workload, incident pressure, or task complexity. |
| Did the result persist? | Later changes completed without Mara personally chasing each response. |
The leader deserves credit for creating conditions in which the improvement happened. That is different from claiming every downstream success as personal impact.
Include the intervention that did not work
Suppose the team also tried automated daily reminders. Recipients found them noisy and began ignoring the channel. Retiring that mechanism is part of good stewardship. Hiding it would teach the organization that only success stories belong in a leadership review.
Separate the hypothesis from the evidence. Shorter response time after a process change is suggestive, but staffing or workload may explain part of it. Collect qualitative accounts from the people doing the work and compare like-for-like cases where possible. Do not manufacture causal certainty from a dashboard.
Use a portfolio, not an impact score
One leader may improve onboarding while another reduces a recurring incident class. A single numerical ranking would erase the context that makes each contribution valuable. Review the problem, intervention, evidence, tradeoffs, and durability of a small number of changes.
Look for invisible costs. Did a team’s faster review come from pushing work onto another team? Did the automation save managerial time while increasing the burden on junior engineers? A wider span of inconvenience is not a span of improvement.
For your next review, choose one intervention that survived without your direct involvement and one that should be stopped or revised. Ask affected colleagues to correct your account before it becomes a performance narrative. That makes the model an instrument for learning rather than a new way to accumulate organizational territory.