What Engineers Actually Think About Standups: Surprising Findings From Real Conversations

The One Thing Nobody Says Out Loud

Most engineers hate standups. Not all. Not always. But a significant number treat them as a daily tax on focus time. A NASA-backed study observed 102 daily stand-ups and interviewed 60 members across 15 teams in five countries. The finding: many team members report a negative experience from conducting the meeting. That negativity reduces job satisfaction, co-worker trust, and well-being.

Yet 87% of agile teams hold these 15-minute check-ins every day, according to Research-Driven Engineering Leadership. The gap between adoption and satisfaction is where the real story begins.

Standups Do Not Work the Way Most People Think

The common assumption: standups improve coordination and transparency. The research says otherwise.

Key point: Stand-ups do not directly improve satisfaction or performance. They work because they create psychological safety. Psychological safety then drives satisfaction, learning, and performance. The effect sizes are significant — standardized coefficients between .46 and .61 for the relationship between psychological safety and various outcomes.

In plain terms: the standup itself is not the mechanism. The habit of showing up, admitting blockers, and asking for help without fear — that is the mechanism. Strip that out, and the meeting becomes a status report nobody wants to hear.

Common mistake: treating the standup as an accountability ritual. "What did you do yesterday?" framed as interrogation kills the psychological safety that makes the meeting valuable in the first place.

The Async Question Is More Nuanced Than Expected

The loudest opinion in engineering circles: "Just go async." Slack bots, daily threads, automated check-ins. One global finance team described by Slack saved over 60 hours a week by replacing live standups with Workflow Builder automations.

Sounds like a clear win. In practice, it depends on the team.

A former Google engineer noted on LinkedIn that async standups worked well across multiple timezones and geolocations. The team created a daily thread — what they planned to do or what they completed. Social pressure and accountability remained. Flexibility increased.

But async fails when teams use it as "fire and forget." Posting an update nobody reads is worse than a bad standup. At least a bad standup forces eye contact.

When async works

• Distributed teams across 3+ timezones.
• Deep-focus roles like data engineering, where interruptions destroy flow.
• Teams with strong written communication habits.

When sync still wins

• New teams building trust. Psychological safety forms faster face-to-face.
• Teams handling live incidents or fast-moving sprints.
• Groups where blockers require immediate discussion, not a Slack thread that sits for hours.

The Format Problem Nobody Fixes

The classic three questions — what did you do, what will you do, any blockers — have been the default for decades. For many teams, they stopped being useful long ago.

Sigma Computing suggests replacing them with prompts that surface real information:

• "What assumptions are you testing right now?"
• "Is the data reliable?"
• "What decision is blocked waiting on your work?"

These prompts force substance. "I worked on the pipeline" tells the team nothing. "I'm testing whether the revenue numbers diverge after the schema migration" tells them everything.

Key point: the format of the standup matters more than whether it happens live or async. Bad questions produce bad answers in any medium.

Size Kills Standups Faster Than Anything Else

According to Plane.so, smaller standup meetings stay faster and more focused. They encourage honest discussion and make it easier to spot dependencies. When attendance grows beyond the core team, conversations lose focus and updates become irrelevant.

Tested in production: teams above 8 people almost always drift into status broadcasting. The meeting becomes a monologue chain. Nobody listens to updates that do not affect their own work.

The fix is straightforward. If someone's presence does not change how the team works that day, they do not need to attend. Stakeholders who want visibility can read the async summary.

The Tools Landscape Is Crowded but Shallow

Dozens of async standup tools exist: Geekbot, DailyBot, Standuply, Range, Steady. Each solves a slightly different problem.

For pure standup automation in Slack, Geekbot and DailyBot handle the basics. For agile ceremony support, Standuply integrates with Jira and offers more structure. For teams wanting check-ins plus goal tracking and AI-generated summaries, Steady covers the widest surface area with SOC 2 Type 2 compliance.

Common mistake: reaching for a tool before fixing the process. As Marissa Goldberg writes, tools should make something that already works more efficient. If standups are broken, a bot will not fix them. It will automate the dysfunction.

What the Conversations Actually Revealed

The most surprising pattern from talking to engineers and founders was not about format or tooling. It was about honesty.

Teams where people openly say "I'm stuck" or "I have no idea how to approach this" — those teams get value from standups regardless of format. Teams where people perform confidence and pad updates with filler — those teams waste everyone's time regardless of format.

The NASA study confirms this: the practice can be adjusted and improved to empower teams, but only when the underlying culture supports vulnerability.

Founders had a different surprise. Several admitted they kept standups because they felt anxious without them — not because the team needed them. Removing the meeting felt like losing control. The standup was solving the founder's problem, not the team's.

Try It

Pick one standup this week and replace the three classic questions with these two:

1. "What is the riskiest thing on your plate right now?"
2. "What do you need from someone else on this team today?"

Run it for five days. Compare the quality of conversation to the previous format. If it works — it is correct. No framework required.