Circles, not lines

Most software is delivered as a line. Requirements at one end, a release at the other, and a sequence of engineering steps in between that converts one into the other. The line is not wrong. It is just the smaller half of the job, and the industry keeps treating it as the whole of it.

The line answers one question: does the thing work? Given the specification, does the software do what it says? That question has a definite answer, it can be tested, and a competent team can reach it reliably. It is also, on its own, close to worthless as a measure of whether the business got what it needed.

A line and a circle

Continuous improvement is not a phase you add at the end, and it is not a recurring meeting in a calendar. It is a second shape laid over the first: a circle that runs while the service runs. Something observes the live system, compares what it sees against what the business actually wants, works out where the gap is, and changes the design. Then it does it again.

Engineers recognise this immediately when it is drawn as a control loop, because it is one. A thermostat is not a better heater; it is a heater that has been told what the room is for. The heater is the line, the thermostat is the circle. A great deal of the software I am asked to review has been built as a heater, and the room is either freezing or boiling, and nobody can say which, because nothing in the system was ever asked to notice.

The aircraft that flies is not the aircraft that wins

Take the functional specification for an airliner. It must carry passengers, take off, cruise, navigate, and land safely and repeatably. Engineer against that specification and you can succeed completely: a certified aircraft, a working airline, a set of functions delivered exactly as described. Nothing on the requirements list is outstanding.

Now measure it. Not against the specification, but against the things the business is actually judged on: cost per seat flown, how much of the day each aircraft spends earning rather than parked, and whether passengers come back. Those are different questions, and they lead to a different aircraft.

This is roughly what the low-cost carriers did to European aviation. Once turnaround time became a number somebody owned, it stopped being an operational detail and started rewriting the design. Time on the ground was time not earning, so the ground stop was attacked from every side at once: point-to-point routes instead of hub connections, a single aircraft type so that crews, engineers and spares were interchangeable, boarding and cleaning procedures rebuilt around the clock, secondary airports with less congestion, and cabin choices that made the aircraft faster to turn round. The hour or more the industry had accepted came down toward half of that, and the economics of short-haul flying changed with it.

Not one of those decisions is discoverable from the functional specification. Every one of them falls out of measuring the right thing and being willing to let the measurement move the design. EasyJet and its peers did not build a better implementation of the incumbent model; they let a KPI redraw the model.

What a control loop actually needs

A loop is not a dashboard. Dashboards are the part everyone builds, because they are the part you can demonstrate. A loop needs five things, and it fails if any one of them is missing.

Part	What it means	How it usually fails
A measure that means something	A number that moves when the business outcome moves, and is hard to move any other way.	Proxies chosen because they were easy to collect: tickets closed, uptime, story points.
A target, and a tolerance	The value you are steering toward, and the band inside which you leave it alone.	No target at all, so every movement is either invisible or an emergency.
A sensing path	The measure arrives from the live service, fast enough to act on, without anybody being asked to compile it by hand.	A monthly export somebody assembles in a spreadsheet, three weeks after the fact.
An actuator	Someone with the authority and the capacity to change the system, including its design.	Insight with no route into the backlog. The report is read, admired, and filed.
A cadence	The loop runs on a rhythm the business can absorb, and faster than the thing it is steering.	An annual review of a service that changes weekly.

Miss the actuator and you have built an observability project. Miss the measure and you have built a reporting project. Both are common, both are expensive, and neither one is a loop.

KPIs that change the design, and KPIs that decorate one

There is a simple test for whether a KPI is real. Ask what the system would have to look like if that number had to halve. If the honest answer is "much the same, but we would try harder", the KPI is decoration. If the answer involves a different architecture, a different operating model, or a conversation nobody wants to have, then it is a real one.

Cost to serve, first-contact resolution, elapsed time from a customer intent to a completed outcome, the proportion of journeys that never need a human: these tend to be real, because they cut across the functional boundaries the software was organised around. That is exactly why they are uncomfortable, and exactly why they are worth having. A measure that respects your team structure is measuring your team structure.

Customer satisfaction belongs in the same category, with one caveat. Used as a score to report, it tells you very little. Used as a signal to mine, with the reasons attached and traced back to the journey that produced them, it is one of the most direct routes I know from a live service to a design change worth making.

Instrument at build time, not after the incident

The practical consequence is that the loop has to be designed alongside the feature, not bolted on when somebody finally asks how it is doing. A service that was never built to emit the signal it will be judged by cannot be retrofitted cheaply; the events were not recorded, outcomes were never joined to the intents that produced them, and the data you need turns out to be the data nobody persisted.

So the question "how will we know if this worked?" belongs in the requirement, next to the acceptance criteria, and shipping without it should be as unacceptable as shipping without tests. In practice that means every meaningful unit of work carries three things rather than one: what it should do, how we will know that it did, and what we will change if it did not.

Why this is the argument behind the rest of the work

This is not an abstraction I happen to like; it is the through-line of what I build. Codamor exists because coding pipelines stop at the release and a service does not, so the loop is wired into the pipeline itself and keeps running over the live system. Aurum is built so that a suggestion the client ignored is a signal rather than a dead card, because a proactive product with no feedback path is only a faster way to be wrong. The service transformation work for a US operator began with 5,560 real calls precisely because the functional description of that service and the measured behaviour of it had become two different systems.

You can get it to fly and land. That is the entry fee. Whether it becomes an airline depends on what you chose to measure, and on whether you meant it.