John Cook blogged about stupid policies within organizations, in response to a quote he saw:
Policies are organizational scar tissue. They are codiﬁed overreactions to unlikely-to-happen-again situations.
John mostly agreed and pointed out that policies sometimes arise for good reasons, though the reasons may be hard to reconstruct later. I want to take the conversation in a different direction: How do you design an organization so that the policies can change if the circumstances have changed?
There are policies designed to handle unlikely events and policies designed to handle everyday events. Both kinds can atrophy over time and no longer be relevant. The ones for unlikely situations are harder to set up time-outs for, but the ones for everyday use are the more costly when they outlive their usefulness.
The hard part of the situation John described is figuring out a different approach that leaves you more flexibility. (If you've built a Maginot line, as in his metaphor, you're pretty much stuck.) So the challenge is designing an organizational culture that can identify outmoded policies and change or discard them.
In a small, agile organization I once worked in, we developed a checklist for use by the project manager (me!) during the release process. The reason was that there were things I occasionally forgot to do that came back to bite me or my boss, the CEO. The rule about the checklist was that it was for me to fill out on my own responsibility. There were items that asked for initials from other people, but I was allowed to ignore them on my own initiative. We updated the checklist often enough that I could remove useless items whenever I noticed that their relevance had disappeared.
For a larger organization, you don't want an individual to make those decisions unless there's a way for them to know the original reason for the policy. So writing up the rationale along with the policy makes it possible for the person on the spot to know whether they should ignore or attempt to change the policy. In a small agile organization you don't want the overhead of having to write up the rationale every time you add a process step, but if the organization grows, you'll need the rationale. It's a dynamic tension that organizations have to learn to adapt to as they grow.
ADDED During the ensuing discussion on The Endeavor, someone pointed to NetFlix' internal presentation on their corporate culture. Very impressive. If I wanted a job, that's the kind of company I want to work in.