Damco

Software loses meaning each time someone retells it We call it the compression problem, and two things have helped

What we've seenWe took over a regulatory program whose plan said 95% done. Checked against the regulator's spec, it was 5%.

What we think it meansNobody dropped the requirement. It got lost a little at every handover.

What we're testingOne person from the first call to the code, with every call transcript attached to its task.

A tall stack of documents with one sheet bending out, etched in bronze squares

You explain your business once, in full, to whoever is in the first meeting. Everything built after that comes from someone's notes on that meeting, and then from notes on the notes.

The requirement is a summary of a call. The ticket is a summary of the requirement. The code gets written by someone reading the ticket.

Each step loses a bit, and nobody decides to drop anything. What falls out is whatever didn't fit in the head of the person retelling it: the caveat that sounded minor, the exception that was hard to phrase, the reason behind the rule. In our experience, those are the parts that mattered.

The plan said 95% done, and the spec said 5%

A program can look healthy the whole time it drifts, because progress gets tracked against the relay, not against what you asked for.

We took over a regulatory integration that had sat “in progress” for more than a year. The plan had it at about 95% complete, counting tasks touched. Checked against the regulator's published spec, it was closer to 5%.

The plan said 95% done, but only 5% met the specShare of a regulatory integration complete, by how it was measured
Tasks marked done in the plan95%
Requirements met, checked against the regulator's spec5%

Source: Damco program records, a regulatory integration we took over

Nobody faked anything. Every task in that plan had been done by someone doing their job. The requirement got lost between the tasks, not in any one of them.

We rebuilt it from the regulation and split it into checkpoints we could each verify. A checkpoint counted as done only when it passed. The program got to 90% first-time submission and acceptance.

Fewer handovers and one shared record have helped most

The first is the engagement strategist. That's one person who knows the business and the technology, runs the discovery calls, agrees with you what to build, and then builds it in the repository.

So there's no relay from account manager to project manager to analyst to engineer. The person who was in the room is the person in the code.

The second is mechanical, and it takes discipline to keep up. On our own projects, it means two things.

  • We transcribe customer calls and attach each transcript to the task it produced. The agents on that task read the call itself, in our delivery platform, powered by Alan AI, not someone's summary of it.
  • We check the record against itself. We compare what was said on the call, what the Blueprint committed to, what the requirement says, and what the code does. A drift then shows up as a contradiction, not as a surprise in acceptance testing.

Both depend on keeping the original where everyone can reach it. That's why the Software Review produces a written Blueprint. It's also why what we learn running a system goes back into the same record.

Agents carry the volume, so one person can hold both

Until recently, one person couldn't run discovery, agree the scope and write the code. There was too much work for one head, so it got split across specialists, and the split created the handovers.

What changed is that agents now do most of the build volume. The strategist keeps the judgment and your context and directs the agents. A Damco engineer still signs off what ships.

Fewer people hasn't meant less rigor on our projects. One program stood up a per-transaction commercial model, with third-party administration, a payment gateway, and a regulatory integration, in 3 to 4 weeks. We got there by sequencing the critical path and reusing regulatory work we'd already built.

An insurer's bilingual claims intake now runs as a voice agent at 96% field-level accuracy, checked by two independent pipelines against the call transcript. In both cases, one strategist who was in the discovery calls held the work.

Where this breaks

One person is also one point of failure. When a strategist is out, the record has to carry the context, and we're still learning how much a newcomer can pick up from transcripts alone. And some clients don't want calls recorded, which puts us back on written notes, with the same loss this post is about.

What we've seen change for clients

With fewer hands between your words and the build, the software is closer to what you actually said. The person across the table in the first week is still accountable in week 12. And the reason behind a decision is still on record in year three.

Meet the engagement strategists

Tell us what you're seeing on your own programs

A strategist reads every reply and writes back.