Good meetings is very much about achieving deep collaboration. But collaboration is often hard. We go into meetings with different modes, intentions, and expectations. How can we make meetings both more fun and energetic? Surprisingly enough: maybe by being more formalized.
In software and in diplomacy its natural to work with and think about protocols. Using pre scripted and formalized ways of interacting makes it easier to cooperate. When someone acts in a specific way I do not have to guess about the intentions (and in worse case guess wrong) when we use a protocol. My pre understanding of the protocol makes me know what is going on, and how I am supposed to act.
At Crisp we use a couple of protocols to support our distributed and decentralized organisation. I have often thought that flat, self-organizing, decentralized organizations ought to use more protocols to help fostering collaboration and cooperation. A number of years ago Michele and Jim McCarthy summarized their experiences of working with successful teams in what they call the Core Protocols.
The Core Protocols is not only about meetings, but I think it applies specifically good to meetings. And you don’t need to bring them all in at once. A few month ago I attended a meetup in San Francisco where Richard Kasperowski presented the core protocols more as a protocol stack. I knew about the Core Protocols since before, but clustering them in a stack made it so much easier to understand and apply the protocols.
Inspired by the event I started introducing Core Protocols in at Spotify squad in San Francisco. We have been using a few of the base layer protocols during our retrospectives, and I think it has helped us becoming more present during our meeting. It also help in creating a language to talk about what we expect from a meeting and from each other.
The Core Protocols consists of 11 protocols. Kasperowski has clustered the protocols in a stack, where the lowest level is actually not so much a protocol as a cultural attitude (transportation layer): he calls it positive bias. On top of that are 4 layers that cover basic needs: the need of not feeling coerced, the need of self awareness, the need to connect to others and be heard and the need to achieve result together. There’s also an exception handler: protocol check.
Just bringing in the two first levels is enough to give focus to your meetings: when you are in a meeting you will have a positive attitude and you are there of free will. At any time you can pass on an exercise or leave the meeting by doing a “Check out”. No one will question you. This mean you are expected to always be mentally present in any meeting that uses the Core Protocols. Even having just a discussion about these protocol deepens a groups sense of how they want and expect their meetings to be.
Given the recent published studies from Google on successful teams (members are good at “social sensivity”) the next protocol level is like the perfect match: doing a Check-in by telling how you are actually feeling right now. You learn to acknowledge your self and you learn to accept that we have feelings and that we carry them with us in the meetings.
What does a good meeting look like? Is it when you get to state your point of view? Or is it when you understand others point of views? Do you need to go to a meeting to understand your own point of view?
The next layer in the stack is just about this: having a way of listening deeply to others and connecting by asking both for others intent (instead of inferring meaning on your own) and do dare to be vulnerable by asking for help. Intentionally practicing Investigate and Ask for help helps a group add practices to their meetings that help them connect.
What are meetings for? Meetings in a work context are of course most often there to achieve result. You want to be present and connect to others, but most importantly, you want to achieve result. Level 5 in the stack contains two protocols that help with that: Decider (a protocol for checking unanimity) and Resolution (a way of getting people to support a proposition by including their views).
The Decider and Resolution protocols are a subset of making decisions by consensus and consent. If you as a group are not used to make consensus decisions it might be a good idea to start with the D&R way, to strengthen your decisions. Consent and consensus often requires more practicing together to get it right (in the end it’s worth it, but that’s another story).
(Investigate, Ask for help, Decider and Resolution will help you with the other core aspect of successful teams Google has identified: members speak “in roughly the same proportion”.)
And last but not least, the Perfection game is about improving your way of working (or actually whatever) in a fast and positive way.
If you think a protocol is not followed correctly or when it should: make a Protocol check.
It’s not much more complicated than this to start using the Core Protocols. I have, however, also create a workshop you can run in an hour to bootstrap discussions around and usage of the Core Protocols. It should be more or less self explanatory. If not, get in touch.
Here’s the presentation you can use to run the workshop.
I co-wrote an article for methods and tools about the core a few years ago: http://www.methodsandtools.com/archive/archive.php?id=106
Thanks for sharing Yves!
Yes, we need to follow some core protocols to make our meetings effective. Most people in organization think only about collaboration but not about productivity. If they successfully collaborate their team for meeting, then they think that meeting is successful. But what i suggest is everyone should target for productivity. However i enjoyed your article and thank you very much for sharing.