Async-First Engineering: How Pods Communicate Without Meeting Overload
The average developer loses 2.5 hours per day to meetings and Slack interruptions. That is 12.5 hours per week. For a 5-person team, that is 62.5 hours of engineering time evaporating into status updates, “quick syncs,” and threads that could have been a Linear comment.
We run our pods async-first because the math is obvious. Every meeting you eliminate gives an engineer back a block of focused time where actual code gets written.
What Goes Where
Async-first does not mean “no communication.” It means every piece of information has a specific channel, and synchronous calls are the last resort instead of the default.
Slack: Quick Questions and Daily Updates
Every pod engagement has a shared Slack channel with the client team. This is where quick technical questions happen, where blockers get raised, and where daily updates get posted.
Response time norm: within 2 hours during business hours. This is set on day one and we stick to it.
Pod members post a written daily update every morning. Here is the actual format we use:
## [Name] - May 8
**Done yesterday:**
- Merged PR #247: user invite flow with email verification
- Fixed flaky test in payment module (was a race condition on DB cleanup)
- Reviewed PR #245: added comments on error handling in webhook processor
**Today:**
- Starting MET-334: multi-tenant workspace switching
- Pairing with [client engineer] on Stripe Connect onboarding at 2pm
**Blocked:**
- MET-312: Need access to staging Stripe account to test webhook signatures
(asked @clientCTO in thread yesterday, following up)This takes 3-4 minutes to write and 1 minute to read. Compare that to a 15-minute standup with 5 people, which burns 75 minutes of collective engineering time daily. Over a two-week sprint, the written format saves roughly 10 hours.
The updates also create a searchable record. When someone asks “what happened with the webhook issue last Thursday,” the answer is in the channel with links to the relevant PRs.
Linear: All Task Tracking and Technical Discussion
Every ticket, every technical discussion about implementation, every scope change lives in Linear. Not in Slack threads where it gets buried. Not in emails where half the team misses it.
When an engineer starts a task, they move it to “In Progress” in Linear and add a brief note about their approach. When they open a PR, they link it to the ticket. When they hit a design decision that affects scope, they comment on the ticket with the options and their recommendation.
This means anyone on the client team can open Linear at any time and see exactly what is happening on every task, who is working on it, what decisions have been made, and why.
When Sync Calls Happen
We schedule synchronous video calls for exactly three situations:
-
Kickoff and early engagement. The first week of a pod engagement includes 2-3 sync calls for relationship building and codebase walkthrough. After that, they taper off.
-
Complex architectural decisions. When a design decision involves tradeoffs that are hard to communicate in writing (usually because the options need back-and-forth exploration), we schedule a 30-minute focused call with a clear agenda and a written summary posted to Linear afterward.
-
Sprint retrospectives. Every two weeks, a 30-minute retro between the pod lead and client stakeholder. What worked, what did not, what to adjust. Written notes posted to the shared channel.
That is it. No daily standups. No “weekly sync to stay aligned.” No “let me grab 15 minutes to pick your brain.” If it can be written, it gets written.
The Sprint Report
Every two weeks, the pod delivers a sprint report directly to stakeholders. Here is what it includes:
- Features delivered (with links to PRs and deploys)
- Planned work that was deferred, and the specific reason why
- Test coverage delta (e.g., “Coverage moved from 67% to 71%, added 34 tests for the payment module”)
- Bug count and incident summary
- Plan for the next sprint
- Decisions or risks that need client input
This replaces the traditional sprint review meeting. Stakeholders read it on their schedule, not when the calendar dictates. Questions and feedback happen in a thread underneath the report.
Why This Produces Better Work
A single meeting in the middle of the morning splits the day into two short blocks. Neither block is long enough for complex engineering work. Research from Microsoft’s developer productivity team shows that engineers need at least 2 uninterrupted hours to reach a productive flow state. A 30-minute standup at 10am destroys both the morning block and the engineer’s momentum.
Async communication lets engineers batch their reading and writing into specific windows (usually first thing in the morning and after lunch), preserving 4-5 hour blocks for actual coding.
It also produces better decisions. When you have to write down your reasoning, you think more carefully than when you are talking off the cuff in a meeting. Written decisions can be reviewed with full context by people in different time zones. Nobody misses the key discussion because they were in another meeting.
How This Works With Your Team
If your internal team runs daily standups and weekly syncs, you do not need to change anything about how they operate. The pod adapts to your communication rhythm for cross-team interactions. Pod engineers join your Slack, use your Linear (or Jira, we work with both), and match your PR review conventions.
The async practices are how the pod operates internally. The interface with your team is whatever works for your team.
If you want to see this in practice, we can show you a sample sprint report and walk through our communication setup. It takes about 15 minutes and we do it over Slack, naturally.