By: Kumar Dattatreyan

You added three teams to go faster and you got slower. The work now crosses four handoffs it never used to. Nobody is doing anything wrong. You built a structure that spends its energy moving work between teams instead of through them.

Permaculture gives this failure a name in its second principle. Catch and store energy. XSCALE reads the same principle as descaling. In an organization, energy is capability, and a bloated structure dissipates it before anyone uses it. You don't store capacity by adding teams. You store it by concentrating your best people in fewer teams that own their work, and by adding a team only when a real constraint forces your hand.

The principle isn't about accumulation

Most people hear catch and store energy and think of a rain barrel. Collect more, keep more. That reading misses what David Holmgren actually put in the principle. He groups principles two and three together as the power principles, the ones about harvest and storage, and his proverb for the second is make hay while the sun shines. The Permaculture Association frames it as a bank account question: not how you spend the interest, but how you make the capital bigger.

The word doing the work there is capital. Energy spread across a wide surface radiates away. Energy held in a dense form does work later. A compost pile heats up because it's concentrated. Spread the same material across an acre and you get nothing.

Capacity in an organization behaves the same way. You can catch it easily, because catching it is just hiring. Storing it is the hard part, and most structures leak.

What XSCALE does with the same principle

XSCALE Alliance takes Holmgren's twelve principles and rewrites them for organizations. Principle two comes out as this: capture and store learning in small, self-organizing teams; as these work with current constraints, they become capable of opening future bottlenecks. Peter Merel built that on Goldratt's constraint thinking, so there's a second claim hiding in it. Each bottleneck a team opens increases what that team can do next. The store isn't a document. The store is the team.

Interpret that as a structural instruction, and it gets sharp. If capability accumulates inside a team, then splitting the team splits the store. Every team you add is another seam, and the seam spends capacity on handoffs and rework. The organization that answers a capacity problem by adding structure pays twice, once to staff the new teams and again to coordinate them, and it stores almost nothing.

XSCALE's own framing puts it plainly. Scaling makes agile teams leaves on a tree. Descaling brings agility to the leaves, the branches and the trunk. Agile Meridian is an XSCALE Alliance partner, so I've had a long run at watching which of those two actually holds up in a Fortune 500 environment.

Fewer teams, not more

Nawaz Butt made the case directly on episode 175 of The Meridian Point. He's spent years inside some of Canada's largest organizations and his diagnosis runs against almost everything the transformation industry sells. As he put it, "the aim has to be not to have more teams but to have less number of teams in the organization."

That sounds like heresy to anyone whose transformation budget is measured in team count. It isn't. It's throughput thinking. A team that owns its work end to end doesn't spend Tuesday waiting on a dependency, and the capacity it doesn't spend waiting is capacity it keeps.

Nawaz was blunt about what leaders contribute here. "please get out of the way of the teams." I see this all the time. A leader who adds a team is doing something visible, and the reorg deck looks like progress. Stepping back looks like nothing on a slide, and it's the harder move.

He also tied team performance to something most staffing models ignore. "It is not the smartest people or the most right, or knowledgeable people; it is the psychological safety." That matters more here than it looks. A store of capability only survives if the people carrying it can say what they know. Concentrate your best people into a team where nobody speaks and you haven't stored anything. You've warehoused it.

The mechanism: cap the team

Nawaz gives you the aim. Glenn Marshall gives you the mechanism. In our fireside conversation on triple loop learning in XSCALE, Glenn described the sizing rule through the Macintosh story: "Steve Jobs was famous for absolutely capping the Macintosh team the original Macintosh team at 100 people if the team needed another person no problem they would they would get it they had to get rid of another."

Remove one to add one. That's not a refusal to grow. It's a refusal to grow flabby. It forces the question every headcount request should answer and almost never does: what does this person do that nobody here should be doing anymore? XSCALE formalizes the same instinct in its descaling metrics as Dunbar size limits for teams, streams and portfolios.

Glenn paired the sizing rule with a communication rule, because a small team will rebuild hierarchy inside itself if you let it. "managers are there to enable but they're not they're not communication conduits you speak directly." A bounded team that routes everything through a manager isn't a store. It's a queue with a friendly face.

The unit matters too. Glenn is describing a cross-functional team, not a pool of people who all do the same job. A pool of eight testers isn't a store of capability, because it can't open a bottleneck by itself. It can only wait for one.

Where to point the stored energy

Fewer teams isn't the goal by itself, and this is where the easy read of descaling falls apart. You can concentrate beautifully and aim at nothing.

Evan Leybourn brought Goldratt into the open on episode 167. "an organization can only be as agile as its least agile function." He's specific that this isn't a technology problem anymore for most large organizations. Product and software have been iterating for a decade. The limit moved.

Where did it move to? Evan puts it in governance, and he's specific about the mechanism: "performance management that's based on individual goals and not team outcomes." Read that against principle two and the connection is direct. Individual ranking pulls energy out of the team and into private competition, which is exactly the leak the store is supposed to prevent. You can cap your teams perfectly and still lose the capacity to a compensation model.

His closing instruction is the one to act on: "the next place for you, as a listener, to focus is at the point of biggest constraint for you in this moment in time." XSCALE says the same thing from the other side. A team can't change faster than its most resistant member, and a stream can't change faster than its most resistant team. Scale at the constraint. Don't scale everywhere.

This holds outside software too. A theme that came up in one of our coaching and facilitation Dojo sessions this spring was positioning: depth in one segment earns reach that spreading across every segment never buys. What you store is focus, and focus is a choice to do fewer things well.

The strongest objection

The scaled-agile establishment has a real answer here, and it deserves to be stated in its own terms rather than in a caricature.

Large integrated solutions can't be built by a handful of bounded teams. An aircraft, a vehicle platform, a defense program or an enterprise banking platform has interconnected parts built in parallel: frontend and backend, infrastructure, compliance, analytics, hardware. Somebody has to integrate them. SAFe's answer is many teams synchronized through Agile Release Trains, typically five to twelve teams per train, with Solution Trains aligning multiple ARTs and suppliers where the cost of failure is unacceptable and regulators want evidence. Dependencies move inside shared planning cycles instead of surfacing at integration.

The org-economics tradition adds the older argument. Division of labor and specialization capture real efficiency at scale, and concentrating work into a few generalist teams caps throughput while rebuilding the single points of failure descaling claims to remove. On this reading descaling is a small-company luxury that doesn't survive contact with a real portfolio.

Here's my answer. The objection aims at a claim descaling doesn't make. Descaling isn't one team, and Nawaz's "less" isn't one. XSCALE still runs portfolios, streams and teams. The disagreement isn't about whether coordination is necessary. It's about where the energy gets stored.

SAFe stores coordination in a layer above the teams and pays for it in the seams. That's the pattern I traced in "The Seam Is the Bottleneck," and there's field evidence for it. A case study of ART formation in a large financial corporation found the old silo structure survived the trains, dependency management across the four silo-based trains created significant coordination overhead, and project managers who weren't part of any train ended up coordinating between trains, which is precisely the arrangement SAFe was supposed to replace. The teams could identify dependencies. They couldn't act on them.

XSCALE stores capability inside the team and coordinates through direct communication and explicit decision rights, which is what the DRI pattern is for. Both approaches need coordination. One buries it in a layer where nobody owns it, and the other gives it an owner. Evan concedes the constraint reality and the honest conclusion follows from it: scale at the constraint, not everywhere.

What to do this quarter

Count your seams before you count your teams. For one piece of work you care about, trace how many team handoffs it crosses from request to production. That number, not headcount, is your dissipation rate.

Then apply the cap. Pick your highest-value team and freeze its size. The next request for another person gets the Glenn question: what comes out to make room? You'll find out fast whether the team is carrying work it should have stopped doing.

Then check what your compensation model is doing to the store. If your best people are ranked against each other while you're asking them to concentrate capability in a team, the model wins and the team loses. Fix the reward before you fix the structure.

Related Podcast Episodes

Episode 175: Bloated Teams, Broken Delivery: The Case for De-Scaling with Nawaz Butt. This is the spine of everything above. Nawaz makes the case for fewer teams without hedging it, and he connects team performance to psychological safety rather than raw expertise, which is the part most staffing plans skip. Watch it if you're being asked to add teams to go faster. 

Episode 167: Business Agility in Crisis: 2025 Trends with Evan Leybourn. Evan is the one who tells you where to aim. His theory of agile constraints explains why a perfectly descaled delivery organization still crawls when governance is the limit. It's worth a listen alongside 175, because the two arguments only work together. 

Episode 38: Ideal Team Size. We went at the sizing question directly in this one, well before the descaling framing existed. The Dunbar limits and the remove-one-to-add-one rule both trace back to the same question we were chewing on here. 

Episode 67: From Permaculture to Agile Organizations. This is where Glenn Marshall and I started the permaculture series, and it's the best introduction to why a set of ecological design principles has anything useful to say about org structure. Start here if the permaculture framing is new to you. 

Your move

If you're staring at a structure that leaks capacity faster than you can hire it, the fix isn't another team. It's a harder conversation about which teams should exist and what they're allowed to own.

I do that conversation for a living. Book a 30-minute call and bring your org chart.