All organizations have policies, hopefully to further their purpose.
Unfortunately, many policies are simply rules without much consideration of efficacy. They tend to be things that create constraints without benefit or with unjustifiable benefits. Naturally these are difficult to enforce. People easily see through them. Whatever outcome was desired is lost in cracking the proverbial whip, only to sap the morale of everyone involved.
Rules are often created, with good intention to achieve a desired outcome. However, if we don’t convey that intention, rules easily morph into something else entirely. If we don’t value everyone understanding the rationale, we’ll quickly get to a point where we just dictate rules whenever a problem surfaces. If we’re not accountable to justify our rules to anyone but ourselves, it’s easy to forget to do this at all. And that’s how we end up with many policies that are simply rules without much consideration of efficacy.
If we want policies and rules to be effective, we must keep in mind the benefits. Everyone must be aware of these benefits and in agreement that a given set of policies are the best way to achieve said benefits.
One of the best ways to do this, is to link benefits to mutual incentives. If we achieve the desired outcome, everyone benefits. Then, the rules are simply a guide for how to get there. They become a set of self imposed constraints to achieve a desired outcome. It’s in everyone’s interest to follow them, or find a new set of rules that will help achieve the desired outcome.
For example, let’s say users frequently experience defects when we release software updates. Developers are doing the release and another team is supporting the system: taking calls from users, triaging issues, etc.
One typical reaction would be to create a policy that developers shouldn’t be allowed to release updates and we need the support team to review and release updates. In reality, this typically leads to delays and decreased capacity to release updates, not a reduction in defects. In a rushed environment, the support team will be relegated to rubber stamping releases. Especially if they don’t have much knowledge about the release process.
What if we step back, sit down all of the development and support staff and discuss the issue. What if we propose merging development and support teams and having everyone on rotating on-call duty on a 24×7 basis. What’s the likelihood that developers will want to find ways to fix problems before they affect users? What’s the likelihood that support staff will know what changes are coming and can provide applicable advice well in advance of the release? What if we take this further and we provide funds to adopt new development practices that catch defects sooner rather than later?
In the latter situation, by making everyone responsible to maintain a working system, we’re more likely to reduce defects. It’ll be of benefit to everyone. Nobody enjoys a phone call at 3 AM. The 24×7 on call duty is simply a constraint everyone can agree is necessary to foster a reduction in defects.