Fungible Capacity

The pool model: plan, commit, release

Standing teams are the default structure for technology work, and they earned that position honestly. Expertise in a codebase took months to build, handoffs between teams were expensive, and the cost of reforming a team exceeded the cost of keeping one idle between projects. For years the standard advice was to build lasting, long-lived teams, and it was right at the time.

When delivery time falls toward zero, the calculus inverts. The cost of keeping a team together past the end of its useful work now exceeds the cost of reforming it, because idle capacity in a standing team is invisible. A team that finished its highest-value work keeps operating on lower-value work, because the team exists and needs something to do. No mechanism ever surfaces the question "is this the most valuable use of these people?" The answer is always "they are assigned to this team."

Fungible capacity is the alternative. One pool of people and agent fleets, managed by the Flow Council, committed to Efforts for their duration, and released when the outcome is met.

Nobody owns a system. That absence is what makes capacity fungible. An organization that restores system ownership has lost the ability to move capacity, whatever the operating model says.

The pool cycle: Plan, Commit, Execute, Release contrasted with standing teams
The pool cycle: Plan, Commit, Execute, Release contrasted with standing teams

How the pool works

Plan. Each week the Flow Council sizes the human and agent capacity available against the Now horizon, net of leave, standing obligations, and the unreleased portions of Decision Owners' weeks. Commitments are made against what exists, not against headcount. An organization with twenty people on the roster and twelve genuinely available has twelve units of capacity. Planning against twenty produces overcommitment, then partial staffing, then Efforts that cannot close the daily cycle.

Commit. Capacity goes to an Effort for as long as the Effort needs it. Commitment is to an Effort, not to a duration, which is how the model absorbs the reality that some outcomes take four days and some take four months. No sprint boundary forces artificial scope decisions, and no end-of-project date creates pressure toward "done enough." Commitment is also what makes the team stable mid-Effort: nobody is pulled for another project, because a team mid-Effort holds spec history, domain context, and harness knowledge that does not survive a handover.

Release. The moment an outcome is accepted, the people and the fleet return to the pool, and the Flow Council redeploys them, usually within the same week. Release is the half most organizations skip, and skipping it is what rebuilds standing teams. If capacity never returns to the pool, within two quarters you have permanent teams with new labels and the model has failed silently. So release is an explicit, minuted Flow Council action with a date. Not drift. Not something that waits to be noticed.

Release depends on someone declaring the outcome met, and Efforts drift when nobody owns that call. The Decision Owner proposes closure when the acceptance criteria are satisfied, and the Flow Council confirms it at calibration, because an owner close to the work will sometimes keep going past the point of value. An Effort with no landed increment for a week is raised at calibration either way. That pattern usually means the outcome was reached and nobody declared it, the Effort is blocked, or it should never have entered Now.

Fungible, not flexible

The word carries a specific meaning, and it is not that people are interchangeable. It means the organizational structure does not prevent redeployment. No team boundaries to negotiate across, no system ownership to transfer, no backlog to hand over. The Flow Council still considers expertise when forming teams. A Decision Owner with deep payments knowledge is more valuable on a payments outcome. The pool model just means the decision is made on value rather than on structure.

If anything, the opposite of interchangeability is true. When execution compresses, the specific knowledge and judgment an outcome needs become more important, not less. What becomes fungible is the organization's ability to form the right combination around an outcome and release it when the work is done. That distinction is what keeps the pool from becoming a staffing spreadsheet: the Flow Council moves capacity, the Domain Knowledge Network routes non-fungible expertise, the Decision Owner holds business judgment, and the Fleet Lead directs machine production.

Nobody owns a system

This is the sentence that causes the most resistance, so it deserves direct treatment.

In a standing-team model, a team owns a system. They know its history, its quirks, its debt. That knowledge is real value, and it is also a binding constraint. Only that team can work on that system, so work on that system queues behind that team's capacity, so the portfolio cannot move capacity to where it is most valuable.

In the pool model, the codebase, its conventions, and its constraints live in the knowledge graph, available to any team that needs them. The harness, built over prior Efforts, proves the system still works. A new team starting on a system they have never touched inherits the accumulated checks and the documented context instead of starting from scratch. That inheritance is what makes fungibility practical. Without the harness and the knowledge graph, putting a new team on an existing system would be reckless. With them, it is a managed transition measured in hours.

Three different things are owned in this model, and by three different parties. The Decision Owner owns the outcome. The team owns the Effort, spec to landed increment, no handoffs, dissolving back into the pool at acceptance. The Domain Knowledge Network owns correctness against policy and domain rules. Keeping those three senses of "owns" separate prevents the most common confusion in adoption.

Fluid formation

A team is fluid between Efforts and stable within one. The Flow Council reforms at three boundaries: the outcome is accepted and capacity releases, a higher-value Effort outranks the current one at triage, or the Effort proves to need different expertise than formation assumed.

What does not trigger a change: convenience, utilization smoothing, or a manager wanting someone back. Rebuilding context is expensive, and the cost is invisible until the replacement team spends two weeks rediscovering what the original team knew.

The manager's new shape

Managers of standing teams keep a job with a better shape. Someone has to steward the pool, develop people between Efforts, hold the guild's health, and enforce release discipline. Management moves from owning a team to growing a talent pool, which is the part most managers say they wanted all along.

The failure modes

The silent failure: four stages from working pool to standing teams with new labels
The silent failure: four stages from working pool to standing teams with new labels

The "my team" instinct. People prefer working with people they know, and managers prefer managing people they have managed before. This is natural, and it is the force that rebuilds standing teams. When the same people appear together across multiple Efforts without a skill-based justification, the pool is congealing.

The capacity lie. Planning against headcount instead of availability. Twelve genuinely available people planned as twenty produces five short-staffed Efforts instead of three fully committed ones.

The release that never happens. Check one number: how many people returned to the pool last quarter. Zero, while Efforts completed, means capacity is not being released. Make release a standing agenda item at calibration.

Expertise hoarding. A Flow Council member protects "their" experts from deployment elsewhere. The correction is not persuasion. It is evaluating council members on the whole portfolio's outcome rather than their area's progress. An expert deployed where they create the most value beats an expert held in reserve.

Its place in the Model

In The AI-Native Operating Model™, Fungible Capacity sits in the Portfolio Direction band, colored blue. It is the pool mechanism the Flow Council manages, with three labeled stages: Plan, Commit, and Release.

Fungible Capacity connects to:

Read the Fungible Capacity white paper (PDF). Return to the Model to see how the pool connects to the rest of the system.