Find the Boundary, Then Work Outside It

Every optimized system has a boundary, and the organization that built it goes blind at precisely that line. Three things draw those boundaries in a company: what its systems optimize, what its roadmaps assume already exists, and whom its org chart permits to feel a problem. I have come to believe that the highest-leverage product moves live just outside those three lines, and that a product leader's real job is to keep walking to the edge and looking over.

The lens

Systems thinking, as I practice it, owes less to diagrams than to a few questions asked with some persistence. What does this system hold constant? What must be true before the next thing can work? Where are the seams, and what loop is actually producing the result everyone is arguing about? The questions are ordinary. Their value lies in the fact that organizations stop asking them at the boundary of whatever they have already tuned, because that is what optimization does: the system becomes excellent at the inputs it was given, and the inputs it was never given become invisible. The org chart is the most expensive optimizer a company runs and the least examined.

Three boundaries, four cases

I trust this lens because it has paid off across all three kinds of boundary, which is roughly the test that separates a way of seeing from a lucky trick. The cases were chosen, I should say, by the person who holds the view; the failure modes at the end are my attempt to be fair about that.

The first boundary is the system's own inputs. When I took over consumer payments at Wells Fargo, I inherited a bill-pay business whose routing engine chose the cheapest path for every transaction and did so admirably, to the point that the organization had filed cost under solved. But an optimizer can only work the inputs it is fed, and this one could not touch the two that mattered, the contracts that set vendor prices and the mix of payment types flowing through it. Those lived in negotiation and product design rather than in the engine, and working them cut total cost by roughly half while quality improved. Years of tuning had polished the box; the money had been sitting, unbothered, in what the box took as given.

The second boundary is the roadmap's assumptions. A new data connection is worth precisely nothing to a business until the data is mapped to a shared model, linked to what the company already knows, and exposed where product teams can reach it, and the roadmap I inherited had quietly assumed those steps existed. Writing the chain down, and declining to fund step four before step two, was the entire case for a multi-year investment. Executives will fund a sequence they can see. A vision without its dependency chain is a request for faith, and I no longer present one.

The third boundary is the org chart, which decides who is permitted to feel a problem. New customers once waited days for their accounts to be verified before they could use what they had signed up for, and no one complained, because the wait fell neatly between two teams and appeared on neither's dashboard. Rebuilding verification on real-time payment rails removed it, and activation moved more than it had for any feature we shipped that year. Nobody had been wrong. The problem simply had no address.

The same boundary can be moved on purpose. I run product teams as a matrix, capability owners on one axis and customer verticals on the other, so that every senior product manager feels two pulls at once and neither the technology nor the customer can be quietly ignored. The measure of whether it works is the arguments it produces. They are now between capability and customer, which are the arguments worth having, rather than between teams over turf, and my group product managers run their portfolios without me in the room.

Operating rules

A few rules follow. Ask what the system holds constant, since what everyone treats as given is the highest-leverage variable available for the simple reason that no one is working it. Put dependency honesty before funding; most wasted platform spend is a chain nobody wrote down. Instrument the seams, where ownership is weakest and dashboards thinnest. Change loops rather than nodes, and notice how much feature work is node-pushing: on my current team the share of documents needing a human review fell by an order of magnitude through a weekly habit of examining what the model got wrong and repairing the cause, and the habit outlasted every push that preceded it. Price the second-order effects, for a most-favored-nation clause constrains your own future deals and a benchmark designed to flatter settles nothing.

Where it breaks, and what comes next

The lens has failure modes, and I have met them. It degrades into analysis theater the moment the map becomes the deliverable, and it earns its keep only when it terminates in a move someone funds. A good many problems are not systems problems at all, just execution debt, and dressing them in loops delays the obvious work. Finding the leverage point does not mean the organization can pull it; leverage points sit inside political systems too, and I have watched the right structural answer lose to a reorg. And one's model of the system is always wrong somewhere, usually at a boundary one did not think to draw, which is how a product that passes every benchmark can still fail in production on the axis the evaluations never covered.

The open question is what becomes of the three boundaries when agents are actors inside the system rather than tools at its edge. Loops that ran at human speed, monthly reviews and quarterly renegotiations, tighten to machine speed, and boundaries begin to move faster than org charts can follow them. My working guess is that the human leverage points migrate to two places, designing the loops that agents run and owning the boundaries between agent systems. If that is right, this is the essay the rest of my thinking will eventually reorganize itself around.