Capacity Governance. Saying No on Purpose

Why capacity is a constraint you set on yourself and how to defend it.

Most founders treat the "max active projects" field like a system preference, set it once, forget it, move on. That's a misuse. Capacity is the single most strategically loaded setting in Foundry, because it's the number that decides what you say no to.

Everyone says yes to too much. The constraint isn't ambition, it's a missing forcing function. Capacity governance is that forcing function: a self-imposed limit that turns "should I take this on?" from a feeling into a math problem.

The mechanism is simple. You set a max. Every time you create an active project past that max, OVERLOAD_ALERT fires. The alert doesn't block creation, it just makes the cost visible. Most overload happens because the cost was invisible until it was too late.

Three questions to size your capacity:

1. How many projects did you ship in the last 90 days? Not started, shipped to a defined completion state. That number divided by 3 (months) is your honest throughput. Most founders ship 1-2 projects per quarter, which sets your reasonable in-flight count at 2-3.

2. How many days per week do you have for project work? Subtract meetings, support, sales, ops. The remainder, divided by ~5, is your true working week. Below 4 working days, you should probably run 1 active project plus maintenance.

3. What broke last time you ran 5+? Almost everyone has run too many before. What slipped: the projects themselves, the commitments to people, your health, all three? That's your evidence, use it.

A useful starting frame: set the max one lower than feels comfortable. The discomfort is the sign that you're forcing a real choice instead of leaving room for everything.

Setting a max is the easy part. Defending it when a new opportunity shows up is where governance happens.

The two acceptable responses to a new opportunity when you're at capacity:

Park something first. If the new opportunity is genuinely more important than something currently active, park the lesser project explicitly, then add the new one. The act of parking makes the trade-off real.

Defer the opportunity. Most "must do this now" opportunities don't require now. Add it as a high-value PARK idea with a revisit date, and decide next quarter.

What's not acceptable: silently exceeding the limit, dismissing OVERLOAD_ALERT, or telling yourself "this one is different." The limit is meaningless if you treat it as advisory. It works because you commit to honoring it, then live with the trade-offs.

Your capacity changes. A new hire raises it. A demanding client lowers it. Health, family, market conditions, all of these shift the honest number.

Build a quarterly capacity review into your operating cadence:

• Audit the last quarter. Did you actually ship at the rate the capacity assumed?


• Look at the energy mix. Was the portfolio sustainable, or did you burn out by month 2?


• Set next quarter's number. Adjust up only if the evidence supports it. Adjust down without apology if not.

Dismissing OVERLOAD_ALERT. Each dismiss is a vote against your own judgment. Don't.

Treating capacity as a feature toggle. It's a strategic stance. Revisit it quarterly, adjust deliberately, defend it daily.

No declared Focus Lane. Capacity governance without a Focus Lane is half the system. Pick the lane, even reluctantly, and let everything else be visibly secondary.

Capacity Discipline