A build does not lose trust on a particular Tuesday. It loses it the way a tyre loses air, over a distance long enough that nobody can point at the puncture. By the time either side says the word out loud, the argument has already moved from the work to the people doing it.
A European banking group's IT services subsidiary outsourced a customer-facing application for its advisory business to an offshore development supplier. Across a build of about ten months the engagement lost its quality, then its schedule, then the willingness of either party to believe the other's numbers. It ended with the statement of work terminated and the work taken back. I led the technical workstream of the independent review that followed.
That review produced a long list of remedies, most of them the kind a reader nods at: agree coding standards upfront, automate quality checks, run peer reviews, align governance. One was different, because it costs real money in a visible line and saves it in an invisible one. Take the key people from both sides, architects above all, and put them in the same place for blocks of six to twelve weeks.
The challenge
The review recorded the decay in the plainest available language. As the problems with code quality and data handling accumulated, and as the backlog grew sprint after sprint, trust diminished and collaboration decreased. There were questions about transparency. The client suspected inexperienced developers had been placed on the work. There were doubts about delivery management on the supplier side. And suggestions were being rejected from both directions.
That last clause is the diagnostic one. Rejection had become symmetrical and reflexive. When both parties are refusing each other's proposals as a default posture, the content of any individual proposal has stopped mattering.
Two artefacts show how far apart the two organisations had drifted while apparently working from the same documents.
The first is estimation. The client used a defined method to size the work at 1,000 person-days. The supplier's figure was above 2,500. The review did not adjudicate between them, and it was right not to. A factor of two and a half on the same written scope is not a disagreement about productivity. It is evidence that no shared estimation method existed, so each side priced a different mental picture of the same specification and neither could show its working in a form the other could check.
The second is status. There were no jointly defined pass and fail criteria for testing, and no shared definition of what a red or amber project status meant. Both parties reported weekly, both reported in good faith, and the reports were not comparable.
Underneath both sat a technical picture with one telling property. The review found design principle violations across the codebase, poor test coverage, security exposures, and no documented systems design artefact, though that document was a contracted deliverable. Without it, the client's own architects could not follow the development logic in the software. And most of the quality issues were spotted only when a client architect went into the code to help a supplier developer solve something unrelated, a performance problem or a broken function.
That is not a finding about code. The only reliable quality signal in a ten-month engagement was a senior technical person from one organisation physically reading the other organisation's work, and it fired by accident, as a by-product of helping.
The approach
So the recommendation follows from the evidence rather than from a preference about ways of working. Install staff, where possible, onsite or offsite together, for prolonged periods of six to twelve weeks. Key staff, and the review named architects in particular. The direction does not matter. Either the client's people go to the supplier or the supplier's go to the client.
The review claimed four returns on that, and they are worth separating because only one of them is the usual argument.
The first is speed: misunderstandings and open issues resolve faster when the people who own them are in the same building. The second is understanding: each side sees what the other is actually working against, which no status report conveys. The third is cost, and it runs opposite to intuition. Sustained co-location reduces the total onsite presence an engagement needs over its life, because the trip you do not have to take is the one whose purpose was already served.
The fourth is the one to read twice. Enough transparency accumulates that both parties can make a timely and informed decision to proceed or to disembark, with confidence and in good faith.
That reframes co-location entirely. It is not a morale measure. It is a decision instrument. Stopping a large build cleanly requires an argument, an argument requires facts both sides accept, and a project neither party can see into does not produce those facts. This engagement did stop, but only once the statement of work was terminated, and the account of why had to be assembled afterwards by an outside party rather than agreed between the two sides while there was still a decision to make.
The structural recommendations around it only work once that condition holds. Architectural ownership carried by the supplier's senior architect across the whole duration rather than during transition alone, tracked with joint metrics. Senior supplier leadership sitting in the steering group. Roles defined jointly at execution level, with a weekly joint management meeting. A standing point in the calendar to read contractual obligations against the statement of work, instead of only when something is already in dispute. A review of at least ten percent of the code against agreed standards, with non-conformance extrapolated and tracked, plus automated checking against a quality model both sides had signed up to.
Every one of those is a shared instrument. A joint metric between two teams who have stopped trusting each other does not measure delivery. It becomes another surface to negotiate.
The same dependency shows up in the work we do now, in a different costume. Machine learning pipelines fail at the same joint. Data readiness is not a property of a dataset, it is knowledge held by the person who knows what a field actually records and which of its values are typed in by hand at a branch. Feature stores and lineage tooling capture that knowledge only after somebody has stated it out loud. Model deployment, as distinct from model building, is where an engineering team and a domain team have to hold one picture of a process, and it is where distributed delivery quietly starts producing two. The Platform work we do puts that dependency in the plan explicitly, with named people in shared time.
The outcome
Nothing described above was performed. The statement of work had already ended before the review began, so no co-location block was run and no architect was seconded. What the engagement produced was a findings report and a phased set of recommendations aimed at the next engagement, sequenced into bands measured in weeks and months. The person-day figures are estimates the two sides brought with them, not measured effort. This is a prescription with a failed project behind it, which is the only kind worth writing down.
What has changed since is not the prescription but its standing. Remote-first delivery has not repealed it. Distributed work made the arrangement easier to skip, cheaper to skip inside the current quarter, and more expensive to have skipped by the time anyone notices. The failure mode is unchanged: two organisations building a shared picture separately, each version internally consistent, and no forcing function that puts them side by side.
Process mining over the workflow and issue data would have measured the decay here without anyone being asked how they felt. Sprint carryover, rework rates, the delay between a defect being raised and being understood, the share of quality findings originating from one side. All of it sat in the tracker throughout. Measurement would have made the decline visible earlier, and it would not have repaired anything, because a trust problem is not fixed by a better chart of the trust problem.
The finding that survives is small, physical and unfashionable. When a build depends on two organisations holding one design in their heads, put the heads that hold it in one room, for weeks rather than days, and treat the travel budget as the cost of being able to stop.