Jazz hands for great meetings

When grownups have meetings, they tend to have grownup meetings.
When developers have meetings, they tend to just talk at each other for a while until they get bored.

A grown up meeting
In a grownup meeting, there’s a chairperson who decides who talks when,  what topic are covered, and in what order. There’s an agenda, with a list of topics to be covered which are agreed in advance, and approved by all parties. Speakers are given a fixed time to say their piece, and keep to the schedule. At the end of the meeting, there’s a summary for all parties.

There’s organised, structured, and directed debate. Things get tabled, decided, and we move on.

On the other hand, there’s not a lot of room for creativity. That idea you had half way through will need to be scheduled for next quarter’s gathering, or dumped into “any other business” alongside the people who just wanted to say a thing after sitting in silence for two hours of process.

An engineering meeting
In an engineering meeting, we set a vague topic “what the hell are we going to do about tech debt in the inter service flux capacitor bridging engine?”. We set vague roles, “Brian sent the invite, so I guess he’s going to do the talking”. We decide who talks next by waiting for the speaker to stop for air, or talking over each other, or making an “erm…” noise. We talk as fast as we can, without taking a breath, lest someone else get a word in before we finish our thought.

We’re all trying to think about complex problems, trying to express them before they slip from our minds, all the while we’re trying to do the fuzzy human interaction thing too.

If we’re good, we’re trying our best to wait our turn to speak, and to make sure we stay on topic, and to make sure we’re listening to those who speak more quietly or less forcefully than others.

All of this communication overhead can get to be a bit much. It’s icky, sticky, human interaction nonsense. The cost of this is a loss of time, a loss of ideas, and a culture of “he who speaks loudest, speaks most”. A culture where the boldest, brashest voices raise up, and the quieter ones are pushed down.

The he in the last paragraph is not accidental. It tends to be men that thrive in this environment. Women, for complex out of scope sociological reasons are often perceived negatively when they speak up, in comparison to their male coworkers. This pushes them down a path of only speaking when spoken to, or hoping someone else raises their point for them. This is a massive issue, and leads to companies, and teams, losing out on knowledge and expertise because we struggle to get our stupid human brains to treat others based on what they can do, instead of what they are.

Ok, let’s work the problem
This is a blog post for engineers, so let’s treat this as an engineering problem.

We have a system where a common bus is used to broadcast information to all hosts, simultaneous transmission is not possible [we are all in the same room, and talking audibly]. Any node can broadcast to all hosts at any time [this is called talking]. Each host has information that needs to be shared with all other hosts [ideas, questions]. No host knows with certainty what any other host knows.

What we need here is some flow control.

So the solution I’m proposing here, and it’s not a new or original idea, but one I stole from a high performing team I once had the pleasure of working with, who stole it from a protest movement, who stole it from a religious group. The idea is to use a non verbal communication channel, to coordinate the verbal channel.

Yeah, that’s right, and I’m talking about jazz hands.

The occupy movement had the same problem. They needed to gather consensus and agree on the best way to move forward without formal leadership. They stole a system of hand signals, from the quakers.

I’m not going to go into the whole system, as that’s better handled by a wikipedia article, but it’s eight hand signs, for feelings and coordination.

These eight signals seem a little overkill for our needs, so we’re going to reduce it down to as smaller set as possible.

 

Agreement

In my experience, the most important signal for keeping meeting as short as possible, is “Agree”, or “Upward Jazz hands”. It expresses slightly more than just “I agree with what the speaker is saying”, but “I agree with what the speaker is saying, and they can stop trying to convince me”.

With a rapid hand shaking, you can express and eagerness to move on, or frustration at the pace.

 

I have a thought on this

Secondly, it’s the direct response pointy finger. Simply pointing at the speaker indicated you have something to say on this topic, and the speaker should pass the torch briefly to you at the next opportunity, while expecting it back shortly after.

By doing this, you can allow the speaker to decide when the best time for you to interrupt is, and avoid you talking over them when they’re halfway through making a point. You’ll often find that by allowing the speaker to finish their thought, or complete their sentence your question, point of interest, or additional information is covered, and you can simply drop your finger as what you were going to say becomes less relevant, or important.

What, just these two? I thought you were going to change the world?

Like good code, simplicity is generally better than the alternative. We kind of all know how to communicate ideas, and how to decide things as a group. We’re not trying to solve “conversation”, we’re trying to provide a simple technique to avoid a meeting where everyone talks over everyone else, and where the way to be heard is to talk over people.

We’re not trying to change the world, we’re just trying to get out of meetings faster.

If you’re interested in a talk about the same thing, the wonderful Ryan Alexander did a whole talk on this at the lead developer.

Image credit xadrian.