How to Communicate Asynchronously with your Development Team – 8 Tips

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

1. Tip: Remember remote ≠ 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.

2. 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.

If you struggle with reorganizing your work in a no-office fashion, there is plenty of great literature on the subject. Remote and Rework from pioneers in the field might be especially helpful.

Remember that some data shows that working remotely is more efficient, even if you wish otherwise.

3. 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!

4. 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 2021?

5. Tip: Overcommunicate

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.

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, 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>”

6. 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.

7. 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.

Read also: What is Product Discovery in Mobile Application Development?

8. 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.

Related posts