Every morning at 9:15 AM, a Slack bot asks your team three questions: What did you do yesterday? What are you doing today? Any blockers? Every morning, your engineers type variations of "continued working on the auth refactor" and "no blockers." And every morning, nobody reads the responses.
Async standups in Slack were supposed to fix the most hated meeting on every engineer's calendar. No more standing in a circle reciting status updates that could have been a message. No more waiting through twelve people's updates to find out if anyone is blocked on your PR review.
The reality is different. Slack standups didn't eliminate the problem - they just moved the waste from a meeting room to a text channel. And in some ways, they made it worse.
The Promise vs. Reality of Slack Standups
The idea behind async standups is sound: collect status updates asynchronously, let people read what's relevant, skip what isn't. Tools like Geekbot, Standup & Prosper, DailyBot, and Polly made this trivially easy to implement. Set up a bot, pick a schedule, define your questions, and you're done.
Here's what actually happens on most teams:
Updates become performative. When you type your standup into Slack, you're writing for an audience - your manager, your PM, maybe your skip-level. The update optimizes for "looking productive" rather than "communicating useful information." "Continued working on JIRA-4521" tells the reader nothing about progress, risk, or blockers.
"No blockers" is almost never true. Engineers write "no blockers" because the standup format doesn't create space for the real blockers: unclear requirements, waiting on a design review, uncertainty about whether an approach will work, an API that's behaving unexpectedly. These aren't blockers in the Scrum-certified sense. They're the actual friction points that slow teams down.
Nobody reads the full thread. A team of 8 engineers producing daily standup updates generates 120+ messages per week in the standup channel. In a 25-person engineering org, that's 375+ standup messages weekly. The signal-to-noise ratio is abysmal. Most people scan for their name and ignore the rest.
The data goes nowhere. Standup responses sit in a Slack channel and rot. Nobody aggregates them. Nobody spots patterns. The same person has been "continuing to work on the auth refactor" for three weeks, and nobody notices because each day's update looks fine in isolation.
What's Actually Wrong With the Standup Format
The problem isn't Slack vs. in-person. The problem is the format itself.
The traditional three questions - what did you do, what will you do, any blockers - were designed for a specific Scrum context where the team is working on the same sprint backlog and needs daily synchronization to coordinate handoffs. For modern engineering teams working on independent streams with async code review, this format is cargo cult.
The questions are backward-looking. "What did you do yesterday?" is a reporting question, not a coordination question. Your team lead can see what you did yesterday in the commit history and PR log. The useful question isn't "what did you do?" but "what changed about our understanding of the work?"
They optimize for individual status, not team coordination. A standup should answer: "Does anyone need something from someone else today?" Instead, it collects eight independent status reports that require the reader to synthesize coordination needs from context clues.
They miss the information that actually matters. What changed since yesterday? Did we learn something that affects the sprint? Is an estimate wrong? Did a dependency surface? Did someone discover the approach won't work? These are the things teams need to communicate daily, and none of them fit neatly into "what I did / what I'll do / blockers."
What to Do Instead: 5 Approaches That Actually Work
1. Replace Status Questions With Risk Questions
Instead of the standard three questions, ask questions that surface real information:
- What's the riskiest thing you're working on right now? This forces engineers to identify uncertainty rather than report activity.
- Did anything change your estimate this week? This catches scope creep and technical surprises early.
- What's one thing the team should know that you haven't mentioned yet? This creates space for the informal knowledge that usually only surfaces in hallway conversations.
2. Use Codebase Intelligence Instead of Self-Reporting
The most reliable status information isn't what engineers say they did - it's what the code says they did. Tools like Glue analyze the codebase in real time, surfacing what's actually changing, where complexity is growing, which areas have high churn, and what dependencies exist between work streams.
When your PM can see that the auth refactor has touched 47 files across 3 services and introduced two new external dependencies, they don't need to ask "how's the auth refactor going?" The codebase answers the question with more accuracy and less interruption than any standup format.
This doesn't eliminate team communication - it eliminates the least valuable form of it. Engineers stop spending time writing status reports and start spending that time on the conversations that actually require human judgment: architecture decisions, approach debates, and risk mitigation.
3. Weekly Syncs Instead of Daily Standups
For many teams, daily synchronization is unnecessary. If your engineers are working on independent streams with async code review, a weekly sync provides better signal at lower cost.
A 30-minute weekly sync with a focused agenda - what did we learn this week, what's risky next week, what needs cross-team coordination - replaces five daily standups (75 minutes of meetings or 50+ async messages) with a single high-quality conversation.
4. Standup by Exception
Instead of everyone reporting every day, only report when something changes. No update means things are on track. This flips the default from "prove you're working" to "flag when something is off."
A 15-person engineering team at a fintech company switched to "standup by exception" and reduced their standup channel volume by 80%. The remaining 20% of messages were genuinely useful - actual blockers, changed estimates, and discovered risks.
5. Embedded Updates in Your Project Tool
Move status communication into the context where it's useful. A comment on a Linear issue or Jira ticket that says "discovered the third-party API doesn't support pagination, need to implement cursor-based fetching ourselves, adding 2 days" is infinitely more useful than a Slack standup that says "working on API integration."
The update lives with the work. Anyone who needs context finds it where they're already looking. No separate channel to check.
How to Transition Away From Daily Slack Standups
Killing the daily standup feels risky because managers worry they'll lose visibility. Here's how to make the transition:
Step 1: Run both models for two weeks. Keep the daily standup but also implement one of the alternatives above. After two weeks, compare: which format surfaced more useful information? Which one caught a real problem earlier?
Step 2: Make the data visible. Use Glue or your project management tool to create a team dashboard that shows what the code and the tickets already reveal. When managers can see progress without asking for it, the daily standup becomes obviously redundant.
Step 3: Keep a weekly sync. Don't eliminate all synchronous touchpoints. A weekly team sync replaces the coordination function of daily standups while giving the team four fewer interruptions per week.
Step 4: Measure the results. Track cycle time, PR review latency, and (if you dare) ask engineers to estimate their daily uninterrupted focus time before and after the change. The numbers make the case.
Frequently Asked Questions
How do you run a daily standup in Slack?
Most teams use a standup bot like Geekbot, DailyBot, or Polly - or Slack's built-in Workflow Builder. The bot posts questions at a set time, team members reply in a thread, and responses are collected in a dedicated channel. However, the more important question is whether a daily async standup is the right format for your team at all.
What should I say in a standup meeting?
Skip the activity report ("I worked on X"). Instead, focus on three things: what changed since yesterday that the team should know, what risk or uncertainty you're currently facing, and whether you need anything from someone else to make progress. These are the only three pieces of information that justify a synchronization point.
Are async standups better than synchronous standups?
Async standups reduce meeting time but often produce lower-quality information because the format encourages performative updates. The best approach combines async status visibility (through codebase intelligence tools like Glue or project management dashboards) with a weekly synchronous sync focused on risks and coordination.
What is the best Slack standup bot?
Geekbot is the most popular and feature-rich. Polly offers good survey-style check-ins. DailyBot adds AI analysis of responses. But the tool matters less than the format - even the best bot can't fix questions that don't surface useful information.
Related reading: Slack Alternatives for Engineering Teams | Conway's Law: Why Your Architecture Mirrors Your Org Chart | Sprint Planning Is Broken