THE ASYNC COMMUNICATION BLUEPRINT: TEAM PROTOCOLS THAT KILL INTERRUPTIONS

Every team claims to be async. Most are just asynchronous SLA violations punctuated by meetings.

Async is not "we use Slack instead of meetings." Async is a documented protocol for every communication channel your team uses. It defines what goes where, when it gets answered, and how to escalate when something actually burns. Without those rules, async is just an excuse for ignoring messages until someone calls you.

I run four engineering teams on async protocols. Zero Slack notifications. Zero daily standups. And my response time on urgent issues is faster than it was when I had notifications on — because the signal-to-noise ratio inverted. Every ping is a legitimate escalation. Not a brain cell tax.

The three zones of communication

Every message belongs to one of three zones. The zone determines the tool, the expected response time, and the behavior.

Zone 1: Asynchronous (response within 4-24 hours)

This is where nearly all communication lives. 95% of messages belong here.

| Tool | What goes here | Expected response | |---|---|---| | Linear / Jira | Tickets, task questions, code review requests | 4 hours during working hours | | Email | External communication, non-urgent internal | End of business day | | Pull requests | Code reviews, technical decisions | 4 hours during maker time | | Shared docs | Proposals, design documents, strategy memos | 24 hours for final feedback |

Behavioural rule: If you send a Zone 1 message, you do not follow up within the SLA window. You do not ping. You do not "just checking in." The SLA is the promise. Trust it.

Zone 2: Synchronous-but-scheduled (response within the meeting)

This is the replacement for Slack-driven sync. Everything scheduled, everything with an agenda, everything in its time slot.

| Tool | What goes here | Expected response | |---|---|---| | Calendar | Decision meetings per meeting consolidation | 30 minutes, hard stop | | Scheduled call | Complex discussions that writing can't resolve | Agenda sent 24h before | | Pair programming | Designated co-working sessions | Scheduled, not spontaneous |

Behavioural rule: If it doesn't have a calendar slot with an agenda, it doesn't go here.

Zone 3: Synchronous-emergency (response within minutes)

This zone exists so the other two can be strict. If everything can be an emergency, nothing is. The protocol defines what qualifies.

| Tool | What goes here | Expected response | |---|---|---| | Phone call | Production down, customer escalation, security issue | Immediate | | SMS | Same as phone — escalation endpoint | Immediate | | Slack (if you must keep it) | Only: "call you now re: incident X" | Never a discussion, always a signal |

Behavioural rule: If the building is not on fire, it does not belong here. If you use Zone 3 for a non-emergency, you erode the protocol for everyone.

Response time SLAs by role

A common concern about async is that it slows down the team. The opposite is true — when SLAs are clear, people know when to expect answers and plan accordingly.

| Role | Zone 1 SLA | Zone 2 SLA | Zone 3 SLA | |---|---|---|---| | IC Engineer | 4 hours (check in at 10:00, 14:00) | Scheduled meetings | Phone if blocked on critical path | | Tech Lead | 2 hours (check in at 9:00, 11:00, 14:00, 16:00) | Scheduled meetings | Phone for production incidents | | CTO (you) | 4 hours (check in at 11:00 and 15:00 — after maker blocks) | Wednesday meeting day | Phone for escalated incidents only | | PM | 2 hours (async coordination is their job) | Scheduled meetings | Phone for customer escalations |

The key is the designated check-in times. Not "I check Slack whenever." Three times per day, I open the async queue. Process everything. Close it.

Tool-specific protocols

Email

→ Process twice per day: 11:00 (after maker), 16:00 (before end of day). → Use the 4-sentence rule: every email response is max 4 sentences. If it needs more, it's a call. → Unsubscribe from everything. If an email is automated and not core to your product, kill it. Spend 20 minutes on unsubscribe once and save 40 hours per year.

Linear / Jira

→ Ticket descriptions must follow a template: Problem → Context → Proposed approach → Acceptance criteria. → Comments are for decisions, not discussion. If a comment thread exceeds 5 comments, it becomes a meeting. → Status updates are a boolean: blocked or not blocked. If blocked, state the blocker in one sentence. No paragraphs.

Pull requests

→ Description must explain the decision, not the code. The code is self-documenting. The PR explains why this approach over alternatives. → Review SLA: 4 hours during working hours. If you can't review within 4 hours, assign someone who can. → No "LGTM" without substance. A review must either approve with reasoning, request changes with specific feedback, or defer with "I can't review this — assigning X."

Shared docs

→ Every doc starts with a TL;DR. Three sentences max. If you can't summarize the decision in three sentences, you don't understand the problem well enough to write about it. → Comment period: 24 hours for feedback. After that, the author makes the call. → No doc longer than 5 pages. If it's longer, it's two docs.

The escalation protocol

The number one objection to async is fear: what if something goes down and nobody responds?

The escalation protocol solves this. It defines exactly how to move a message from Zone 1 to Zone 3.

Zone 1 first. Report the issue in the appropriate channel (Linear ticket, PR comment, email). Include severity assessment (critical, high, medium, low).
Wait the SLA. If it's critical: 15 minutes. If high: 1 hour. If medium: 4 hours. If low: 24 hours.
Escalate to Zone 2. If the SLA expired without response, request a 15-minute decision meeting. Link to the original message. State the decision needed.
Escalate to Zone 3. If the decision meeting doesn't resolve or the issue can't wait, call the escalation contact. Phone. Not Slack. Not email.

This protocol works because it's rare. When 95% of messages are Zone 1 and respect their SLA, the 5% that escalate feel like the exceptions they should be. Most teams have the opposite: everything is Zone 3 until everyone is numb to alerts.

The recovery protocol

You will break the async protocol. An incident will pull you into synchronous mode during your maker block. A stakeholder will call you during your transition.

That's fine. The protocol survives the exception.

→ Tag the lost time. When an emergency pulls you synchronous, log it. Note what time and what you were doing. This is data, not whining.

→ Recover, don't cram. The Hybrid Day has buffer for a reason. Use it. If you lost 2 maker hours, don't try to work 2 hours later. Recover them the next morning.

→ Debrief the protocol. If the same type of emergency happens twice, the process is wrong, not the people. Fix the process.

The 30-day async shift

You cannot flip a switch to async. Your team will resist — the same way mine did for two weeks after I banned Slack. The shift takes 30 days of consistent enforcement.

→ Week 1: Document and distribute the protocol. Explain the zones, the SLAs, the escalation rules. Get buy-in. Expect skepticism.

→ Week 2: Enforce the protocol in your own behavior. Do not respond outside SLAs. Do not escalate unless the protocol says so. Lead by example — your team will mirror what you do, not what you say.

→ Week 3: Correct violations. Gently, consistently. "This looks like Zone 1 — let's put it in Linear." "Did you wait the SLA before escalating?" Not punitive. Educational.

→ Week 4: Audit. Count Zone 1 vs Zone 3 messages. Measure average response time. Show the team the data. The improvement will be measurable, and the team will convert from skeptical to convinced.

By day 30, the protocol runs itself. Your notifications are silent. Your interruptions are near zero. And your deep work hours are protected.

The final rule

Async is not about speed. It's about autonomy.

A team that can communicate without waiting for synchronous permission is a team that can ship without waiting for you. Your job as CTO is not to answer every question. It's to build a system where the team answers most questions themselves.

The protocol handles the exceptions. Part 4 shows you how to use the time you just reclaimed.