Most specifications aim to be helpful. They describe what a system should do, how it might behave, and what constraints to consider. But in practice, they’re a snapshot - shaped by what was visible at the time, filtered through roles, assumptions, and shifting priorities.
They are rarely complete. They are often wrong. And if followed too literally, they can produce the exact thing that was asked for but actually fail to deliver meaningful value.
Good delivery teams don’t treat specs as gospel. They treat them as one of many inputs — useful, but partial. They keep their focus on the underlying goal: what this thing is supposed to enable, who it’s for, how it will be used, and under what conditions.
Getting there means working with ambiguity. It means spotting where reality diverges from the plan and where delays, defects, or confusion emerge — not because people aren’t following instructions, but because they are.
At Tomra, I supported a fantastic team creating software for a complex industrial sorting machine, the Tomra 5C. It’s a huge machine, built around conveyor belts, sensors, imaging systems, and edge compute. Testing against the real prototype required booking time, often days in advance. Entire teams had to plan around its availability whilst it was actively being built (and taken apart!) by other teams too.
So, people started to just trust the spec — not because it was ideal, but because it was the only thing they had consistent access to.
The result? Misalignment at the seams. Software was shaped by team boundaries. Integration problems were spotted late. The machine was correct in parts, but brittle as a whole. And still, everyone was doing what they’d been asked.
I started asking questions. Building four or five full machines wasn’t feasible — the 5C is expensive, complex, and physically massive. But what if we built just the core elements? On trolleys (literal food trolleys), with power and networking, and the ability to spin up real versions of the software stack?
If each trolley represented a different part of the system — a sensor here, a subsystem there — teams could test changes earlier. They could integrate against something real and with each other. They could verify assumptions long before they reached the main prototype.
That wasn’t in the spec. But it addressed the actual constraint.
We built one. Then three more. Now, those trolleys roll between teams. They host real builds. They help catch problems early. Time-to-delivery improved. Defect rates dropped. Not because the spec changed — but because we chose to focus on the outcome it was meant to serve.
By encouraging the business to foster a spirit of experimentation and communication (in part through helpful retrospectives), the team was able to add very significant value to the actual outcome.
And that's the mark of a great team. They don’t just deliver what’s written. They stay alert to where friction builds. They sense when plans are being followed, but not working. And they create space — even small, practical space — for feedback to flow sooner.
And it starts by having the mechanisms in place to actually notice. Asking the obvious question that no one’s had time to ask. And having just enough slack in the system to try something new.
Delivery isn’t about building what was imagined months ago. It’s about producing something reliable and valuable in the conditions that exist now. That takes more than compliance. It takes judgement, empathy, and the ability to focus on outcomes over instructions.
Thanks for reading.