Rule Redesign

System Problem

Developers behave exactly as the rules allow. If a company runs on a toxic rule set such as "Only release management may deploy to production, every Tuesday at 4 a.m.," then it breeds toxic delivery behavior. Teams stop caring about continuous quality, build giant pull requests, and throw them over the wall in one big bang. The system manufactures bugs because the rules suppress healthier forms of action.

Intervention

"Rule Redesign" corresponds to leverage point number five in Meadows's model. Whoever writes the rules owns the system. You abolish the Tuesday deployment ritual and replace it with a new rule: any pull request that meets agreed test and pipeline standards deploys automatically without human gatekeeping. You replace a permission rule rooted in hierarchy with a physical rule rooted in automation.

Expected Impact

The system begins to regulate itself. Architects no longer need to chase a hundred developers with reminders to write tests. The new rule changes incentives directly. If following the rule means nobody has to stay up for manual release night anymore, developers immediately feel the benefit in their own lives. The architecture improves through the rule itself.

Side Effects and Risks

Rules shape power, so redesigning them always triggers sabotage. If you change the rule from "The architecture board must approve all cloud services" to "Teams may self-provision up to a clear budget limit," then the central board loses part of its reason to exist. Poorly designed rules can also create tragedy-of-the-commons effects, such as runaway cloud spending.

Diagram

When This Intervention Becomes Effective

Meadows offered many examples of rule design in society, and the same logic applies to architecture. One of the strongest rules in modern engineering is "You build it, you run it." If teams are expected to write stable code, the rule has to connect their decisions to the lived consequence, including being paged at night when their service fails.

What Distinguishes This Intervention from Other Levers

*Parameter Tuning* changes the numbers inside a process. *Rule Redesign* changes the process itself. Instead of discussing the QA budget, you may change the rule so QA no longer acts as a bug-hunting gatekeeper but instead coaches teams in practices like TDD.

How to Introduce the Intervention Cleanly

Find the company's core bottleneck and identify the silent rule protecting it from repair. Many IT rules are nothing more than inherited conventions. Convert implicit prohibition into explicit freedom where appropriate. Encode architecture fitness functions so that rules become machine-enforced laws, not polite suggestions.

First Implementation Steps

Rules without consequences are not rules at all. A redesigned rule in software architecture should never live only as a Confluence page. If a new security rule matters, it should be embodied in IAM policies, CI checks, and build breakers. Cybernetic rules have to be enforced in the physics of the system.

How to Recognize Impact

Are there sacred-cow ITIL-style process rules in our company that could already be replaced by fully automated CI/CD verification if we had the political courage to remove them?

Sources

Donella Meadows — Leverage Points, Point 5: Rules (1999)

Elinor Ostrom — Governing the Commons, Ch. 3: Design Principles (Cambridge UP, 1990)

Wikipedia: Twelve Leverage Points