Delivery Realism

One of my favourite pizza places is on the other side of town — the kind that makes a proper thin-crust Neapolitan: simple ingredients, blistered crust, enough heat that everything works only because the timing is right.

When you eat there, it is fantastic. They also deliver, and technically it works. But after 30-plus minutes in traffic, it is not the same pizza. The crust has softened, the heat has faded, the texture is gone. The thing that made it excellent in the restaurant did not survive the delivery model.

The pizza is good. The delivery reality is not.

A lot of technology and organizational ideas fail in exactly this way.

They are strong at the source — working in the prototype, clean in the architecture diagram, compelling in the strategy deck. But most ideas do not get judged at the source. They have to travel.

Through procurement, legacy systems, data quality issues, front-line adoption, unclear ownership, and competing priorities. Through the distance between the people who designed the idea and the people who have to operate it.

That is where delivery realism matters.

Delivery realism is the discipline of testing an idea against the real conditions it has to survive — not the ideal version of the organization, not the clean version of the process, not the version where every dependency lands on schedule and every user behaves as expected.

The real version.

Who operates this? Who supports it when something breaks? Who explains it when it behaves unexpectedly? Where does the complexity actually land? What depends on consistent human behaviour under pressure?

One of the most important questions is where organizational boundaries become system boundaries. Systems tend to mirror the organizations that build and run them. If a design assumes tight coordination between teams that rarely talk, that is not an implementation detail — it is probably where the solution starts to break.

Delivery realism is not cynicism. It is being honest about the road the idea has to travel before you commit to the route.

That honesty might mean changing the design, phasing the rollout, or acknowledging that the organization is not yet shaped to support the solution it wants.

And sometimes the lesson is simpler: do not deliver the Neapolitan pizza across town and expect it to arrive the way it left the oven.

A good idea is not enough. The real test is whether it survives the trip.