Technical conversations are hard: a few loud people drone on, consensus is rarely reached, layers of paint are added to empty bike sheds.

Whether you’re trying to align people around a new architecture, a new team structure, or a new tool, even healthy teams can fall victim to these problems.

Some background

By now, you’ve probably heard of Conway’s Law:

An obvious paraphrasing of this makes it a bit more obvious

• “System designs will mirror the communication structure of the designers”

This rule has a number of implications, probably the most significant of which is that the structure of the product will follow the structure of the team, and vice versa.

Roughly, this means that:

• Good communication between people leads to
• Good communication between components, leads to
• Good interfaces,
• Good design,
• Good architecture

You get the idea.

“If you change how people connect, you change what they build, how they build it, and how they feel about building it.”

– Me, probably

What’s wrong with Technical Conversations?

The problems that come up with technical conversations are a special case of the problems that come up with groups of people, and the problems with scaling technical conversations are special cases of the problems with scaling groups of people:

• Some feel excluded and lose interest
• Some dominate the conversation
• Some accept that it’s easier to sit quietly
• New ideas are discouraged by groupthink
• Old assumptions become entrenched are left unquestioned

Intuitively, this should make sense.

How often have you tried to break into a group only to find yourself quietly ignored?

How often have you brought a great idea to a meeting and convinced everyone of its brilliance, only to later realize that the intern had noticed a major flaw but wasn’t given the opportunity to speak up?

About 15 years ago, I had been trying to understand why these problems kept happening, and over time, I realized that there had to be a better way. After trying a number of different approaches to this problem, one of the teams that I was leading faced a number of these problems in microcosm — strong voices, complex issues, passive but persuasive background players, the list goes on*. After one particularly difficult and unproductive session, we started talking about how we were having conversations. This was the stepping stone to the Apocalypse meeting.

I’ve taken the meeting format with me over the years, refining and improving as I went. It has been used — in one form or another — at many companies from enterprises to startups.

Let’s take a closer look at how Apocalypses work.

* The team was at Infobright — our product was a columnar database engine, based initially on MySQL

Apocalypses

Contrary to the colloquial use, an apocalypse is not catastrophic; it is a revelation

The guiding principals of apocalypses[0] are designed to encourage and unearth revelations:

1. They are lightweight — Anyone can easily and quickly spin up an apocalypse conversation
2. They are strictly time-boxed — This means that they predictable, easy to manage, and have clearly defined outcomes.
3. They are inclusive — They encourage — even force — each participant to take a turn speaking, even if only to ask questions.
4. They force people to listen — They force each participant to take a turn silently listening. Even the loudest voices are forced to slow down and pay attention.

I’ve arrived at the details of the structure below over the course of hundreds of apocalypses over the last 15 years in almost as many organizations and projects — whether open source, enterprise or non-profit.

Use it as a starting point, but don’t take it as gospel — use the guiding principles to hack your own Apocalypse to fit the needs of your specific problems in your specific organizations. I’ll give some examples of Apocalypse hacks at the end of this presentation.

So… What does this look like?

An Apocalypse is typically focused on a single idea or problem. There are some basic rules:

1. Speakers are not interrupted while presenting
2. There are no restrictions or limitations other than time
3. Note takers and Leaders cannot comment — they are active listeners
4. Nothing is sacred

We start an apocalypse with a few easy steps:

Start

1. Start an Apocalypse with a theme (e.g. increase throughput, change our agile process, decide on Python versus Node.js)
2. One person leads the theme (Lead)
3. Everyone — except the Lead — has a turn presenting (Presenter)
4. Everyone — except the Lead — has a turn taking session notes (Note taker)

Present

Next, for each presenter:

1. Nominate a timekeeper (can be the same person multiple times)
2. Choose a note taker (each person can only be note taker once)

We also set some time limits around how long people can speak, and how long we’re going to allow for questions:

For example, in our canonical example of apocalypses, we use the following:

• 10 minutes to present — No interruptions
• 5–10 minutes for Q&A — Everyone can (and should!) speak

Combine

Finally, the Lead is responsible for combining the output of each Presenter (as captured by each Note taker):

• Lead captures all ideas, comments and notes
• Presents a proposal for next steps
• Keeps tabs on progress

Note that the results of the apocalypse are for the group: in this way, the Lead serves the group. This means that there is an explicit

Post Mortem

• Everyone has a chance to buy in
• All ideas given fair attention
• Lead can (should!) change from apocalypse to apocalypse

The Who’s Who of an Apocalypse

As you can see, there are four key roles in an apocalypse. We wanted to clearly define the roles, not so that we could be draconian about their enforcement, but rather to make sure that there was just enough structure that we could hack and change our conversations to make them fit our various styles of problem solving, without compromising on our shared principles.

Let’s take a closer look at the roles:

1. Apocalypse Lead (“Leader”) — in an apocalypse, a leader is responsible for solving the problem, but explicitly not for the solution. Leaders in apocalypses are facilitators. The Lead describes the problem that the group is trying to solve. They are responsible for making sure that everyone sticks to the rules, but are otherwise silent. This means that during the apocalypse, there are two reasons a Leader is allowed to speak: (1) to clarify a point of the problem or (2) to make sure that everyone is following the rules.
2. Presenter — Everyone with the exception of the Leader gets a chance to present. When someone presents, there are generally three things that they can do: (1) Present a solution for the problem that the group is trying to solve (2) Clarify the problem, digging into the definition of the problem or (3) Ask questions. (3) is a great way for people to get up to speed quickly and effectively.
3. Note taker — Note takers are responsible for capturing what presenters and active participants say. They are not allowed to speak, other than to ask for clarification of what someone has said.
4. Time keeper — The timekeeper is responsible for calling out the time limits that the group has set around the apocalypse. Timekeepers are active participants in the conversation.

How many people can be in an apocalypse?

The canonical Apocalypses work best with groups between 4 and 8 people; however, there are hacks for the format that allow larger (>20) and smaller (2–3) groups to effectively manage their conversations.

That’s all there is to it!!

• Apocalypses use what we call Pareto Fairness (fair enough, but no fairer — we are trying to balance fairness and overall welfare)
• Apocalypses are useful in seeding conversations even if all artifacts are lost or not implementable)
• Apocalypses are also great for bootstrapping difficult projects
• Apocalypses are very hackable — Roll your own!

Hacking Apocalypses: The Mini-pocalypse

Quick, meaningful conversations about design, architecture and code

Here’s a problem: Not every problem is huge, or even just “big”. Some problems don’t need a full apocalypse because, either:

1. There is a specific problem needing input from the group
2. A decision is about to be made that impacts everyone — they should know

This feels too light for an apocalypse: What conversation should I have?

Solution: Have a mini-apocalypse.

This is a great example of an apocalypse Hack.

Here’s the hack:

1. There is a Leader and Timekeeper
2. The Leader is the Note taker and Presenter
3. The Leader clearly outlines the purpose of the Mini-apocalypse:
4. Knowledge Sharing — making sure that everyone is on the same page OR
5. Solving a specific problem — getting the answer to a specific question from the group

NOTE: these are not mutually exclusive.

1. Leader presents for 5–10 min
2. Everyone asks questions for 5–10 min
3. Session is concluded: The Leader captures the results and shares them with the group

NOTE: The group can decide that a full apocalypse is needed

Next Steps

In future blogs, I’ll give some more examples and context.

Specifically:

1. Further examples of how to hack apocalypses
2. Other meeting and conversation formats
3. Some success stories
4. Tools and methods for streamlining your conversations

[0]: Any of you from the Perl world will remember the apocalypses from Perl 6 (https://perl6.org/archive/doc/apocalypse.html)

Original Source:  https://be.helpful.com/accelerate-technical-decisions-with-apocalypses-bea5a4b9733e

Learn more about our Head of Engineering, Graham Toppin