Every threshold is money. None is weeks
Open the delegation schedule of any organisation delivering construction and you're looking at a table of values. Up to this figure, a project manager. Above it, a director. Above that, a board.
The table is careful, it was thought about, and it protects the organisation from the thing it is designed to protect against, which is somebody committing money they should not commit.
Now look for the other column — the one saying how long a decision may take before the delay itself needs approving. It isn't there, on any of them.
Where the bands came from
The values in that table weren't set for your project. They're the organisation's standing limits, applied to whatever the organisation happens to be doing.
So the same threshold governs a job worth a few million and a job worth several hundred. On the first it catches things that matter. On the second it catches routine site decisions and sends them up two levels, because a figure representing a significant commitment on a small job represents a fortnight of ordinary progress on a large one.
The visible symptom is a director's inbox full of items they have no useful view on, arriving from a project they visit twice a year. That is a queue created by arithmetic rather than by anybody's judgement about what needs looking at.
Nothing about that is irrational from the organisation's side; a single schedule is easier to govern than one per project. It does mean the threshold on your job was set with reference to something other than your job, and that it's a thing you can ask about rather than a fact of nature.
Asking is worth a conversation once. A threshold raised for one project, with a reason recorded, removes a whole category of referrals for the life of the job and costs one meeting to obtain.
The asymmetry
Here's the whole week, and it follows from the missing column.
A decision that commits money is measured, routed and approved. A decision that commits time — deferring, referring, asking for more information, waiting for the next meeting — passes through no gate at all, because there is no threshold expressed in weeks for it to cross.
Follow that through and two things become visible. Something costing a modest sum that saves six weeks needs three signatures. Something costing nothing that loses six weeks needs none. The structure prices one of those and is silent about the other.
Which isn't a criticism of anybody in the chain. It's a description of what the instrument measures, and instruments shape behaviour in the direction of what they measure.
It also explains why exhortation fails here. Telling a chain of approvers to be quicker asks each of them to accept a personal exposure the structure has never asked them to weigh against anything.
What that makes rational
Put yourself in the position of somebody holding an approval request that sits at the edge of their authority.
Approving it exposes them. Their name is on it, the amount is recorded, and if it turns out badly the record shows they decided. Referring it upward exposes them to nothing at all: no name on a decision, no figure against them, and the referral is defensible as diligence.
So the individually rational move is to refer, and the individually rational move is collectively expensive. That's a structural incentive rather than a character trait, which matters because the responses differ. Character is addressed by talking to people. A structure is addressed by changing what gets measured.
Splitting to fit under a limit
A threshold expressed as a value also creates a second behaviour, and this one is worth naming because it looks like efficiency.
Work that would exceed a limit can be divided into pieces that don't. Two orders instead of one, three variations instead of one, a package let in halves. Each piece is genuine, each is approved by somebody holding the authority for that piece, and the aggregate appears nowhere as an aggregate.
Nothing in the system is capable of noticing. Each approval is correct on its own terms, and correctness at the item level is the only thing the control examines.
The motive can be keeping the job moving rather than avoiding scrutiny, and the effect is the same either way: a control designed to catch commitments above a size stops seeing them, and the only record that would show the pattern is one nobody produces.
The chain with no clock
One more absence, and it explains why escalation feels different from contractual approval.
The contract gives the Engineer periods. A review runs no more than so many days; a determination follows a stated procedure; a notice has a deadline. Those clocks are enforceable, and week 15 showed what they do to a document — including creating a permission by the mere passage of time.
No internal chain has anything resembling that. There is no such thing as a deemed internal approval.
An internal escalation chain has no clock anywhere in it. Nothing says a director shall respond within ten working days, and nothing happens if they don't. So an item referred upward enters a queue with no service level and no visibility, and its progress depends on whether the person who sent it keeps asking.
Which puts the sender in an odd position. They've done the correct thing by routing it properly, and the correct thing has made the item somebody else's while leaving the consequence theirs.
Interfaces Week 8 follows what happens when three organisations each do this on different calendars. Inside one organisation it is simpler and no faster.
System design
Row three is the whole intervention and its required quality is the part that makes it work: stated on all requests. A figure that appears only where the sender is frustrated is an argument. The same figure on everything is a field, and a field gets read.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Delegation schedule for this project | The organisation, standing | Dated, with what the bands were originally sized against | The value of this job | Which decisions leave site |
| Escalation route | You, by asking | A named person at every level, not a role | Who actually answered last time | Where an item goes and to whom |
| Cost per week of delay | You, on every request | Stated on all requests, not only the ones you care about | The activity it delays | The approver’s missing number |
| Approval log | You, two dates per item | Sent and answered, so the queue has a measurable length | The requests themselves | Whether escalation has a service level |
| Split-item aggregate | Nobody, unless you do it | Groups items divided beneath a threshold back into what they are | The work they collectively buy | Whether the control still works |
Row five has no producer unless somebody appoints themselves. Items split beneath a threshold are individually correct and collectively invisible, and the only way the aggregate exists is if one person adds it up.
Practical insight
Put a time price on every approval request you send. It costs you one line and you can start on the next one you write.
At the top of it: each week this is unresolved costs the project X — a delay to a named activity, a plant standing charge, a crew you have to hold or release, whatever is actually true for you. Not a threat and not an escalation. A fact your approver has no other way of knowing.
It works for a reason that has nothing to do with persuasion: you have supplied the missing column. The person weighing whether to refer your item upward holds one number, the value, and referring costs them nothing. Give them a second number and their calculation changes, because deferring now has a figure attached to it and their name sits against that too.
Do it on everything you send, including the requests that get approved the same afternoon. A line appearing only when you are frustrated reads as pressure. The same line on all your requests is a format — and a format is what week 9 said a decision needs in order to survive.
Key takeaways
- A delegation schedule is a table of values, and it has no column stating how long a decision may take.
- The bands are the organisation’s standing limits rather than limits set for your project.
- So the same threshold governs a small job and a large one, and on the large one it catches routine decisions.
- Committing money passes through a gate; committing time passes through none, because no threshold is expressed in weeks.
- Something costing a modest sum and saving six weeks needs three signatures; something costing nothing and losing six weeks needs none.
- Approving exposes the approver by name and figure. Referring upward exposes them to nothing and is defensible as diligence.
- So referral is individually rational and collectively expensive, which is a structural incentive rather than a character trait.
- A value threshold also invites splitting: two orders instead of one, each genuine, each approved, the aggregate recorded nowhere.
- The contract gives the Engineer enforceable periods; an internal escalation chain has no clock at any level.
- An item referred upward enters a queue with no service level, and its progress depends on the sender continuing to ask.
- Supplying a cost per week of delay gives the approver the number the structure omits, and changes the calculation rather than the argument.
Records born here. The delegation schedule as it applies to this project, with the date it was set · the approval thresholds and what they were originally sized against · the escalation route with a named person at each level · the cost per week of delay, stated on every request · the approval log, with sent and answered dates · the aggregate of items split beneath a threshold.
What is coming next
Above the individual approvals sits a body that meets to decide the ones nobody else can.
It has a name and a membership and a cycle, and what reaches it has already been shaped by the people preparing the papers. Alongside it runs the other recurring review the project holds, the one about things that haven't happened yet — which was set up in month one, has been held every month since, and has changed almost nothing.
Enjoyed this lesson?
Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.
Already following on LinkedIn works too — this is just for the weekly email.