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.
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.
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.
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.