Remote != Async
A mistake most people do when working remote is thinking that async work is necessary and should be applied to everything: this is a costly mistake.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
🔄 Remote work means "not in the same physical location", being sync or async is an orthogonal decision.
⚖️ Sync and async work each come with their trade-offs, but sync work is aligned with the Lean principle of optimizing the whole.
👨💻 Teamwork and faster feedback loops are fundamental in product software development, and being a team implies most work is done in sync.
🌐 While it’s always true that every team needs to find a good balance for itself, they also need to be aware of the trade-off caused by their choices, and going async makes no exception to this.
Remote ≠ Async
When we think of remote work, we often associate it with asynchronous communication—emails, chat messages, or task updates that can be answered whenever it’s convenient. But here’s the kicker: remote work does not automatically mean async work.
Remote work simply means "not in the same physical location". It does not dictate whether a team should work synchronously or asynchronously. These are two completely separate decisions. You could work in an office and still operate asynchronously by using tools like email or Slack, with team members working in isolation and rarely meeting face-to-face. On the flip side, a remote team can be highly synchronous, with regular stand-ups, pair programming sessions, and live collaboration, leveraging video calls, live documents, and real-time feedback.
So, why is this distinction important? It’s because sync and async work each come with their own trade-offs.
Sync vs. Async: Pros and Cons
Synchronous work—working in real-time with your team—enables rapid decision-making, faster feedback loops, and a sense of camaraderie that can be hard to replicate asynchronously. It’s particularly beneficial in software development, where live discussions, quick problem-solving, and shared understanding are crucial for team success.
However, synchronous work can sometimes feel like a non-stop marathon of meetings, causing burnout and reducing deep focus time.
Asynchronous work, on the other hand, allows for greater flexibility and uninterrupted deep work. You get more time to think and solve complex problems without distractions. But there are also downsides: it slows decision-making, causes miscommunication, and creates feelings of isolation.
Teamwork in Software Development
Here’s where it gets interesting. Software development is most effective when treated as a team sport—not a collection of isolated “individual contributors.” We need collaboration, real-time problem-solving, and continuous feedback loops to build better software faster. We need collective ownership.
XP, Lean, Agile and DevOps principles emphasize "optimizing the whole" rather than optimizing for individual productivity. Techniques like continuous integration, trunk-based development, and practices like mob programming, thrive in environments where synchronous communication is the norm and ensures a better outcome for the team and the business. The synergy that comes from working together, even remotely, is essential to delivering high-quality software.
Remote Doesn’t Have to Be Async
Just because your team is remote, it doesn’t mean you have to adopt an entirely asynchronous workflow. You can have the best of both worlds: maintain the flexibility of remote work while keeping the benefits of synchronous collaboration. The key is to find a balance that works for your team and to consciously make that decision rather than defaulting to async just because you're not in the same place.
Before you default to a global async-first approach, consider the trade-offs: a hybrid approach can be effective, with my suggestion to be sync-first within the team, and async-first with any other internal/external teams (not departments!).
Within the team, make sure to make it explicit when async becomes an option, for example:
gather inputs for brainstorming or retrospective
simple code changes where all the team members fully agree on the solution
manual documentation and or adding tests to non-covered code
Remember: remote and async are orthogonal choices, not inevitable companions.
Until next time, happy coding! 🤓👩💻👨💻