The governance model existed. It had been written, shared, and approved. The design system had a defined owner, a contribution process, a decision framework, and a set of standards that every component had to meet before it shipped.
The person enforcing it was the person who had initiated the initiative. Not because they had the deepest knowledge of the system. Because they had the authority that came with having started it. The director who commissioned the work became the governor of the work. And the people who actually used the system — the designers, the engineers, the product managers building products with it every day — were not consulted when the governance rules were written. They were informed. There is a difference.
This is the client versus user problem applied to governance. The director who bought the system is not the person who has to live inside it. The real users were asked to use the rules as they were. Nobody asked whether the rules made sense from where they were standing.
Accountability collapsed. Not because the rules were wrong. Because the people who were supposed to honor them had never agreed to them. They had been informed of them. Informed is not the same as consulted. Consulted is not the same as involved. And involved is the only one of the three that produces a person who feels genuinely bound by what was decided.
Governance without accountability is a suggestion with a committee attached. And the committee only meets when something has already gone wrong.
Why Accountability Collapses
Most governance models fail at the accountability layer for one of three reasons. All of them are structural, not personal.
Reason 1 — The Agreement Was Never Made
The rules were written by the people with the authority to write them. The people who have to follow them were told what the rules were. This is presented as communication. It is not accountability. You cannot hold someone accountable to an agreement they were never party to. Accountability requires a prior commitment. A prior commitment requires a conversation that actually happened.
A standard that was handed down is not a shared standard. It is a policy. Policies get followed when enforced and ignored when not. Shared standards get maintained because the people who hold them helped build them.
Reason 2 — Enforcement Replaced Clarity
Most organizations treat accountability as enforcement. Find the violation. Apply the consequence. The problem with this model is that enforcement is always retrospective — it arrives after the damage. And in organizational life, the cost of enforcing a rule is almost always higher than the cost of ignoring the violation. So enforcement gets deferred. The violation accumulates. The standard erodes quietly until enforcing it would require confronting months of accumulated precedent.
Enforcement is what accountability looks like when clarity failed earlier. The goal is not better enforcement. It is earlier clarity.
Reason 3 — The Consequence Felt Arbitrary
When a consequence arrives without a prior agreement about what the consequence would be — it feels political, not procedural. The person on the receiving end does not experience accountability. They experience power. And power applied without prior agreement does not produce behavior change. It produces resentment and workarounds.
Accountability that feels arbitrary is not accountability. It is consequence without context. And consequence without context is just punishment with extra steps.
What Actually Holds
The accountability mechanisms that survive delivery pressure, organizational politics, and personnel changes share three characteristics. None of them involve enforcement as the primary mechanism.
Characteristic 1 — Visible Agreements Made Before the Pressure
The agreement is explicit, written, and made before anyone is under pressure to violate it. Not a policy document distributed after the governance model was designed. A conversation that happened before the first component shipped, where the people who would be governed by the standard were in the room and had the opportunity to shape it.
The test of a visible agreement is simple: can every person who is expected to honor it describe it in the same words? If the answer is no — the agreement was not made. A document was distributed.
Characteristic 2 — Fast Feedback Before Accumulation
The moment a standard slips, the feedback arrives. Not at the quarterly review. Not at the post-mortem. At the moment of the slip, or as close to it as the process allows. Fast feedback keeps the standard visible and keeps the cost of course-correction small. Slow feedback allows the drift to accumulate until correction requires a confrontation that nobody wants to have.
Fast feedback is not the same as surveillance. It is a structural feature of the process — a check built into the workflow that surfaces the deviation before it becomes a pattern. Not a manager watching. A process catching.
Characteristic 3 — Consequences That Feel Fair, Not Arbitrary
The consequence for violating the standard was agreed upon before anyone violated it. The person who exceeds the standard knows what will happen. The person who falls short knows what will happen. Neither is a surprise. Neither feels political. Both feel proportionate because both were defined in advance by the people who would be subject to them.
Shared clarity under pressure is not a soft alternative to accountability. It is the only accountability model that does not require a manager to be the enforcement mechanism. Managers are not a scalable governance layer. Clarity is.
Three Rules for Accountability That Holds
Rule 1 — Write the Agreement Before the Pressure
Before the governance model goes live — run one session with the people who will be governed by it. Not a presentation. A working session. The question is not whether they agree with the standard. The question is whether they can describe it, apply it to a real scenario, and name a situation where it would require them to do something they would not otherwise do.
Document the agreement in Notion or Confluence — not as a policy page but as a shared reference that every participant helped shape. The document is not the agreement. The conversation is the agreement. The document is the record of it.
If the session reveals that the standard is unclear, unworkable, or unknown to the people who have to follow it — that is not a failure of the session. That is the session doing its job.
Rule 2 — Make Feedback Visible and Fast
Build the feedback mechanism into the workflow, not into the manager’s calendar. Linear and Jira both support automated flags on tickets that match defined criteria — a component submitted without a token reference, a PR opened without a review, a deprecation notice issued without a migration guide attached. The system catches the deviation. The manager does not have to.
For deviations that require a human conversation — Loom makes the feedback asynchronous and timestamped. A three-minute recording that names the specific deviation, references the prior agreement, and asks one question: was there a reason this standard was not followed here? That question is not accusatory. It is an invitation to surface either a workflow gap or a genuine exception. Both are useful. Neither requires a meeting.
Feedback that arrives three weeks after the deviation is not fast feedback. It is a delayed consequence. And delayed consequences do not change the behavior that produced them. They just make the person feel managed.
Rule 3 — Define the Consequence Before Anyone Needs It
For each standard in the governance model — name what happens when it is not met. Not in punitive terms. In procedural ones. A component that ships without token compliance is flagged and returned to the contributing squad for revision. A deprecation that goes live without a migration guide is rolled back until the guide exists. A decision made outside the defined authority level is reviewed and potentially reversed.
These consequences are not punishments. They are the natural results of a process that was not followed. They feel fair when they were defined in advance and arbitrary when they were not. Define them before anyone needs them. Share them with everyone who will be subject to them. Then apply them consistently — not selectively, not politically, not based on who submitted the violation.
A consequence applied selectively is not a governance mechanism. It is a power signal. And power signals produce compliance from people with less power and resentment from everyone else.
The Quick Win: Run the Agreement Audit
This week: identify the three most important standards in your design system governance model. For each one, answer three questions.
Can every person who is expected to follow this standard describe it in the same words? Did the people who are governed by this standard have any input into it before it was finalized? Is there a defined consequence for not meeting it — and was that consequence communicated before anyone violated it?
If the answer to all three is no — the standard is not a governance mechanism. It is a preference held by the people with the most authority. Preferences are not enforceable. Agreements are.
Pick the one standard with the most no answers. Schedule one working session with the people who have to follow it. Not to explain it. To build it together from the existing foundation. The version of the standard that comes out of that session will be followed. The version that was handed down will continue to be ignored when it is inconvenient.
The Argument
The accountability gap is not a people problem. It is a design problem. The people who were never consulted cannot be held to agreements they never made. The people who defined the rules without the people who have to follow them should not be surprised when the rules do not hold. Governance that relies on authority to enforce it will fail every time the authority is absent, distracted, or politically outmaneuvered. Governance that relies on shared clarity holds because the people who hold it helped build it. Build the agreement before the pressure. Make the feedback fast. Define the consequence before anyone needs it. That is the entire model.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a governance model was built with the people who had to use it and held without a single enforcement conversation.
Before you go, entertain this for a second
Which governance standard in your design system was written without the people who have to follow it — and how is that going?
