Why two pairs of eyes is a control, not a courtesy
The pattern is old. Banks have used it since paper ledgers; it appears in SOX 404 guidance as segregation of duties, in Basel as the four-eyes principle, and in every payment system you have used today. The reason is unglamorous: the person who made the mistake is the worst person to find it. They know what they meant to write, so they read what they meant, not what is on the page.
An independent checker does not have that mental model. They look at the artefact and the standard. That is the whole mechanism — and it is why the checker must not be the maker's manager under time pressure, and must never be the maker.
The three roles, precisely
| Role | Owns | Must not | Output |
|---|---|---|---|
| Maker | Producing the work to the brief and the standard | Approve their own work; choose their own checker | The artefact + a short note on what was done |
| Checker | Correctness, completeness, evidence | Rewrite the work silently — that destroys the trail | Pass, or a named defect with a deadline |
| Approver | The decision to release, and the rating | Approve work they have not opened | A signature, a timestamp, a score |
In a team of four, one person can wear two hats — but never maker and checker on the same item. The system should refuse the overlap rather than relying on good intentions. In TeamControlSheet the database rejects a task where the reviewer equals the assignee, so the control cannot be talked around.
The five states of a controlled task
- Assigned — owner, deadline, reviewer and urgency are set before any work starts. A task without an owner is a wish.
- In progress — the maker works; the clock is visible to both sides.
- Submitted — the maker declares it done, with notes and attachments. This is a handover, not a notification.
- Reviewed — the checker has passed it (or reverted it with a named defect). Reverted is a first-class state, not a failure.
- Approved / done — the approver signs off, the completion time is recorded, and the rating is written to the confidential ratings table.
Two things fall out of this list that spreadsheets cannot do: the time between each state is measurable (cycle time per stage), and "on time" is decided by the server from the submitted timestamp, not by anyone's memory.
Make the deadline mechanical, not emotional
The failure mode of every approval workflow is politeness. The reviewer has a bad week, work sits in Submitted, and nobody says anything until a client does. Fix it with rules rather than character:
- Nudge the owner before the deadline, and the reviewer the moment it is submitted.
- Escalate on a fixed ladder — 1 hour before, at the deadline, then +2h, +1 day — to the reviewer, then the approver.
- Repeat recurring obligations (month-end, payroll, statutory filings) automatically, so the control does not depend on someone remembering to create the task.
- Never let an escalation be silent: it must appear in the task's audit trail, otherwise you cannot tell a late approval from a missing one.
A control that depends on somebody remembering is a hope, not a control. Move the memory into the system.
The four numbers that tell you it is working
On-time %
Approved before the deadline ÷ all approvals. The single best predictor of whether clients notice your process.
Rework rate
Tasks reverted at least once ÷ submitted tasks. A rising rate means the brief, not the person, is usually at fault.
Checker latency
Median hours between submitted and reviewed. This is where approval workflows rot — and where the escalation ladder earns its keep.
Rating spread
Variance of ratings by approver. If one approver gives 5s to everything, the rating is decoration, not data.
Five ways this pattern fails in real companies
- Rubber-stamping. The approver is the maker's manager and approves in bulk at 6pm. Fix: sample audit, and expose approval latency per approver.
- Checker as reworker. The checker quietly fixes the work instead of returning it. Fix: rework must go back to the maker and be visible.
- Role confusion. Maker picks a friendly checker. Fix: the reviewer is assigned by the team leader or derived from the reporting line.
- Approval theatre. Three signatures, none of which can actually stop the release. Fix: exactly one approver with authority, named in advance.
- No trail. The approval happens in chat and disappears. Fix: the approval writes an immutable row with who, when, and what score.
Running it in a week
- Day 1 — list the artefacts that must never go out unchecked (filings, client deliverables, payments, board packs). Ten is plenty to start.
- Day 2 — name the roles for each artefact. If one person is maker and checker, you found a real control gap, not a scheduling problem.
- Day 3 — set the standard: what does "checked" mean for this artefact? Two or three bullet points beat a 40-page policy.
- Day 4 — move it into the tool. Import the backlog from CSV, assign reviewers, set escalation windows.
- Day 5 — agree the four metrics and their targets. Publish them where the team can see them.
Teams usually run this on TeamControlSheet's Free plan first — one company, five users, the full workflow — then upgrade when they add entities or people. The workspace takes about a minute to create, and the CSV template takes the backlog.
Questions people ask before adopting it
Is maker–checker the same as four-eyes?
Four-eyes is the two-person minimum: maker plus checker. Maker–checker–approver adds a third decision point — the authority to release — plus the performance rating that makes the review meaningful over time. In small teams the approver may also be the checker, but never the maker.
What is the difference between reviewed and approved?
Reviewed means the work meets the standard. Approved means a named person has accepted responsibility for releasing it, with a timestamp and a rating. Splitting them gives you a real audit trail and tells you whether the bottleneck is quality or authority.
How do I stop approvals becoming rubber stamps?
Make approval cost visible: per-approver latency, rating spread and sample audits. If one approver scores everything 5 and approves in under a minute, that is your finding — not a happy team.
Can one person be maker and checker in a small team?
No — that removes the entire control. If your team is too small, bring in the team leader as checker for the highest-risk artefacts rather than self-reviewing. TeamControlSheet blocks self-review at the database level.
Does this work outside finance?
It is used for legal drafts, client deliverables, HR letters, procurement, engineering releases and regulatory filings. Anywhere an error is cheaper to catch than to fix afterwards.
Put the control in place this week
Free for five users. No card, no trial countdown. Bring the backlog with a CSV.