The compression problem

Software is built from a description of a description

A customer explains their business once, in full, to whoever is in the first meeting. Everything built afterwards is built from an account of that conversation, and then from an account of the account. The requirement is a summary of a call. The ticket is a summary of the requirement. The code is written by someone reading the ticket.

Each step is a lossy re-encoding. Nobody decides to drop anything; what falls out is simply whatever didn't fit the frame of the person doing the retelling: the caveat that sounded minor, the exception that was hard to phrase, the reason behind the rule. The parts most likely to be lost are the parts that were hardest to say, which are usually the parts that mattered.

Effort is not outcome

Compression hides. A programme can look healthy the whole time it is drifting, because progress gets tracked against the artifacts of the relay rather than the thing the customer asked for. We inherited a regulatory integration that had sat “in progress” for over a year, tracked at roughly 95% complete. That number counted tasks touched. Audited against the regulator's own published spec, true completion was closer to 5%.

Nothing was being faked. Every task in that plan had been done by someone doing their job. The requirement itself had been lost somewhere between the parts, and no single handover was where it went. Rebuilt from the regulation, broken into independently verifiable checkpoints and marked done only when proven, the programme reached a 90% first-time submission and acceptance rate.

Shortening the chain, and keeping the record

There are only two honest responses to a lossy chain: pass the message through fewer hands, and stop relying on the message when the original is still available.

The first response is the engagement strategist: one techno-functional person who runs the discovery, decides with the customer what to build and how, and is then in the repo building it. Not a relay of account manager to project manager to analyst to engineer. One person who was in the room and is in the code.

What that looks like in practice

The second response is mechanical, and it is the part that is easy to promise and rare to actually do. Concretely, in our own delivery:

• Customer calls are transcribed, and the transcript is attached to the task it produced. The agents working that task read the call itself, inside the Damco harness, powered by Alan AI. Not somebody's paraphrase of it, and not a ticket summarising it.
• We cross-reference across the record, not within one document. What was said on the call, what the Blueprint committed to, what the requirement says and what the code does are checked against each other, so a drift between them surfaces as a contradiction rather than a surprise at UAT.

Both depend on the same discipline: keep the original, and keep it reachable. That is also why the Software Review produces a written Blueprint, and why what we learn operating a system goes back to the same record rather than into somebody's memory of the project.

Why one person can hold both now

A role that runs discovery, agrees what to build and how, and then builds it used to be a staffing fantasy: there was too much volume for one head, so the work was split across specialists, and the splitting is what created the handovers. What changed is leverage. Agents carry build volume; the strategist carries judgment and the customer's context. The generalist became viable because the specialist work that used to be delegated to a chain of people is now delegated to agents the same person directs, and a Damco engineer still signs off what ships.

This is not a claim that fewer people means less rigour. One programme stood up a per-transaction commercial model, covering third-party administration, payment gateway and regulatory integration, in three to four weeks, by sequencing the critical path and reusing regulatory work already built elsewhere. An insurer's bilingual first-notice-of-loss intake now runs as a voice agent audited by two independent pipelines against the call transcript, at 96% field-level accuracy. Both were held by one strategist who had been in the discovery calls.

What this changes for you

Fewer hands between your words and the build is not a staffing detail. It is why the software resembles what you actually said, why the person across the table in week one is still accountable in week twelve, and why the reason behind a decision is still retrievable in year three.

Meet the engagement strategists →