Systems Don't Scale Because Authority Is Missing
A system doesn't fail because the components are poorly designed. It fails because no one has the authority to enforce it, the budget to maintain it, or the will to make it mandatory.
Systems scale through adoption. Adoption requires a mandate. But mandates without genuine value create resentment and workarounds.
This is the central tension. And most organizations never resolve it.
A system doesn’t fail because the components are poorly designed or the documentation is incomplete. It fails because no one has the authority to enforce consistency, no one has the budget to maintain it, and no one has decided that consistency is worth the friction it creates.
Systems without mandates are optional. Optional doesn’t scale.
What’s actually happening
When a system “doesn’t get adopted,” what we’re actually saying is: “The organization is not willing to trade local autonomy for global coherence.”
That’s not a design problem. That’s a structure problem.
A product team can ship faster by creating custom components. A platform team can ship faster by ignoring the system and building what they need. A founder can move faster by letting individual contributors make their own decisions. All of that is locally rational.
The system is an argument for global optimization at the cost of local friction.
That argument only wins if someone has the authority to say no to custom solutions. Someone has to be able to block a decision because it violates the system. Someone has to have the budget to maintain consistency as the organization scales. Someone has to decide that coherence is worth the tax on speed.
Without that authority, you don’t have a system. You have a toolkit that some teams use when it’s convenient.
Systems without mandates are optional. And optional things don’t scale.
The mandate problem is real
When adoption is voluntary, the system survives only as long as teams perceive direct, immediate value. The moment shipping a custom solution is faster than following the system, the system loses. And it always will, because the system adds friction in the short term for benefits that accrue in the long term.
That’s not a failure of communication or documentation. That’s a failure of structure.
A true system has teeth. Someone owns the decision to enforce it. Someone has invested in making it mandatory, not aspirational. Someone has decided that the benefit of global consistency is worth overriding local optimization.
Without that mandate, you’re not governing. You’re suggesting. And suggestions don’t scale.
But here’s the catch
For systems like ResearchOps and Accessibility, the situation is different. You can’t mandate these systems the way you might mandate a design system embedded in infrastructure. You have some authority (the “wink” from leadership), but not full enforcement power. Teams won’t block shipping decisions because someone says so. They block shipping decisions because they understand why consistency matters for their work.
In this space, the mandate is real but softer. It’s “leadership agrees this matters,” not “you will use this tool.” The adoption burden falls on you to demonstrate value fast enough that teams choose the system before they choose their own path.
This is harder than a hard mandate. It requires different work.
Where authority lives
Authority over a system comes from one of three places:
1. Executive sponsorship with enforcement. A leader with budget, hiring, and firing power who has decided the system matters enough to block work. This is rare and usually temporary.
2. Operational necessity. The system is so tightly coupled to infrastructure that bypassing it is harder than using it. Examples: a monolithic frontend framework, a single token server that controls rendering across all surfaces, a mandatory research pipeline that gates launch. This is structural. It scales without constant advocacy.
3. Demonstrated value. Teams use the system because it makes their work faster, safer, or easier. This is the hardest to build and the easiest to lose. It requires the system to deliver real benefit to real teams, not theoretical benefit to theoretical future problems.
Most systems attempt to operate on demonstrated value alone, with no executive sponsor and no enforcement mechanism. Then they’re surprised when adoption stalls.
But demonstrated value is fragile. The moment a team discovers that building custom is faster, the culture cracks. Without a mandate backing it up, the system has no defense.
The scaling problem
Systems fail at scale because the cost of inconsistency becomes visible exactly when the cost of centralized authority becomes impossible to bear.
At 10 people, everyone can talk. Decisions are negotiated. A shared understanding can emerge without formal authority.
At 100 people, you need structure. You need someone to own decisions. But by then, teams have already built autonomously. They’ve made different technical choices. They’ve shipped different patterns. The system arrives too late and asks teams to undo months of work to achieve global consistency.
This is the paradox: the system is most needed when authority is hardest to establish.
Organizations that scale systems successfully usually do one of two things:
- Build authority early. The system is a constraint from day one, embedded in infrastructure. Teams don’t have the option to opt out because opting out is harder than using the system.
- Accept local autonomy. The system is a set of optional patterns. Teams use them where it makes sense. The organization accepts that consistency will be imperfect and invests in bridges and documentation instead of enforcement.
What doesn’t work is claiming the system is mandatory while providing no mechanism to enforce it, no budget to maintain it, and no consequence for ignoring it. That’s neither a system nor a mandate. That’s a suggestion that lost its funding.
If you don’t have full authority
If you’re building a system without enforcement power, the work changes. You have a softer mandate (leadership supports this) but you can’t rely on enforcement. So you must:
1. Prove value in weeks, not months. Pick a team with a real pain point and make the system solve it visibly. Then show that win to the next team. Speed matters. Teams move on.
2. Make adoption the easy path. Build so that using the system is faster than not using it. Not eventually. Immediately. Every friction point teams encounter is a moment where they might decide to build custom instead.
3. Integrate into existing workflows. Don’t ask teams to change how they work. Embed the system into the tools they already use. ResearchOps lives in their existing research process. Accessibility lives in code review, not as a separate gate.
4. Make yourself indispensable. If you’re the only person who understands the system and can help teams implement it, you become the mandate. This is not sustainable. But it buys time while you build structural adoption.
5. Create the consequence indirectly. You can’t block shipping. But you can make the cost of ignoring the system visible. Accessibility: show how much technical debt and risk a team is adding. ResearchOps: show how much time and money they’re wasting by running research ad hoc instead of using the system.
6. Document ruthlessly. Without enforcement, documentation is your only persistent tool. It needs to be so clear and so specific that a new team member can implement the system without your help. That documentation doesn’t exist yet for most organizations.
The core truth remains: systems without mandates are optional. But if you only have a soft mandate, your job is to make the system so obviously valuable that teams adopt it before they even know they have a choice.
What this means for practitioners
If you’re building a system, ask these questions before you start:
On authority:
- Who owns the decision to use the system? Not who maintains it. Who decides whether teams must use it?
- What happens if a team ignores it? Is there a consequence, or is it genuinely optional?
- Does leadership have appetite to enforce this if it becomes a bottleneck?
On resources:
- Who funds maintenance? Will there be budget in 18 months when teams want features the system doesn’t have?
- Is someone dedicated to this full-time, or is this a side project?
On structure:
- Is the system embedded in infrastructure, or layered on top of it? If it’s layered on top, it will always lose to local optimization.
- Can teams implement the system in days, or does it require weeks of training?
On value:
- Do teams immediately see benefit, or is the benefit deferred?
- What do teams have to give up to adopt? Is it worth it?
If you can’t answer those questions with confidence, you’re not building a system. You’re building a recommendation.
Recommendations are valuable. But they scale differently. They require ongoing advocacy, constant evidence of value, and teams that actively choose to listen.
Systems scale through authority, incentive, and structure. Everything else is hope.