Why my estimates hold (and what I do when they will not)

I have been the developer giving the estimate and the CTO promising it to a board, which cured me of believing estimates are predictions. They are agreements about what happens when reality disagrees.

So I split every piece of work into the part I have done before and the part I have not. The first part gets a number I will stand behind. The second gets a time-boxed investigation with a decision at the end of it — not a guess dressed up in hours.

The other half is deciding in advance what gets cut. Before starting I ask which of the requested behaviours would be acceptable to ship in a dumber form: manual instead of automatic, admin-only instead of self-serve, one currency instead of five. Clients answer this easily at the start of a project and painfully in the last week of one.

And when I am going to miss, I say so on the day I know — not the day it is due. That has cost me approximately nothing over sixteen years and bought a great deal of trust. Nobody remembers the two-day slip they were warned about. Everybody remembers the deadline that quietly passed.