The most common mistakes made by async teams

Hello IH 👋

As a huge fan of working async and doing it for many years, I've seen how hard it can be. As time flies, I realise some tricks that were given to me by more experienced people are now habits and I happen to repeat those quite often to more junior people I work with.
I thought it might be interesting to go over those in a post, so here we are. 😄
Although it's often a required skill for experienced developers, it can still be worth reading for other positions as well 😉

We will rely on the following conversation to point out these mistakes (we assume they use async communication system such as Slack or Discord).

[Monday 9:15 AM] Alice - Intermediate Developer
Hey Bob! 👋 Eve asked me if we could change how the profile page is displayed for our non-paying customers, so we can show them the benefits of subscribing to our app. Can you take care of this, and if so, can you tell me how long before the change is ready to be pushed in production?
[Monday 9:20 AM] Bob - Junior Developer
Hey Alice! 👋 Sure thing. I think it should be quick, half-a-day of work should be enough, I'll tackle it this afternoon, I've got some free time. I'll ping you when it's ready to be reviewed and I guess we can go to production on Wednesday morning.
[Tuesday 5:45 PM] Eve - Product Manager
Hey Alice! Have you had the chance to look into the profile page change? 🙏
[Tuesday 6PM] Alice - Intermediate Developer
Hey Eve! Yes, sorry I've not come back to you. Bob should have been looking into it yesterday afternoon. I'll come back to him and update you once it's ready for you to checkout.
[Wednesday 9AM] Alice - Intermediate Developer
Hey Bob! Can you tell me if the profile page update is ready?
[Wednesday 10AM] Bob - Junior Developer
Hey Alice! Sorry for the delay, I've been scratching my head with a nasty bug for hours, but it should be ready soon...
_[Wednesday 10:15AM] Alice - Intermediate Developer
Alright, let me know if I can be of any help.
[Wednesday 3PM] Bob - Junior Developer
Hey Eve, Alice! I've just published in staging for you to test, I think it should be fine.
[Wednesday 4:30PM] Eve - Product Manager
Hey Bob! Thanks for reaching out, but this does not feel right. I've got some bugs in the app (white screen) and we should change behaviour X so we could do Y.
[Wednesday 5:30PM] Alice - Intermediate Developer
Hey Bob! I'll pull your code on my computer and make the relevant fix. Just look at the commit once I'm done. Eve, I'll try to make things right asap and come back to you.
[Wednesday 6PM] Eve - Product Manager
Alice, Bob, I'm actually in vacation starting tomorrow and be back in a week, so I'll take a look at that point.

Don't laugh. This has happened in every project I have ever worked on and you will probably encounter this situation someday if you haven't already.
Obviously, there is something wrong with the communication here as the change is not delivered as expected by the product team, but what is wrong exactly? Try to think about it before reading the answers below.

Mistake 1: Failing to communicate properly

This is a common one, and more likely the one that is the most made, even by more senior people in the industry. Communication is hard to do properly, so let's see what are the issues in this conversation (and there are plenty!).

Hey Bob! 👋 Eve asked me if we could change how the profile page is displayed for our non-paying customers, so we can show them the benefits of subscribing to our app.

Eve asked Alice for product change, whom turned to Bob. It would have been clearer to use a public channel for this and ask all developers directly. Everyone could have had the information, and synchronisation would have been automatic in the thread. Anyone with some availability would have answered Eve.

Can you take care of this, and if so, can you tell me how long before the change is ready to be pushed in production?

Alice is sharing the request from Eve to Bob. This is a bit too soon without more context on the task (deadline, product expectation, business impact). Before asking another developer to take the task, she should make sure she has all the necessary information so the work can be properly estimated and delivered. If not, she should ask for clarification.

I think it should be quick, half-a-day of work should be enough, I'll tackle it this afternoon, I've got some free time.

Bob is underestimating the task, and communicating about it. Bad communication is worse than no-communication. He should have asked for details before committed to a deadline, and tried to split the delivery and made intermediate review to make sure it would be on track.

Hey Alice! Have you had the chance to look into the profile page change? 🙏
Hey Bob! Can you tell me if the profile page update is ready?

Alice and Bob both make the same mistake here: not communicating soon enough on their progress. Eve and Alice had to pull the information, which requires Alice and Bob respectively to shift focus from what they were doing to answer on the clock so the task moves on. It's bad for their productivity, and leaves their teammates in the dark when they could have just push the information in the proper timeframe.

TL;DR:

Keep things public as much as possible. Avoid DMs as the information can be lost between multiple people.
Always make sure you've every important information before making a decision or shifting focus. Don't drop your current task each time someone ask you to do something else.
Don't overpromise when communicating on deliveries, either on deadlines or results. You need to assume
Make sure people don't have to pull information from you. Push them regular updates with progress and problems. Be careful of timeframe, and try to communicate in a relevant time. Too much communication is useless, not enough communication force people to pull and distract you from work.

Mistake 2: Failing to ask for help when stuck

Hey Alice! Sorry for the delay, I've been scratching my head on a nasty bug for hours, but it should be ready soon...

Bob says here that he has been scratching his head for hours, and that it should be ready soon, implying it's still not solved. Those are clear signals he is missing something and he should take a break and ask for help.

This mistake is often committed if you have a strong ego and the will to prove yourself to others (I know, I've been there, done that 😔).
Let the ego aside, and just ask for help, you will learn a lot both technically and humanly. No-one can possibly knows everything, and it's way simpler to ask for help than to just stay stuck in your task.
When the people answer you, make sure to grab not only the solution to your problem, but how the solution was found (mental model, knowledge area, etc).
Nobody should ever blame you for asking for help.

Mistake 3: Failing to take ownership

Can you take care of this, and if so, can you tell me how long before the change is ready to be pushed in production?

Ownership is a vague term, but here Alice is not taking ownership of the task as requested by Eve. Even though it's not required for Alice to do the job herself (owning != doing), it's her responsibility to make sure Bob is able to handle the task correctly. In the present situation, she has to ask Eve for more information so Bob does not feel overwhelmed by the request she is passing by.

Alright, let me know if I can be of any help.

Alice is clearly looking away from Bob hidden cry for help. Alice should own the task at hands, and proactively ask Bob to pair or look at the code so he feels okay to share his problems.
Passive way like that make less experienced people feel bad if they reach out to you. Make sure you're open to discussion and help, and keep things clear on how often/how long you can provide help so you're not always a safety net for the less experienced developer.

Hey Bob! I'll pull your code on my computer and make the relevant fix. Just look at the commit once I'm done. Eve, I'll try to make things right asap and come back to you.

Alice is taking over the work of Bob. It will probably make Bob feel bad for not solving the issue on his own, and also make things look like it's kinda important to solve fast. If Alice really owned the subject, she would have asked Bob for review-pairing and explains what was wrong in a positive manner. She would also ask Bob open-questions so he could challenge his work by himself.

As a general rule, you own a subject when:

you actively make sure the subject goes in the right direction (either by doing the work or making sure other people has everything they need to do it) in the right timeframe
you proactively help stakeholders and remove blockers from their path, but do not take over their work
you're aware of the implications and the impact of the subject on other department/business-area

Mistake 4: Failing to test what you've done

Hey Bob! Thanks for reaching out, but this does not feel right. I've got some bugs in the app (white screen) and we should change behaviour X so we could do Y.

Bob clearly didn't test his code enough before communicating. It's a common mistake, but quite deadly as it erodes in the team trust if it happens too often.
The important points in testing are:

Make sure the nominal use cases work fine
Make sure the app is recovering from unexpected behaviour (no white screen, black screen) on errors
Make sure the stakeholder is aware of any gaps before testing your implementation, to avoid bad surprises

Mistake 5: Be kind, write kind.

We often underestimate the power of written words, and we lack empathy when we are behind a keyboard. Words have power and can break people.
Obviously, you should never insult people and send them bad messages. But even when trying to do good, try to think on how people will react to your tone or choice of words.
For those interested in the topics, Josh Comeau's Code of Conduct is quite interesting and cover this area.

If you liked this post, you can follow me on Twitter and/or on IH as I share my journey building products 😊