When Rules Expire

Operating rules encode assumptions. When the assumptions change, the rules expire. Most founders never notice.

A constraint that made sense last year can calcify into orthodoxy this year because nobody went back to ask what it was actually protecting against. The rule keeps running past its expiration date, looking like discipline when it has become inertia.

The right question to ask about any operating constraint is not whether it worked when you designed it. It is whether the conditions that made it necessary still exist.

Constraints built around resource scarcity stop making sense when the resource gets cheaper. Constraints built around human bandwidth stop making sense when automation changes the cost structure. Constraints designed to enforce focus stop making sense when better filters are available.

Founders are good at designing rules. Most are bad at sunsetting them. The constraint that enforced the right behavior at the right moment accumulates authority it no longer deserves. Nobody wants to be the person who says the thing everyone agreed on no longer applies.

Two tests worth running on any rule you have been operating under for more than six months: What assumption was this built to protect? Does that assumption still hold?

If the answer to the second question is no, the rule is a candidate for revision, not a principle to defend.