When Routine Work Needs a Rule — and When It Needs a Manager

Your team is waiting on a decision that should not be interesting. The customer refund is under the normal threshold, the vendor issue has happened before, and the same question is already sitting in three Slack threads because nobody knows whether this is a rule, an approval, or a managerial judgment call. That pause is not a people problem. It is a decision-rights problem.

Founders often try to fix this by asking for faster escalation or more responsible managers. That misses the point. Routine work gets stuck when the company has not decided which decisions should be governed by a rule and which decisions should be handled by a manager. If you do not draw that line, every exception feels urgent, every routine issue gets relitigated, and leadership time gets spent approving things that should have been settled long ago.

The core distinction: rules settle routine work, managers settle uncertainty

A rule is a pre-decided instruction for a known pattern. It tells people what to do when the condition is clear. A manager is needed when the situation is incomplete, ambiguous, cross-functional, or costly enough that judgment matters more than speed. The mistake most companies make is treating every difficult case as a manager problem and every repeatable case as a training problem.

The practical test is simple: if the same situation should produce the same answer most of the time, it belongs in a rule. If the answer depends on context, tradeoffs, or a risk the business has not already defined, it belongs with a manager. The question is not whether the issue feels important. The question is whether the company can describe the decision well enough that a capable operator can make it without phoning the founder.

A useful decision framework

Before you assign a decision, sort it through four filters: repeatability, risk, reversibility, and ambiguity. This gives you a clean way to separate routine execution from managerial judgment without turning every exception into a meeting.

If a case is repeatable, low-risk, reversible, and clear, write the rule and stop revisiting it. If it is non-repeatable, high-risk, hard to undo, or ambiguous, keep it with a manager. Most dysfunction appears in the middle: companies let routine cases float because they are afraid to be too rigid, then they let ambiguous cases stay informal because they do not want to write down the tradeoffs. Both habits create drag.

A realistic example: customer credits and refunds

Consider a services company handling post-project credits. A client complains about a missed deliverable and asks for a partial refund. The team has two bad options: route every request to the founder, or let each account manager negotiate ad hoc based on confidence, pressure, and mood.

A better operating model separates the decision into two parts. First, define a rule for standard cases: if the issue is documented, the dollar amount is below a set threshold, and the remediation is straightforward, the account manager can approve a credit within the boundary. Second, define the manager case: if the issue involves scope dispute, repeated failure, legal exposure, or an amount above threshold, it moves to a manager with the authority to weigh customer retention, margin, and precedent.

That structure does two things. It removes friction from the predictable cases and it reserves managerial attention for the cases where the tradeoff actually matters. It also creates better evidence. Over time, leadership can see which rules are too tight, which ones are being bypassed, and which recurring situations need a revised policy instead of another one-off conversation.

Common failure modes

• Everything is escalated because leaders do not trust the team. This turns management into an approval desk and teaches people to stop deciding.
• Rules are written too broadly. When the policy cannot handle ordinary variation, employees either ignore it or spend time hunting for exceptions.
• Managers stay involved in routine cases because no threshold or boundary was ever defined. That creates dependency and slows execution.
• A team confuses escalation with approval. Issues surface upward too early, but the person receiving them has no clear authority to decide, so the work boomerangs.
• Exception handling is undocumented. The company learns from cases but never turns them into better rules, so the same problems keep reappearing.
• People are praised for being “resourceful” when they really mean “working around the system.” That is not agility; it is a sign the system is underdesigned.

These failure modes usually come from one of two root causes: fear of losing control or reluctance to do the work of definition. A founder who wants speed but refuses boundaries gets neither. A manager who wants authority but refuses clarity gets noise. Good decision rights are specific enough to guide action and narrow enough to avoid pretending that judgment can be automated away.

How to implement the boundary in order

1. 1List the recurring decisions that consume time, create rework, or trigger unnecessary escalation. Start with the top ten by frequency or friction, not the most dramatic ones.
2. 2Classify each decision by the four filters: repeatability, risk, reversibility, and ambiguity. Be honest about which cases are routine and which actually require judgment.
3. 3Write the rule for the routine case in plain English. Include threshold, owner, required evidence, and what happens if the condition is not met.
4. 4Assign the manager case explicitly. Name the role, not just the person, so the decision does not collapse when someone is on vacation or promoted.
5. 5Define the escalation trigger. State exactly when a case leaves the rule and enters management review.
6. 6Publish examples. Show one normal case, one edge case, and one case that must be escalated.
7. 7Review the exceptions weekly for a short period. If the same exception appears more than once, decide whether the rule needs revision or the threshold is wrong.
8. 8Remove old habits. If leaders keep stepping into cases covered by the rule, the team will follow the behavior, not the policy.

This sequence matters because most companies try to write the policy after the conflict has already happened. That produces defensive rules, unclear ownership, and too many loopholes. You want the opposite: observe the pattern, define the boundary, then reinforce the boundary until it becomes normal operating behavior.

What good looks like in practice

In a healthy operating system, routine work moves without ceremony. People know when they can act, what evidence they need, and when they must stop and escalate. Managers are not flooded with small decisions. They spend their time on real exceptions, tradeoffs, and capability building. The founder is not the universal fallback. The organization can resolve ordinary issues without asking for permission every time.

You should be able to look at any recurring decision and answer three questions quickly: What is the rule? Who owns the rule? What case requires managerial judgment? If those answers are vague, the organization is not really operating; it is improvising with a few familiar people acting as human middleware.

The goal is not more bureaucracy. The goal is fewer unnecessary conversations. A company that knows when routine work needs a rule and when it needs a manager can move faster, train better, and surface real problems sooner. That is what operational maturity looks like in everyday work: less guessing, less rework, and more decisions made at the right level.