Quarterly Capacity Planning

I’m curious: how do you do quarterly capacity planning?

Here’s what I do:

For each squad, we’ll lay out how many engineers there are and figure out how many person-weeks of capacity we have, subtracting out OOO vacation time.¹

I’m assuming that engineers are always the limiting factor, so other functions’ capacity (PM, PD, Data, etc) are considered free because they are working weeks ahead of engineering.

We’ll then subtract time spent on “Keeping The Lights On”, which is mostly bugs and unexpected small urgent requests, but should also include some time for small product debt and tech debt improvements. It’s also a good place to account for time spent in meetings, if your company is a meetings-heavy culture.²

And then we get to the Opportunity Backlog. Going back to our hypothesis-based roadmaps concept, this is where we carve out how much time we’re going to dedicate to a hypothesis that ties to an OKR.

Remember - we are NOT estimating how long it will take us to build a feature. We’re estimating how much time we think we’ll need to deliver on an OKR outcome. So I would recommend giving your teams longer than it’ll take to build the first thing they want to try, in case they need to do a second or third iteration post-launch to fully hit the KR.³

To recap, the two things this template successfully avoids are: 1) over-allocating capacity because we forget to account for KTLO time, and 2) promising features when we should instead be signing up to explore opportunities in order to deliver outcomes.

The Workshop

This is a newsletter-only section where I share a half-baked idea in hopes that y’all who are smarter than me can work it out with me.

No Workshop today because I’ve got 3 hours of back-to-back-to-back interviews this morning.

In case you missed it, a couple weeks ago I did a fun and sometimes Real Talk podcast with Estee Goldschmidt on corporate lingo and what people really mean.

One of my favorite bands, Lawrence, had their new album launch this morning and it’s pretty great. Check it out here.

And if you’ve ever wanted to go down a rabbit hole, check out this YouTube documentary on competitive Tetris (seriously, it’s a thing) and the 15 year old who is the best Tetris player in the world.

1  Just as an aside, in this example, we probably have too many squads. Three 2-engineer teams is spreading pretty thinly.

2  If the KTLO work is exceeding 30%, it might be worthwhile to look at that as a systemic issue that needs its own OKR to address it. It’s also good to reveal for transparency to stakeholders, who might be wondering why so little new stuff is coming from the team.

3  Topic for another day, but this exercise can sometimes reveal that the way we’ve divided up the squads is no longer matching our product strategy. If you’re finding that some squads are capacity bottlenecked and others don’t have enough high value OKR work to do, that’s a sign.