Expanding scope from team outcomes to organizational outcomes#

TL;DR#

Scope is the single dimension that most cleanly separates senior engineers from staff-plus engineers: senior engineers own outcomes for their team, staff-plus engineers own outcomes that span multiple teams and require judgment calls no single team is positioned to make alone. Expanding scope is a deliberate practice — noticing problems that fall between teams, then claiming and delivering on them — not something that happens automatically with tenure.

The idea#

Every engineering organization is divided into teams for good reasons: focus, clear ownership, accountable roadmaps. But that division creates seams — problems that don't fit neatly inside any one team's charter because they touch several teams' domains, or because no team's roadmap has room for work that benefits everyone but is nobody's explicit job. A shared library duplicated four different ways, an incident caused by two teams' services interacting in an untested way, a migration that only makes sense if six teams move together — these live in the seams.

Senior engineers, by design, are evaluated and rewarded for excellence inside their team's boundary. Nobody's roadmap explicitly says "notice and fix problems between teams" — that's exactly the gap staff-plus scope exists to fill. The transition from senior to staff is, in large part, the transition from "I make my team's roadmap items excellent" to "I notice and address the things that don't belong to any roadmap." This is uncomfortable, because seam problems are ambiguous by nature (there's no ticket for them), often political (crossing into territory other teams consider theirs), and slower to show results (cross-team alignment takes longer than a single team's sprint).

How it works#

Where seams hide#

Four classic locations where organizational-scope problems accumulate: 1. Duplicated effort — multiple teams independently solving the same underlying problem (auth, retries, pagination, notification delivery) slightly differently, each solution a little bit wrong in a different way. 2. Interface friction — two teams' systems interact constantly but the interface between them was never deliberately designed, so every change on either side risks breaking the other. 3. Systemic risk — a failure mode that no single team's on-call rotation is positioned to see, because the failure only manifests from the interaction of several systems (a classic distributed-systems cascading-failure pattern). 4. Strategic gaps — a capability the business will need in 12-18 months that no current team's roadmap includes, because it doesn't obviously belong to any one team yet.

Claiming scope deliberately#

Because nobody assigns this work explicitly, staff-plus engineers have to notice it and claim it — which is a skill, not a passive byproduct of experience. Larson's practical approach: 1. Notice via pattern-matching across contexts. A staff engineer who sits in on multiple teams' planning, incident reviews, and design docs (rather than only their own team's) is positioned to notice a pattern repeating across three different teams that no single team member would ever see, because no one on any individual team attends all three meetings. 2. Write it down before acting. A short document ("I've noticed X happening in teams A, B, and C; I think the root cause is Y; here's what I'd propose") turns a vague hunch into something concrete other people can react to, agree with, correct, or push back on — see staff-engineer/06. 3. Get explicit buy-in before treating the scope as yours. Claiming cross-team scope without checking with the affected teams' leads and managers reads as overreach, even when the underlying observation is correct. A quick "I think this is worth someone owning — is it okay if I take a first pass?" conversation avoids that. 4. Deliver something concrete, then hand off maintenance. Staff-plus scope-expansion projects should produce an artifact that outlives the initial push — a shared library, a documented standard, a fixed piece of infrastructure — with a clear owner for ongoing maintenance once you move to the next seam. Staying the permanent owner of everything you've ever fixed is how staff-plus engineers get organizationally stuck (see staff-engineer/12).

Worked example. A staff engineer notices, across three unrelated incident reviews over two months, that every incident involved a service silently retrying a downstream call in a way that amplified load during an outage instead of backing off. No team owns "retry behavior" as a whole. The engineer writes a two-page document naming the pattern, proposes a standard retry library with jittered exponential backoff, gets sign-off from the three affected tech leads, builds the library with a fourth engineer who's interested in owning it long-term, and migrates the first team's usage personally as a working example for the others to follow. Three months later the library is used by eight teams and retry-storm incidents have measurably dropped. The staff engineer then hands ongoing maintenance to the volunteering engineer and moves to the next seam.

Scope and formal authority are different things#

Expanding scope does not require a title change or a reporting-line change. It requires proving, through delivered work, that your judgment on cross-team problems is trustworthy — see staff-engineer/07 on leading without formal authority. Titles tend to catch up to scope that's already being exercised well, not the other way around.

Pros#

Directly addresses problems no single team is incentivized or positioned to fix, which otherwise silently accumulate as technical and organizational debt.
Builds exactly the track record (cross-team judgment, delivered results, voluntary trust from other teams) that promotion committees look for — see staff-engineer/05.
Multiplies impact: one seam fixed well benefits every team that touches it, unlike team-scoped work whose benefit is capped at one team.

Cons#

Ambiguous by nature — there's rarely a manager assigning this work, so it's easy to either under-claim (never expand scope, stay comfortably team-bound) or over-claim (grab scope aggressively and alienate the teams whose territory you're stepping into).
Slower feedback loop than team-scoped work — cross-team alignment, buy-in, and rollout take months, which can feel discouraging compared to the weekly cadence of shipping team features.
Real risk of becoming the permanent, unscalable owner of everything you've ever noticed and fixed, if you don't deliberately hand off maintenance.

Alternatives#

Staying purely team-scoped and going deeper technically instead — a valid choice for engineers who want to remain a very strong individual contributor without taking on cross-team ambiguity; this is a legitimate senior-engineer (or Principal Engineer in a narrow-expert sense) path, just not the staff-plus path this book describes.
Letting a dedicated platform or infrastructure team own all cross-cutting concerns — some orgs solve the "seams" problem structurally, by having a permanent team whose entire charter is cross-cutting work, rather than relying on individual staff engineers to notice and claim scope opportunistically. This works well at larger scale but doesn't eliminate the need for someone to notice which seams matter most.
Manager-assigned cross-team initiatives — instead of an engineer organically noticing and claiming scope, a director or VP can explicitly assign a cross-team initiative to a staff engineer (see staff-engineer/09); this is faster to start but depends on leadership already being aware of the seam, which is often exactly what's missing.

When to use it#

Deliberately widen your attention — sit in on other teams' planning and incident reviews, read design docs outside your team, ask "who else has this problem?" whenever you fix something for your own team — once you've established strong, trusted execution at the team level and have some bandwidth beyond your team's immediate roadmap.

When NOT to use it#

Don't chase cross-team scope before your own team's work is in good shape, or before you've built any track record — showing up in other teams' territory with unproven judgment reads as overreach rather than leadership, and it starves your own team of the execution they need from you. Depth first, breadth second.

Key takeaways / mental model#

Picture your organization as a set of overlapping circles (teams) with gaps between them. Senior-engineer excellence lives entirely inside one circle. Staff-plus impact lives disproportionately in the gaps — and getting there requires actively looking at the gaps (attending outside your circle), writing down what you see, getting buy-in before acting, delivering something durable, and then handing off maintenance so you're free to look at the next gap.

Self-check questions#

Name a "seam" problem at your own company — something that falls between team boundaries and that no single team is incentivized to fix. Which of the four seam categories (duplication, interface friction, systemic risk, strategic gap) does it fall into?
Why does Larson emphasize getting explicit buy-in from affected teams before treating cross-team scope as "yours," rather than just doing the work and presenting the result?
Describe the risk of becoming the "permanent owner" of every seam you've ever fixed. What's the concrete mechanism (in this lesson) for avoiding that trap?
Contrast expanding scope organically (noticing and claiming it yourself) versus having a manager assign you a cross-team initiative. What does each approach require to work, and what can go wrong with each?

References#

Staff Engineer: Leadership Beyond the Management Track (Will Larson), Chapters 1-2 and the "Getting Started as a Staff Engineer" material.