Perfectly Designed for These Results

If you don’t like the outcome, redesign the system

There is a particular kind of sentence that sounds obvious when you first hear it and unsettling the longer you sit with it:

Organizations are perfectly designed to get the results they get.

At first glance, it feels almost tautological. Of course results come from the organization. But the deeper implication is harder to swallow. It suggests that persistent outcomes, whether good or bad, are not accidents, not flukes, and not the result of a few underperforming individuals. They are signals. They are the system expressing exactly what it was built to express.

The phrase is commonly attributed to Arthur Jones, an organizational design thinker who worked at Procter & Gamble in the UK. Over time, it was broadened and popularized by Paul Batalden, who reframed it beyond organizations to systems more generally. That reframing matters because it removes any illusion that this idea applies only to business. It applies to hospitals, governments, schools, software platforms, and any complex human endeavor where outcomes emerge from structure rather than intent.

Once you pair the quote with its corollary, if we keep doing what we’ve been doing, we’ll keep getting what we’ve been getting, the message becomes impossible to ignore. Wanting different results without changing the system is not optimism; it is denial.

This idea sits squarely in the tradition of systems thinking articulated by W. Edwards Deming, who spent decades arguing that most performance problems are systemic, not personal. People do their best within the constraints they are given. When outcomes repeat, the explanation is rarely individual incompetence and almost always structural design.

And yet, when results disappoint us, our instinct is still to look for someone to blame.

The Seduction of Blame

Blame is emotionally satisfying. It gives leaders a villain, a sense of action, and the illusion of control. If the problem is a person, then the solution is straightforward: replace them, retrain them, or pressure them harder. The organization gets to move on without confronting anything deeper.

But blame rarely changes results for very long. At best, it produces a temporary spike in effort. At worst, it drives fear underground, silences dissent, and makes the system even more brittle.

When you see the same problems resurface quarter after quarter, missed deadlines, quality regressions, safety incidents, coordination failures, that repetition is the clue. Randomness does not produce consistency. Systems do.

This is where another idea becomes essential, especially for leaders who work in technology or large-scale operations.

Conway’s Law and the Shape of Systems

In 1967, computer scientist Melvin Conway published an observation that has since become known as Conway’s Law. He noted that organizations designing systems are constrained to produce designs that mirror their own communication structures. In other words, the architecture of what you build will reflect how your organization talks to itself.

If teams are siloed, systems will be siloed. If communication paths are indirect, systems will be tightly coupled and fragile. If ownership is diffuse, accountability will be unclear in both the org chart and the codebase.

Although Conway originally framed this insight in the context of software, its reach is far broader. Processes, policies, safety mechanisms, and even cultural norms tend to crystallize around existing organizational boundaries. Over time, those boundaries harden. What began as a pragmatic structure becomes an invisible constraint.

Conway’s Law is not a warning you can choose to heed or ignore. It operates whether you acknowledge it or not. The only real choice is whether you design with it in mind or let it quietly design your outcomes for you.

Few companies illustrate the upside of intentional design better than Amazon.

Amazon: Designing for Speed and Scale

Amazon’s scale today makes it easy to forget that, at one point, it faced a very real risk of collapsing under its own growth. As the company expanded beyond books into an ever-widening set of products and services, coordination costs began to rise. Decision-making slowed. Dependencies multiplied. The system was straining.

Amazon’s response was not to centralize more control or add layers of oversight. Instead, it made a counterintuitive organizational choice: it deliberately broke itself into smaller pieces.

The now-famous concept of the “two-pizza team” emerged from this period. Teams were intentionally kept small enough that they could be fed with two pizzas. More importantly, they were designed to be cross-functional and end-to-end accountable. A team didn’t just write code or design features; it owned a service from conception through operation.

This was not an efficiency tweak. It was a statement about how Amazon wanted to behave. Small teams move faster. They communicate more directly. They feel ownership more acutely. But they also demand a certain kind of system around them.

As these teams multiplied, friction began to surface in predictable places. Shared databases became bottlenecks. Coordinated releases became risky. Informal agreements between teams broke down as scale increased. The organization’s structure was creating pressure on the technical architecture.

Rather than fighting that pressure, Amazon leaned into it. Teams were encouraged, and eventually required, to expose functionality through well-defined APIs. Services became independently deployable. Ownership boundaries became explicit. Communication between teams increasingly happened through interfaces rather than meetings.

This was Conway’s Law working in Amazon’s favor. The organization was designed around small, autonomous teams, and the systems evolved to match that reality. The result was a highly modular architecture that could scale without requiring proportional increases in coordination.

What’s striking about this story is not that Amazon built microservices. Many companies have tried that and failed. The difference is that Amazon aligned its organizational design, incentives, and technical architecture around the same goals. Autonomy was not just encouraged; it was structurally enforced.

The results speak for themselves. Amazon became capable of running thousands of services, deployed independently by teams that could move quickly without waiting for centralized approval. Speed, resilience, and scalability were not accidental byproducts. They were the outcomes the system was built to produce.

Now consider a very different outcome.

Boeing: When the System Drifts

For much of its history, Boeing was held up as a model of engineering excellence. Safety was not a slogan; it was a deeply embedded value reinforced by processes, authority structures, and cultural norms. Engineers had a strong voice. Concerns were expected to be raised and addressed. The system was designed to err on the side of caution. Over time, that system changed.

By the early 2010s, Boeing found itself under intense competitive pressure from Airbus, particularly after the success of the A320neo. Airlines wanted more fuel-efficient aircraft, and they wanted them quickly. Boeing faced a choice: design a new plane from scratch or modify its existing 737 platform to compete faster and cheaper.

The decision to modify the 737 became the foundation for the 737 MAX. On the surface, the logic was compelling. A derivative aircraft would save time, reduce costs, and minimize pilot retraining requirements. But beneath that logic, the organization itself was already evolving in ways that would shape the outcome.

Engineering authority had been gradually diluted. Financial and schedule pressures carried increasing weight. Decision-making became more fragmented, with responsibility spread across organizational boundaries that did not always align. Communication with regulators and pilots became more constrained.

One of the most consequential manifestations of this drift was the Maneuvering Characteristics Augmentation System, or MCAS. Designed to compensate for aerodynamic changes introduced by larger engines, MCAS could automatically push the aircraft’s nose down based on input from a single sensor. Pilots were not fully informed of its behavior, and redundancy was limited.

This design did not emerge from a vacuum. It reflected a system in which tradeoffs were consistently resolved in favor of speed, cost, and continuity over fundamental redesign. It reflected communication structures where concerns could be raised but not always resolved. It reflected incentives that rewarded meeting deadlines and avoiding disruption.

When Lion Air Flight 610 crashed in 2018, followed by Ethiopian Airlines Flight 302 in 2019, killing 346 people, the immediate focus was on MCAS. But investigations quickly revealed deeper issues. Internal emails, testimony, and regulatory findings painted a picture of an organization where safety signals were weakened by structural forces.

This was Conway’s Law playing out in the most tragic way possible. Organizational silos and communication breakdowns produced technical designs that mirrored those same fractures. The system behaved exactly as it had been shaped to behave.

Even after the global grounding of the 737 MAX and subsequent redesigns, later incidents raised uncomfortable questions about whether Boeing had truly redesigned its system or merely patched the most visible failures. When a door plug blew out of an Alaska Airlines 737 MAX in 2024 due to missing bolts, it reinforced the sense that the underlying organizational issues were not fully resolved.

Boeing did not suffer from a lack of intelligent or well-intentioned people. It suffered from a system that had drifted away from the outcomes it once prized.

Two Organizations, Coherent Results

What makes Amazon and Boeing such powerful case studies is not that one succeeded and the other failed. It is that both outcomes were coherent.

Amazon designed an organization that rewarded autonomy, ownership, and speed. Its systems evolved to reflect that design, and the results followed. Boeing allowed its organizational incentives, communication structures, and authority boundaries to shift in ways that deprioritized safety. Its systems reflected that shift, and the results followed as well.

In both cases, individuals largely acted rationally within the constraints they were given. Engineers responded to incentives. Managers responded to pressure. Leaders responded to market forces. The system did the rest.

This is the heart of the insight behind the phrase perfectly designed for the results it gets. Systems do not care about intent. They respond to structure.

The Real Work of Leadership

If this is true, then the real work of leadership is not exhortation or enforcement. It is design.

Designing systems means paying attention to how information flows, how decisions are made, and how tradeoffs are resolved when values collide. It means understanding that culture is not what leaders say, but what the system consistently rewards.

You cannot train your way out of misaligned incentives. You cannot document your way out of broken communication paths. You cannot hire your way out of a system that punishes the very behaviors you claim to value.

Redesigning systems is slow and often uncomfortable work. It requires leaders to look beyond surface-level fixes and ask harder questions about structure and power. It requires humility to accept that persistent problems are not aberrations, but feedback.

Listening to the Results

The most productive way to interpret outcomes is not as verdicts on people, but as messages from the system itself.

• If quality problems recur, the system tolerates them.

• If innovation stalls, the system taxes experimentation.

• If safety incidents repeat, the system normalizes risk.

Results are not arguments. They are evidence.

Amazon listened to the friction in its system and redesigned accordingly. Boeing, for a time, did not. The difference was not intelligence or effort, but willingness to confront what the system was actually producing.

If you want different results, you must be willing to redesign the system that generates them. Everything else is noise.

That is the uncomfortable truth embedded in the phrase we began with. Organizations are perfectly designed for the results they get. The only question is whether those results are the ones you truly want.