Async-First: The Manifesto

Last article, I showed you the math. 11 hours a week lost to ceremonies. Information duplicated 3.4 times. Three-hour latency for questions already answered in the CRM.

The response I got most: “Okay, but what did you actually do about it?”

Fair question. Here’s the answer: we went async-first. Not as a philosophy or a trend. As the only logical solution to the problem we’d measured.

This is what that actually looks like.

The Transition Nobody Wanted

First week without daily standups felt wrong. Like we’d forgotten something important.

“How will we know what everyone’s working on?” someone asked.

My answer: “The same way we knew before standup existed—check the work.”

But that’s not actually how we knew before. We knew because we asked in standup. The work itself was scattered across Jira, Slack, the CRM, people’s heads. Standup was where we synchronized all that scattered information.

Removing standup didn’t solve the problem. It exposed it.

The real issue: we had no single source of truth. Information lived everywhere and nowhere. Standup was just expensive duct tape covering that architectural failure.

Documentation Over Synchronization

Here’s the pattern we’d fallen into:

Monday morning, client asks: “What’s the status on the workflow optimization?”

Old process:

1. See message in Slack
2. Check where we actually are (Jira? CRM? Last week’s notes?)
3. Respond verbally: “Making progress, should have draft by Wednesday”
4. Client asks follow-up: “What specifically is left?”
5. Another message: “Final review and documentation”
6. Client saves none of this
7. Thursday: “Hey, what’s the status?” (same question again)

We measured this. For our active client projects, status questions came up 2.3 times per week on average. Each answer took 5-10 minutes to formulate because we had to find the information first. Then it disappeared into Slack history.

Time cost: ~30 minutes per project per week just answering “what’s the status?”

For three simultaneous projects: 90 minutes a week. On a three-person team, that’s 4.5 person-hours weekly spent re-answering the same question.

New process: Every project has a living document. Not a static plan—a continuously updated source of truth.

Project Brief Template:

PROJECT: [Client Name] - [What We're Optimizing]
CURRENT PHASE: [Discovery/Design/Implementation/Review]
LAST UPDATED: [Date + Who]

PROGRESS THIS WEEK:
- [Completed items]
- [In progress items]
- [Blocked items with explanation]

NEXT STEPS:
- [What's happening next, with dates]

DECISIONS LOG:
- [Date]: [What was decided and why]

OPEN QUESTIONS:
- [What we need from client]
- [Internal uncertainties]

Client asks “what’s the status?”

Response: “Updated the doc this morning: [link]”

They read it. They see exactly where we are. They see what they need to provide. They don’t need to ask again because the doc updates every time something changes.

Time cost: 5 minutes to update the doc (we were tracking progress anyway). Zero time answering status questions.

But here’s the thing nobody tells you about documentation: it’s only useful if it’s actually maintained. Dead docs are worse than no docs because people stop trusting them.

So we made a rule: if you did the work, you update the doc. Not at end of week. Not when you remember. When you complete something, you immediately update the source of truth.

This felt like overhead at first. Now? It’s faster than explaining what you did in standup.

Why Conversation Fails for Process Work

We optimize client processes. Manufacturing workflows, approval chains, inventory systems—complex operational stuff.

Here’s what happens when you try to do this work in meetings:

Client kickoff call, old way:

• 60 minutes scheduled
• First 15 minutes: smalltalk, waiting for everyone to join
• Next 30 minutes: client explains their process verbally
• We ask clarifying questions
• They give verbal answers with examples
• We frantically take notes
• Last 15 minutes: agree on next steps (vaguely)

After the call:

• Spend 2 hours writing up what we heard
• Realize we’re missing critical details
• Email client with follow-up questions
• Wait for responses
• Have another call to clarify
• Repeat

Total time to clarity: 3-5 days, 4+ hours of meeting time

Client kickoff, new way:

Before any call, we send a structured questionnaire:

CURRENT STATE ANALYSIS

1. What process are we optimizing?
   [Describe in detail - screenshots welcome]

2. What's the problem?
   [Specific pain points, with examples]

3. What's the current workflow?
   [Step by step - who does what, when]

4. What have you tried?
   [Previous solutions and why they didn't work]

5. What does success look like?
   [Concrete metrics or outcomes]

6. What constraints do we have?
   [Budget, timeline, technical limitations]

Client fills this out asynchronously. Takes them maybe 90 minutes, but they do it when they have time to think. They attach screenshots, documents, examples.

We read it. We analyze it. We come to the call with:

• Understanding of the problem
• Initial hypotheses
• Specific questions about edge cases
• Draft approach for discussion

Call is now 30 minutes. Focused. Everyone prepared.

After the call: documentation is 80% done because the client already wrote most of it. We just structure it and add our analysis.

Total time to clarity: 1 day, 2 hours total (mostly async)

The difference? Writing forces clarity. When you have to type out your process, you notice the gaps. The inconsistencies. The “well, sometimes we do it this way, sometimes that way” becomes visible.

Verbal conversation lets everyone pretend they’re aligned when they’re not.

Deep Work Versus Shallow Collaboration

Last article showed we were spending 9.4% of time in ceremonies. That’s the direct cost. The indirect cost is worse: fragmentation.

A typical day before async-first:

9:00-9:15   Daily standup
9:15-10:30  Start analyzing client workflow
10:30-11:00 Client call (someone else's, but I'm backup)
11:00-12:00 Continue analysis (try to remember where I was)
12:00-1:00  Lunch
1:00-1:30   "Quick sync" about another project
1:30-3:00   Back to analysis (reload context again)
3:00-3:30   Sprint planning
3:30-5:00   Finish analysis (maybe)

Actual deep work time: maybe 3.5 hours, split into three chunks.

And deep work doesn’t chunk well. Understanding a client’s workflow means loading their entire operation into your head. Their steps, their tools, their constraints, their edge cases. Takes about 30 minutes to fully load. If you’re interrupted after an hour, you dump half of it.

We tracked this properly. Looked at work output on days with many interruptions versus days with few.

High-interruption days (3+ scheduled breaks in the day):

• Time spent working: 7-8 hours
• High-quality output: 2-3 hours worth
• Rest is shallow work, context switching, recovery

Low-interruption days (1-2 scheduled breaks maximum):

• Time spent working: 7-8 hours
• High-quality output: 5-6 hours worth
• Actually finish things instead of “making progress”

Same hours. Double the output.

This is why async matters. Not because meetings are evil. Because uninterrupted time is where the actual work happens.

The Async Workflow We Actually Use

Here’s a real example from last month. Client in logistics, wanted us to optimize their route planning process.

Week 1: Discovery

Monday: Client fills out our intake questionnaire (async, on their schedule)

Tuesday: We review, add questions directly to the doc (async, they answer when they can)

Wednesday: 30-minute call to clarify complex points. Record it. Notes in the doc immediately after.

Thursday-Friday: We analyze their current process, document findings in shared doc. Tag client on specific questions.

Status updates: Zero. Everything visible in the doc.

Week 2: Solution Design

Monday: Draft proposal in doc. Three options with tradeoffs clearly laid out.

Tuesday: Client reviews async, comments with questions and preferences.

Wednesday: We refine based on feedback. Update doc.

Thursday: Client approves approach via comment.

Friday: We start implementation planning.

Meetings: One 30-minute call. Everything else async.

Week 3-4: Implementation

Daily: Update project doc with progress. Blockers documented with explanation.

Client checks doc when they want updates. Usually daily, sometimes twice daily. They see exactly where we are without asking.

When they have questions, they comment on the doc. We answer same day, usually within 2-3 hours.

We need a decision? Document the options, tag them, set 24-hour deadline for input.

Total meetings during implementation: Zero.

Week 5: Delivery

Final review as document. Client comments async. We adjust. Deliver.

One 45-minute walkthrough call to hand off and answer questions.

Project total: 2 calls, maybe 90 minutes total. Everything else documented and async.

Compare this to our old process:

• Weekly status calls
• Ad-hoc “quick syncs”
• Endless Slack threads
• Information scattered everywhere

We’d spend 4-5 hours in meetings per project. Plus another 2-3 hours preparing for and recovering from those meetings.

Async workflow: ~7 hours of meeting overhead eliminated per project.

What This Requires

You can’t just stop having meetings and call it async. That’s just chaos with a trendy name.

Async requires infrastructure:

1. Single source of truth for each project

Not Slack + email + Jira + CRM + people’s heads. One doc (we use Notion, but whatever). Everything relevant lives there or links from there.

Client asks a question? Answer in the doc, then link them to it.

Make a decision? Document it in the doc.

Change the plan? Update the doc.

The doc is reality. Everything else is just pointers to the doc.

2. Structured communication

Slack is for urgent stuff only. And by urgent I mean “system is down” urgent, not “I have a question” urgent.

Everything else goes in:

• Project docs (for project-specific stuff)
• CRM (for client relationship stuff)
• Jira (for technical task stuff)

Each has clear purpose. No information lives in multiple places.

3. Response time expectations

Async doesn’t mean slow. It means asynchronous.

Our SLA: 4 hours for client questions during business hours. Not 4 hours to solve it—4 hours to acknowledge and give timeline.

Internal questions: 24 hours.

Urgent issues: tagged as urgent, we respond immediately. But urgent is rare—maybe once a week.

This only works because people trust the system. They know their question won’t disappear into a void. They’ll get a real answer, in writing, within a predictable timeframe.

4. Meeting criteria

We still have meetings. Just way fewer. A meeting needs to meet at least one of these criteria:

• Real-time collaboration required (whiteboarding, brainstorming)
• High complexity + high stakes decision
• Relationship building (client kickoff, project closeout)
• Genuine blocker that async isn’t resolving

“Status update” is never a valid reason. “Quick question” is never a valid reason. “Getting everyone aligned” is never a valid reason.

If you can write it, write it. Only meet when async genuinely can’t solve it.

What Clients Actually Think

We were worried. Would clients think we’re being difficult? Unresponsive? Hiding behind documentation?

Opposite happened.

Client feedback from last quarter:

• “Most organized vendor we work with”
• “Always know exactly where things stand”
• “Don’t waste our time in status meetings”
• “Appreciate the detailed written communication”

Here’s why it works for them:

They can check progress on their schedule. Not waiting for our weekly call. Not interrupting us with Slack messages. Just open the doc, see the status, done.

They have documentation of everything. Decisions, rationale, changes. Six months later when someone asks “why did we do it this way?” they have the answer in writing.

They’re not in meetings either. They’re doing their actual job while we do ours. We sync asynchronously.

One client said: “You’re the only vendor who respects that we’re busy too.”

That’s not altruism. It’s efficiency. Their time costs money. Our time costs money. Meetings cost both. Async saves both.

The Numbers After Six Months

We measured this the same way we measured the Agile overhead.

Time savings per week:

• Ceremonies eliminated: 11.25 hours (team total)
• Status meetings eliminated: ~6 hours (team total)
• Slack interruptions reduced by ~60%: ~4 hours (team total)

Total: ~21 hours per week recovered

For a 3-person team working 40-hour weeks (120 hours total), that’s 17.5% more capacity.

Quality improvements:

• Client satisfaction scores: up 23%
• Project delivery on-time rate: 89% → 97%
• Revision requests: down 31% (better documentation = clearer expectations)

What we lost:

• “Team bonding” from daily standups (we do monthly lunches instead)
• Immediate answers (replaced with better answers)
• The feeling of being “aligned” (replaced with actually being aligned through documentation)

This Isn’t Ideology

We’re not anti-meeting zealots. We’re not “async purists.” We’re people who measured a problem and fixed it.

The problem was synchronous communication overhead. The solution was async-first workflow with proper documentation infrastructure.

Would this work for a 50-person company? Maybe not the same way. Different scale, different problems.

But for small teams doing complex work? This is the only thing that makes sense.

You can’t do deep work while constantly synchronizing. You can’t serve clients well while serving internal ceremony. You can’t optimize other people’s processes while your own is broken.

We sell process optimization. The best proof we can offer is our own process.