Skip to content
Institute of Technical Leadership
All blog posts

Delivery & Risk

Padding the Estimate Doesn't Protect You. Naming the Risk Does.

Principal Architect · 18 June 2026 · 5 min read

A delivery lead I worked with added about 30 per cent to every estimate that crossed his desk. He called it realism and he wasn't entirely wrong: he delivered on time for two years, which is better than most. Then one project went sideways in a way the padding couldn't cover, and he had nothing to say in the review except that he'd thought it would be fine. He'd spent two years training everyone around him to believe his numbers were soft, and the one time he needed them believed, they weren't.

Padding is a bet that nobody will ask what's inside the number

When you pad, you're taking something you actually know, which is that a specific part of this work might go badly, and dissolving it into a single figure where it can't be seen, discussed or planned against.

You know the migration script might not handle the four legacy record types. That's real knowledge. It's the most valuable thing you have. So you turn it into "let's say six weeks instead of four" and hand over a number that contains a risk, a mitigation and a judgement call, all invisible, all yours alone.

Then one of two things happens.

The risk doesn't materialise, you deliver in four and a half weeks, and everyone updates their internal model of you slightly: this person's numbers have air in them. Do that four times and your estimates get discounted automatically before you've finished saying them.

Or the risk materialises and eats more than the padding, and now you're explaining a slip while holding nothing that shows you saw it coming. Your own honesty has no paper trail.

The padding gets negotiated away, and nobody knows what they just bought

This is the part people underestimate. Padded numbers get cut. Not maliciously. Somebody senior looks at eleven weeks, feels it's long, and asks for nine. They're not being unreasonable, they have no information suggesting otherwise. The number is just a number to them.

A firmware upgrade across roughly 310 branches for a builders merchant. The engineering view was eight weeks of actual work at eight branches a night, in the window between the trade counters shutting and the yard opening again at six. The lead quoted eleven, carrying three weeks of quiet contingency for a known defect in the firmware train those branches were currently running, which might or might not affect them.

The sponsor came back and asked for nine. The lead said yes, because there was still a week of slack in there and because arguing felt like a poor use of political capital in week one.

What actually happened in that exchange: a sponsor accepted a significant technical risk without knowing it existed, and a lead surrendered a mitigation without ever telling anyone it was a mitigation. The defect turned up in week three, on about 90 branches. The programme lost four weeks, and the conversation in the recovery meeting was about estimating accuracy rather than about a vendor defect, because nothing on paper mentioned a vendor defect.

Here's the version that costs the same to write and lands completely differently:

"Eight weeks, assuming the nightly change window holds at eight branches per night. There's a known defect in the firmware train those branches are on. We'll know by week two whether we're exposed, and if we are, add three weeks. You can either put those three weeks in the plan now, or we take a decision point in week two. My recommendation is the decision point, because if we're clear we give the three weeks back to the business."

Same underlying knowledge. Eleven weeks either way, in the worst case. But now the sponsor owns the risk they're actually carrying, the date has a named condition attached, there's a review point in the calendar, and when the defect appears in week three, nobody is surprised and nobody is looking for someone to blame for the estimate.

Two numbers and a name

The habit to build is simple enough to apply in a corridor. Every time you give a date, give three things with it.

The number, based on the work as you understand it, with no hidden margin. What has to be true for that number to hold, as a sentence a non-engineer can read. What it becomes if that thing isn't true, and how you'll know.

Then, and this is the bit that separates it from covering yourself, add the name and the decision. Who needs to decide, what you recommend, and by when. A named risk with no recommendation attached is just a record you can point at later, and everyone recognises that move for what it is. You're not building an alibi. You're transferring one decision, with your best advice attached, to the person whose decision it actually is.

You'll notice this is harder than padding. It requires you to say out loud that you don't know something, in front of people who'd prefer certainty. That discomfort is roughly the whole job.

Monday

Open whatever plan or estimate you've most recently sent to someone senior. Find the one number in it you know is soft, the one with quiet margin inside it. You know exactly which one.

Rewrite that single line today, in the shape above: the real number, the assumption it rests on, what it becomes if the assumption breaks, and when you'll know. Send it to the person who owns the date with one line saying you've made the margin in your estimate explicit.

They may well decide to accept the risk rather than the contingency. That's a legitimate decision and it was always theirs to make. The difference is that this time, they know they're making it.

Principal Architect

Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.

This is the kind of thing we teach properly in Foundations of Technical Leadership.

Foundations of Technical Leadership is 25 self-paced lessons, with templates you can use the same week.