# Async communication with an outside development team, from sixteen years of tickets

> How an agency and its outside development team kept thousands of jobs moving for sixteen years in writing, with fewer than five meetings a year.

Source: https://lastdoorsolutions.com/blog/async-communication-with-a-development-team

**Async communication means the work moves in writing, and nobody has to be online at the same time for it to move.** With an outside development team, it decides whether you spend your week in status calls or reading progress when it suits you.

From 2018 to 2025, every job Anchor Wave sent us went through one shared board. **That board holds 1,687 tickets and more than 66,000 comments.** In our earlier case study of the partnership, approved by Anchor Wave, the two teams met fewer than five times a year. The work ran on a ticket format both sides trusted.

## What async communication is

- **Asynchronous communication is written and waits for the reader.** A ticket, a comment, a recorded walk-through. Each team member answers when they are ready.
- **Synchronous communication is real-time.** A meeting, a call, or a chat on Slack or Microsoft Teams that expects an immediate response.
- **Async suits a remote team across time zones.** Nobody waits for a shared hour, and the deep work between messages stays unbroken.
- **It needs a format.** Without one, messages scatter across email, chat and calls, and nobody can say where a job stands.

## When to write, and when to talk

| | Write it | Talk it through |
| --- | --- | --- |
| **Use for** | Briefs, questions, drafts, reviews, status, rules | A new working relationship, a disagreement, a trade-off with no clear answer |
| **Leaves** | A record anyone can read later | A decision someone must then write down |
| **Costs** | Time to write clearly | Everyone's time at once |

**Our default is to write.** A call is for what writing cannot settle, and its outcome goes back into the ticket.

## Sixteen years, three formats

Anchor Wave is a web design and marketing agency in Tucson, Arizona, founded in 2003. From December 2009 to April 2026 we were its development team. **Anchor Wave owned strategy, its client relationships and most of the design. We built and looked after the websites.** The [Anchor Wave story](/partners/anchorwave) covers the work itself.

The tickets lived in a different place in each period, and each move kept what had worked.

![Three periods. 2010 to 2015, tickets in the agency's own system: 4,524 task assignments to us. 2015 to 2018, a project for each job: 414 projects. 2018 to 2025, one shared board: 1,687 tickets and more than 66,000 comments. Below: fewer than five meetings a year between the two teams.](/images/blog/async-three-formats.png)

*The Anchor Wave work in each of its three formats.*

- **2010 to 2015.** Jobs came as tickets in Anchor Wave's own system, from page build-outs and design mockups to fixes and responsive conversions.
- **2015 to 2018.** Each job had its own project with us.
- **2018 to 2025.** One shared board for everything. Comments peaked in 2020, at more than 28,000 in the year.

**What stayed the same was the unit:** one job, one ticket, one place where everything said about it was written down.

## A ticket carried the conversation

A meeting decides something, and then someone has to write it down. **A ticket starts written down.** On the shared board, the brief, the questions, each draft and each revision sat in one thread. Page builds went through numbered drafts, some as far as an eighth. A developer who picked up a job a year later could read how it got there.

**That is why the comment count matters more than the ticket count.** More than 66,000 comments on 1,687 tickets shows where the discussion happened: in the ticket, where both teams could see it.

## A status for every ticket

The board's lists said where each job stood: the task list, new builds, quality checks, and jobs waiting for a client's response. **The state of every job was on the board,** for both teams to read without asking.

The list for jobs waiting on a client's response kept two kinds of delay apart. A job stalled on an answer from the agency's client sat in its own list, separate from work waiting on us.

## Rules written down, once

From 2020 to 2021, the two teams set down their shared rules as messages both could point to. They covered how time was entered, how tasks synced between the two teams' systems, who held access to what, and how quality was checked before a job went back. **Each rule was settled once, in writing.**

## Five checks for async work with an outside team

1. **One place per job.** Does every job have exactly one place where its brief, questions and decisions live?
2. **Status without asking.** Can anyone see the state of every job without a message or a call?
3. **Whose turn it is.** Is "waiting on us" kept apart from "waiting on them"?
4. **Rules in writing.** Are the shared rules on time, access and quality written down where both sides can find them?
5. **A year-old job.** Could someone new pick it up from its thread alone?

A team that answers yes to all five rarely needs more than a few meetings a year. The same habit runs our [WordPress support](/services/wordpress-support) for teams with many sites.

Async communication is often sold as fewer meetings. Over sixteen years, its real return was a written history of every job that anyone could pick up.