Why we started syncing with the agency team

We are good at async. Our managers know how to run a project in tickets. The agency’s project managers are experienced enough to keep a build moving through comments and annotations alone. For most of a year, that was how the partnership ran.

Then the reviews started getting longer.

Not wrong, exactly. Not the kind of review that says “start over.” The kind that says “this is technically fine, but it is not what we meant.” The kind where the comment thread on a single design element runs to fourteen exchanges. The kind where a developer fixes the thing the comment asked for, and the next comment is “yes, but now the other thing is off.” Two or three of those in a row and a review cycle that should close in a week is still open at week three.

The word the agency started using was “interpretation.” As in: “We think there’s an interpretation issue.” As in: “The brief said X, and what you built does satisfy X, but the spirit of what we meant was different.” The word was diplomatic. What it meant was: we are spending a lot of time teaching each other what we meant, after the fact.

The thing about “after the fact” is that it is the most expensive possible moment to establish shared understanding.

What async cannot carry

Async communication is excellent at transmitting decisions. It is poor at transmitting intent. A ticket can say “hero section: full-width image, H1 overlaid left-aligned, CTA button below.” A developer can build exactly that, and the agency can review it and find that the result feels wrong — not because the spec was violated, but because the spec was silent about things that mattered. The image contrast. The way the H1 sits against the image on mobile. The fact that “below” meant below the H1, not below the image.

None of these things are in the ticket. They are in someone’s head. In a colocated team, they move from head to head continuously — in corridor conversations, in shoulder-taps, in the thirty seconds before a standup when someone says “I’m looking at that hero, does it feel heavy to you?” That information does not travel over ticket systems. It accumulates in a backlog of unstated expectations.

Our developers and the agency’s developers were not talking to each other at all. They were communicating exclusively through a layer of management — through project managers and account managers who translated on both sides. Those managers are good at their jobs. They translated accurately. But there is information that a developer can only articulate to another developer, because it is technical in a way that project management vocabulary does not have words for.

“The brief said Gravity Forms, and I used Gravity Forms, but the layout they’re expecting is based on the Elementor native form because that’s what the previous three sites used — and none of the tickets mentioned that.” That is the kind of thing a developer says, not a ticket.

We did not know this was happening until it had been happening for months. The signal was the review length.

The fix: developer-to-developer calls

We proposed a standing call. Not a status meeting — there was already a status meeting. A working call between our developers and the agency’s developers, plus whoever from the agency’s review team had been doing most of the commenting on recent projects.

Thirty minutes. Fortnightly. No prepared agenda. The only standing item: “tell us what is currently frustrating you about how these builds come through.”

The first call was uncomfortable. Both sides were used to the buffering layer of management. Talking directly felt like bypassing something, and neither side was sure what the protocols were. We got through it. The second call was easier. The third was where things started to shift.

A few things emerged in those early calls that no ticket had ever surfaced.

The agency’s team wanted process documentation included in the staging handoff. Not code comments — documentation about which components were custom-built, where the content slots were, what to expect when the client starts editing. We had never produced this because nobody had asked for it. Nobody had asked because nobody had been in a room to ask. Once they asked, we produced it, and the agency’s QA time on the next three projects dropped noticeably.

Our team wanted briefs to specify which existing sites to treat as reference for visual style. The briefs were abstract — they described the desired outcome but not the comparable. “Professional, clean, trustworthy.” That describes half the portfolio. When our developers are unclear on the visual register, they default to whatever they built last. That is why five consecutive sites had the same hero layout. Once the agency started attaching one or two reference screenshots from their preferred benchmarks, the visual register of handoffs improved sharply.

Both of these were solvable problems that had been running unsolved for months, because there had been no channel that carried them.

What the calls changed

The most immediate change was in the review cycle length. The review conversations that had been running fourteen exchanges on a single element started closing in two or three. Not because the builds were dramatically different. Because both sides now had enough shared context to understand what the other meant quickly, even in text.

The agency’s reviewers began to distinguish between things that needed a fix and things that were judgement calls they could make themselves. Before the calls, everything that felt off generated a comment. After the calls, reviewers had enough understanding of how our team made decisions to know when a deviation was intentional. They started making decisions instead of escalating them.

Our developers started building differently. Not according to different rules — the conventions document had those — but with a different mental model of what the agency’s reviewers were going to look for. They were optimising for an audience they had now met. That changes how you build.

The trust dimension was harder to quantify but obvious in the texture of the working relationship. There is a difference between working with a team you have exchanged messages with and working with a team whose voices you know. The agency’s team started mentioning us by developer name when they had a question on a project. That does not happen in a purely async relationship.

One specific thing we did not expect: some of the information that had been getting lost in translation was not being lost through bad management — it was being unconsciously filtered. Project managers, on both sides, had been processing information before forwarding it, removing what seemed like noise. Some of that “noise” was meaningful signal. The calls bypassed the filters, and some of it surfaced in ways that changed how both sides were working.

The lesson this suggests

This is not an argument against async work. We still run projects primarily through tickets and workbook threads. Async has real advantages — it is searchable, it has a record, it scales across time zones. We are not proposing to replace it.

The argument is narrower: async cannot carry everything. Specifically, it struggles with the informal layer of a professional relationship — the unexplained context, the unstated expectations, the feel of what was meant rather than what was specified. That layer is not noise. It is a significant part of what makes a collaboration work.

If you are a marketing agency running WordPress builds through a subcontractor, and the review cycles are lengthening, and the comments are increasingly about “interpretation” rather than errors — the problem is probably not that the developers are bad at their jobs. The problem is probably that neither team knows what the other team considers obvious.

The cheapest diagnostic is a thirty-minute call. Put one or two of your reviewers in the room with one or two of the contractor’s developers. Give it three sessions before judging whether it helps.

A few things to notice: Is the contractor’s team describing problems that you didn’t know existed? Are they describing constraints that your briefs have been ignoring? Is your team realising that what you said in the brief was not what you meant?

If yes to any of those, you have found the information gap that has been costing you in review cycles. The call did not solve the problem. It revealed where the problem lives. That is usually enough — once both sides know where the gap is, filling it is mostly mechanical.

The fully async subcontractor relationship works, up to a point. The point where it stops working is when the two teams have accumulated enough unstated context that every new project is an opportunity for new misinterpretation. The gap does not announce itself. It appears as review friction, as “interpretation issues,” as builds that are technically correct and feel wrong.

We ran that dynamic for long enough that the review comments started to feel inevitable. They were not inevitable. They were the cost of two teams that had never spoken, trying to communicate in writing about things that did not have agreed-upon written vocabulary.

Thirty minutes, fortnightly, between the people doing the work — not reporting on the work — was a relatively small investment. The return was reviews that ran faster, handoffs that came in cleaner, and a working relationship that had enough shared context to absorb the occasional genuine mistake without a defensive response from either side.

We should have started them sooner. The reason we did not is that it felt like it should not be necessary. Good documentation, good process, good management — these should be enough. Sometimes they are. When they are not, the tell is in the length of the review comments.