What actually needs approval
Most approval processes are archaeology. Someone made a costly mistake in year one, an approval step was added, and it never got removed. Three years later everything routes through a person who now approves 95% of requests without reading them, which means the control provides no control at all.
Three genuine reasons for a gate:
Hard to reverse. Signing a contract, deleting production data, publishing something public, making an offer of employment.
Above a threshold you set deliberately. Not a threshold inherited from when the company had no money.
Legal or customer exposure. Anything that creates an obligation to someone outside the company.
The test for an existing approval
What percentage of these requests get rejected? If it is close to zero, the step is not a control, it is a delay with a signature on it. Either lower the threshold so it catches real decisions, or remove it.
Everything outside those three should be a decision the person doing the work makes, with a record so it can be reviewed, rather than a gate that stops work while someone else is in a meeting.
Designing the approval
Set a no-ask threshold and mean it
A figure below which nobody asks anyone. Publish it. The right level is where the cost of the approval exceeds the cost of the occasional wrong purchase.
Most small companies set this far too low, then wonder why their managers spend afternoons approving software subscriptions.
Publish the numberOne approver per category, with a named backup
Spending, hiring, customer commitments, anything legal. One person owns each, and one named person covers when they are away.
The backup is not optional. An approver on holiday should never stop the business, and "it can wait until Monday" is how a two-day task becomes a two-week one.
Name the backupMake the request contain the decision
What, how much, why, what happens if we do not, and what the alternatives were. A template, so nothing is missing.
Most approval delay is not deliberation, it is the approver asking for information the request should have carried.
A template saves daysGive it a deadline and a default
"If I have not heard back by Thursday, I will proceed with option B." Written into the request itself.
This single mechanism removes most of the pain from approvals, because silence stops being a blocker and becomes a decision.
The highest-value rule hereRecord who approved, and when
In one place, searchable. Not in a chat thread that scrolls away.
The record is often more valuable than the gate. When something goes wrong six months later, what matters is what was known and who agreed to it.
Searchable, not scrollable
Why approvals become bottlenecks
Four causes, and they are all structural rather than personal.
Everything routes through one person. Usually the founder. The fix is delegating whole categories rather than individual decisions, which our guide to delegating without micromanaging covers in detail. The uncomfortable part is that delegation means some decisions will be made differently from how you would make them, and reclaiming the category the first time that happens undoes it.
No backup. One person away, everything stops. Costs nothing to fix and almost nobody does it until it bites.
Approval is a meeting. If a decision waits for the next scheduled call, everything moves at the speed of the calendar. Batching approvals into the weekly review slot is fine for non-urgent items, as long as urgent ones have an out-of-band route. Our guide to a weekly operating rhythm covers where they fit.
Thresholds set for a smaller company. A limit that made sense at three people and no revenue is an active tax at twenty. Review it annually, and expect to raise it.
Deadlines and defaults
The default-action mechanism deserves its own emphasis, because it is what separates a fast approval culture from a slow one.
An approval request with no deadline waits indefinitely, and the person waiting has no legitimate way to escalate. An approval request that says what will happen in the absence of a response converts silence into a decision, which is almost always better than a stall.
Sensible defaults by risk:
| Risk level | Deadline | Default if no response |
|---|---|---|
| Low, reversible | 24 hours | Proceed |
| Moderate | 48 hours | Proceed with the safer option |
| High, hard to reverse | Named date | Do not proceed. Escalate instead |
The bottom row matters. Defaulting to yes on something irreversible is not speed, it is recklessness with a process wrapped around it.
Once the shape is settled, the mechanical parts are worth automating: the request appearing for the right person, the reminder when a deadline approaches, the record of who decided. The judgement itself never is, which is the line drawn in what to automate first. Pod holds approvals and polls alongside the boards and check-ins the team already uses, so a decision leaves a record in the same place as the work it unblocks rather than in a chat thread nobody can find later.
Frequently asked questions
- What should require approval in a small company?
- Anything hard to reverse, anything above a spending threshold you set deliberately, and anything with legal or customer exposure. Everything else should be a decision the person doing the work can make, with a record rather than a gate.
- How many approvers should there be?
- One per category, with one named backup. Multi-person approval chains in a small company add days without adding judgement, and they diffuse accountability so nobody feels responsible for the decision.
- What is a sensible spending threshold?
- Set it where the cost of the approval exceeds the risk. If a manager spends fifteen minutes approving a purchase worth a few hundred, the approval costs more than the mistake it prevents. Many small companies set it far too low.
- Should approvals be in writing?
- Yes, always, with a record of who decided and when. Verbal approvals are how disputes start, and the record is more valuable than the gate itself when something later goes wrong.
- How do you stop the founder being the bottleneck for everything?
- Delegate categories rather than individual decisions, then let people make some wrong calls without reclaiming the category. Approving each item personally while claiming to have delegated is the most common version of this problem.