Thought piece

The capacity to surge

Neil Middleton · 15 October 2026

At one operation, too much of the travel spend was flowing around the claim-number gate. The booking tool saw what staff booked for themselves. The rest, bookings made by phone and email through the travel management company and charters arranged by an operations desk, reached finance as invoices with nothing in front of them. Where money moves, some of it is gamed; that is why delegation of financial authority exists, and why a gate that much of the spend never passes through is not a control. The rest is simply how an operation moves people when the tool cannot book what it flies.

The request, when it came, was for an offline enhancement: bring those bookings into the system. The requirement was partially understood with significant process and human complexity. The signal was real.

I have come to expect both. Requirements written by people running an operation are partial for a good reason: the people writing them are running the operation. They describe the last thing that went wrong, in the words of the tool they have, and they leave out what is obvious to them. The signal underneath is what they are trying to protect, and it is usually right. The job is to read the signal through the request.

What we did was push through a workflow automation that pulled that spend inside the claim-number gate. It came with imperfections we chose to accept. The travel management company's agents had to log into a portal for one client: necessary, and not the goal, since a TMC's back office exists to avoid exactly that. Some nice ideas went in that should have been deferred. We did what we were told where it was prudent to do so, and when it turned out to be different, or a partial, we did it again. In one sense that is an unpleasant way to work. In another it is the only way the important goal gets across the line, because the alternative is a specification phase the operation cannot afford while it is moving people every day.

The important goal was the second gate. No traveller moves without a booking number, and no provider is paid without an approved claim number, for the whole of the spend and not the part the tool could see. Once that held, the record was complete, and the changes since have been changes to rules on a record that exists.

In the worst weeks of that work, forty production changes shipped per week. I do not offer that as a sign of success. It was the capacity to do what needed to be done to get where we needed to go, without surrendering to pressure. Forty changes over a week is not a long-term sign of product management success. The capacity to surge people and platform to avoid failure is.

The long-term sign is the ordinary week. Continuous improvement in a live operation is not a programme. It is the rules changing a little at a time on a record that already exists, each change verified against real event history and shipped when it is ready, so a requirement that arrives as a line item does not wait for a release. The surge is the same practice at the pace a crisis sets. An architecture that can only ship in quarters can do neither, so it asks the operation to wait, and operations do not wait. They route around the system, and the spend goes back around the gate.

The interim stage should not survive, and it is not meant to. The portal for the TMC's agents is the thing I now ask TMCs to replace: a content source feeding their own mid and back office, so our travel arrives as a feed instead of a login. The nice ideas will swim, or sink and be quietly retired. What survives is the model, and the model is what the interim stage taught us: one record, two gates, rules as configuration, and the capacity to change the rules faster than the operation changes its mind.

The model is not finished either. It grows as our understanding grows and as the business environment changes. The gates are in it because of work like this rather than a design on day one. That is not serendipity; it is what an engineering culture built on continuous improvement produces, and the choice to work that way was made deliberately and paid for, in favour of purity of purpose. The next operation will add something we have not seen. That is continuous improvement at the second level: the rules change every week; the model changes when the world does.

That is also where the review comes from. The request is rarely the need. A specification written by a busy operation is a request. The record is where the need shows, and the people who run the operation are where the reason shows. We read both before we write anything, and we are still prepared to do it again when the first answer turns out to be a partial. Being able to thrive in that environment was the evolution necessary to get to the model. The model is the result. The surge was the cost of getting there.

Also: The second shift and UnityTrip and SAP: a single source of truth. The review page sets out how the record is read before anything is treated; the operations page, how change ships.