After talking with me on the Dev Interrupted podcast about Asynchronous Communication for remote teams, Cate Huston (Director of Engineering at DuckDuckGo) joined the Dev Interrupted discord community to answer some frequently asked questions.

(The exerts below came from the Friday Community AMA series hosted in the Dev Interrupted discord community for dev leaders. You can join the community here.)

Q: How does Asyc Comm create a more inclusive work environment?

Great question. A few things stand out:

– People can respond as they have time – this levels the playing field across timezones (and life commitments).

– People can think before they respond – better for those who don’t like to be put on the spot.

– It’s self documenting. So many benefits here, but two: 1) no-one has to “take notes” and 2) it’s much harder to give the wrong person credit for someone’s idea if it was there first in writing.

Q: You made a point during the podcast about the importance of having both a transient place (ex. slack) and a more permanent place(ex. Asana). Can you give an example of how you use each?

Totally. We use MM for our water cooler conversation, and short term coordination (e.g. looking for PR reviewers).

We use Asana for anything longer term and more important discussion – such as putting together project scopes, or discussing how to address a complex bug with varying options.

If the answer to “will this matter later?” is “yes”, then it should go in the more permanent place.

Q: We just started doing our Feature Review via Async. Do you have any tips for team members who are new to communicating asynchronously?

Totally it takes some getting used to, two things that help:

– framing the feedback and breaking it up – you don’t want detail feedback until the “thing” is structurally sound

– processing the feedback and coming back – the person requesting feedback needs to take the inputs, go through them all, and then come back saying they have done it and requesting the next round.

Q: What qualities have you found to be good indicators for people who thrive in a remote environment?

I’m a strong believer that how people take feedback is a predictor of coachability, and generally a good thing to consider in hiring. Some remote specific things are: good written communication, ability to ask for help, good work habits / self discipline.

Q: Do you run a daily stand-up with your team? If so, how does that work async?

🙈  not on my current team.

On my previous team, yes. We were using Slack, and we used a tool called Geekbot.

Everyone would get a ping when they logged on and answer:

– How they felt

– What they did yesterday

– What they hoped to do today

– Any blockers

Q: What is the biggest thing you think dev teams are getting wrong about remote work right now?

I think they have just shifted their regular work online, and missed the opportunity to reinvent how they work across the board.

I understand doing that initially, I have so much empathy for the sudden shift to remote.

But even with the good news about vaccines, it’ll be late in 2021 at the earliest before we come back to “normal”. Now is a great time to start making changes to improve the way things are.

This is the time to get rid of all boring meetings!

Q: When is a synchronous meeting needed?

When it’s contentious 😜

Synchronous meetings are great for arguments

Q: How do you know when to expect arguments?

When people have strong opinions, when there’s no clear right answer, when the stakes are high.

Synchronous meetings are also good for team bonding, not every meeting has to be an argument.

I think the main thing is where there is nuance that is going to be lacking in text based communication. So, anytime when how people feel is important.

Q: Can you give an example of a good synchronous meeting?

Sprint planning. Because most sprint planning is pretty boring. If everyone agrees, it is dull.

The real value of sprint planning is where people disagree.

So you can break that kind of meeting up, do the boring bit in tech, and then have the more interesting part of the conversation synchronously.

Cutting a 2h meeting to <1 hour is a huge win.

Q: What tips do you have for helping new hires feel welcome and engaged in an distributed, async team?

I break it into: belonging and accomplishment.

Accomplishment is easy – people want to feel like they are contributing.

Belonging is harder, it’s making people feel welcome and psychologically safe.

On our team we do “experiments”, and one of our things is that the previous new hire has to do an experiment for the next new hire.

It generally involves coordinating something across the whole team. Examples so far:

– Having a 1:1 with everyone on the team.

– Putting together a piece of advice for the new hire, one from each member of the team.

– Putting together a list of projects that are good to learn from (about process, the way we run things, or just generally), each person on the team suggested one.

Everyone also gets an “onboarding buddy”, whose job it is to foster a sense of accomplishment on the new hires first project.

Overall I think it’s really important that the team see onboarding a new hire as a collective responsibility.