Defining Rules Vs. Guidelines, Errors and Empowerment

Cheat To Win (an excellent book) had one lesson that I think growing companies should pay strict attention to — something that is the true difference between a rule and an guideline.

The difference is whether you allow thought in a decision. In loosely coherent systems, flexibility will usually perform better than rigid systems.

Think about a feature and its development.  There is a rough concept which is boiled into a spec that has a number of rules. As the feature is being created, a developer identifies a problem.

If this process is run in a rule-based system with the spec being the final authority (and a rule), it would be like lemmings jumping off a cliff.

RFCs — the standards that make up the protocols of the Internet — labor over the nuance of the words.  Should, must, may and others are meticulously placed and defined.  There’s a whole RFC (RFC 2119) devoted to this, also recognized as Best Current Practice number 14.

When you think about this process on a larger scale and if you are too rule based, you start thinking about your errors, false positives and false negatives (type I and type II errors). When you start making rules like this, your exceptions drive your rule making.

This article has a great description of getting these things wrong even with a small error rate (think spam).

Managers in fast growing companies have to be diligent about when to create a guideline which encourages thought and when to create rules which discourages thought.  Too many guidelines and there’s no direction, while too many rules makes robots.  The right balance is empowerment.