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.
By now, you’ve probably heard of Conway’s Law:
An obvious paraphrasing of this makes it a bit more obvious
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:
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
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:
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
Contrary to the colloquial use, an apocalypse is not catastrophic; it is a revelation
The guiding principals of apocalypses are designed to encourage and unearth revelations:
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.
An Apocalypse is typically focused on a single idea or problem. There are some basic rules:
We start an apocalypse with a few easy steps:
Next, for each presenter:
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:
Finally, the Lead is responsible for combining the output of each Presenter (as captured by each Note taker):
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
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:
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.
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:
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:
NOTE: these are not mutually exclusive.
NOTE: The group can decide that a full apocalypse is needed
In future blogs, I’ll give some more examples and context.
: Any of you from the Perl world will remember the apocalypses from Perl 6 (https://perl6.org/archive/doc/apocalypse.html)
Learn more about our Head of Engineering, Graham Toppin
I love building products, teams & experiences. My two passions are growing people and building practical artificial intelligence systems