Until recently, the mil-spec for fruitcake (MIL-F-1499F) filled 18 pages with dense text describing every aspect of the allowable composition and baking process. Most of us would use a half-page recipe to get something just as inedible. Why the difference?
The mil-spec was written as a result of abuses during the Civil War when unscrupulous bakers would throw a few raisins into a barely cooked lump of flour and call it fruitcake. Given the legislated procurement process which required the service to accept the lowest bid, soldiers got stuck with discouraging regularity. The mil-spec tried to ensure that at least some minimum standards were met. Sure, you have to assume that people are basically evil but you might get something edible.
The problem comes in implementation over time. One specification document might be readable, especially that first clean draft. But a hundred of them? After they’ve been through a dozen inconsistent rewrites? And how do you interpret that incredibly specific policy when the circumstances have changed? People either comply with the specification by rote (not good) or ignore the policy altogether (worse).
I’ve been thinking a lot about governance lately and I think there’s a lesson here for corporate policies. You have a choice about how you try to get people to do the right thing.
Many companies follow the mil-spec model. They write detailed policies itemizing all the allowed and disallowed behaviors. They attempt to predict every scenario and end up adding to their policies for every new situation. Not only do you have an acceptable use policy for email but a separate one for Facebook and Twitter and instant messaging, all on top of the old guide for telephone ettiquette, etc, etc, etc. Regulators and auditors love this highly detailed approach. It shows that the policy writer has thought hard about the topic and, more importantly, it gives the regulator lots of concrete things to measure.
Of course, compliance under this model is suspect at best. Who has time to read a 200 page ethics guide? How do you enforce your policy when someone does something bad that’s not explicitly covered? Detail prevents gamesmanship but often at the cost of inhibiting critical thinking. Eventually, you’ll raise the costs of compliance past the costs of the problem you were originally trying to solve.
The alternative is to write policies more generally. Start with the assumption that most people basically want to do the right thing and set broad expectations on outcomes and approaches. Give them a short, understandable set of principles that can be applied across lots of scenarios and set specific standards only where absolutely necessary. Then give your staff the authority to use their discretion. Of course, you also have to hold them strictly accountable to living up to those broad expectations. You are delegating authority, not abrogating it.
The broader alternative carries its own risk, however. Regulators are much less comfortable with the lack of detail. So are your lawyers when it comes time to terminate someone for violating the policy. You may have to deal with someone deliberately gaming the rules. This approach takes real leadership. It may take your staff less time (which means they’re more likely to read the policy in the first place) but it will take more of your time. Is that a price you’re willing to pay?
So what’s your approach to governance like? Does your security policy read like a mil-spec, attempting to spell out every possible scenario and itemize every misdeed? Or do you take a broader approach? What’s worked for you?
Leave a Reply