The daily standup is the most common meeting in tech—and the most commonly butchered. At companies like Amazon, Google, and Meta, standups are surgical: 15 minutes, standing up, and everyone walks away knowing exactly what’s happening. In most Thai companies, “standups” are 45-minute seated discussions where the loudest person talks the most. The difference isn’t culture. It’s discipline.
We’ve run standups at Amazon, Google, Robinhood Markets, Databricks, Meta, and OpenAI. Here’s what actually works—and how to adapt it for teams in Thailand.
What a Standup Actually Is
The standup originated in Agile and Scrum methodology, but the best teams have evolved it far beyond any textbook definition. The original idea was simple: get everyone standing in a circle so the meeting stays short. That physical constraint forced brevity. The principle behind it is what matters.
A standup is an alignment meeting, not a status report. The goal is to ensure every person on the team knows what’s moving, what’s stuck, and where help is needed. That’s it. If your standup doesn’t achieve those three things, it’s not a standup—it’s a waste of time.
The classic format uses three questions:
- What did you do yesterday? — Context for the team, not a performance review.
- What will you do today? — Signals intent so others can coordinate.
- What’s blocking you? — The most important question. This is where the value lives.
The timebox is non-negotiable: 15 minutes max. If you can’t cover it in 15 minutes, your team is either too large or your meeting is doing too much. No exceptions.
How the Best Teams Run Them
The pattern across top-performing engineering teams is remarkably consistent. Here’s how it plays out in practice.
Amazon
Amazon’s writing culture extends to standups. Teams often start with a brief written memo—a few bullet points per person pushed to a shared document before the meeting. The synchronous time is reserved for discussing blockers and dependencies. Status is consumed asynchronously. The meeting is for decisions, not information transfer.
Google’s distributed teams leaned heavily into async standup tools long before remote work was mainstream. Engineers post updates in shared channels or tools, and sync meetings only happen when there’s something that requires real-time discussion. Many teams run sync standups two or three times a week instead of daily—supplemented by async updates on off days.
Stripe
Stripe takes written communication to the extreme. Updates live in shared docs. Standup meetings are reserved almost exclusively for cross-team dependencies—the kind of problems that can’t be resolved by a single team in isolation. If your blocker is within your own team, you handle it in your team’s async channel, not in a meeting.
The Pattern
Across all of these companies, the principle is the same: minimize synchronous time, maximize written context. Written updates are searchable, referenceable, and don’t require everyone to be in the same room at the same time. The sync meeting exists to handle the things that writing can’t—real-time negotiation, unblocking, and rapid decision-making.
Why Thai Standups Go Wrong
We’ve worked with dozens of Thai engineering teams. The failure modes are consistent and predictable.
Seniority dynamics kill participation. In Thai culture, junior team members defer to senior colleagues. This is deeply ingrained and not inherently bad—but in a standup, it’s fatal. If your junior engineer is blocked but won’t speak up because the tech lead is in the room, the standup has failed its primary purpose. The blocker stays hidden. The sprint slips.
Standups become planning sessions. The “meeting about the meeting” problem. Someone raises a blocker, and instead of noting it for a follow-up, the entire team spends 20 minutes trying to solve it on the spot. Now your 15-minute standup is a 45-minute architecture discussion that half the team doesn’t need to attend.
No timeboxing. Meetings expand to fill available time. If you book a 30-minute slot for standup, it will take 30 minutes. If you book an hour, it will take an hour. Without a hard stop, standups drift.
Status reporting to the boss. This is the most common anti-pattern. The standup becomes a performance review where each person reports upward to the manager instead of across to the team. The manager asks follow-up questions. The rest of the team checks their phones. Alignment goes to zero.
The Fix: A Framework That Works in Thailand
You don’t need to fight the culture. You need to design the process so the culture works for you, not against you. Here’s the framework we use with every team we build and train.
- Async-first updates. Every team member posts a written update before the meeting—Slack, Notion, or whatever your team already uses. Three bullet points: done, doing, blocked. This takes 2 minutes and eliminates the need for status reporting in the meeting.
- Sync meeting: 15 minutes, blockers only. The meeting starts with a quick scan of the async updates. Discussion focuses exclusively on blockers and cross-person dependencies. If it’s not blocked, it doesn’t need airtime.
- Round-robin format. Go around the room in a fixed order. Everyone speaks. No one gets skipped. This neutralizes the seniority dynamic—the most junior engineer gets the same time and space as the tech lead. It’s structural equality.
- Rotate the facilitator weekly. The person running the standup changes every week. This builds ownership across the team and prevents the meeting from becoming “the manager’s meeting.” When a junior engineer facilitates, the power dynamic shifts.
- Use a “parking lot.” Any topic that needs more than 2 minutes of discussion gets written on the parking lot—a list of follow-up items. Schedule those conversations separately with only the people who need to be there. This keeps the standup surgical.
This framework works because it doesn’t ask anyone to behave differently in the moment. The async update gives junior engineers a safe, low-pressure way to flag blockers. The round-robin format removes the social cost of speaking up. The rotating facilitator distributes authority. The structure does the heavy lifting so the people don’t have to.
The Tools
Teams overthink tooling. The tool matters far less than the habit. That said, here’s what works.
- Slack + a standup bot. Tools like Geekbot or Standup.ly automate the async update collection. The bot pings each team member at a set time, collects their three bullet points, and posts a summary to a channel. Zero-effort async updates.
- Notion or Google Docs. For teams that prefer longer-form updates or want a searchable history. A simple shared doc with a running log works surprisingly well. The key is that it’s written, shared, and accessible before the meeting.
- Linear, Jira, or your project tracker. The standup should reference what “done” actually means. Link your updates to tickets. This creates accountability and makes it easy to verify progress without asking “what did you mean by that?”
Pick tools your team already uses. The worst thing you can do is introduce a new tool just for standups—it adds friction and kills adoption. If your team lives in Slack, use Slack. If they’re in Notion, use Notion. The habit matters more than the tool.
The best engineering teams in the world don’t have better tools or smarter people. They have better habits. The daily standup is where those habits start—15 minutes that set the tone for how your team communicates, collaborates, and ships.
Get the standup right, and you’ve built the foundation for everything else. Get it wrong, and you’ve trained your team to tolerate meetings that waste their time. Every single day.
Start tomorrow. Post async updates. Timebox to 15 minutes. Go round-robin. And actually stand up.