Keeping product & engineering functions working smoothly and in sync with each other is difficult. Product people need a regular venue to communicate and discuss business and product requirements, which in most environments are constantly evolving, and engineering teams needs the time and space to do deep work without interruption.

Having worked with quite a few remote product/engineering teams now, my impression is that most remote product/engineering teams don't do regular enough high bandwidth communication, and do too much low bandwidth communication.

What's High bandwidth communication?

Real-time (synchronous) audio, video, facial expressions & body language, screen share. Large amounts of information exchanged per unit time. Great for discussion, brainstorming, clarifying, branching conversations, overcoming emotional obstacles, getting buy-in.

What's Low bandwidth communication?

Non-real-time (asynchronous), text-only. Small amounts of information exchanged per unit of time. Self-perpetuating and (with most modern chat tools) never ending (no clear "start and end point").

What this looks like

Imagine a chart that shows daily communication patterns per hour. In the majority of remote teams I've worked with, the communication patterns look something like this:

Under this setup, the default method of communication throughout the day is instant messenger, and chat channels serve as an ever-present digital water cooler. This creates the expectation that chat need to be open at all times, and heavily impairs the capacity for deep work.

A healthier chart looks more like this

In this setup, product and engineering have high bandwidth comms once each day, in the morning. If anything pops up in the mean time can be added to a document or tracker and discussed in detail at most 24 hours later.

The optimum interval for high-fidelity (face-to-face) feedback between planning (product) and execution (engineering) is 24 hours. Why?

Parkinson's Law says a given task will expand or contract to fill the time allotted to it. Checking in daily creates a habit of "Whatever we cover today will be revisited tomorrow". This doesn't always mean "We're going to have everything complete by tomorrow", but it does mean that by the end of a week, we'll have discussed and therefore actioned, more high priority work if we have 5 discussions than if we only meet once or don't meet at all.

Keeping chat-noise to a minimum is surprisingly difficult to do, but being intentional about it shows the dev team there's mutual understanding and establishes good will while at the same time as an expectation of output

Minimises Cost of Delay

Minimises Ad Hoc "Can we jump on a call?" requests, which are very disruptive.

The optimal amount of low bandwidth, instant-message communications (Slack etc) to exchange each day is almost-zero

• Destroys deep work -> This alone is argument enough.

• Expectation of Response: Different communication channels have different social expectations for when to expect a response. Letters -> Weeks. Email -> Days. Project Tracker -> Hours. DM -> Minutes. The common responses to this is "People just need to be intentionally protective of their time - it's their responsibility". But social norms are powerful. If I'm in a Slack where I can see all of my colleagues responding close-to-immediately, I'm going to find it very hard to be the one guy who is known to be "hard to reach" in the name of protecting my deep work time.

• Text, as a medium, is extremely limited: Takes a long time to type - language is scrutinised to much greater extent, emotions are difficult to convey.

• Infinite chat is close-to-ephemeral and not a good place for evergreen information.

• Creates expectation of management: Receiving a message isn't just about seeing it - it often requires follow up, particularly if you're busy/distracted. So you're often assigning a task with each message you send,

• Creates bad habits around storage and retrieval - put in project tracker vs "I mentioned in slack"