The expensive part of working in another team’s service was never writing the code. Writing fifty lines has never taken a week. What took the week was building enough of a model of the service that the fifty lines were safe.
That was the toll on the boundary. You paid it or you did not cross. I think we stopped collecting it, and nothing else changed.
You used to clone the repo, follow one request end to end, and take a small ticket, ideally a bug, because a bug makes you work backwards through code you did not write. Ask why a field is nullable and get a story about a migration nobody finished.
Now you point a model at the repository and get module structure, request lifecycle, dependencies and a defensible architecture summary. An afternoon.
I am not arguing for the old way. The toll cost real money in gatekeeping, knowledge hoarding and three-week waits. It also forced questions, surfaced unknowns and kept blast radius small. My worry is that we removed the delay and the questions together, and only meant to remove one.
What changed and what did not
Changed: the cost of comprehension, the speed of contributing, and how quickly confidence arrives, whether or not it is justified.
Did not change: review bandwidth, on-call, deployment rights, runbooks, and the person who remembers why that field is nullable.
Conway’s Law gets quoted as systems ending up shaped like the org chart. The mechanism underneath is that crossing a team boundary cost a week of comprehension, so people mostly did not. The inverse Conway manoeuvre, reshaping teams to get the architecture you want, leaned on that the entire time. Code can now appear anywhere. It can still only be operated in one place.
What the brief cannot tell you
A reservation service publishes a state change event. Three services consume it. Two deserialise permissively and persist whatever arrives. The third validates strictly and dead-letters anything it does not recognise.
That fact is not in the reservation service’s repository. It lives in three other codebases and in the memory of someone who moved teams. No brief drawn from that repo produces it, because the information is not there to find. A schema registry, registered consumers or contract tests would put it within reach. That is the actual fix, and it is a great deal more work than the change that exposed the need for it.
The brief is not wrong. The problem is that it feels complete. The slow route left you visibly ignorant, which is what made people ask.
What it costs
Someone on the fulfilment team needs a field on that event. The reservation team’s sprint is full, so they read the brief, write the change, raise the merge request. Twenty lines, tests pass, reviewer has four others open. It goes through.
That reviewer is not a bottleneck anyone planned for. I have watched review take forty to fifty percent of the week for particular tech leads and senior developers, because team velocity climbed and the queue never emptied. Nobody wrote that into a role description and nobody staffed for it.
Two consumers store the new field without complaint. The third dead-letters every message. Nightly job, so nothing happens for a day.
At 03:12 the on-call for the replenishment job is paged. Nothing they own has changed. They trace it to the reservation service, which is not theirs either, and from there to a merge request raised by a third team. By the time the author is awake and on the call, three teams are involved and none of them holds the whole picture. The person paged owns neither the service nor the change. The person who owns the service did not write the change. The person who wrote it has never seen this service fail.
The author opens the repository and it looks exactly like the brief said. That is the problem. The brief was right. It described a service that publishes an event and said nothing about who was listening.
They ask the model, get a reasonable answer, make the third consumer tolerant, and the page clears. The visible failure is gone. What nobody has looked at is the other two consumers, which have spent a day persisting a field no one validated. Someone finds that in a fortnight and files it as an unrelated bug.
Nobody there did anything indefensible. The estate had one control doing several jobs and it was withdrawn without replacement.
Where I could be wrong
I have no data showing cross-boundary contribution has actually risen, so this is a hypothesis with a test attached. Measure the share of merged changes whose author sits outside the owning team, defined by CODEOWNERS or the on-call rotation rather than the org chart.
Authorship alone will miss boundaries still enforced by permissions or policy, so pair it with review rounds, lead time and post-merge incidents for owner versus non-owner changes. If none of that moves, I am wrong about the mechanism and I would like to know.
DORA’s 2025 report is the nearest supporting evidence I trust, though it does not test this mechanism directly. It found higher AI adoption associated with increases in both delivery throughput and delivery instability, and time saved during creation being re-allocated to auditing and verification.
Four questions before merging across a boundary
Does someone accountable for each affected consumer know this is coming, and agree with what it does?
Does a test run it through a real consumer rather than a mock?
If this alters permissions, credentials, dependency scope or data access paths, has that been reviewed on its own terms?
If it needs reverting at 3am with the author unreachable, does the runbook cover it, and does the revert deal with what got written downstream?
Any no means it is not ready to merge on its own. Narrow it, pair with an owner, or go and find the missing evidence. Handing the whole thing over should be the last option rather than the first, or you have rebuilt the gate you were trying to route around.
We treated the cost of comprehension as waste. Some of it was. Some of it was signalling, coordination and control, and those need explicit replacements now that the cost has gone.
Which control did your organisation remove, and did you find out before or after the phone went off?
And if your team has written down what a service brief must contain before an outsider can safely change that service, I would like to read it.
Source: DORA, 2025 State of AI-assisted Software Development.
I write about architecture and AI engineering for companies that aren’t Google. The newletter lives at mayankkaul.com
Top comments (0)