How to Run an Async-First Engineering Team
A practical playbook for running async-first engineering teams, from communication norms to decision-making rituals that actually stick.
By Ellis Keane · 2026-04-06
When the telegraph killed the daily briefing
In 1844, Samuel Morse sent the first telegraph message between Washington and Baltimore, and within a decade, businesses that had relied on daily courier briefings started operating differently. Not because they wanted to be "telegraph-first" (nobody said that), but because the constraint changed. Information could travel faster than a horse, so the rituals built around horses quietly became unnecessary.
The parallel to running an async-first engineering team is uncomfortably direct. We have Slack, Linear, GitHub, Notion, and about seven other tools that move information at the speed of a webhook, and yet most teams still organize their days around synchronous rituals designed for when you had to be in the same room to share context – the daily standup where everyone recites their Jira tickets to a manager who already has the exact same board open on a second monitor, the "quick sync" that runs 45 minutes because three people are screen-sharing sequentially while everyone else checks their phones.
For a small engineering team like ours – four people across three time zones – recognizing that the constraint changed was the easy part. Rebuilding the rituals took longer.
What an async-first engineering team actually looks like
Async-first engineering means your team's default communication mode is asynchronous. Decisions get written down. Status is visible without asking. Context is documented where people can find it on their own schedule. Meetings still happen, but they're the exception you opt into, not the default you have to opt out of.
What it doesn't mean is that nobody ever talks in real time, which would be absurd and, honestly, a little lonely – design reviews, conflict resolution, brainstorming sessions, and the kind of nuanced architectural discussions where you need to read body language and draw on whiteboards all remain synchronous, and that's fine. The distinction is which mode you reach for first when you need to communicate something, and for most things on an engineering team, the answer should be writing it down rather than scheduling a call, because a well-written Linear comment at 2pm in Brooklyn is still perfectly legible at 9am in Berlin the next morning.
Async-first doesn't mean async-only. It means your default is asynchronous, and you opt into synchronous communication deliberately when the situation genuinely calls for it.
The four pillars (that sound obvious until you try them)
Over the past year, we've been building Sugarbug as a four-person team spread across the US East Coast and Europe, and the things that actually made our async-first engineering team work weren't the tools or the policies – they were the habits. Here are the four that stuck.
1. Write decisions down where they happened
Almost nobody does this consistently. A decision gets made in a Slack thread. Someone says "ok let's go with option B." And then... it lives there. In a thread that will be functionally unfindable in three weeks.
The fix isn't a decision log (well, not primarily). The fix is a norm: whoever makes the final call writes a one-sentence summary of what was decided and why, in the tool where the work lives. If you decided to change the API response format, that summary goes in the Linear issue or the GitHub PR description, not in a Slack thread or a meeting recording transcript that nobody will rewatch.
We learned this the expensive way: a PR sat in review for three days because the reviewer didn't know we'd already decided to use server-side rendering for that page – the decision was buried in a Slack thread from the previous week, and nobody had written it into the issue. The reviewer left six comments about client-side hydration trade-offs that were already settled, the author got frustrated, and we lost most of a week to a conversation that should have taken ten seconds if the context had been attached to the work in the first place.
After that, we stopped trying to maintain a separate decisions document (which had worked for about two weeks before it became one more thing nobody updated) and started writing decisions directly into the issue itself. Ten seconds of effort, and it survives because it's attached to the work, not floating in a meta-document nobody checks.
2. Make status visible, not reported
For our team, the status update meeting was the single most expensive synchronous ritual – each person narrating what they did yesterday and what they're doing today while everyone else half-listens and waits for their turn. In an async-first team, status should be something you can see, not something someone has to tell you.
This means your project management tool needs to actually reflect reality. If a Linear issue is in "In Progress," it should be because someone is genuinely working on it right now, not because they moved it there on Monday and haven't touched it since. GitHub PRs should have descriptive titles and linked issues. Figma files should have clear naming that tells you what's in progress versus what's approved.
What makes status visible
- Linked PRs to issues – Anyone can see what code maps to what task
- Clear branch naming –
feat/user-onboarding-flow tells you more than fix-stuff
- Updated issue states – Move tickets when work actually moves, not during standups
- Written weekly summaries – One person writes a digest, everyone reads it async
What keeps status invisible
- Verbal-only updates – Information disappears the moment the meeting ends
- Status meetings as the system of record – If it wasn't said in standup, it didn't happen
- Stale boards – A Kanban board that hasn't been touched since Monday
- Context locked in DMs – Two people know, everyone else is guessing
3. Define response windows, not response times
One of the subtler anxieties about async communication is the open-ended wait. You send a message, and you don't know if you'll get a response in twenty minutes or tomorrow afternoon. The uncertainty is worse than the actual delay.
The solution isn't to demand faster responses (that just recreates synchronous culture with extra steps). It's to set explicit expectations about response windows for different types of communication. For our team, it looks roughly like this:
- Slack messages in public channels: Within 4 working hours
- PR reviews: Within one business day
- Linear issue comments: Within one business day
- DMs marked urgent: Within 1 hour during working hours
- Everything else: Within 2 business days
The specific windows matter less than the fact that they exist and everyone has agreed to them. Once the cadence is explicit, the "did they see this?" anxiety fades, and people stop sending follow-up pings after thirty minutes of silence.
4. Protect synchronous time for what actually needs it
Something we didn't expect: the meetings we kept became noticeably better. When a meeting is the exception rather than the default, people show up prepared and engaged because they know this is the one window they have to hash something out together.
We kept three types of synchronous meetings:
- Weekly team sync (30 minutes, max) – Not status updates, but blockers, cross-cutting concerns, and "does anyone else think this architectural decision is going to bite us?" conversations
- Design reviews – Some things genuinely need synchronous visual feedback
- Pair programming sessions – When two people are stuck, talking through it together is still faster than async back-and-forth
Everything else that used to be a meeting became a written proposal, a Loom video, or a comment thread on the relevant issue. Our calendar went from looking like a game of Tetris to something a human could actually work around – which, it turns out, is the entire point of having a calendar.
stat: "3 meetings/week" headline: "Down from 12" source: "Our team's actual calendar after going async-first"
The part nobody warns you about
The hard part of async-first isn't the communication norms or the tool setup. It's the emotional adjustment. When we dropped our daily standup, one of our engineers mentioned feeling "weirdly guilty" about starting deep work at 10am without first checking in with someone. Another said the silence in Slack before noon felt like nobody was working, even though GitHub showed commits landing every hour.
This is the human-nature part of the problem, and it doesn't have a system-level fix. What helped us was being explicit about it. We talked about the fact that async can feel lonely sometimes, and that it's okay to hop on a call just because you want to talk to a human about the problem you're solving. The norm isn't "never call," it's "don't require a call for things that don't need one."
Some people on the team genuinely prefer more synchronous interaction, and accommodating that isn't a failure of the async-first philosophy – it's recognizing that communication preferences are personal, and rigid adherence to any single mode is its own kind of dysfunction.
The hard part isn't setting up async workflows. It's getting comfortable with the silence between messages, and trusting that your teammates are working even when you can't see them doing it. attribution: Ellis Keane
Making it stick: the first 30 days
If you're transitioning an existing team to an async-first engineering team model, the first month is where it either takes root or quietly collapses back into "let's just hop on a quick call." Here's what worked for us as a rough timeline:
Week 1: Write down the communication norms. Literally – a one-page document that says "here's how we communicate, here's the expected response windows, here's what warrants a meeting." Share it, discuss it synchronously (yes, the irony), and get buy-in.
Week 2: Cancel or convert three recurring meetings. Pick the ones that are most obviously status-update-in-disguise and replace them with a written format. Don't cancel everything at once – people need a gradual ramp, not a cliff.
Week 3: Audit your tool hygiene. Are Linear issues actually up to date? Are PR descriptions useful? Are decisions getting written into the places where work happens? If not, this is the week to establish those norms. Assign someone as the "async champion" who gently nudges people when a decision happens verbally but doesn't get written down.
Week 4: Retrospective (async, naturally). Send out a simple form: "What's working? What's not? What do you miss?" The answers will surprise you – some people will love the quiet, others will be struggling. Adjust the norms based on real feedback, not theory.
- [x] Write communication norms document
- [x] Define response windows for each channel
- [ ] Cancel or convert 3 status meetings
- [ ] Audit tool hygiene (issues, PRs, decision docs)
- [ ] Assign async champion for the transition
- [ ] Run async retrospective after 30 days
- [ ] Adjust norms based on team feedback
When async-first is the wrong call
Async-first is a bad fit in several common situations. If your team is three people sitting in the same office, synchronous communication is probably fine and the overhead of formalizing async norms would be solving a problem you don't have. Similarly, if your team is in a genuine crisis – production is down, a critical launch is imminent, or you're pivoting the product direction – that's synchronous territory, and pretending otherwise would be dogmatic rather than practical.
Async-first works best for teams that are distributed across time zones, teams larger than about five people (where the combinatorial explosion of synchronous coordination starts to hurt), and teams that would rather ship code than narrate what they shipped in a meeting about what they shipped. If that's you, the investment in async norms pays for itself within the first month, primarily in recovered engineering hours that used to disappear into the meeting-industrial complex.
The telegraph didn't eliminate face-to-face conversation – it just made the daily courier ride unnecessary. That's all async-first does for an engineering team: it retires the rituals that only existed because the tools hadn't caught up yet, and protects the conversations that actually matter.
Frequently Asked Questions
Q: How do you handle code reviews in an async-first engineering team? A: Set an explicit review SLA (ours is one business day) and make PR descriptions do the heavy lifting – explain not just what changed but why, link the relevant issue, and flag anything the reviewer should focus on. The biggest async-review failure mode is a PR that sits for three days because the reviewer needs context that exists only in someone's head. Write it down or pay for it later.
Q: Does Sugarbug help with async-first workflows? A: It helps with the specific problem of context getting fragmented across tools – a decision in Slack, a task in Linear, a design comment in Figma. Sugarbug connects those signals so status is visible without anyone having to narrate it in a meeting. It's not the only way to solve that problem (you could also be very disciplined about cross-linking everything manually), but we built it because we got tired of the manual version.
Q: What's the biggest mistake teams make when going async-first? A: Treating it as a policy change instead of a habit change. You can write a beautiful "communication norms" document, but if people don't actually update their Linear issues or write decisions into PRs, you've just removed meetings without replacing the information flow. The norms have to become muscle memory, which takes about a month of gentle, consistent nudging.
Q: How do you handle urgent production issues in an async-first team? A: You don't handle them async – that's the whole point of "async-first, not async-only." Define a clear escalation path: a dedicated Slack channel or PagerDuty for true emergencies, with the understanding that everything else follows normal response windows. The key distinction is between "urgent" (production is down) and "I want an answer now" (which is usually impatience, not urgency).
Q: Can Sugarbug replace standup meetings entirely? A: It can replace the information-gathering part – the "what did everyone do yesterday?" ritual – because that context is already flowing through GitHub, Linear, and Slack. What it can't replace is the human connection part, which is why we still keep a short weekly sync for the conversations that benefit from being in the same (virtual) room.
Get signal intelligence delivered to your inbox.