David Guttman, author of The Superstruct Manifesto, says daily standups may seem harmless, but they’re disrupting the deep focus developers need to do their best work.
Cal Newport is a smart guy. There’s a reason why his book Deep Work is so popular. Uninterrupted time blocks of deep work are crucial for getting important work done, especially for software engineers. Every single meeting that you put on a dev’s calendar is a giant hole with a “NO DEEP WORK” sign in front of it.
It’s even worse than that. The size of those holes isn’t limited to the start and stop of each meeting. Depending on the placement of those meetings, those holes can extend well beyond the start and end times.
This is why I recommend that founders stop doing daily standups. What should they do instead? They should use async text chat like Slack or Teams. This approach has loads of advantages, but I’ve written about that elsewhere, in The Superstruct Manifesto and it’s not the focus of this article.
The focus here is to address the main objection I get from people about async standups.
When I talk to people about eliminating daily standups and suggest using async chat as an alternative, I am often met with shock. I hear complaints like “Nobody can be productive with constant pings and notifications!” or “Our Slack is already bad. It would only get worse if we didn’t have a daily standup each morning!”
I know it sounds crazy, but hear me out.
Your team can be productive using async chat as its primary method of communication. If you remove the disruption caused by a synchronous daily standup (or other recurring meetings), you do not automatically incur a larger interruption cost from notifications and long chat threads. Devs don’t have to be distracted by pings and notifications. You can balance necessary collaboration and communication with valuable focus and deep work.
Deep work is a non-negotiable requirement for software engineers. It takes time to get started, to build momentum, and to model a system in your mind. Interruptions cost developers by taking them out of that mode of thought.
It’s like working at the bottom of the ocean. You have to check your tanks, put on your scuba gear, get all of your equipment together, and slowly descend. Once you’re down there, you can be productive. If you are called back up to the surface, it will be a while before you can get back down to the ocean floor and return to a productive state.
This “ocean floor productivity” is flow state. It’s where developers are at their best, and for many, it’s where they are happiest. This is where they create enduring value for the business: features, fixes, documentation, tests, etc. It’s difficult to do any of these well without full attention and focus.
The main argument against async communication is the fear of constant notifications breaking focus. But that only happens if developers don’t manage their notifications effectively. Here’s how to make async communication work:
Clear Communication: For non-urgent issues, a simple message like, “I’ll get back to you at 2 p.m.,” is enough to manage expectations without breaking focus.
Devs should either be in deep work mode or not. When they are in deep work mode, they should turn off all notifications and eliminate all distractions. Silence all alerts. Close all tabs that aren’t relevant to work. Nothing should get through.
Then, once an hour, developers should check their messages and notifications. If something is on fire and needs their immediate attention, they should attend to it. But normally, this is not the case.
For non-urgent requests, devs can respond in a way that minimizes disruption to flow and gives the requestor a solid idea of when they will get their resolution. For example, “I’m finishing something up right now, but I will get back to you at 2 p.m.”
In my experience, exceedingly few things would be negatively impacted by a response time of an hour. Devs do not need to be “on call.”
If you’re looking for a structured framework to help developers maximize deep work while balancing collaboration, the Pomodoro Technique is the way to go.
This approach works because it breaks work into manageable sprints, maintaining focus without burnout. It also allows developers to check notifications at predictable intervals, reducing the anxiety of constant pings.
The biggest challenge in adopting this approach is leadership’s resistance to change. To succeed, leaders must:
If you’re skeptical about replacing daily standups with async communication, try it for two weeks. You’ll likely see an increase in deep work and developer productivity. You’ll prove to yourself that uninterrupted focus is the key to achieving flow state.
If this sounds easy, it’s because it is. In fact, the only likely issues will come from leadership. Leaders need to be willing and able to set and reinforce boundaries. Two things should be made clear to everyone:
In my experience, people often have contradictory fears for their team. One is that devs are off in their individual silos, building without any regard to other team members or business needs. The other is that there is so much chatter and noise that nobody is getting anything done.
If these are your fears, run an experiment. I’m confident that neither fear will materialize. What you will see, however, is happier and more productive developers.
David Guttman is the author of The Superstruct Manifesto, a survival guide for Founders who depend on devs to get things done.
This article was written and submitted by an external contributor. Inference & Signals did not receive any payment or sponsorship in exchange for its publication. The views expressed are those of the author and do not necessarily reflect the official position of OpenTeams or Inference & Signals.
OpenTeams Partners with O-SAIF to Promote AI Safety and Transparency in U.S. Government. Discover how this partnership advocates for ethical, open-source AI to protect national security and public trust.
