Build Healthier Teams with Core Protocols

Communication is one of the biggest factors in a team's productivity. Turns out it has a much bigger impact on a team's success than individual performance of its team members [1]. In 2013 I was lucky enough to be in a workshop with Jim McCarthy where I learned about Core Protocols and how they can take a team's communication to the next level. Since then I couldn't stop being amazed by how powerful a tool it is. However, it took me a few years of practice to fully understand the potential it brings and here's why.

Let's start with the definitions. What is a protocol, after all? Collins Online Dictionary, for example, gives several meanings:

If you read between the lines, you can deduct some common logic behind all four. First, there are two or more sides participating in an exchange. Second, there's a set of rules. Then, there are some typical situations when the exchange happens. Finally, the sides agree to use the rules, while making an exchange, all during those typical situations. And that's exactly what Core Protocols are. It's a set of rules a team uses in their daily communication to make it easier and clearer. In practice, it takes the form of marker phrases. Whenever somebody says a marker phrase — a protocol is initiated and all the team members are expected to respond in a very specific way.

Here's an example. Say, you want to ask for feedback. The usual problem with asking for feedback is, the feedback they give you back is oftentimes plain useless. And it's not intentional — the other person just doesn't know what you expect from them. However, there's an easy way to improve this. Use Perfection Game, one of the Core Protocols. How does it work? You set it up by saying "Would you perfect this thing for me?" — and tell exactly what to perfect — "My presentation today. Can you rate it on the scale of 1 to 10?". The other person gets a clear marker that you've started a Perfection Game. They already know how to follow up: they rate your presentation on a scale of 1 to 10 and tell you what they liked about it. They also add a couple of suggestion about what you need to do in order to make it a 10. You've just saved a lot of time and received some valuable — and actionable — tips.

Some of the Protocols have gained specific popularity in the Agile community. Perfection Game seems to be everybody's favorite and pops up in blogs and articles quite often. Some others receive occasional attention too. But Core Protocols are rarely discussed as a whole.

Indeed, many of them can be used as mere facilitation techniques — and it's a good starting point for an inexperienced or skeptical team. However, there's much more to Core Protocols than just this. Core Protocols have much more profound goals than simply helping run regular meetings. The expected effects include[2]:

1. Closer interpersonal connection.
2. More efficient collective decision making and related accountability distribution.
3. Better team and personal alignment.
4. Achievement of a shared vision.

A team that applies Core Protocols systematically can expect to fundamentally change its way of communication and ultimately its culture.

I like to think about Core Protocols as of a way to 'preprogram' people to react to common (possibly unpleasant) situations in a healthier way. What do I mean by that? A lot of the problems in communication occur because of our own perception. Emotions are caused not by the external events that are actually happening but rather by a person's own beliefs, especially irrational beliefs [3]. With Core Protocols you can rewire the circuit by making a team agree on how they are supposed to react when push comes to shove.

A good example is the Check Out protocol. The idea behind it is simple. Any person may leave any activity if they feel that they can't participate anymore. Reasons can be different: not adding value to the activity, tired and falling asleep, too emotionally charged to continue, and so on. Simply leaving the room would offend people because common belief is, it's impolite. Especially so, if a person leaves in frustration. Check Out provides a graceful way out of this. It allows a team to agree: anyone has the right say "I check out" and walk out of the room. So, when this actually happens, everybody knows how to react and that they are not supposed to blame the person and or question their reasons. In exchange, the 'quitter' promises not to make a fuss out of it and commits to rejoining the team as soon as they can. In a sense, by agreeing to use Check Out team members replace the traditional belief (it's impolite) with a new one (it's expected, it's how we communicate).

Another thing that makes Core Protocols so powerful is how they are designed. Each protocol is phrased very carefully. Every phrase tries to nudge towards constructive and concrete results. Let's take Decider and Resolution for example. Together they form a simple voting mechanism. It starts with a person stating a proposal followed by an invitation to vote ("one-two-three"). The voters can choose from "Yes", "No", or "Support It" (there's also an "Absolute No" which is essentially a veto but let's leave it for now). The proposal passes if there are enough "Yes's" and no "No's". If there are "No's" but not too many, they can be resolved with Resolution. The proposer asks the group "What can I do to get you in?" Take a close look at the phrasing. It deliberately directs the possible response to suggesting an improvement or an alternative. It leaves no room for complaining or pointless rambling. Compare it to asking "Why didn't you like my proposal?"

Okay, but what if the team doesn't buy the idea in the first place? I've heard a lot of times how Core Protocols make communication too mechanical. I've also seen people not being comfortable enough with how Core Protocols made them open up before their teammates. First of all, with the chart above you can tailor the protocols to the team's level of readiness. But then, if you still expect a lot of pushback, just don't tell them what it is. Start using the protocols yourself without explaining them. Let the team learn by doing. You may even change the wording slightly to make it sound more natural and less protocol-ish. For instance, you may start checking in to each meeting or running Deciders without telling. When you see that the team starts getting used to a protocol, explain and add another one. Hopefully, after a while, you will be able to introduce Core Protocols formally. But even if not, it shouldn't be a problem because you can stay undercover like this indefinitely and still get a lot of value.

Core Protocols are a part of my starter kit for new teams (more on that in future posts) and I think that it's the best time best to introduce Core Protocols. The sooner they'll start the sooner they'll learn. Also, supposedly, it should help a team overcome the storming phase faster because they will have more open and constructive communication. However, nothing prevents you from starting with the protocols even in existing teams.
I like to introduce Core Protocols in a short session, usually 1.5 hours. I start by explaining what Core Protocols are and how the team will benefit from them. Next, I let the team read through Core Commitments — this is the foundation of Core Protocols, a list of statements somewhat similar to Agile Manifesto a team commits to follow. Once the commitment is formed, we quickly go over each protocol and I explain the mechanics. Many protocols can be confusing when you see them for the first time, so it's crucial to provide examples. In the end, I run a Decider voting to get the agreement about using Core Protocols. If the team agrees, you are good to go. If the idea doesn't get full support, together with the team I tailor the set of protocols as described above. And of course, it's totally fine if the team rejects it altogether. It's extremely important that Core Protocols are only used when there are motivation and acceptance.
The next few weeks I allow the team to learn by doing and make sure that they get enough coaching in the usage of the protocols. I like this format because in a work environment it's oftentimes not so easy to carve out time for a full-size training. However, if you have the possibility to have a proper training, always go for a training.