Boards Don't Buy Speed. They Buy Fewer Surprises.

Almost every pitch for AI in software delivery opens the same way: it will make you faster. Ship in days, not quarters. Ten times the output. It's an easy promise to make because it's an easy thing to demo — you put a prompt in, working software comes out, and the speed is undeniable in the room.

Then take that promise up a few floors, into the room where the budget actually lives, and watch it land flat. Because the people in that room are not, in fact, optimising for speed. They're optimising for something speed doesn't deliver and often undermines.

Listen to what a board actually asks

Sit in on a board or executive review and pay attention to the questions. Almost none of them are about velocity. Nobody leans forward to ask why the last release wasn't faster. The questions that carry weight are different in kind: Why did this cost what it cost? Why are we only hearing about this problem now? Who signed off on the thing that went wrong? How exposed are we? What else don't we know yet?

Every one of those is a question about surprises — unexpected costs, unflagged risks, decisions nobody can trace, discoveries that arrive too late to do anything about. A board's core function is stewardship under uncertainty, and the thing that makes stewardship fail is the nasty surprise: the overrun nobody saw coming, the compliance gap discovered in an audit, the feature that shipped and created a liability nobody had approved. Boards are, structurally, machines for reducing the number and severity of surprises. Speed is not on their list of wants. Predictability is the whole list.

Faster ungoverned delivery is a surprise factory

Here's the uncomfortable connection that the speed pitch never makes. Ungoverned AI delivery, run fast, doesn't just fail to reduce surprises — it actively manufactures them. When construction was slow, the slowness produced a kind of involuntary early warning. Problems surfaced gradually, with time to react, because everything took long enough that someone usually noticed. Remove the slowness and you remove the warning. The wrong build now completes before anyone reviews the assumption behind it. The cost is incurred before anyone questions it. The thing legal would have objected to is live before legal sees it.

So the organisation goes faster and, at the same time, discovers more of its problems after the fact rather than before. From the board's seat, that is precisely the wrong trade: you have bought velocity with the currency of predictability. More speed, more surprises. It is hard to imagine a worse deal for the people whose job is to not be surprised.

What boards are really buying when they buy governance

This is why we think the entire AI-delivery conversation is pitched at the wrong altitude. At the engineering level, speed is a genuine and exciting benefit. At the board level, the benefit that matters is the opposite quality: the confidence that what's being built was agreed, that the cost was authorised, that someone is accountable, and that you will hear about a problem while you can still act on it rather than in the post-mortem.

That confidence doesn't come from a faster model. It comes from governance — from a delivery that is held against a clear, signed agreement, where divergence surfaces at the moment it happens instead of at the quarterly review. Governance is what converts software delivery from a source of surprises into a source of evidence. It's the difference between a board being told "trust us, it's fine" and a board being able to see what was agreed, what was built, and that the two still match.

This is the quiet thing Propel is really selling, underneath the language of agreements and specifications and traceability: fewer surprises. A delivery where the expensive discoveries happen early and cheaply, at the point of agreement, rather than late and expensively, after the build. Where the answer to "who signed off on this?" is a record, not an argument.

Sell speed to the engineer. Sell certainty to the board.

Speed will always have its place in the pitch, and it should — it's real, and engineers feel it daily. But if you are trying to convince the people who actually authorise the budget, leading with speed is answering a question they didn't ask. They didn't want faster software. They wanted to stop being surprised by their own software. Those are not the same goal, and at AI speed, pursuing the first without governing for the second gives the board more of exactly the thing it was trying to avoid.

The board doesn't want faster software. It wants fewer surprises. Build for that, and the speed becomes a bonus instead of a liability.

The four questions a board actually asks

• “What did we commit to build?” Answered by a signed agreement, not a ticket backlog.
• “Does what we shipped still match it?” Answered by checking the build against the spec, continuously.
• “Who approved the change?” Answered by a version history with names on it.
• “Can we prove it?” Answered by evidence produced as a by-product of delivery. Note that no faster coding tool — Cursor, Copilot, Claude Code — answers any of the four.