PRODUCTHEAD: Async working and communication

product police

---

tl;dr

Async working lets you set aside time for deep thinking

Forced remote working led naturally to more async work

Async relies on three main tenets: multiplexing, communication and action

Find the right balance between flexibility and cohesion, independence and togetherness

In-person time is important to sustain the human relationships that enable you to get work done

---

a favour: please share this with other product people

every PRODUCTHEAD edition is online for you to refer back to

hello

We’ve just finished up a project for Prolific (a company that lets you run a research study with participants matching your desired criteria). The unique feature of this project was that Prolific is async.

If you’re not familiar with the concept, ‘async’ means ‘asynchronous working’ in this context. Despite working with plenty of organisations who encourage remote working, this was the first time I’d come across a company declaring its intent to be async by default.

It took me a little while to get my head around the idea, but as I’ve thought more about it, working async makes a great deal of sense, particular when coupled with remote working practices (although it doesn’t need to be).

What is async? #

Simply put, async means working and communicating in a way that is not reliant on other people being available at the same time as you are. This allows people to do their work at a time that comes naturally to each of them. If nothing else, this makes it much easier for team members to work remotely, and / or from different time zones, or just to work more flexibly around personal commitments.

Async appeals to me. I’ve never been a fan of the kind of large meetings where the attendance list is more governed by office politics than necessity. In the past I’ve attempted to discourage these by displaying a running tally of the cost of the meeting, based on the salaries and day rates of the attendees. That tended to keep things quick and focused.

What? Never meeting up again? #

I do think there will always be occasions where you need to be in a room with people at the same time. My view is that these situations fall into two categories: difficult stuff (performance, disciplinary, firing) and celebratory stuff: async socialising is just drinking alone, and that’s not a good look. For everything else, async will probably work just fine.

And when you do decide to get together in person, you’ve rightly got to appreciate the preciousness and value of that opportunity and make the best use of that time.

How does async work in practice? #

Imagine you wanted to solicit the views of a group of people. Instead of pulling everyone into a (virtual) room for a meeting at a specific time, you could let people contribute in their own time to a collaborative document or virtual whiteboard.

Or instead of attending a daily stand-up each day, each team member could record and upload a quick, daily video of themselves answering the 3 traditional questions. (What was I doing yesterday? What am I doing today? Could you help me unblock X?) The rest of the team could then watch them when convenient and respond if needed.

Even things like retrospectives could be tweaked relatively easily to work async, although these might fall into the categories of being difficult or celebratory, meaning sometimes a synchronous meeting is a more appropriate option.

Prior planning and preparation #

How does async change the planning a preparation needed to collaborate? I suppose that if you wanted a group to do a task, then synthesize the findings and feed them into a second task, you’d probably need to do this as separate rounds, rather than as one big, joined-up exercise.

I would also guess you’d need to put more thought into the guidance you design up-front. You’d need to help people understand what you’re asking them to do and provide the necessary context without being there in person to provide it. Otherwise I can imagine the participants becoming bamboozled, rather like when you return to a console game months after you last played it and your muscle memory has vanished.

But if that forces you to think more clearly about what you’re trying to achieve before asking people to devote time and effort to help you do so, then that’s only to the benefit. There’s nothing more frustrating than giving up time to attend a meeting for which the organiser is woefully under-prepared.

Not necessarily a time-saver #

While I do think that async is more accommodating to individuals’ working patterns (and that’s reason enough for trying it out), I don’t think it necessarily saves a huge amount of time in the long run.

My suspicion is that at least some of the time saved by eradicating unnecessary meetings, phone calls and synchronous Slacking will be lost again while waiting for people to get around to contributing asynchronously (although timeboxing would help with this). And that’s assuming we can all overcome the urge to interrupt our own flow every 5 minutes to check whether anyone’s updated anything.

Procrastinators of the world, unite! #

I also reckon that some people are going to be more comfortable with async than others. There’s the self-organising aspect to consider.

My sense is that async relies on individuals being responsible and disciplined enough to work in a focused way through a growing list of things at a reasonable rate, in an appropriate order.

I can’t speak for other procrastinators, but async sounds to me as if it would run the risk of overloading the already-fragile coping strategies I have for getting anything done. Feeling like I have more things to work through can trigger my sense of being overwhelmed, at which point I get nothing done.¹

In its defence, async doesn’t necessarily change the amount of work to do, it’s just more relaxed about when it gets done.

Tell me about your experience #

This week I have gathered you some articles to give you the inside track on organisations successfully working async, and what they’ve learned by doing so.

Are you working async? Drop me a reply to tell me how you’re finding it and to share your tips.

Speak to you soon,

Jock

---

---

what to think about this week

How asynchronous communication could change your workday

More of us are working different hours than our colleagues, reducing our real-time communication. Will it stay this way?

More autonomy, but more responsibility

[BRYAN LUFKIN / BBC]

Going async — a case study

In March 2020 we all left the office. From then on everybody was working remotely. We expected the transition to be rather smooth, but it wasn’t. The devil is always in the details.

Try something, change something

[BJÖRN ROCHEL / XING]

---

---

Why you should be working asynchronously in 2022

Asynchronous (async) work is a way for workers to organize the order in which tasks are executed to align with their own timetable. In asynchronous work, communication is not expected to be immediate, meaning workers can fine-tune work to reduce pressure on themselves and their colleagues.

Always default to action

[MARCELO LEBRE / REMOTE]

Four lessons learned after a year of asynchronous work

When the pandemic started, we made the decision to go remote. We’ve been a fully remote company for almost two years now, and it’s turned out to be one of the best decisions we’ve made. It kick-started a major international hiring spree, let us bypass the present IT talent shortage and, most importantly, put systems in place to make asynchronous work our norm. The latter has done wonders for our productivity as a company, and I believe this truly is the future of work.

Treat synced time like the gem it is

[NICK USTINOV / FORBES]

Remote product management: challenges and opportunities

Even though more and more companies are getting comfortable with remote work, the field of product management still seems to push back against this trend quite forcefully. There is a general sense that product managers can’t do the things they need to do unless they are physically located with their teams. This has some ironic consequences, such as that Slack — a company that builds a tool “where work happens” — doesn’t hire remote employees.

We don’t hate meetings, we just value focused work

[RIAN VAN DER MERWE / MEDIUM]

recent posts

Sorting the signal from the noise — a guide to fact-checking

One of the most important, and arguably hardest jobs we have as product managers is to work with our team to sift through information, read between the lines, and verify what is fact and what is merely opinion.

Who can you trust?

[I MANAGE PRODUCTS]

Start building a community of practice with the 3 minute challenge

When you start out as a head of product (or product director or VP product), you’ll probably need to create a community of product people. In this latest entry for my series of 100 things I’ve learned about product management, I share my advice to help you get the ball rolling with your own community of practice.

The first step is to turn up

[I MANAGE PRODUCTS]

Should a growth product manager even be a thing?

There’s an ongoing debate about generalist product managers versus emerging product manager specialisms (such as ‘growth product manager’). I think there is room in our profession for both. Let me explain.

“No one wants to get rich slow”

[I MANAGE PRODUCTS]

upcoming talks and events

5-6th April 2022

Product-Led Festival #

The Product-Led Festival is back. 🎉

Join us on April 5-6 for 20+ hours of captivating content from 30+ of the best in product, including:

🎙 Airbnb – Group Product Manager
🎙 Monzo – Senior Product Manager
🎙 wefox – Chief Product Officer
🎙 MyFitnessPal – Senior Product Manager
🎙 GitLab – Group Product Manager
🎙 Zoom – Senior Product Manager

There’s no better place to connect with product trailblazers, take away invaluable insights and build long-lasting professional relationships. 🤝

Subscribers get 20% off an Access All Areas pass, just use PROD20 at checkout 💸

Grab your pass 👉

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from … *time passes* … *I’ll get to this bit later*.