Most organizational policies are written by people who know what the policy should say. They are read — if at all — by people who want to find the minimum required compliance. The gap between those two orientations is where policies fail.
This is not primarily a compliance problem. It is a design problem. A policy that is technically in place but operationally ignored is not a policy that is working. It is a policy that has been laundered through a documentation process and filed. The organization has the appearance of governance without the substance of it.
I have reviewed policy sets for organizations at various stages of development. The pattern is consistent: long documents with abstract principles, unclear triggers for when the policy applies, no specification of what a person should do when they encounter the situation the policy is meant to govern, and consequence chains that are either absent or obviously unenforced. These are not policies designed to be followed. They are policies designed to be cited.
This article is about the design principles that produce policies that actually operate — that change what people do when the situation the policy governs actually occurs.
Why Policies Fail
The failure of policies to achieve the compliance they specify is not random. It follows from identifiable design failures, each of which can be corrected.
Written for the drafter, not the follower. Most policies are written from the perspective of the person who knows what the right outcome looks like. They specify the goal (safety, fairness, consistency, legal compliance) and describe the principles that should govern behavior. What they do not specify is what a person should actually do when they encounter the situation the policy is meant to govern. The gap between "the organization values X" and "when Y happens, do Z" is where compliance breaks down. Principles are not actionable. Actions are actionable.
No clear trigger. A policy without a clear trigger for when it applies is a policy that each person interprets individually. Does this situation require the expense approval process? That depends on whether this counts as a discretionary expense. Does this situation require an incident report? That depends on what counts as an incident. Without explicit triggers, compliance becomes a function of individual interpretation — which is precisely the variability that policies are supposed to eliminate.
No single required action. Policies that specify multiple options ("team members should consider X, Y, or Z depending on circumstances") do not produce consistent behavior. They produce the behavior that is most convenient in the moment, justified post-hoc by whichever option the policy listed that most closely resembles what was done. A policy that governs how expense reports are submitted should specify how they are submitted — one way, with clear exceptions. A policy that governs how customer complaints are escalated should specify the escalation path — not the range of appropriate responses depending on judgment.
Consequences not specified or enforced. A policy without a consequence for non-compliance is a suggestion. People are generally not malicious; they are busy and under pressure. When compliance is optional in practice — when non-compliance is never noted and never addressed — the implicit message is that the policy does not actually matter. This message, once received, is very difficult to unsend. Organizations that have established a norm of non-enforcement for a category of policy cannot restore compliance by simply announcing that the policy will now be enforced. They have to demonstrate it through actual enforcement of actual violations.
Conflicts with other policies or with incentive structures. Policies that require behavior that other policies contraindicate, or that require behavior that is contrary to how people are evaluated and compensated, will not produce consistent compliance. A policy that requires thorough documentation before project approval conflicts with an incentive structure that rewards speed to execution. A policy that requires consultation before making certain decisions conflicts with a culture that rewards decisive action. When policies conflict with the actual operating pressures of the organization, they reliably lose.
The Four-Element Design Standard
A policy that actually gets followed has four elements, each of which addresses one of the failure modes above.
A clear trigger. The trigger specifies, precisely, the situation that activates the policy. Not "when significant expenses are incurred" but "when any expense exceeding [threshold] is approved." Not "when concerns about a colleague's behavior arise" but "when a direct observation of behavior that appears to violate [specific category] occurs." The trigger should be stated in terms that a person in the middle of a busy workday can recognize without extensive judgment. If the trigger requires interpretation, it will be interpreted inconsistently.
A single unambiguous required action. The action specifies exactly what the person who has encountered the trigger situation is required to do. Not a menu of options. Not a description of the outcome to be achieved. An action. "Submit the [specific form] to [specific person or system] within [specific timeframe]." "Contact [specific function] via [specific channel] and report [specific information]." "Do not proceed until [specific approval] is obtained."
This level of specificity feels uncomfortable to policy drafters who are accustomed to writing in principles. The instinct is to preserve flexibility by leaving judgment in the hands of the person in the situation. This instinct is wrong in the context of policies that need to produce consistent behavior. Flexibility and consistency are in tension. A policy optimized for flexibility will not produce consistency. A policy optimized for consistency preserves flexibility by defining the exceptional cases explicitly rather than by leaving the ordinary cases to interpretation.
A specified consequence chain. The consequence chain specifies what happens when the policy is not followed. This does not require that consequences be severe — but they must exist and they must be enforced. A consequence chain that is specified but not enforced is worse than no consequence chain: it establishes that the organization will tell you what it will do and then not do it, which destroys credibility with more thoroughness than silence would.
The consequence chain should be proportional to the stakes of the policy, and it should account for the different circumstances under which non-compliance might occur. A first violation of an administrative policy is different from a repeated violation of a safety-critical policy. These should be treated differently by the consequence chain, and the chain should specify the difference.
Compatibility with incentive structures. Before a policy is finalized, it should be evaluated against the existing incentive structure: do the pressures under which people operate create systematic reason to not follow this policy? If the answer is yes, the policy will not be followed regardless of how well it is written. The incentive structure has to be addressed — either the incentives have to change, or the policy has to be designed around the incentive pressures rather than against them.
This evaluation is often skipped because it surfaces uncomfortable conclusions about the organization's actual priorities. A policy that requires behavior inconsistent with how people are evaluated reveals that the organization values two things that conflict. Acknowledging that tension is harder than writing the policy as if the tension did not exist.
A Worked Example: The Incident Report Nobody Filed
The four elements are easiest to understand when you watch one policy fail all four at once. Consider an incident-reporting policy of the kind almost every organization has. It reads: "Team members are expected to promptly report any significant incidents through appropriate channels so that the organization can respond effectively and maintain a culture of safety and accountability." It is signed, posted, and referenced in the onboarding deck. It produces almost no incident reports.
Walk it through the four elements. The trigger is "any significant incident" — which requires the person to first judge what counts as significant, in a moment when they are stressed and the cost of being wrong about that judgment is borne by them. The required action is "report through appropriate channels," which is a category, not a destination: the person has to determine which channel, in what form, to whom. The consequence chain is absent entirely; nothing happens if the report is not filed, and nothing happens to the reporter if it is — which, given that filing creates work and visibility, means the incentive runs against compliance. And the incentive structure is actively hostile: in a team evaluated on uninterrupted delivery, an incident report is a self-inflicted interruption that draws scrutiny to your own work.
Each failure compounds the others. Even a person motivated to comply faces an interpretation problem at the trigger, a routing problem at the action, no reinforcement at the consequence, and a career reason to stay quiet. The policy is not weak because people are careless. It is weak because every element that should carry behavior is missing or pointed the wrong way.
The redesign is mechanical once the elements are named. The trigger becomes a list of concrete observable events — "a customer's data was exposed to another customer," "a deployment caused a service outage longer than five minutes," "a physical injury occurred on site" — that a person can recognize without judging significance. The action becomes one destination: "file the incident form at [link] within twenty-four hours." The consequence chain specifies that a filed incident triggers a no-blame review and that a known-but-unfiled incident is itself the violation. And the incentive conflict is addressed directly by making the review explicitly no-blame, so that filing is not self-incrimination. The redesigned policy is shorter than the original and produces reports because each element now carries its share of the behavior.
How to Audit an Existing Policy Set
Most organizations have large collections of policies accumulated over years, written under different standards, and varying widely in quality. Auditing this set is not about reviewing the content of the policies — it is about evaluating whether each policy can actually produce compliance.
The audit applies four questions to each policy:
Can a person recognize the trigger? Read the trigger condition and imagine a person in the middle of a normal workday encountering the situation it describes. Would they recognize it as a situation that activates this policy? Or would they need to consult a lawyer or a manager to determine whether this counts? If the latter, the trigger needs to be rewritten.
Is there one required action? Count the number of distinct actions the policy requires. If there is more than one, determine whether they are sequential (do X, then Y) or conditional (do X in this case, Y in that case). Sequential actions are manageable. Conditional actions are the beginning of the flexibility-consistency tradeoff — evaluate whether the conditions are genuinely necessary or whether a single action with explicit exceptions would serve better.
Is there a consequence? If the policy is not followed, what happens? If the answer is "nothing formally specified," the policy is a suggestion.
Does it conflict with anything? Check the policy against (a) other policies in the same domain, and (b) the incentive structures — compensation, evaluation criteria, cultural norms — that govern the people who are supposed to follow it. Conflicts should be resolved at the audit stage, not left to the person encountering the situation to resolve in real time.
Policies that fail the audit should be revised, not left in place. A policy set that is mostly non-functional is actively harmful: it creates the appearance of governance while providing none of the substance, and it consumes the organizational bandwidth required to maintain a large document library without producing the compliance that document library was supposed to achieve.
A practical way to start the audit this week is to pull the three policies that matter most — the ones whose violation would cause the most damage — and run only the four questions against them, nothing else. Three policies, four questions, an afternoon. You will almost certainly find that at least one of the three fails on the trigger or the consequence, and that single finding is more useful than a comprehensive review you will never finish.
Writing for the Stressed, Distracted, Time-Pressured Person
The final test for any policy is the person at the worst possible moment. Not the thoughtful reader with time to consider the policy carefully. The person who is under deadline pressure, who has three things demanding their attention simultaneously, who encounters the situation the policy governs without having reviewed the policy recently.
This is not an edge case. This is the normal condition under which most policies are tested.
A policy that produces correct behavior in this person has passed the real test. A policy that produces correct behavior only when the person has time and attention to read it carefully has not.
Writing for this person requires:
Short sentences. Long sentences with multiple clauses require active cognitive processing. Short sentences do not. Under pressure, long sentences get misread or skipped. Short sentences get understood.
Active voice and imperative construction. "Expenses exceeding the threshold must be submitted" requires the reader to determine what role they play. "Submit expenses exceeding [threshold] to [system] within [timeframe]" does not. The action is stated directly. The subject of the sentence is the person.
Concrete specifics over abstract principles. "Submit Form A to the Finance inbox by end of business on Friday" is more useful than "ensure timely and appropriate processing of expense documentation." Both convey the intent. One conveys the action.
Visual structure that allows scanning. The trigger condition should be visually distinguishable from the required action. The consequence should be visually distinguishable from both. A person who encounters a policy document should be able to scan to the relevant section without reading the entire document.
Where This Standard Reaches Its Limits
The four-element standard is calibrated for policies whose job is to produce consistent behavior in routine, recognizable situations. It is not the right standard for every governing document, and applying it everywhere produces its own failure.
Some policies are genuinely principles-based by necessity. A code of professional ethics, a conflict-of-interest standard, a research-integrity policy — these govern situations too varied to enumerate as triggers and too dependent on context to reduce to a single required action. For these, the attempt to specify a concrete trigger and a single action does not produce compliance; it produces a brittle rulebook that the next novel situation immediately escapes. The right design for principles-based policy is different: clear values, worked examples of application, and a named person to consult when judgment is required. Forcing the four-element template onto it is a category error.
There is also a cost the standard does not eliminate. A single required action with explicit exceptions is more consistent than a menu of options, but it concentrates the consequence of getting the action wrong. If the specified action is poorly chosen, the policy now reliably produces the wrong behavior instead of variably producing a mix. Specificity raises the stakes of the design being correct. That is usually a good trade, because a wrong specific action is visible and fixable in a way that diffuse non-compliance is not — but it is a trade, not a free improvement, and it means the design work has to be done with more care, not less.
And no design survives an incentive structure that is genuinely opposed to it. The fourth element names this, but it is worth stating plainly as a limit: where the organization's real priorities conflict with what a policy requires, the best-written policy in the world loses. The four-element standard makes good policies followable. It cannot make an organization want to follow a policy it has structured every incentive against. That problem is upstream of policy design, and no amount of trigger precision reaches it.
The Maintenance Problem
Policies degrade. The conditions that made them sensible change. The people who wrote them leave. The organization the policy was designed for evolves. A policy set that is not actively maintained becomes increasingly disconnected from the organization it purports to govern.
Maintenance requires two things: a schedule and an owner. The schedule determines when each policy is reviewed for continued relevance and accuracy. The owner is responsible for executing the review and for escalating when the review reveals a policy that needs to be revised or retired.
The review process should ask: is the trigger condition still a situation that occurs? Is the required action still available and appropriate? Is the consequence chain still operational? Does the policy still reflect the organization's actual priorities and incentive structures?
Policies that fail this review should be revised or retired. A policy set where outdated policies remain in place has the same problem as a policy set that was never designed well: the signal-to-noise ratio degrades to the point where the entire set becomes unreliable as governance infrastructure.
Conclusion
Policy design is governance design. The policies that actually operate — that change what people do when the situations they govern occur — are the ones that were designed to be followed by people who are busy and under pressure, not by people with time to interpret them carefully.
The design standard is achievable and not complicated: clear trigger, single required action, specified consequence chain, compatibility with incentive structures. Most organizational policies fail at least one of these. The audit reveals the failures. The redesign addresses them.
The result is a policy set that is smaller, because the policies that were not working have been revised or removed, and that actually functions as governance infrastructure rather than as documentation that provides the appearance of governance without its substance.
Continue in this series
This piece is part of What Is Organizational Governance? A Systems Practitioner's Complete Guide, my systematic guide to organizational governance and operating systems. Related reading:
- The Five Signs Your Governance Is Theater, Not System
- What Is Organizational Governance? A Systems Practitioner's Complete Guide
- What Is Governance Theater?
- When Compliance Becomes a Competitive Advantage
Working through this in your own organization? I help technical leaders design it directly — advisory engagements.
