Jordan Lee
Most standups are a waste of time. Not because the format is broken, but because nobody ever taught the team what it’s actually for.
You might be wondering if that’s too harsh. I don’t think it is. I’ve sat through hundreds of these meetings across AAA studios and my own indie projects, and the pattern is painfully consistent: someone reads a task list out loud, a few people zone out on Slack, and everyone leaves without a single blocker resolved. The meeting ends, and nothing changes. That’s not a standup. That’s a status report with worse chairs.
Here’s what I tell people when they’re setting up standups for the first time, or fixing ones that have stopped working: the meeting exists for one reason. Blockers. Everything else is a bonus.
What Game Dev Standups Are Actually For
Games are made by specialists working in parallel. Your animator needs something from your technical artist who’s waiting on a shader from your programmer who’s blocked on a design decision that nobody’s made yet. That’s a completely ordinary Tuesday in game development, and if you don’t surface that chain in the morning, you lose a full day.
The standup is your daily circuit check. You’re not updating management. You’re not building accountability through public confession of what you did yesterday. You’re asking: is anyone about to hit a wall, and can we prevent that right now?
That reframe matters enormously for how you run the meeting. Once the team understands that the goal is unblocking (not reporting), the energy shifts. People start listening to each other instead of rehearsing their own update.
The Format That Actually Works
Forget the classic “what I did, what I’m doing, what’s blocking me” if your team has more than eight people. Past that size, the third-person status updates become noise. Nobody remembers what the character artist said by the time you get to the engine programmer.
Here’s what I’ve landed on after a lot of trial and error:
Keep it under fifteen minutes, hard. Set a timer if you have to. Fifteen minutes is not a soft target. When you let it slip to twenty-five “just this once,” you’ve permanently trained the team that the end time is negotiable. It isn’t.
Run it standing up, but don’t be precious about it. If your team is remote, being on camera is the equivalent. The point of standing is that physical discomfort creates a social contract to be brief. On a call, the camera does some of that work.
The actual format I use: go around the team fast, and each person answers one question: “What do you need from someone else today, or are you good?” That’s it. If someone’s good, great. If someone needs something, that’s the conversation you’re there to have. You can post yesterday’s progress in your task board (Linear, Jira, Shortcut, whatever you’re using) the night before. Don’t eat meeting time with information that can be written down.
Blockers get flagged immediately and the right people are pulled into a quick sidebar after standup. Not during. That’s the other discipline that makes standups work: you identify the issue in the meeting, you solve it outside. “Let’s take that offline” is not corporate cowardice. It’s respecting the nine other people standing there who don’t need to watch two engineers debug a shader graph.
Running Standups When Your Team Is Mid-Sprint (and Stressed)
Codecks -- Game Development Project Management Tool · Gamefromscratch on YouTube
This is where things get real. Sprint crunch, milestone pressure, a publisher build due Friday. Standups get skipped first, then when they do happen, they spiral into anxious status meetings where everyone’s performing calm they don’t feel.
Don’t skip them. Shorten them. Five minutes is a real standup. The higher the pressure, the more important it is to know who’s stuck.
During crunch periods, I add one question at the start of the week: “Is anyone at risk of not hitting their Friday deliverable?” Not as a gotcha. As a genuine early warning. One of the worst things I ever did as a producer was let a team grind quietly toward a missed milestone because nobody felt safe saying they were behind in standup. That’s a culture problem, but standup is where the symptom shows up first. If people aren’t being honest, that’s the real issue to solve.
Psychological safety in daily meetings is worth more than any project management tool you’ll ever buy. I mean that literally.
The Standup Killers
A few things that seem harmless and will quietly destroy your standup’s usefulness:
Letting the same person talk the longest every day. Usually a lead or senior dev. It trains the team that their updates matter less. Rotate the facilitation role if you have to. Even a junior artist running standup for a week changes the dynamic noticeably.
Running standups right after a long Slack thread. If the team already processed something in a channel, don’t re-litigate it in standup. The meeting is for things that haven’t been resolved, not recap theater.
Not having a task board everyone can see during the meeting. I’ve used Jira, Notion, Trello, and Shortcut across different projects. Doesn’t matter which one. What matters is having a shared visual reference so people are orienting around actual work state, not memory. Ideally a TV or shared screen with the sprint board open behind the person facilitating.
Missing standups without rescheduling them. This is the one I push hardest. A skipped standup is a day with no circuit check. One day is fine. Three days in a row and you’ve lost visibility on the sprint entirely.
Async Standups: Real Option or Productivity Theater?
Sources
- Ollie Craig
- with worse chairs
Here’s a take you might push back on: async standups are rarely as effective as people claim, especially for creative teams.
I know, the tools are good now. Geekbot costs $2.50 per user per month and integrates with Slack. Parabol is free for small teams. The prompts go out, people fill them in, and technically the information exists somewhere. But the reason real-time standups work is the friction and the social pressure to actually listen. When you can post your async update at 11 PM and nobody processes it until noon the next day, you’ve lost the blocker-surfacing function almost entirely. A blocker posted at midnight is half a day lost by the time anyone acts on it.
Async makes sense when your team is genuinely spread across five time zones with no viable overlap window. That’s real, and in that case, async is better than nothing by a lot. But if you have three or four hours of overlap and you’re doing async “because it’s more flexible,” you’re probably optimizing for individual comfort at the cost of team throughput.
Photo: Ollie Craig via Pexels
