Increasing developer efficiency with async communication
Writing quality code is an art, an art that requires periods of patience and focus. When working on complex code, a developer has to keep many things in their head, from requirements to low level state, and to get to that productive state it takes time.
Unfortunately for most, losing that focus doesn’t take much. Having to answer a quick Slack message, although it may take only a few seconds, can be enough of a context switch to impact efficiency.
Communication is vital between everyone in a team, but the way most organisations handle it does not work well for developers. The solution is asynchronous communication.
What is asynchronous communication?
Most online communication in an organization is done synchronously, which mirrors how we do in-person communication such as meetings. Synchronous communication is when you expect a response to your communication immediately.
Alternatively, asynchronous communication is expecting to get a response at some point in the future. For example, you send an email; I open and respond to the email several hours later.
For any developers, these concepts will sound very familiar as they are used as a way to describe how certain actions in code are handled.
Before we look at how we can move towards async communication we need to understand why synchronous communication has its downsides.
The problems with synchronous communication
While synchronous communication has many benefits and is something we do every day, it’s not the best form of communication for everything.
Working on a large team, with many people and many of those moving, it becomes hard to scale communication, especially for key individuals who have to be in communication with many different groups.
The advent of modern tools, such as email and chat apps, makes it easier but there is still a limit to the amount of real time chats a person can effectively manage.
Paired with the task of coding, a large amount of sync communications can cause a number of negative effects:
- Reduced development time: As I talked about in the intro, the context switching required to reply to messages further reduces the already limited amount of time developers have to focus on their tasks.
- Low quality code: Interrupted focus when working on complex code, paired with less development time, can lead to the introduction of bugs and vulnerabilities.
- Increased stress: Developers can become worried about managers thinking they are not working or missing out on important discussions if they don’t quickly react to messages. Stress can really impact concentration and focus.
- Rushed discussions result in bad solutions: When constraining discussions on an issue to relatively short real-time meetings / chat conversations, you reduce the amount of time for people to give well-considered and well-researched contributions.
An email notification can be just as distracting as someone walking over to you and starting a conversation.
How can async help?
Moving towards a more async process can have great benefits, both for a project and the developers.
Better developer experience
Developers are given time to do what they’re best at… writing code. They are saved from some of the juggling acts of delivering their work and being in constant communication.
They are given the space to tackle their work in a way they feel works best for them. This not only makes them more productive but also makes their day to day work more enjoyable.
Improved planning
Not only does async help improve the output from developers but it can also improve your planning.
Unlike sync communication, when working async you are not able to rely on last minute rushed chats to make decisions or ask questions. This forces you to plan ahead and ask the right questions enough in advance to allow for people to respond.
Example: It’s the first day of a sprint and you are doing sprint planning, but some of your stories are missing information. If you’re working synchronously, you may ask the relevant people to join to get the necessary information… In async you can’t ask them to join; you have to be planning ahead. Those questions should have been asked beforehand so the information was already available when it was needed.
The above example not only reduces the people needed for the planning session and reduces the risk if they’re not available but it also reduces the time needed for the session. This leaves more time for the team to work on stories.
Reduces points of failure
No matter how hard you try, it is very likely that there will be a number of key individuals that are necessary to answer certain questions or make certain decisions. In a larger organisation these people may be required in many different meetings, so if you need to have them in your sync meeting you’ll have to find a time that will work for them.
With an async process, people like that don’t become bottlenecks for others. Most questions they are needed for can be asked of them in a longer, well-thought-out question and they can then take their time to respond.
Better discussions
Unlike the rushed answers or replies of ‘I’d need to check on that’ that come from real-time meetings, async allows the participants in a discussion to properly think through their responses. It allows for time to do more in-depth research and to properly consider all elements of the discussion.
Balance between the two
Async is great and effective, but in reality you need a mix of both for optimum communication. These following are times when you should probably stick with sync communication most of the time:
- Back-and-forth discussions: Some discussions require a little more real-time communication to effectively argue your point or explain certain topics. Discussions that involve a lot of questions being asked can sometimes be done better in real-time. This kind of discussion would ideally be done as a precursor to something more formal.
- Final stage interviews: Determining if a potential employee is a good fit for a team is something that can’t be easily done without an informal person to person chat.
- Creative discussions: Creative and exploratory concepts can be hard to communicate through text.
- Sensitive topics: Certain discussions need a more personal side to them. Being given praise or informed about a promotion has much more impact when done in a personal way. (Side note: some sensitive discussions may make people uncomfortable and they may prefer it to not be in person or over the phone. Consider the individual person where possible.)
- Team building: Teams work better when they get along and enjoy working together. Hackerthons, meals out and other non-work events can be great for helping teams collaborate better and for mental health.
There also needs to be some structure around time to respond to a query, as it’s not practical to wait forever. A good idea would be to expect 48 hours to be a maximum expected time for a reply. This, alongside a system to determine priority, would work well.
How to implement async
Going async can seem like a daunting change, especially for very traditional organisations. Luckily, it can be incrementally adopted quite easily.
Basics
Start by being conscious of the amount of real-time communication that you are using to ask questions or have discussions. Each time you are about to use one of these, take a minute to think whether there is a way you can make this async. A couple of examples of this are:
- If you’re about to send a message to start a conversation regarding the status of a few stories, write one message asking all the questions you want answered instead.
- If you’re about to schedule a meeting and know you need some people just to answer a couple of questions, add those questions into the meeting notes instead so those people can add their responses and then are no longer required for the actual meeting.
Let your team know that regular questions from you do not need immediate replies, but work out a way to signal that a query is urgent. Slack and similar tools provide a way to mute notifications but still show them if the sender marks them as urgent.
Further adoption
To fully embrace async you will need to define a structured process for ways of working and communicating that can be easily referenced by anyone unsure whether they should use sync or async communication. As this is used, have constant feedback and look to see what areas are working well and which need further improvement.
Use tools such as issue, trackers, chat systems and email which have many great features to allow for async communication. Define the role that each plays in your process documentation and try to stick to it as closely as possible, flagging any need to diverge as a sticking point that needs improving.
Specific to developers
Encourage developers to block out time to focus on development or have a certain time of the day / sprint where you schedule most of the meetings that require developers to be involved.
If you work in teams, use your more senior / lead devs to be the representative for your team who can then pass the information on to the rest of the team.
Remote working
When combined with remote working, async unlocks even more amazing benefits. This is by no means a comprehensive list…
- Allows for developers to work at the time they feel the most productive. No more having to force yourself to fit into 9–5 work days.
- Enables more distribution . You can hire people from places that would normally have too much of a time difference.
- Lets developers easily fit work in alongside their personal life.
Conclusion
It can be hard to change people’s traditional ideas of ways to work and their processes but asynchronous communication can be a great way to improve productivity, especially when working with developers.
