The 60/30/10 Portfolio Capacity Split
Allocate team capacity across incremental wins, operations, and audacious bets before priorities compete
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 93%
Ryan Salva runs multiple GitHub product lines against a fixed default distribution of team capacity: roughly 5-10% on uncertain, audacious research bets, 25-30% on operations that keep in-market products meeting customer expectations, and the remaining ~60% on incremental improvement of shipped products. The point is to reserve the moonshot slice by default so it never loses the weekly argument against urgent operational work, while accepting that the majority of capacity harvests payoff from bets made years ago. The split is a portfolio-manager posture, not a startup one — at a startup you're all-in on one bet and the percentages collapse.
Origin
Salva's own operating rule as a product and portfolio manager across multiple GitHub product lines (Copilot, Codespaces, Actions, Advanced Security); it sits on top of the three-horizon planning language GitHub uses, which Salva explicitly declines to attribute to Microsoft as a corporate standard.
Core principles
- 01Reserved capacity beats intended capacity — bold bets only happen if a slice is ring-fenced in advance
- 02Most of your capacity should be realizing payoff from bets you already made 1-4 years ago
- 03Operations is a first-class budget line, not overhead you squeeze into the gaps
- 04The exact percentages shift with world, org, and technology circumstances — the discipline of having a split does not
- 05The split is a large-team instrument; a startup is effectively 100% one bet
How to run it
- 1
Establish the default split
Set the baseline as ~5-10% uncertain/experimental research bets, ~25-30% operations (keeping in-market products meeting customer expectations), and the remaining ~60% incremental improvement of in-market products.
Pro tip Write the split down as a default rather than negotiating allocation fresh each planning cycle — the whole value is that it resists the pull of urgency.
Watch out If your team is small enough that 5-10% is less than one person, you don't have a research slice; you have a rounding error.
- 2
Ring-fence the bold-bet slice organizationally
Put the 5-10% in a separate team with separate expectations (at GitHub, GitHub Next) rather than as a side-of-desk allocation inside a product squad, so operational pressure cannot silently consume it.
Watch out A slice held inside an operational squad is the first thing sacrificed the moment an incident or a customer escalation lands.
- 3
Fund operations explicitly
Budget the 25-30% for uptime, reliability, security, and customer-expectation maintenance on shipped products, so this work isn't implicitly stolen from the incremental slice.
Pro tip Track when ops actuals exceed the budget — persistent overrun is a signal of accumulated technical debt, not a staffing problem.
- 4
Spend the majority on compounding the bets you already won
Direct the ~60% to iterative improvements on in-market products, treating it as the mechanism that realizes payoff from big bets placed one to four years ago.
Watch out Teams that romanticize the moonshot slice under-invest here and never actually convert an incubated hit into a business line.
- 5
Re-derive the split when circumstances change
Revisit the percentages when organizational, technology, or market circumstances shift — the answer isn't always the same, but the reserve for audacious bets should survive every revision.
In the wild
GitHub Next, the ring-fenced team working on second- and third-horizon projects, was where Copilot originated. It was funded as a low-confidence, long-dated bet with no expectation of near-term revenue — precisely the slice most large orgs cut first.
→ Copilot went from research project to a generally available, paid product in roughly 18 months, with multiple EPD squads then carrying the roadmap forward.
Salva notes that at the startups he worked in, the team was effectively only a big bet — there was no meaningful operations or incremental slice to defend.
→ At startup scale, the percentages invert to an all-in posture on 'that one proverbial lottery ticket' and the portfolio framework doesn't apply.
Common mistakes
Treating the moonshot slice as slack capacity
If the 5-10% is the buffer you raid when a release slips, you have no research function — you have an aspiration. It has to be reserved before the quarter starts.
Importing the percentages into a startup
Salva is explicit that the distribution works when you have larger teams. A startup running 60% incremental on a product with no market is optimizing the wrong thing.
Underfunding incremental work in favour of new bets
The ~60% is what realizes payoff from prior bets. Starving it means a portfolio of half-converted experiments and no compounding product.
Is it for you?
Best for
Product/portfolio leaders at mid-to-large companies running multiple product lines who keep losing their innovation budget to operational urgency
Not ideal for
Early-stage startups pre-product-market-fit, where the whole company is the bold bet
From the transcript
“You can kind of think of those like those really uncertain bets as being 5% to 10% of the team's capacity.”
“About 25, maybe 30% of the team's capacity should generally be on just operations.”
“That works when you have larger teams, though. At startups, you know, where we were pretty much only a big bet, obviously your percentages get…”
From the episode
The role of AI in product development
Ryan J. Salva (VP of Product at GitHub, Copilot)