The Async-First Engineering Team: What Actually Works (And What Doesn't)
Async engineering across timezones
Two years ago I had a senior engineer leave my team. Great technical mind, solid output. His exit interview feedback: "I felt invisible."
We had daily standups. Weekly 1:1s. Slack was always open. And somehow — through all of that contact — I had missed that he was struggling. He'd been quietly drowning in ambiguity for four months. By the time I noticed, he'd already accepted somewhere else.
That one stings still. And it's the honest place to start this conversation about remote work and async-first teams: the approach that let me miss it.
The Lie Remote Work Tells You
The dominant narrative around remote work — and I've bought into it, sold it to leadership, argued for it — is that it's strictly better. Fewer interruptions. No commute. Hire anywhere. The best engineers don't want to be in an office anyway.
All of that is true. It's also incomplete.
What nobody says out loud: remote work, and especially async-first remote work, is hostile to the informal signals that tell you when something is wrong. The hallway conversation. The face you make when someone says something in a meeting. The way a person who's checked out shows up differently in a room full of people who know them.
You don't get any of that on Slack.
Before I get into what works, I want to be clear: I went async-first because the tradeoffs favor it on net. But I'm not going to pretend there are no tradeoffs.
What "Async-First" Actually Means
Async-first doesn't mean no meetings. It means every meeting has to earn its existence.
The default for communication is written and asynchronous. The meeting is the exception — reserved for things that genuinely need real-time interaction: hard decisions with competing values, interpersonal tension that needs resolution, early-stage brainstorming where half-formed ideas need to bounce.
Everything else — status updates, decisions with a clear right answer, reviews, questions with factual responses — those go into writing.
When I made this shift with my team, I expected pushback. Instead I got one consistent complaint: they wished we'd done it sooner. The standups they'd been sitting through for years, it turned out, nobody liked either.
The Specific Practices That Work
Async Standups
We use a simple daily check-in format posted in a dedicated Slack channel by 10am local time, no exceptions. Three fields:
- Yesterday: What shipped or moved forward
- Today: What I'm working on
- Blockers: Anything I need from someone else
I read every one of these. Every day. This sounds obvious but most managers skim them. I use them to catch patterns — the engineer who's mentioned the same blocker three days in a row, the person whose "Today" list is unchanged from last week.
The standups also give me a weekly picture I couldn't get from a 15-minute meeting. I review them on Fridays and write a team summary that goes to my manager and any relevant stakeholders. This took about 45 minutes of overhead per week. It reduced my meeting load by roughly four hours.
Decision Documentation
Every non-trivial technical decision gets a lightweight Decision Record before we build it. Not an RFC — nobody wants to write an RFC for every decision. A paragraph with three things: what we decided, why we decided it, and what alternatives we considered and rejected.
The "rejected alternatives" part is the one most people skip. It's also the most valuable. It's what stops you from having the same argument six months later when a new engineer joins and asks why we're not doing the obvious thing.
We store these in Notion, linked from the relevant repo. They take maybe 20 minutes to write. They've saved us from undoing decisions at least a dozen times.
Weekly Written Summary
Every Friday I write a summary of what the team shipped, what's in flight, and where we're blocked. This replaces a status meeting that used to consume an hour each week from seven people. The summary takes me 30 minutes. People read it when it's convenient to them. Executives can search it. New hires can read the archives.
This single practice has done more for organizational visibility into my team's work than any meeting I've run.
Deep Work Blocks
The core promise of async-first is that people get uninterrupted time to do hard work. If you don't protect that explicitly, Slack fills every gap.
My team blocks 9am to noon, four days a week, as "deep work." No meetings scheduled in that window. Slack notifications expected to be off or ignored. Responses to messages not expected until afternoon.
This is the part that makes async-first actually work. Without it, you're just a synchronous team that writes things down sometimes.
When I Insist on Synchronous Time
There are two categories where I don't default to async: quarterly in-person time, and individual connection when something seems off.
Quarterly In-Person
Three days, four times a year. Not a conference, not a hackathon with a packed agenda. We work on real things together, eat meals together, have conversations that don't fit into Slack. I've seen teams try to skip this on budget — it always costs more later. The relationship capital you build in three days of being in the same room takes six months to rebuild over video if you let it lapse.
This is also where I've caught engineers who were struggling — the one who mentioned offhand at dinner that they'd been feeling uncertain about their scope for a few months. Not a crisis. Not something that would have shown up in a standup. Just a thing that came out when people were comfortable.
Synchronous 1:1s
My 1:1s are weekly, 30 minutes, video required. I don't do async 1:1s. The 1:1 is not for status — I have the daily standup for that. It's for the person. How are they doing? What's frustrating them? What are they trying to learn? What do they need from me?
That's a conversation, not a document.
The senior engineer who left — I let our 1:1s drift toward status check-ins. That was on me. Now I actively redirect: "I already know what you're working on. What I want to know is how you're doing."
What Still Doesn't Work Remotely
Early career engineers
The biggest structural problem with async-first is that it's rough on engineers who are still developing their pattern recognition. Senior engineers can work independently because they've already internalized a lot of implicit knowledge. Junior engineers learn a significant portion of what they know by proximity — watching how a senior engineer thinks through a problem, overhearing how decisions get made, absorbing culture through observation.
None of that happens in a Slack channel.
I've tried async mentorship structures. They help. They don't fully substitute. My current approach: early career engineers get more synchronous access to senior engineers on the team — we call it open office hours, Tuesday and Thursday afternoons, video on, any question. Even this is imperfect.
If you're running an async-first team and you're hiring early career engineers without acknowledging this problem, you're going to lose them to frustration.
Sensing that someone is struggling
I mentioned my senior engineer who left feeling invisible. The honest follow-up: I still miss things. Async-first makes this problem worse, not better. Written communication is flatter. People edit out the emotional signals before they hit send.
What I do now: I pay close attention to changes in pattern. The engineer who used to send long detailed standups who now sends one-liners. The person who's been unusually quiet in the team Slack channel. These are signals I've trained myself to notice and respond to with a direct message or a video call within 24 hours.
It's imperfect. I'm still slower to catch things than I would be in person. I've accepted this as a real cost.
Team culture and belonging
Culture in a remote team requires active maintenance in a way it doesn't in an office. Shared physical space does enormous cultural work invisibly. Remove it and you have to replace it deliberately, which most managers don't do, which is why remote teams often feel flat and transactional.
What I've done: a non-work Slack channel that actually gets used, a 15-minute informal opener at the start of our quarterly in-person, a habit of sharing context about myself in team communications so people know I'm a person and not just a function.
These feel small. They add up. They're not a substitute for proximity.
The Honest Accounting
Async-first has made my engineers meaningfully more productive. The deep work blocks, the elimination of pointless meetings, the written documentation that forces clarity before it's spoken — these are real gains. I've shipped more with the same headcount since making this shift.
It has also made some things harder. I'm slower to detect struggle. Culture requires more deliberate investment. Early career development is genuinely challenging.
The people who will tell you remote work is purely upside are selling something. The people who will tell you it's purely downside are usually selling office leases.
The truth is that going async-first is a better operating model for engineering teams — with specific, real limitations that you have to work around explicitly rather than hoping they solve themselves.
My engineer who left feeling invisible: I think about him when I'm reading standups, when I'm making sure 1:1s are actually about people and not just status. He's part of why I'm more deliberate now.
It doesn't fix the fundamental challenge of remote work. But it's made me a better manager of it.