When to Set Rules in a Small Company? A Decision Framework for Rule Boundaries

The dilemma of small company rules

Years ago, when I founded Chengdu Past Time Network Technology, we had only four people. No rules at all: push directly to master, reimbursement via WeChat screenshot, take leave by just saying so. Things moved fast, but occasionally went wrong — once a database field mismatch caused half a day of rollback.

As the team grew to a dozen, the chaos started to bother me. So I copied the rule system from my previous large company: weekly standup, weekly report, code review, leave approval flow, reimbursement process. Result? After two months, everyone complained. Output dropped. Writing weekly reports took longer than writing code. Standups became a ritual. An urgent bug took two days to fix because of the approval chain.

This is the classic small company rule trap: either no rules and chaos, or too many rules and paralysis.

Core insight: Rules are a trade-off in transaction costs

I later realized: a rule is essentially a transaction cost. You spend time defining it and enforcing it, to reduce another cost — the loss from randomness, errors, or conflicts. If the cost of enforcing the rule exceeds the cost it saves, the rule is a liability.

Why do big companies need so many rules? Because scale amplifies the cost of errors. A bad deployment can affect millions of users. But for a small company, the cost of most errors is low, while the value of speed is high.

So the question is not "should we have rules?" but "where is the boundary?"

Decision framework: Three questions

I now ask three questions before deciding to formalize anything:

1. How often does this happen?

If it's weekly (e.g., merge conflicts, customer feedback), a simple standard process helps. If it's twice a year (e.g., server crash), a checklist is enough, not a rule.

2. How costly is a mistake?

If one mistake could lose thousands of dollars or a key customer, you need protection. If it just wastes half a day, allow mistakes and learn.

3. Does the executor have sound judgment?

If everyone is senior, a code style document (not enforcement) is fine. If there are newcomers or cross-team work, automate checks (like lint, CI) rather than write rules.

Example: reimbursement. Our company had few expense reports — maybe three a month, each under $50. I used to require a form, approval, and finance check. People procrastinated and only reported at year end. I changed it: under $50, just tell me on WeChat with a screenshot; over $50, a simple note. One year later, no problems, and people are happier to report promptly.

Rule boundaries by team size

From my experience:

• 1-5 people (startup): Almost no rules. Trust and verbal agreements are enough. The only must is how to split money.
• 6-15 people (growing): Introduce lightweight rules: branch strategy, customer response SOP, meeting rhythm. But question every rule: can it be lighter?
• 16-30 people (expansion): Need basic finance, HR, and project management rules, but avoid complex approvals. Use low-code automation for leave requests, not a heavy workflow.

Counterintuitive finding: The more detailed a rule, the more likely it will be bypassed. People find loopholes, and nobody remembers the details. Better to have a few principles plus a "when in doubt, ask me" fallback.

How to build rules gradually

Don't write a handbook in one go. I recommend:

1. Record friction points: When a problem repeats or a decision stalls, note it.
2. Minimal solution: Write a one-pager or automate for that friction. Don't anticipate future edge cases.
3. Trial for a month: If no issue arises from the lack of rule, or the rule itself causes new problems, adjust or drop it.
4. Quarterly review: Delete obsolete rules, simplify surviving ones.

For example, frequent merge conflicts. I initially wanted a "git workflow" document. Then I just wrote a simple script that forces rebase and auto-checks. That script works better than any rule.

Rules are not the goal

Finally, the biggest mistake small companies make is treating "building a rule system" as a sign of management capability. KPI, OKR, weekly reports, daily reports, performance reviews — these tools are fine, but if you adopt them just because "others do it," they become a burden.

Real management is enabling the team to make good decisions at low cost. Rules are only one tool, not even the most important one. Trust, communication, and shared values often solve more problems than black-and-white documents.

PaxLee