Oh My Learning

Sponsoring projects so teams can move faster independently

staff-engineers-path/10 staff drafted · 7 min read

The Staff Engineer's Path (Tanya Reilly), Chapter 6 - "Good Influence" (sponsorship vs. mentorship)

Prerequisites staff-engineers-path/07

Sponsoring projects so teams can move faster independently#

TL;DR#

Sponsorship means using your standing, credibility, and visibility to open doors for other people's work — advocating for a project in rooms they're not in, lending your name to unblock it, connecting it to resources — as distinct from mentoring, which is about developing a person's skills directly. Good sponsorship makes a team more capable of moving without you, not more dependent on you.

The idea#

Mentorship (staff-engineers-path/11) improves what a person can do. Sponsorship improves what a person or team is allowed and resourced to do — it operates on the organizational barriers around someone's work, not on their skill. A brilliant engineer with a genuinely good project idea can still fail to get it prioritized, staffed, or taken seriously if nobody with organizational standing vouches for it. Staff engineers, by virtue of their scope and reputation, often have exactly the kind of standing that makes the difference — and using it on someone else's behalf, deliberately, is sponsorship.

This matters especially for people and projects that are systematically under-recognized: engineers earlier in their career, people from underrepresented groups whose contributions are statistically more likely to be overlooked in promotion and visibility decisions, or unglamorous-but-important infrastructure work that doesn't naturally attract attention the way a flashy user-facing feature does.

How it works#

What sponsorship actually looks like in practice#

  • Advocating in rooms the person/team isn't in — mentioning a team's strong migration work in a leadership review they weren't invited to, explicitly attributing the credit to them by name.
  • Lending credibility to unblock resourcing — a staff engineer's public endorsement ("I've reviewed this proposal, the approach is sound, I think it deserves headcount") can move a stalled project past a resourcing committee faster than the original proposer's advocacy alone, purely because of the sponsor's standing.
  • Connecting people to opportunities — recommending a mid-level engineer, by name, to lead a visible cross-team initiative instead of taking the visible role yourself.
  • Publicly attributing credit accurately — actively making sure the people who did the work are the ones recognized for it, especially in settings (leadership updates, all-hands) where credit tends to flow to whoever is already most visible.

Worked example. A mid-level engineer on a platform team has quietly built a strong internal tool that several teams have started using informally, but it has no headcount and isn't on any roadmap — it survives on the engineer's personal initiative. A staff engineer who's seen the tool's impact writes a short note to the relevant director: "this tool is now depended on by three teams; I think it deserves a real roadmap slot and I'd back that with my own review of the technical approach," and makes a point of naming the original engineer as the person who should lead it, not offering to take it over herself. The project gets resourced. Critically, the staff engineer's involvement ends there — she didn't take the project, she opened the door and stepped back, leaving the original engineer with more visibility and more organizational standing than before.

Sponsorship vs. taking over#

The failure mode that distinguishes sponsorship from something else is taking credit or taking control. If "sponsoring" a project results in the sponsor becoming its visible owner, or the original engineer's role shrinking, that's not sponsorship — it's absorption, and it actively harms the person it was supposed to help by taking away their growth opportunity and their visibility. Good sponsorship is measured by whether the sponsored person/team ends up more independently capable and visible, not less.

Sponsorship compounds trust, but spends it too#

Every act of sponsorship is also a bet on your own credibility — vouching for a project or a person publicly means your reputation is now somewhat entangled with theirs. This is a real cost, which is why sponsorship (unlike mentoring, which is nearly always safe to offer generously) requires genuine conviction: you should sponsor because you've actually evaluated the work and believe in it, not merely because someone asked.

Pros#

  • Unlocks resourcing, visibility, and opportunities that skill alone often doesn't secure, especially for people who are systematically under-recognized by default organizational dynamics.
  • Scales a staff engineer's impact through other people's advancement, rather than through their own personal output — a direct instance of the "leveling up others" pillar (staff-engineers-path/01).
  • Builds a durable, reciprocal trust network across the org: people who've been well-sponsored tend to sponsor others in turn, compounding the effect over years.

Cons#

  • Costs real organizational credibility/capital, which is finite — sponsoring something that turns out badly has a real cost to the sponsor's future credibility, so it can't be done indiscriminately.
  • Easy to get wrong by accidentally taking over rather than opening a door, especially for engineers used to being the one who executes; the instinct to "just do it myself" undermines the entire point.
  • Sponsorship's benefits are often invisible to the person it helped least directly — a project getting resourced looks, from outside, like it succeeded "on its own merits," so sponsorship's leverage is easy to underrate or overlook when evaluating a staff engineer's own impact.

Alternatives#

  • Mentoring — develops a person's skill directly rather than removing organizational barriers around their work; the two are complementary, not competing (see staff-engineers-path/11), and a well-rounded staff engineer typically does both, aimed at different people/situations.
  • Direct management advocacy — a manager sponsoring their own report is a related, narrower mechanism, limited to people in their reporting line; staff-engineer sponsorship is valuable partly because it can cross team/org boundaries a manager's advocacy usually can't.
  • Formal nomination/award programs — structured, process-based recognition (spot bonuses, formal award nominations) that some orgs use instead of relying on informal sponsorship; more consistent and auditable, but slower and less responsive to opportunities that arise outside a formal cycle.

When to use it#

Sponsor a person or project when you've genuinely evaluated the work and believe in it, and when your standing can plausibly move a real organizational barrier (resourcing, visibility, priority) that the person/team couldn't move alone — especially for underrecognized contributors and unglamorous-but-important work.

When NOT to use it#

Don't sponsor work you haven't actually evaluated just because you were asked — an uninformed endorsement risks your credibility and can backfire on the person you meant to help if the work doesn't hold up under scrutiny. And never let sponsorship slide into taking over: if you notice yourself becoming the visible owner of something you set out to sponsor, that's the signal to step back.

Key takeaways / mental model#

Mentoring changes what someone can do; sponsorship changes what they're allowed and resourced to do, using standing you have that they don't yet. Do it by opening doors and attributing credit accurately, then stepping back — if you end up owning the thing you sponsored, you've absorbed it, not sponsored it.

Self-check questions#

  1. Recall a time someone's good work went unrecognized or unresourced despite being genuinely good. What specific organizational barrier (not a skill gap) was actually in the way, and what would sponsorship targeted at that barrier have looked like?
  2. Explain, using your own example, the difference between sponsoring a project and quietly taking it over. What's the observable difference in outcome for the original owner?
  3. Why does sponsorship cost the sponsor something (credibility/capital) in a way that mentoring mostly doesn't? What follows from that difference in how freely you should offer each?
  4. Name a category of work or person in your organization that's plausibly under-sponsored relative to its actual value. What's one concrete sponsorship action you could take?

References#

  • The Staff Engineer's Path (Tanya Reilly), Chapter 6: "Good Influence" (sponsorship vs. mentorship).