← Blog
async

Standups Are a Symptom. Async Tools Don't Fix the Diagnosis.

·5 min read

Standups Are a Symptom. Async Tools Don't Fix the Diagnosis.

The async-first market is growing. 85% of remote teams report productivity gains with async video tools. Loom, Claap, AI meeting summaries — these are standard now. The pitch is that standups were the problem and async is the solution.

The pitch is wrong.

Standups are not the problem. They're a symptom. The underlying condition is that teams have no persistent shared state — no single source of truth about what's in progress, what's blocked, and why. When there's no persistent shared state, teams compensate with synchronous check-ins to reconstruct it in real time. That's what a standup is: a manual state-sync ritual.

Async tools solve the synchronous nature of the ritual. They don't solve the absence of shared state.

What Loom Actually Changes

A team that records Loom updates instead of meeting still has no persistent, queryable source of truth about project state. They've replaced a meeting with a video that also has to be consumed actively and manually. The coordination cost is lower. It's not gone.

The information in a Loom update is still locked in a medium that requires a person to watch it, interpret it, and hold it in their head. It doesn't accumulate. You can't query it. When someone new joins the project, they can't read the Loom history the way they'd read a ticket or a pull request and arrive at an accurate model of where things are.

The productivity gain from async video tools is real but narrow. It reduces the cost of communicating status. It doesn't create status as a persistent artifact.

The Origin of Ordia's Design

I built Ordia because I had this problem. Not in the abstract — concretely, daily.

I was manually syncing Jira, GitHub, and Slack to reflect the same project state across three surfaces. The time cost was not large — fifteen minutes a day, maybe. The interruption cost was large. Three times a day, I had to switch context from building to reporting. The cognitive shift required to write an accurate status update is not trivial. You have to exit the building context, reconstruct the current state of all active work across all surfaces, and then re-enter the building context.

At solo scale, this was irritating. At team scale, this pattern is why standups exist. The standup is a scheduled reconstruction of shared state because the shared state doesn't persist automatically.

The solution I built is not "replace the standup with an async equivalent." The solution is to make the state persistent automatically so that the standup contains no new information. When the standup contains no new information, it stops happening.

The Tools That Actually Eliminate Standups

The products that eliminate standups are not communication tools — they're state management tools. Linear, with cycles and priorities visible to everyone. GitHub project boards, when actively maintained. Tools that surface the current state of work without requiring anyone to describe it.

The key property is automatic state maintenance. When a PR is merged, the linked ticket should update. When a build fails, the blocker should be visible. When a branch has been dormant for two weeks, something should flag it. State transitions happen in the tools already — the problem is that humans are currently the integration layer, manually propagating those transitions across surfaces.

When state maintains itself, the need to reconstruct it in a meeting disappears.

The Gray Group's State of Remote Work 2026 report observes that fewer tools with deeper adoption consistently outperforms wide tool sprawl. That's the other half of this: more tools creates more state that needs to be manually synchronized. The goal is not a better async communication tool on top of the existing stack. The goal is a stack that maintains its own state.

Async tools are one layer. State-management tools are the fix. Teams adopting Loom while still running daily check-ins have made the symptom slightly less painful. They haven't treated the diagnosis.

What "No Standup" Actually Looks Like

I don't run standups. Not because I'm solo — the solo case is trivial. But the design principle behind Ordia's coordination layer is explicit: every feature should move the system toward a state where the standup would contain no new information.

That means: every status transition should update the source of truth automatically. When a branch is pushed, the linked ticket should reflect it. When a PR is opened against a ticket, the ticket status should update. When a build breaks, the blocker should propagate. No human should be the relay.

This is harder than building async video tooling. It requires integrating with multiple tools, handling conflicting state, making decisions about what counts as "blocked" and what counts as "in progress." There's no shortcut to explicit state management.

The teams that will actually eliminate standups in the next two years are not the ones buying the best async communication tools. They're the ones investing in the integration layer that keeps state consistent across surfaces. That investment is less visible than a Loom subscription, requires engineering effort to set up, and produces a quieter, less-noticeable result: meetings that stop being necessary rather than meetings that are slightly less painful. That's the correct goal. It's also the harder one to sell.