I recently finished reading Escaping the Housing Trap by Charles Marohn Jr. and Daniel Herriges. One idea, in particular, stayed with me long after I closed the book. In Chapter 3, the authors examine J.C. Nichols’ postwar philosophy of “Planning for Permanence,” a vision of creating neighborhoods that would remain permanently stable through careful, master-planned design rather than the organic evolution that had shaped cities for generations. Their critique of that philosophy sparked a realization that ultimately led me far beyond urban planning.
Marohn and Herriges argue that this vision misunderstood the nature of cities. The issue is not planning itself. Every healthy community requires planning. The problem is assuming that we can predict enough about the future to permanently determine the form a community should take. Roads, utilities, zoning, and development become organized around a vision that may or may not correspond to the reality that eventually unfolds.
Strong Towns is a movement founded by Charles Marohn Jr. that challenges many assumptions of modern urban planning. At its core, it argues that cities are not machines that can be designed into their final form but complex systems that must continually adapt and evolve. Rather than attempting to build the ideal city all at once, Strong Towns encourages communities to grow incrementally. Small investments are made, their results are observed, and each successful step creates opportunities for the next one. The city is not treated as something that can be completely designed in advance but as something that continually adapts to reality.
Healthy complex systems cannot be permanently designed because they are continually discovering new information about reality. That realization extends far beyond cities. As I reflected on it, the idea began to feel strangely familiar. I had encountered this pattern before, although not in urban planning. The more I thought about it, the more I realized I had seen it in several completely different disciplines. Each discipline described the same organizational principle while using an entirely different vocabulary. What surprised me most was not that they shared similarities, but that they all seemed to arrive at the same conclusion independently.
An Ancient Pattern
One of the earliest examples appears in Exodus. After leading Israel out of Egypt, Moses became responsible for judging every dispute among the people. At first this may have seemed manageable, but as the nation grew it became impossible. Everyone depended upon one man to resolve every significant question. The larger Israel became, the more the entire system depended upon Moses’s ability to make every important decision.
Jethro immediately recognized the problem. His solution was not to replace Moses or eliminate hierarchy. Instead, he distributed responsibility among leaders of thousands, hundreds, fifties, and tens. Ordinary matters remained close to the people who understood them best, while only the difficult cases moved upward. Moses remained the leader of Israel, but his responsibility fundamentally changed. Rather than personally carrying every burden, he became responsible for integrating the work of many smaller leaders.
What has always fascinated me about this story is that authority did not disappear. Moses still led the nation. The hierarchy remained intact. The difference was that responsibility was moved closer to the people who possessed the knowledge needed to exercise it well. The higher levels of the system did not become less important, but their role shifted from doing the work themselves to coordinating the work of others.
The same organizational pattern appears centuries later in the idea of federalism. The word federal comes from the Latin foedus, meaning covenant or compact. Independent communities joined together because there were responsibilities they could fulfill more effectively together than separately. The federal government existed to coordinate the states, not to replace them. Each level possessed responsibilities appropriate to its role, and the health of the nation depended upon each level fulfilling those responsibilities well.
Catholic social teaching expresses this same principle through subsidiarity. Decisions should remain with the lowest level capable of making them effectively. Families should remain responsible for what families can accomplish. Local communities should remain responsible for what local communities can accomplish. Higher levels certainly have responsibilities of their own, but those responsibilities are not to absorb the work of smaller communities. Their role is to support them, coordinate them, and provide what they cannot provide for themselves.
At the time, I did not have language for what connected these examples. I only knew they all seemed to preserve responsibility at the lower levels while allowing higher levels to create something greater through integration. Whether I was reading about ancient Israel, constitutional government, or Catholic social teaching, the same pattern kept reappearing. That made me wonder whether this was more than a historical coincidence. Perhaps healthy complex systems naturally organize themselves this way because reality itself favors this pattern.
Software Rediscovers the Same Idea
The final place I encountered this pattern was the one most familiar to me. Long before I read Strong Towns or spent much time thinking about federalism and subsidiarity, I had spent years trying to solve the same problem in software engineering.
When I first began developing software, many applications were designed around a large central application layer that understood almost everything. Business rules, persistence, communication, and user interactions often became tightly coupled because it seemed easier to keep the logic in one place. As systems grew, however, every new feature required modifying the same increasingly complex components. Those components eventually became bottlenecks. They possessed too much responsibility because they attempted to understand too much about the system.
The industry gradually moved in a different direction. Rather than concentrating responsibility into larger and larger components, software architects began dividing systems into smaller modules with clearly defined responsibilities. Each component became responsible for a narrow part of the system while providing well-defined capabilities to the components above it. Larger applications were no longer constructed by continually expanding a central application layer. They were assembled by composing many smaller pieces that could each evolve independently.
This shift became even more apparent with Agile development. Agile is often described as a project management methodology, but I have come to think of it differently. At its heart, Agile recognizes that knowledge is distributed throughout a system. Product owners learn from customers. Developers learn from implementation. Testers discover assumptions that everyone else overlooked. Operations teams learn how software behaves under real workloads. Instead of assuming that one group can predict everything in advance, Agile allows each part of the organization to contribute what it uniquely learns through direct contact with reality.
The same principle appears in software architecture through Inversion of Control. Although the term is usually associated with dependency injection or application frameworks, I think its deeper significance is often overlooked. Inversion of Control is really about allowing each component to remain responsible for the knowledge it already possesses. Repositories understand persistence. Services understand business rules. APIs understand communication with external systems. User interfaces understand how people interact with the application. Each layer consumes capabilities provided by the layers beneath it while providing new capabilities to the layers above it. The architecture becomes simpler because responsibility remains where the knowledge already exists.
One Pattern, Many Disciplines
As I reflected on these examples, I realized they all shared something even deeper. Every level within these systems both consumes and provides. A neighborhood depends upon its residents while providing economic activity to the city. States depend upon their citizens while providing stability to the federal union. Leaders of tens provide judgment to leaders of fifties. Software services depend upon lower-level components while providing capabilities to APIs and user interfaces. Every part receives something from below while contributing something of value to what comes next.
Years later, while writing Striving for Quality, I finally realized what connected these examples. I came to call it the Consumer–Provider Paradigm. Every healthy complex system is composed of modules that consume value from the systems beneath them while providing value to the systems above them. Higher levels become valuable not because they replace lower levels, but because they integrate their provision into something greater. Likewise, lower levels are not isolated. Their work becomes meaningful because it contributes to the flourishing of the larger system.
Looking back, I no longer see Strong Towns, the Hebrew Republic, federalism, subsidiarity, and software architecture as unrelated discoveries. They are different windows into the same structure of reality. Urban planners discovered one aspect of the pattern. Political philosophers described another. Catholic social teaching explained another. Software engineers solved the same problem while building applications. None of these disciplines invented the principle. Each simply encountered reality honestly enough to discover it.
That realization has profoundly changed the way I think about quality. Healthy systems certainly require leadership, vision, and coordination, but they do not flourish because higher levels continually absorb more responsibility. They flourish because every level faithfully fulfills the responsibility that belongs to it while providing something of value to the systems around it. Leadership does not replace provision. It integrates it.
This has become one of the central ideas explored throughout Striving for Quality. Again and again, disciplines that appear completely unrelated arrive at remarkably similar conclusions because they are all studying the same reality. Engineering, theology, economics, history, and political philosophy each illuminate different aspects of the same underlying order. The names differ. The examples differ. The language differs. Yet the pattern remains remarkably consistent.
The more I study healthy complex systems, the more convinced I become that they are not primarily built through control. They grow through provision, responsibility, and integration. Every healthy part consumes from what supports it and provides to what depends upon it. When each level faithfully fulfills its own responsibility instead of attempting to assume the responsibilities of another, the entire system becomes capable of growing into something greater than any individual part could accomplish alone.
That, I believe, is where responsibility belongs.
LongLoft - Code Writer 