The Death of Process

To write great policies, arm those in the future who will kill your darlings

Writing policy and process guidelines is hard. You work for weeks collecting everyone’s feedback, tweaking the wording to avoid all kinds of anti-patterns, and then still you have to watch people use it as a blunt instrument to bludgeon colleagues with anyway. There is no bulletproof policy that can’t be misused. There’s no trick to designing process so that people consistently honor the spirit and intention rather than the literal interpretation of the document in front of them. I spent months working with some of the deadliest and most effective policy wonks in DC — both on the Hill and in the White House — and the one thing I learned is that policy has a natural lifecycle. When it’s brand new it moves awkwardly through the world, when it settles in it hopefully thrives for a time.

But even if it does, no matter how successful it might be, eventually its routine wears its effectiveness down, its body starts to fail and it can no longer perform its role.

That’s because good policy fixes problems and when a problem is removed from the system, the system incentives change. Think about this way: why do startups start young, idealistic and innovative only to eventually grow more and more corporate and litigious in nature? It’s because early stage companies tend to hire people who prioritize the company’s well being and mature companies tend to hire people who prioritize their personal gain. But this isn’t about the loss of company culture. Nor are the early stage employees saints and the later stage employees parasites. It’s all about how structure determines incentives. When a company is young, the risk of failure is high. People who choose to join have likely passed on more stable opportunities, probably for better money. They do this because if the company is successful the reward for being early is greater than the reward they would get at those stable jobs, but the company has to be successful first. Prioritizing for personal gain doesn’t make any sense. There isn’t much personal value that can be extracted out of a young company, and the more you extract the more likely you will lose the big pay off in the future.

But once the company is successful, the risks/reward calculation is different. There is no big future pay off on the table anymore, all of the value add is based on what you can extract for yourself — money, benefits, job title, career advancement. More to the point, at truly big companies the odds that optimizing for your personal gain is going to affect the company’s stability is pretty low.

The risk is gone. The fear is gone. The opportunists move in.

Policy has the same problem. If the policy is good it lowers risk, it diminishes fear, and people forget why the policy was necessary in the first place. As soon as they are disconnected from the reason for the policy, they will start misusing the policy.

A trick I picked up years ago is not to save good policy from being weaponized but to plant instructions on how to destroy it for future wonks to use.

Every policy or process doc I write now has a section called “Reasons to Revisit.” It is essentially a reverse success criteria. Rather than a short list of things I would expect to see if the policy was successful — which I do but in a different section — I write about things I would expect to see if the policy needed substantial revisions or to just be killed off altogether.

It’s important that these signals be as specific as possible. If you’re familiar with the methodology of Objectives and Key Results, you should write them the same way you write Key Results. Be specific, be measurable and double check that whatever correlations you’re assuming are relevant.

Some policy people think they’re covered by writing a summary of their goals and intentions in the beginning of the document. That should make it clear to everyone what interpretations make sense. These “commander’s intent” style statements are good to have, but I’ve never seen them prevent anyone from abusing a policy unless they reference specific benchmarks. I used to spend a lot of time trying to keep compliance officers from using NIST guidelines to force us to ship bad software. Trust me, no one at NIST intents for this to happen. In these sort of scenarios no one cares what the intent of the policy is. They care about whether they can be blamed for bad outcomes or not. The strictest, most literal and inflexible interpretation of a policy is almost always the option that will ensure the benefit of the doubt in failure.

Other people think the problem of dying policies can be solved more easily by “sunset clauses”, a passage towards the end that gives the policy a clear expiration date. It’s true that sunset clauses will force the policy to be revised, but since the process of gathering comments and trying to get the various stakeholders to buy in to changes is long and painful, there’s no guarantee that the revised and reissued policy will change anything more than the sunset date written at the bottom.

Writing down a few explicit indicators that the policy is broken won’t make those that would allow dead policies to fester any more likely to remove them, but when a policy is failing there’s almost certainly someone out there that just hates it. There’s someone who watched a good initiative get completely tanked because of the bureaucracy feeding from the corpse of a dead policy. There’s someone who cares about all these bad outcomes and has the energy to attempt to prevent them. Explicitly calling out what failure looks like, arms these warriors with valuable ammunition. We can argue all day about what adapt to modern architectures and frameworks for IT resource utilization means, but it’s harder to argue about a statement like it takes longer than two months to patch a system.

You will never force a true bureaucrat to forego the risk avoidance that often keeps dead policy around. The point is to set up an adversarial system where those people have antagonists who are going to push them forward (or drag them forward kicking and screaming maybe)

So when I write policy, I always include a few internal facing failure signals and a few external facing failure signals because I know that five, ten years from now someone is going to think this policy I’ve worked so hard on eff-ing sucks. And they’re probably going to be right! Many of the problems I was worried about probably don’t exist anymore. There are likely some new problems I could never have guessed would come up. I know those future policy warriors will appear at some point and I want to make sure they have what they need to get the job done.