How to Communicate Asynchronously with your Development Team – 8 Tips
8 battle-tested tips on improving asynchronous communication with your offshore app development team.
Are you wondering how to communicate asynchronously in an effective way? Welcome to our discussion about asynchronous communication between the App Owner and the Development Team.
In the previous article – Communication with your Remote Dev Team – Introduction for App Owners – we’ve explained what asynchronous communication means, what benefits it brings, and when it’s worth to be asynchronous.
In this post, we will focus on how to make asynchronous communication with your offshore Development Team effective. Below you’ll find advice on different levels of abstractions: mindset-related advice, dos and don’ts, as well as more technical tips.
8 tips on how to communicate asynchronously in an effective way
Tip: Remember remote doesn’t mean asynchronous
We need to carefully differentiate remote from asynchronous. The former means cross-location contact. Asynchronous, the latter, means decoupling the sending and reading of messages.
Remote doesn’t automatically mean asynchronous. If your team is remote, but you constantly require meetings in order to see the progress, this isn’t asynchronous. If you allow your team to show their progress when they feel it is best (eg. record a video with a presentation), and you watch the videos at your most convenient time, this is asynchronous.
In 2020, lots of teams and companies were forced to be remote. But they will only achieve success if they also switch to asynchronous. Learn more basics about asynchronous communication.
Tip: Don’t try to mimic the office
You may be used to working in the office; chances are you haven’t worked differently in your career. If you want efficient asynchronous communication, you may need to change your habits. For example, when working in an office, if you want to announce an important message, it’s pretty straightforward to have a meeting, invite everybody and make a speech. In the async world, a message on email or Slack should be enough.
After switching to remote, you may miss your everyday chit-chat in the kitchen with your coworkers. In the asynchronous world, you can still achieve it, only in an asynchronous fashion. Instead of nagging whoever is currently available, you can create a Slack channel titled “random” and encourage people to drop a message whenever they have a little time. Remember, not everyday at 12, but whenever they feel like and if they feel like it.
Remember that some data shows that working remotely is more efficient, even if you wish otherwise.
Tip: Don’t expect immediate answers
This is probably the hardest habit to break. In the office, you are used to getting immediate answers – you can call a meeting, or you can go straight to somebody’s desk.
Remember that, in an asynchronous world, you allow other people to acknowledge your messages at a time convenient to them. Expecting immediate answers is a common mistake to avoid when developing a mobile app with a remote team.
Simply put – you allow the team to close Slack. In exchange, you get two things:
- you can close Slack as well 🙂
- the other side must respond to messages regularly. At least once a day, but typically it’s several times a day. Only then will asynchronous communication will work. Remember that you should respond regularly as well!
Tip: Avoid meetings
Another tip on how to communicate asynchronously with your Development Team is about avoiding meetings. In my experience, that’s another habit that’s hard to break. Working in the office, it’s extremely obvious for some people to communicate by meetings. A new requirement from a client? Let’s refine it in a meeting. Team rotation? Let’s make a meeting. My work is hard? I’ll tell you about it in a daily meeting.
In reality, meetings are often a waste of time and energy, not bringing enough to the table even if some people wish it. Yet half-remote, half-onsite meetings tend to be particularly painful.
This is not to say that you shouldn’t make meetings at all! There are occasions where a meeting is the best medium. However, in my experience, sticking to asynchronous communication is enough in most cases.
Before making a meeting, you should ask yourself about the goal of it. If you can achieve the same goal without making a meeting, that would be a great win in terms of communication. Believe me. If not, well, it happens – but at least try to make your meetings better. In the next article in this series, you’ll find a whole section about better meetings.
Finally and perhaps most importantly, asynchronous communication is usually much cheaper than having a meeting. A meeting 1 hour long for 8 people costs you: 1 hour x 8 = 1 man-day, in exchange giving you often no more than false consensus. Read also: How Much Does it Cost to Develop a Mobile App in 2020?
A message that hasn’t been sent, has no chance to be received. In contrast, if you send one message twice, and some receive it twice, there’s not much hurt. A simple conclusion – everybody should send more messages, or at the very least, not hold them back if they hesitate.
Overcommunication can happen on many levels. You can send:
- more messages
- more information in a message
- to more receivers
- the same information multiple times
Generally, you should encourage your team to communicate more, rather than less. If you are afraid of being “spammed”, then think twice. Maybe you need more communication channels (eg. Slack channels)? Maybe you need some standards on what to send and where? Maybe you need a document (a single source of truth) rather than a stream of Slack messages on some particular subjects?
Pro tip: if you want to increase your overcommunication is to send a quick message with a link, whenever you change a single source of truth. It doesn’t have to contain all the information – that is kept in the other place. But people don’t keep track of that place every second, so such information may be extremely useful, even if is kind of redundant:
“Hey, I’ve just changed the requirements files – added a bunch of acceptance criteria to feature X. Please let me know what you think – <link>”
Tip: Provide a link
That’s an example of “overcommunicating” that I often find to be very useful, but lacking in frequent use. If you are talking about something on the Internet, provide a link to it immediately. Other people can quickly see what you are talking about, read more details if needed, etc. It’s very simple yet also very handy.
Tip: Make everything public
The IT world is complex and every Dev Team is cross-functional by nature. Therefore, its members need much information for their work. If the information is missing, it can mean the whole app development process for a person or even the whole team can be blocked. Because of one little piece of information that somebody forgot to pass!
Regardless of the missing information being blocking or not, it’s always time-consuming or even annoying, if you need to ask somebody for permission. In general, it’s very unpredictable when somebody needs access.
The solution to this problem would be to have everything public to everybody. In my experience, this is rarely the case. Unless your project is in a very top-secret area (such as with the government), you should give your team every piece of information that can possibly help them understand the product – such as the requirements, prototypes, historical discussions, and user feedback.
At the same time, the Dev Team should not hide anything on a technical level – like the code, documentation, or infrastructure, all of which should be public within the team.
Tip: Communicate directly
In the previous article, we explained what Scrum Team is, and who is who in this team – read about it here. You, as a Product Owner, may be onsite, but it’s likely that the Dev Team and Scrum Master are remote. It’s tempting to treat the SM as some kind of “mother” to the Dev Team and talk to the latter through the former, rather than directly. Please don’t do that. It’s worth to communicate with the whole team directly.
On the other hand, the PO should expect their team to talk to them directly as well.
In other words, you should eliminate middlemen in communication, because they can add noise.
However, remember that in the previous chapter we learned to communicate publicly. This means that you should avoid private messages. Aim for public channels (eg. non-private Slack channels) and as wide an audience as is needed.
How to communicate asynchronously – takeaways
That was the short guide on how to communicate asynchronously with your offshore Development Team. I hope you enjoyed yourself and have tons of ideas. To sum up:
In the next article, you’ll learn how to improve your communication skills, regardless of whether it’s synchronous or asynchronous. Read also: Outsourcing Software Development – Benefits & Risks for App Owners.