Calm things down with communication protocols

Summary
Without a set of communication protocols in place, your team will fall prey to a hyperactive hivemind workflow. You'll reinvent your workflow for every new piece of work. Instead, spend some time on establishing some collaboration norms on the team.

1. Show your workflow transparently on your task board. Everyone should know in a single view what the team is upto. Define ownership for each stage of the workflow and design for the best average cost and not the worst case.
2. Make your task board the primary hub for communication. Email and IM should be for external and interdepartmental communication first, general team communication next, and task based communication only as an exception.
3. Adopt a consent-based decision making process instead of trying a consensus-based or democratic decision making approach every time. This'll help you default to action, while improving the overall pace and quality of decisions.
4. Agree on response times and reply expectations for each channel. Without these expectations in place, people will suffer from FOMO and you'll risk becoming an ASAP culture.

Before you start tweaking individual practices on your team, you need to zoom out and examine your work and communication protocols. We all value “self-organising teams” and “autonomy” at work. However, self-organising and autonomy are also terms we misunderstand. You don’t want to tell a skilled developer how to code a certain requirement. If two developers are pairing on a problem or a developer and designer are figuring out a solution, you want to trust their skills. Smart people expect that once they understand a problem, they’ll have the freedom to figure out solutions. This is what Cal Newport refers to as “work execution”.

Newport distinguishes work execution from “workflows”. Workflows define how we:

• find and prioritise work; 

• assign it to people;

• communicate about it;

• coordinate it;

• and review it.

Teams that don’t agree on a workflow, end up reinventing it each time they execute work. This is not just wasteful, but it also makes communication ineffective. One of the reasons the office can be an ineffective place to work, is what Jason Fried calls M&Ms - i.e. meetings and managers. Don’t get me wrong. We need effective meetings and we sure do need proper managers. While I say this, I’m sure many of you agree that our meetings aren’t always effective or even necessary. And managers can often be more a hindrance than help. 

In most cases if you dig deep, you’ll realise that the root cause for these problems is a poorly designed workflow or even a non-existent one. Of course, this leads to frequent, inefficient, back and forth communication which in turn translates into lots of interruptions leading to a fragmented workday. Instead of fixing the workflow, teams find themselves with a bloated managerial layer so there’s someone who can make sense of all this communication. Before you know it, you’re in a “how many techies does it take to screw in a light bulb” situation. 

When teams go remote, they find themselves wading into another trap. I call this “office on the cloud”. This happens when you mimic the workflow of the office or the absence of it, using communication tools like email, instant messaging, and video conferencing. Before you know it, you’re using fast, cheap communication systems to worsen all the problems I just mentioned. You become victims of what Newport calls the “hyperactive hive mind”. Always connected, always interrupted. 

Efficient teams need efficient workflows and protocols, so they collaborate and communicate in a predictable fashion. So, in this post I want to share with you a few fundamentals you need in place, so you avoid the hyperactive hive mind.

Revisit your workflow statuses and transitions

If you’re working on a remote team, you most likely have a task board in place. It doesn’t matter whether you use Jira, Trello, Asana, or another tool. Most project management tools allow you to define a workflow for your team and visualise that workflow as a task board. For the uninitiated, the workflow could be as simple as the table below.

Workflow stage	Description
To do	The backlog of work; sorted in descending order of priority.
Analysis	Tasks that the product owner is analysing so they’re ready for a developer to pick up.
Dev	The list of tasks that developers are currently working on.
Test	Tasks that developers have written code for which a QA (quality assurance analyst) is testing.
UAT	QA tested functionality that internal users are testing out.
Done	Tasks representing functionality that’s in production and/or meets the definition of done.

Your workflow may look similar or different or even more complex. The number of stages doesn’t matter as much as the principles of setting up the workflow. 

1. Represent every stage of your process on the task board. Often, teams don’t show their informal or shadow gate checks in the workflow. This creates a few problems. One, you can’t really tell what’s really happening with a task by just looking at the task board. Second, you can’t gather data on where tasks get stuck. For example, if an undocumented desk check stage causes stories to stay in development for too long and you have no data about this, how will you ever make the process more efficient?

2. Define primary ownership for each stage. For example, your product owner or business analyst is responsible to flesh out the tasks in the “analysis” lane. Developers handle stories in the “dev” lane. Testers pick up items in the “test” lane. Of course, every team member can roll up their sleeves and help in case tasks are stuck in a specific lane, but you need to be clear about primary responsibilities. 

3. Optionally, spell out the rules to transition between stages. Not all tools allow you to do this. If your project management tool has such functionality, consider using it in the interest of a disciplined workflow. For example, you may want a tester to log all user feedback when transitioning tasks out of the UAT stage. In such cases, you can set up the workflow to nudge the tester, if only to remind them about this step. Effective workflows try to remove errors by oversight. This isn’t micro-management. It’s a helpful nudge.

When you revisit your workflow be careful not to design for the exceptions and worst-case scenarios. If you do this, you risk creating unnecessary gate checks in your process to cover for small risks. This is the kind of risk averseness that makes a user story go through six different meetings before it hits production. That kind of workflow is more fragile than agile. Optimise your process for flow and avoid creating bottlenecks. 

Make email and IM secondary communication tools

Your task board should be the source of truth for all the work your team is up to. Most times the team must communicate about work in progress. And if so, that communication should happen in the context of work. Almost every task board out there allows you to have conversations inside a task. You can tag people on the team to get their attention on the task and if you’re interested in updates about a specific task, most tools allow you to “watch” it, so you get updates about it.

When you make your task board the primary communication interface for the team, you’ll gain two huge advantages.

1. You only have one place to track communication about work in progress. The tools allow you to be specific in how you choose to communicate. For example, you can set up the tool to generate notifications only for the tasks you’ve signed up for and the tasks you’re watching. 

2. Every task has an audit log attached to it in the form of contextual conversations. Anyone can look at a card, examine its details - i.e., the description, attachments and comments and know what’s happening with it. You don’t need a manager to keep asking people about updates.

 What about email and instant messaging then? I suggest making them secondary tools. Use them for external or inter-departmental communication first and general internal communication next. If your chat conversations take any more five minutes or five back and forth messages, then you’re probably using the tool for the wrong purpose. Some companies remove their entire IM history every few weeks, to discourage people from placing permanent, referenceable information there. Modern IM tools like Twist do away with presence indicators and notifications, so people can use it without feeling like they must respond ASAP. 

Knowledge workers spend way too much time checking email and IM. The average worker can’t go more than 6 minutes before switching to one of these tools. Think about the cost of those interruptions and how deep work becomes a casualty. You don’t have to change your entire toolset. Just avoid the ASAP mindset these tools promote and give people the safety to know that it’s ok to check email or IM once or twice a day.

Streamline your decision-making process

When teams don’t have a standard decision-making process, every decision can be chaotic. Everyone wants to be involved in every decision, work slows down, you end up with too many meetings and communication overload, and the team often ends up with a risk-averse attitude. This is what Seth Godin calls “thrashing”, i.e. “the apparently productive brainstorming and tweaking we do for a project as it develops.”

Before I go on, let me admit that some decisions benefit from a democratic or consensus based decision making approach. However, as Aviva Pinchas of Parabol says, “All decisions are not spicy,”. Today, with the sophistication of continuous delivery, most decisions are reversible. While that’s no reason to make bad decisions, it’s certainly a good reason to simplify decision making. We want to default to action whenever possible. 

So instead of trying to get everyone to agree on every decision, adopt a consent based decision making process as your default. Consent implies “the absence of objections”. Here’s how an asynchronous consensus-based decision-making process could work.

1. A team member writes up a proposal in a shared document or a wiki page, for the decision they want to make. They also write down a time by which they expect to hear back from everyone else. There shouldn’t be a false sense of urgency to this timeline.

2. People have the chance to respond to the proposal. They do so through inline comments, or questions. This is also the time to raise objections if any.

3. The proposer can then incorporate suggestions and amend the proposal if necessary. 

4. If there are no major objections after this, the decision goes through, otherwise people can get onto a meeting and sort things out. 

With a writing focussed, asynchronous, consent-based decision-making process, you can avoid wanting to be perfect all the time and settle for “good enough”. You get to slow down everyone’s thought process, so the proposer is deliberate about what they’re suggesting. Everyone else just needs to think about whether they have any objections or just suggestions. On balance you’ll make more decisions than if you were to take a consensus-based approach. 

Jeff Bezos

“Some decisions are consequential and irreversible or nearly irreversible one-way doors (Type 1 decisions). If you walk through and don't like what you see on the other side, you can't get back to where you were before. But most decisions are changeable, reversible - they're two-way doors (Type 2 decisions). You can reopen the door and go back through. As organisations get larger, there seems to be a tendency to use the heavyweight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.”

Channels and response times

Last, but certainly not the least, you must agree on response times for various collaboration tools and channels that you use. Thanks to James Stanier for the original version of this. Be mindful that this is just a sensible default - so use your judgement when implementing this protocol on your team. Just be mindful of the following principle.

Urgent is overrated. ASAP is toxic. Keeping someone blocked though, is insensitive. 

Medium	Length	Reply expected	Reply time	After hours?
Phone call	Short	Yes	Immediate	Yes
Text message	Short	Mostly	Hours	No
Chat	Short	Mostly	Hours	No
Video call	Medium	Yes	Immediate	No
Email	Medium	Not always	Days	No
Recorded audio/ video	Medium	No	N/A	N/A
Written document	Long	Not always	Days	No
Task board	Variable	Not always	Variable	No
Wiki	Variable	N/A	N/A	N/A

---

The work you put into setting up your workflow, decision making process and communication protocols may seem pedantic to start with. I assure you that you’ll see the payoff in a calmer, more thoughtful team environment. This serves as the foundation for every practice you tweak on your team. 

 So go ahead, align your team to these new communication protocols. Once you’re done, head on to the next section of this website where I help you improve team collaboration, practice by practice.