By: Kumar Dattatreyan

You ran the program for a year and shipped one big release. It missed. Now the room is arguing about whose fault it was and nobody can settle it, because you bet everything on one outcome and took no reading until the end. You can't tell whether the plan was wrong or the execution was. You can't tell whether a sound bet broke bad or a reckless one just ran out of runway. You spent a year to buy an argument you can't win.

Permaculture names this failure in its third principle. Obtain a yield. In an ecosystem the system doesn't only spend your energy, it feeds you back, and a design that never yields is a design you walk away from. In an organization the yield is value the customer can see. Most programs defer that value to a single distant release, and a yield you defer to one release is a yield you can't steer and can't verify.

#XSCALE reads the principle as descaling delivery. Peter Merel's ecosystems thinking takes obtain a yield to mean value delivered early and continuously by small teams close to the customer. Put the people closest to the work in charge, break the work into small reversible bets and take a yield from each one. This is part three of the permaculture series. Part two concentrated your capacity into fewer teams. Part three makes that capacity pay.

Value shows up at the edge

Colin O'Neill spent eleven years helping build the Scaled Agile Framework before he built a model to sit on top of it. He's clear about where value actually comes from, and it isn't the plan pushed down from the portfolio. It's the edge. "there is empirical evidence that the people that are closest to the customer and the product are the ones that come up with the most brilliant ideas," he told me on the Meridian Point podcast. He's just as clear about where the scaled frameworks break. Execution holds, delivery holds, and then "when it gets up to the portfolio level, it starts to fall apart."

That second point matters more than it looks, because the portfolio is exactly where most organizations try to count the yield. The delivery works and the counting doesn't. So obtain a yield isn't a scheduling trick you bolt onto an annual plan. It's a decision about who holds the authority to deliver value. Move that authority to the people who can see the customer and the yield shows up where the value is made instead of where the plan gets filed. Leave it at the top and you get a portfolio that reports on value it's too far away to produce.

Every handoff spends the yield

Chris Daily put the mechanism plainly on the show. He's watched a single feature crawl through a long chain of teams before it reaches a customer, and every handoff in that chain spends time the yield never gets back. He makes a second point that hits harder. Most of the work we plan far from feedback turns out wrong, and if we're honest with ourselves we already know it's wrong most of the time.

Read both through obtain a yield and they point the same direction. Shorten the path from the work to the yield, and take a reading before the plan hardens. Fewer teams between the work and the customer, faster feedback, a yield you collect while you can still act on it. The handoff isn't a coordination cost you pay once. It's a tax on every reading you were going to use to steer.

A yield is a promise with a consequence

David Greer, also a guest on the podcast says this about a yield not being a feature count. "it's much more important that you be able to demonstrate the value you can deliver to your client," he said. His example is a security company that built its whole brand on one promise: "five minutes to your door, your money back." The promise had a consequence attached. Miss the window and it costs you.

That consequence is the test principle three demands. A yield isn't output you can point at in a demo. It's a result the customer would pay for and you'd stake something on. His own headline says the rest. Most innovation fails. That's the reason to take the yield in small reversible bets instead of one irreversible push, because when three out of four bets miss you want to find that out on the small ones.

The part I glossed over, and Peter Merel caught

Here's where it gets harder. Peter Merel founded the XSCALE Alliance, and he read the promo for the last post and took it apart in the comments. His argument is worth following, because it goes at the weak joint in the whole idea.

Take a yield every cycle, fine. But a yield you take every cycle is a yield you measure, and the moment you fix that measure to a role or an office, someone games it. That's Goodhart's Law. A measure that becomes a target stops being a good measure.

Peter runs it back to first principles. Learning is cheap inside a team and expensive across teams, and bigger teams share worse inside themselves, so no team size resolves the tension. Bureaucracy grows in that gap. It pins measures to specific offices and settles conflict by decree or by vote. Then Goodhart does the rest. The local measure gets gamed for local benefit, the gaming creates learning bottlenecks, and the coordination layer built to reconcile all those local measures doesn't just cost money, it destroys the learning the yield was supposed to produce. His example is the Declaration of the Rights of Man, gamed by the Committee for Public Safety, then handed to a century of successor bureaucracies with much the same membership through revolution after revolution. He quotes Kafka on revolutions evaporating and leaving behind "the slime of a new bureaucracy," and he ties it to Conway's Law. A transformation designed by a bureaucracy can only produce more bureaucracy.

His fix is clean. Don't reform enterprise comp first. Assemble a small kernel of willing people, run it on open book management with one shared incentive pool, prove it, then double it by splitting the kernel and back-filling. XSCALE pays everyone on one shared measure, throughput, so there's nothing local left to game. One reading, shared, and the whole gaming problem goes quiet because nobody has a private scoreboard.

Where I go the other way

I agree with the diagnosis all the way down. I wrote as much in "Rewarding the Wrong Behaviors." The fastest way to teach people to game a target is to make it a target. Where I arrive somewhere else is the fix. I keep a split. Sixty percent of the reward on shared outcomes, forty percent on the individual, added together on purpose. I keep the forty because "our high performers will leave" is the sentence that kills comp reform in every real company I've worked in, and a fix that empties the building before it proves anything isn't a fix.

So the live question is whether that forty percent quietly rebuilds the bureau Peter warns about. It can. If the forty % measures private output, a personal number each person optimizes, then it's the local measure Goodhart punishes, dressed up as merit pay. But it doesn't have to. Design the forty to reward contribution to the shared yield, the capability someone built, the bottleneck they cleared, the teammate they made better, and it stops being a private scoreboard. The distinction Peter and I both hold is that the measure can't be local output. Where we differ is whether you can keep any individual slice at all. I think you can, as long as it points at the shared yield, and I think you often have to, because the alternative loses the people you need to form the kernel in the first place.

One more objection belongs right here, because it surfaces whenever the word measure appears. The #NoEstimates crowd will say drop the estimate entirely, just ship a prioritized list of value until the time runs out. Fair. But even then a room is still deciding what counts as value and in what order, and that decision is a measure, and the moment you fix it to a role it gets gamed the same way. Dropping the estimate doesn't dissolve the reading. It just moves it somewhere you stopped looking.

The patient-capital objection

The sharpest argument against all of this comes from patient capital. Clayton Christensen's capitalist's dilemma is the clean version. Markets reward the quick efficiency yield and starve the market-creating bet that pays off slowly, so a company trained to obtain a yield every cycle optimizes itself into small safe gains and misses the investments that compound. The platform and deep-architecture people add the engineering case. You can't ship a bridge halfway. Some value only exists once the whole thing is built.

The counter aims at a claim principle three never makes. Obtain a yield was never obtain cash this quarter. A food forest yields for decades and the principle still holds, because the principle is about designing for a yield you can obtain and read, not a payoff you defer and never verify. Small reversible bets are how you keep a long bet honest. Each thin slice returns a yield of evidence even when the money is years out. You still build the whole bridge. You deliver a load test, a survey, a walkable span, a proof at each stage, so you don't learn at the very end that the design was wrong.

Colin made this exact point to me when I asked how you guard against cutting funding too early. His answer was leading indicators and latitude. If the work is complex and takes extra quarters to show its value, you read the leading indicators and you give it room. Christensen's real target is the big irreversible bet graded only by its final outcome, which is the same failure I opened with. Patient capital and small bets are allies against it, not opponents. The long bet needs the small yield most of all, because the small yield is the only thing that tells you the long bet is still alive.

Fail fast is the wrong instruction

There's a version of small bets that goes wrong, and it goes wrong on a slogan. Fail fast. Told to people whose failures still cost a fortune, fail fast is just permission to lose money quickly. The real work is different. You redesign the system so that trying and being wrong costs less than doing nothing. That's what makes a yield every cycle possible in the first place. Small reversible bets only stay reversible while the cost of being wrong stays low enough to keep taking them.

Start with one team, not the whole reward system

The closer on the last post said fix the reward before you fix the structure. That compressed too far, and it compressed in the one direction that does damage, because comp reform first is the move that fails. What "Rewarding the Wrong Behaviors" actually argued was smaller and harder. Start with one team. Add one shared metric. Run it in 90-day cycles. Take a real yield, prove it, then double by splitting the team and back-filling.

That's the same shape as Peter's Pull Transformation, and the agreement matters more than the argument over the forty percent. You don't obtain a yield by re-engineering the whole reward system on day one. You obtain it from one kernel taking a real harvest on one shared reading, and then you grow the thing that worked.

So here's Monday. Pick one team that sits close to a customer and give it the authority to deliver a real yield, not a status update. Give that team one shared measure it gets read on, and make sure the measure is the customer's value and not an internal output count someone can inflate. Run it in a 90-day cycle and take the reading at the end of each one, so the next bet is smarter than the last. That's the harvest. It's small on purpose, and it's the only kind you can steer.

Related Podcast Episodes

Episode 88, "Rethinking Value Realization: The EVER Model" with Colin O'Neill. Colin helped build SAFe and then named the seam where it breaks, the portfolio level where value gets counted from too far away. His case that the best ideas come from the people closest to the customer is the spine of this whole argument about moving the authority to deliver a yield out to the edge. Watch: 

Episode 146, "Why 75% of Innovation Fails: From Addiction to $M Exit" with David Greer. David's line between shipping features and delivering value the client can see is the definition of a yield I use here. His brand-promise-with-a-consequence example is what separates a real harvest from a demo. Watch: 

Episode 150, "Top-Down vs Bottom-Up: Two Transformation Methods, Same Result" with Glenn Marshall. This is the episode where Glenn and I trace how top-down and bottom-up transformation arrive at the same place, and where I credit Peter Merel's XSCALE steel thread as the inspiration for the thread that runs through The Disruptor Method™, which Michael Jebber architected without ever knowing XSCALE existed. It's the backstory to the disagreement in this post. Watch: 

Want to pressure-test where your teams actually take their yield, and where they defer it to a release they can't steer? Book a listening session: https://tidycal.com/coachkumar/30-minute-meeting