How to Run Engineering Standups Async

The average engineering team spends 31 hours a month in meetings. Standups alone account for roughly 5 of those hours per person. That is 5 hours of everyone on the call looking at the same Jira board that is already visible to everyone on the call.

There is a version of this that makes sense. It was 1993, your team sat in the same office, and the only way to know your teammate was blocked was to ask them. The daily standup solved a real coordination problem. The problem is that Slack, GitHub, and linear issue trackers have existed for over a decade now, and most teams are still running the same ritual as if none of that infrastructure exists.

The standup did not survive because it works. It survived because killing it feels risky. What if someone misses something? What if blockers pile up silently? Those are legitimate fears. They are also completely solvable without a recurring calendar event.

The thing standups are actually doing wrong

A standup has 3 jobs: surface blockers, share state, and force a next action. Most standups do the 2nd job passably and skip the other 2 entirely.

The reason is structural. Verbal updates are not auditable. When someone says "I'm blocked on the API review" in a standup and the meeting moves on, that blocker lives in nobody's queue. It was heard, but not owned. By tomorrow's standup it will be mentioned again, and the day after that, until someone finally gets frustrated enough to Slack directly.

Written async formats have the opposite problem. They get filled out dutifully and read by nobody because there is no signal about what matters. A Slack thread with 6 "here is what I did yesterday" messages is not async communication. It is a standup that lost its chairs.

What actually works is treating async like a decision system, not an update system. The output is not "what happened" but "what needs to move and who owns it."

This distinction came up directly in conversations with teams running Ryva:

Most of the info is already sitting somewhere: commits, tickets, PRs, Slack threads. But then we still ask people to repeat all of that in a meeting every day. It ends up feeling like you're just re-explaining work that's already been done and recorded.

That is the standup failure mode in 1 sentence. The data exists. The meeting is just asking people to narrate it back out loud.

Why engineers specifically hate standups

Context switching has a measurable cost. A 2001 study from the University of Michigan found that switching tasks reduces productivity by up to 40%. For engineers, who do their best work in long uninterrupted stretches, a 15-minute standup at 10am does not cost 15 minutes. It costs the hour before it, because the meeting is close enough to make deep focus feel futile, and the hour after it, because it takes roughly 23 minutes to return to a flow state after an interruption.

The daily standup is 3 interruptions per week minimum. For a team of 8, that is 24 interruptions per week, all coordinated to happen at the same time, for a meeting that most attendees consider optional in hindsight.

There is also a subtler issue that rarely gets named directly. Standups are optimized for the person running them, not for the people in them. The format that makes a manager feel informed is not the same format that helps an engineer stay unblocked.

How to actually replace it

The goal is not to move the standup to Slack. The goal is to replace the coordination function of the standup with something that requires less synchronization and produces clearer output.

Start with signal, not summaries. Your team's actual state already exists in GitHub and Slack. PR lifecycle, open issues, thread conversations about blockers are all there, timestamped and searchable. Any async format that asks engineers to manually describe what they are working on is adding a translation layer on top of data that already exists. Remove the translation step.

Structure output around decisions, not activity. There is a meaningful difference between these 2 outputs:

• "Authentication PR is in review."
• "Authentication PR has been in review for 4 days, no reviewer assigned, blocking the release candidate."

The 1st is a status. The 2nd is a decision that needs an owner by end of day. Only 1 of them creates movement.

Force resolution on a timeline. The standup's hidden function is urgency. Something gets raised, the team is watching, a decision gets made before the meeting ends. Async has no natural urgency unless you build it in. A practical rule: any open decision older than 72 hours escalates to the team lead. Not for them to resolve it, just for them to see it. Visibility is enough to unstick most things.

The difference between status and state is where most async formats fall apart. One engineering manager described it exactly right:

Slack. Not because it is designed for it, but because that is where the real conversations happen. The decisions, blockers, and direction changes are buried in threads, not dashboards.

The decisions exist. They are just not surfaced, not owned, and not tracked past the moment someone typed them.

The rollout

Do not cancel every standup at once. Pick the 1 with the lowest decision density, usually the weekly engineering status sync, not the daily. For 2 weeks, run both: publish the async summary before the meeting starts, then attend the meeting and track whether anything came up that was not already in the summary. If the answer is consistently no, you have your case.

In week 3, cancel the recurring event and replace it with an optional open window at the same time. No agenda, no host. Anyone who wants synchronous back-and-forth can join. Most weeks, nobody does.

Measure resolution rate, not attendance. If open decisions are closing within 48 hours, the format is working. If blockers are aging past 72 hours, the issue is usually 1 of 2 things:

• The decision format is too vague to act on
• Nobody has ownership of the escalation rule

Fix whichever 1 it is.

When to keep the meeting

Some standups are worth keeping. Incident response, architecture tradeoff alignment, anything where the right answer depends on live negotiation requires synchronous time. The question is not whether to have meetings, it is whether this specific meeting earns its slot.

Look at your last 5 standups. Count the decisions made in the room versus the updates that could have been written. If the ratio is below 1 decision per meeting, the meeting is a status report wearing a collaboration costume.

Standups will almost always become status theatre unless you actively fight it.

That quote came from a conversation during Ryva outreach. It is the clearest framing of the problem. The standup does not become useless on its own. It drifts there because nobody is actively asking whether it is still earning its time.

The version worth keeping is the one where live negotiation is actually required:

• Incident postmortems where context is time-sensitive
• Architecture tradeoffs where the right answer depends on back-and-forth
• Cross-team dependency alignment where written threads would take longer than a 20-minute call

Everything else can be async.

Where Ryva fits into this

The hard part of running this playbook is the signal layer. Pulling PR state, issue movement, and Slack blockers into a structured summary that actually surfaces what needs a decision is not something you want to build manually every Monday morning.

Ryva does that automatically. It reads your GitHub and Slack activity and produces a structured project state summary with open decisions, blockers, and next actions. If you are running a small engineering team and want the async workflow without the manual overhead, it is worth trying.