What the Founders Got Wrong First
Founding Fathers as Change Management Leaders
The United States turns 250 this July. There will be fireworks and speeches and a lot of reverence for the founding generation’s vision. But the part of the founding story I keep thinking about isn’t the triumphant part. It’s the twelve years between the Declaration of Independence and the Constitution, when the country was governed by a document most people have forgotten.
The Articles of Confederation were America’s first operating system. They were a reasonable design, born from a reasonable fear: the colonies had just escaped centralized authority and they weren’t about to recreate it. So the Articles gave each state maximum autonomy. No executive branch. No federal courts. No power to tax. Congress could request things from states. It could not compel them.
It didn’t work. Autonomy without coordination produced fragmentation, not freedom. States issued their own currencies. Trade disputes went unresolved. Shared problems like defense, debt, and interstate commerce festered because no one had the authority to address them.
The Constitution wasn’t the founders’ first idea. It was their correction.
I’ve been thinking about this because I’ve spent a lot of my career in technology watching organizations try to transform how they build and deliver software. Most of these transformations follow the same arc: someone declares that the current way of working is broken, publishes a new operating model, and expects adoption. Declaration to Constitution in a single step. They almost always fail, and usually for the same reason the Articles failed. Nobody did the work of understanding why the current state exists and what legitimate needs it serves.
-----
In most large technology organizations, teams own domains. They own backlogs. They own their release cadences and deployment rituals. Coordination between teams happens through negotiation (meetings, Slack threads, escalations) rather than through structure. Shared concerns go unaddressed because no single team has the authority or incentive to solve them.
That’s the Articles of Confederation. And like the Articles, it didn’t emerge from stupidity. It emerged from trauma. At some point, a top-down mandate failed these teams. Someone centralized decision-making, removed autonomy, and created bottlenecks. Teams responded by claiming sovereignty over their territory. They built walls out of self-preservation, not selfishness.
When you frame the current state as the Articles rather than as dysfunction, it changes the conversation. The Articles were a rational response to a real problem. What comes next isn’t revolution. It’s a constitutional convention: a correction informed by experience, not imposed by ideology.
-----
The founding generation produced a stack of documents, and each one did something the others couldn’t. I think this sequence is more useful as a change management framework than most of what I’ve seen in the Agile or transformation literature.
The Declaration of Independence was philosophy. It didn’t describe how the new government would work. It made the case that the old arrangement was untenable, cataloging specific grievances against a system that had become unresponsive to the people it was supposed to serve. If you’re transforming a delivery organization, your Declaration makes the pain of the status quo specific and evidence-based. Not “we need to be more agile,” which is a bumper sticker. Something more like: here are the seven ways our current model fails the people who depend on what we build.
The Constitution was architecture. Structure, jurisdiction, and separation of powers. Who owns what. How authority flows. What decisions get made at which level. The founders’ core design insight was federalism, a division of sovereignty where certain powers belong to the national government and everything else is reserved to the states. In a delivery organization, this maps onto the tension between enterprise standards and team-level autonomy. Security requirements, data contracts, API standards, platform decisions: federal. Implementation patterns, tooling choices, internal rituals: state. Getting this boundary wrong in either direction was the exact failure mode the founders were designing against.
The Bill of Rights was a set of guarantees. The Constitution alone wasn’t enough for ratification. People needed explicit assurances that the new centralized structure wouldn’t recreate the problems of the old one. In an engineering organization, this means telling teams what they’re entitled to under the new model (clear specifications before work begins, autonomy within defined boundaries, and access to shared platforms) and what they’re protected from (mid-sprint scope changes, accountability without authority, and ambiguous ownership).
The Federalist Papers were persuasion. Hamilton, Madison, and Jay didn’t publish the Constitution and wait for applause. They wrote 85 essays, each one arguing for a specific design decision to a skeptical public. Why this structure? Why these tradeoffs? Why not the alternatives? If you’re transforming a delivery organization and you haven’t written the equivalent of the Federalist Papers, standalone arguments for each controversial design choice, you’re asking people to adopt a system they don’t understand.
-----
The part of this history that sticks with me most is the opposition.
The Anti-Federalists, Patrick Henry, George Mason, and Mercy Otis Warren, argued that the Constitution concentrated too much power. That it would erode local responsiveness. That the cure was worse than the disease. They made their case publicly, in essays and speeches that matched the Federalists point for point. They lost the ratification debate, but they won a concession that mattered more: the Bill of Rights exists because the Anti-Federalists demanded it. The Constitution is a better document because people who believed it was dangerous forced its authors to prove otherwise.
Every transformation has Anti-Federalists. They argue that your new team model destroys hard-won domain expertise. That your new process adds overhead. That centralizing ownership dilutes accountability rather than strengthening it. These are legitimate structural concerns, the same ones the historical Anti-Federalists raised, and they deserve the same treatment: engagement, honest concession where warranted, and design changes where the evidence supports it.
I’ve come to think the best thing a transformation leader can do is publish their own Anti-Federalist Papers alongside the Federalist ones. Steelman the strongest objections to your own design, then address them. It shows the new model has been tested against its failure modes. And it takes the air out of opposition by acknowledging the concerns before they harden into resistance.
-----
Thinking more about this comparison, a few more constitutional mechanisms translate directly:
The Supremacy Clause (Article VI) establishes that federal law supersedes state law when they conflict. Every delivery organization needs an equivalent. When a team’s local optimization conflicts with an enterprise requirement, what wins? If you don’t answer this explicitly, you’ll answer it through escalation which is slower and more corrosive.
Judicial review, established by Marbury v. Madison in 1803, addresses who arbitrates disputes. When two teams disagree about ownership of a shared domain, or a specification is ambiguous, who interprets the Constitution? The useful insight from the courts is that the arbiter should be separate from both those who write the rules and those who execute them.
The amendment process (Article V) might matter most. The Constitution was designed to be changed, but not easily. Supermajorities are required. The system evolves deliberately rather than reactively. Your operating model should define its own amendment process: who proposes changes, what evidence is required, what threshold triggers adoption. Rigidity breaks and instability exhausts. Article V sits between those two failure modes.
-----
There is one question this metaphor keeps forcing on me…
Every constitutional system exists to serve someone. In government, the whole structure exists for the citizen. In a technology organization, who’s the citizen? The end user? The internal team consuming a shared platform? The business stakeholder?
If the citizen is the end user, your Constitution optimizes for delivery speed and quality to market. If it’s the internal consumer, you optimize for composability and reliability. If it’s both, you need something like dual sovereignty, which is what federalism was built to handle.
The American founding was messy, Ii was argumentative, and It was built on the admission that the first attempt didn’t work. Twelve years of operating under an inadequate system gave the founders the experience to design a better one. As the country marks 250 years since the Declaration, I think the more interesting anniversary is still two years out. The document that actually governs, the Constitution, came from the willingness to admit that independence alone wasn’t enough. You also need architecture and a thoughtful operating model.
Same thing is true for how we build software. Declaring the old way broken is necessary, but that’s 1776. The harder work is Philadelphia, 1787.