Your SOPs Are Not the Problem
A distribution company founder spent months building comprehensive systems. Scorecards, SOPs, software, org chart, goals. Every process documented. Every hire solid. And still, every minor decision landed back on the founder's desk.
The team had the documentation. They just kept calling anyway.
This is not laziness, and it is not a hiring problem. The founder tried setting dollar thresholds. Tried pointing people back to the SOPs. Still got the calls. When they finally took a two-week vacation, things ran acceptably. The team could operate without daily founder input. They just were not doing it.
Most founders facing this assume they need better documentation, clearer processes, or different people. They do not. The problem lives one layer below the documentation: decision authority is undefined, and founder availability reinforces the habit of asking instead of deciding.
When Decision Authority Lives in the Founder's Head
Teams do not escalate because they cannot find the SOP. They escalate because the decision-making process still lives in the founder's head.
Every time the team faces something slightly outside the normal workflow, they come back to the founder because they do not know the boundaries of their authority. Can they approve a vendor change under five hundred dollars? Can they refund a customer without checking? Can they adjust a delivery schedule to keep a big client happy?
The SOP says how to process a vendor change. It does not say who gets to decide. Those are different questions, and the second one is what stops people.
Without explicit decision levels, the team defaults to the safest behavior: ask. Especially when the founder has high standards but no stated tolerances. Nobody wants to cross an invisible line, so they treat every decision as potentially the one that crosses it.
The SOP says how. Nothing says who. Those are different questions, and the second one is what stops people.
Why Smart Hires Keep Asking Permission
Hiring good people does not fix this. It can make it worse.
A sharp new hire notices that the founder responds immediately to every Slack message and picks up every call. They learn quickly that asking is faster than deciding. The founder's availability trains the behavior. Even when the answer is already documented, interruption works.
The new hire is not being difficult. They are optimizing for the system as it actually runs, not as the founder wishes it ran. If asking gets a fast answer and deciding independently carries unknown risk, asking wins.
This replicates. Add an operations manager to reduce founder load, and without clear decision authority the new hire becomes another person escalating to the founder instead of a decision buffer. You have not reduced the bottleneck. You have just added a step. The same pattern shows up in businesses where the pile that waits for vacation return reveals how much still depends on one person.
Decision Levels: Own, Inform, Approve
The fix is not more documentation. It is defining three decision levels for each role, separate from the process SOPs.
| Level | Definition | Example |
|---|---|---|
| Own outright | Decide independently, no approval needed | Warehouse lead owns reorder timing below safety threshold |
| Own + inform | Decide independently, report in daily/weekly check-in | Project manager owns schedule adjustments, logs new timeline |
| Require approval | Cannot proceed without explicit sign-off | Vendor contracts over threshold, pricing exceptions, hiring |
Every role needs all three levels spelled out, with explicit thresholds. Dollar amounts. Customer impact windows. Time constraints. Not just principles. The version that works says "you own credits under $200, report monthly" not "use good judgment on customer issues."
Document this separately from your process SOPs. Process says how. Decision authority says who.
- List every recurring decision type for each role (vendor approvals, customer credits, schedule changes, pricing adjustments).
- Assign a decision level to each: own outright, own and inform, or require approval.
- Set explicit thresholds in dollars, time, or customer impact, not principles like "use good judgment."
- Document separately from SOPs so the team can find authority boundaries without hunting through process docs.
- Review quarterly as the business grows and thresholds need adjustment.
The Vacation Test and the New Hire Trap
The two-week vacation is the tell. If things ran acceptably while you were gone, your team has the capability. The problem is behavioral, not technical.
But behavior runs both directions. The team needs to practice making decisions within defined boundaries. You need to become strategically unavailable. That means blocking off working hours when you do not respond to Slack, do not pick up the phone, and do not answer questions that fall inside a decision level someone else owns.
When someone escalates a decision that should be theirs, redirect them to the decision level framework instead of answering. The first few times this will feel slow and inefficient. It is an investment. You are training the behavior you actually want.
Before you hire more people, test whether decision frameworks work with your current team. If you are planning to add accounting, marketing, product, and field sales but have not solved decision ownership with the people already here, you are about to replicate the bottleneck across five more people. That is expensive.
Fix the authority problem with the team that proved they can operate without you. Then hire into a system that does not route everything through the founder by default.
Decision frameworks are not set-it-and-forget-it.
As your business grows and new situations emerge, authority boundaries need ongoing adjustment. InsiderHub helps operators build decision systems that scale with the business, then maintains them as part of a flat monthly engagement. If your team has the capability but still routes every decision through you, the fix is not more documentation. It is clearer boundaries and the discipline to enforce them. We can help you define those boundaries, test them with your current team, and adjust as you grow.
Book a workflow audit →