Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Replaced Standups With Async Daily Updates
Transcript
- Lucas: So I recently talked to a CTO at a 200-person SaaS company who did something that sounds deceptively simple. He eliminated daily standup meetings entirely — replaced them with an async update that takes each engineer about two minutes to write. Luna: Okay, but haven't we heard this before? Async standups have been a thing for a while. What was different about his approach? Lucas: Fair question. The difference was the format and the enforcement. He didn't just say 'post your standup in Slack.' He built a lightweight bot that runs at the same time every morning — 9:15 AM, team by team — and asks exactly three questions. And the questions aren't 'what did you do yesterday, what will you do today, what blockers.' They're different. Luna: Alright, I'll bite. What are the three questions? Lucas: Question one: 'What's one thing you completed yesterday that moved a priority forward?' Question two: 'What's the one thing you're starting today that has the highest uncertainty?' And question three: 'Is there anything you need from someone else to unblock you — and if so, who and by when?' Luna: I like the uncertainty question. That's not standard. But how does that replace the coordination that a live standup is supposed to provide? Lucas: That's the key insight. He argued that most standups aren't really about coordination — they're status reporting disguised as coordination. People rattle off what they did, everyone nods, and the real coordination happens in the hallway or in DMs afterward. So he designed the async format to surface exactly the coordination signals. The bot also auto-tags anyone mentioned in the 'need from someone else' field, and it posts a summary in a channel that includes all unblocker items that haven't been resolved. Luna: So it's not just async — it's structured to force accountability on dependencies. That's clever. Lucas: Right. And the results were pretty concrete. After three months, they measured a 20 percent drop in mean time to resolve incidents. The CTO's theory: engineers were no longer saving non-critical questions for the next standup. They posted them in the async update, the right person saw it within minutes, and the conversation happened immediately instead of being delayed by up to 24 hours. Luna: Wait — 20 percent? That's a big number for just changing how you do standups. Did they control for other factors? Lucas: They did. They looked at the previous six months' incident data, and also at a control team that didn't adopt the async format until later. The improvement held. Now, correlation isn't causation, but the qualitative feedback from engineers was strong — people said they felt less interrupted because they weren't rushing to a 10 AM meeting, and they got more deep work done in the morning. Luna: I can see that. The classic problem with daily standups is that they break the morning flow. You get in, check email, then at 9:30 you have to context-switch to a meeting that's often not that useful. Lucas: Exactly. And this CTO was pretty blunt about it — he said 'the standup is the single worst meeting in most engineering orgs, and nobody has the courage to kill it because it's sacred in agile dogma.' He wanted to prove that the ritual could be replaced without losing the benefits. Luna: But here's the question I always have with async standups: what about teams that are colocated, or teams that are new and still building trust? Doesn't the live interaction serve a social function? Lucas: He actually addressed that. He said the social function is real, but you can separate it from the status function. His teams still have a weekly 'coffee sync' that's purely social — no agenda, no updates. And for new hires, they do a daily sync for the first two weeks, then transition to async. The key is not to let the async system become a cold, transactional bulletin board. Luna: That makes sense. I've talked to other CTOs who tried async standups and it failed because people just stopped reading each other's updates. Did they have that problem? Lucas: They did at first. The bot posts in a channel, and some people ignored it. So they added a lightweight accountability mechanism: each team has a rotating 'daily reader' whose job is to skim all updates and flag anything that needs a follow-up. It's a two-minute role per day, and it ensures someone is paying attention. That alone increased readership from about 40 percent to over 90 percent. Luna: A rotating reader — that's a smart human-scale solution. A lot of async standup tooling tries to solve this with analytics dashboards and read receipts, but having a real person do a quick scan feels more natural. Lucas: Totally. And the CTO was adamant that the tool should be stupid simple. They started with a bot that just posts a form in Slack, and they didn't add any features for months. He said the temptation is to build a dashboard that shows who has posted, who hasn't, what the trends are — but that starts to feel like surveillance. Keeping it minimal made adoption easier. Luna: If today's tech conversation gave you something usable, a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, listener support is what keeps us ad-free and focused on real stories like this one. Appreciate it. Luna: Back to the async standup — one thing I'm curious about is the team size limit. Does this work for a 10-person team? What about a 100-person team? Lucas: Good question. The CTO said their teams are typically 6 to 9 people, and it works well at that size. For larger teams, they split into sub-teams with their own bot channels. But he warned that if you have a team of 15 or more doing async updates in one channel, the signal to noise ratio drops fast — you get overwhelmed reading 15 updates every morning. So the structure forces you to keep teams small, which is probably healthy anyway. Luna: What about teams that are highly interdependent — like a platform team that supports multiple product teams? They might need more real-time coordination. Lucas: He actually used that as an example. The platform team kept their daily sync because they had a lot of handoffs. But they changed the format: instead of everyone going around, they used a Kanban board with a 5-minute huddle to review bottlenecks. So it wasn't a standup — it was a focused flow review. He's not dogmatic about async; he's dogmatic about not wasting time on status updates. Luna: That's the key distinction. The problem isn't the meeting format — it's the status-reporting culture. If you can separate coordination from reporting, you can design the right ritual. Lucas: Exactly. And he gave a great example of an antipattern he saw at another company that tried to copy their system. They mandated async updates but kept the daily standup meeting as well. So engineers had to do both — which is worse than just having the standup. The double burden killed adoption. Luna: Oh that's brutal. You'd end up with people copy-pasting their async update into the standup, which is the worst of both worlds. Lucas: Right. So his rule: if you adopt async standups, you must cancel the synchronous standup entirely. No hybrid. You can have other meetings — like the weekly social sync or the Kanban huddle — but you can't have both a daily meeting and a daily async update. That's just redundancy. Luna: One more thing — how did they handle people who just didn't post? Was there any enforcement? Lucas: Initially, no enforcement. Just a gentle nudge from the bot after 30 minutes. But they found that about 10 percent of engineers consistently didn't post. When the CTO dug into it, the reasons were usually: they felt their work was too fragmented to summarize, or they didn't see the value. So they did two things: they made the questions more specific, like the 'highest uncertainty' question — which forced people to think rather than just list tasks. And for the holdouts, the team lead had a one-on-one conversation to understand the resistance. In most cases, it turned out the person was already over-communicating in other channels, so the async update felt duplicative. They gave those people an opt-out, with the condition that they had to be reachable via DM for unblocker questions. Luna: So the system had flexibility. That's important — a rigid async mandate can feel like a straightjacket. Lucas: Absolutely. The goal is better coordination, not compliance. And I think that's the takeaway: the format is less important than the principle. If you're going to replace standups, do it with a clear hypothesis about what problem you're solving — and measure whether you actually solve it. Luna: That's a good note to end on. For anyone thinking about trying this, what's the first step? Lucas: Pick a single team that's willing to experiment for two weeks. Use a simple shared document or a Slack bot. Ask three questions that force prioritization and dependency disclosure. And most importantly, cancel the daily standup for that team. See if the world ends. Spoiler: it won't. Luna: I think a lot of teams could benefit from that experiment. Lucas: And if you try it, let us know how it goes. We'd love to hear your results. That's it for this episode of Tech Leadership with Fexingo. Thanks for listening.