Coda's Catalyst: The art of the 10x decision forum

Explore

Coda's Catalyst: The art of the 10x decision forum

Coda's Catalyst: The art of the 10x decision forum

Coda's Catalyst: The art of the 10x decision forum

How we accelerate reviewing decisions with multi-threaded meetings.

David Kossnick

Follow along in your own copy.

Read on to learn how Catalyst works and why it 10x’s your decision-making. Click here to get your own copy of this doc, and when you’re ready, check out

Getting started⁠

⁠

Copy doc

⁠

I’ve seen a lot of decision-making forums.

I worked at Google for years, and saw firsthand how leaders like Larry Page and Eric Schmidt ran their decision forums. I ran my own startup, where I tried hard to set up a frictionless decision making forum. And in my role at Coda, I’ve worked with thousands of our customers on how they use Coda for their decision making meetings.

But I can say with confidence: Coda’s decision forum, called “Catalyst,” is the better way. Not a little bit better, but 10x better. Over the years, Coda has evolved the Catalyst forum to 10x our decision-making process in three ways:

10x more decisions: We make 10x more decisions per week... by eliminating standing attendees.

10x faster decisions: Each decision is made 10x faster... with structured decision making.

10x easier decisions: With a decision making process... that runs itself on autopilot.

This doc is an inside look (and template!) on how Coda’s Catalyst works.

⁠

A brief side-note on the name “Catalyst”: Coda founder Shishir came up with the name of the forum after chatting with Elise Keith, a well-known meeting expert. You can hear his background on the name in

this fun talk at Figma Config⁠

that he gave with Yuhki Yamashita (Figma CPO) on meeting rituals.

10x more decisions... by eliminating standing attendees.

This may sound like an odd observation, but if you want to 10x your decision volume, you need to eliminate standing attendees.

When I was at Google, the predominant decision-making forum was called EMG (Executive Management Group) reviews. They were held in Building 40 in a large conference room called Marrakesh. The standing attendees group was over 20 people, and most of them had designated seats in the room (e.g. Sergey Brin set up a treadmill in the back of the room, Urs Hölzle had a designated spot on the couch, etc).

I’ve seen this pattern countless times. Each company calls this something different: Decision Forum, Product Review, Launch Review, etc. The announcement usually reads:

“We have a new dedicated decision making forum that happens every Wednesday at 1pm, and all the key potential decision-makers are guaranteed to be there.”

In some ways, this is a big step forward. It could be worse; many companies have no such forum at all, and say “we make our important decisions in our weekly staff meeting.” (For a deeper look at why this is an anti-pattern,

Shishir’s Config talk⁠

has a nice explanation on what he calls “Cadence !=Catalyst.”) By having a distinct forum, there’s a dedicated time and space for decision-making, and most importantly, all the key potential decision makers are guaranteed to be there.

And therein lies the problem.

This type of meeting has a standing group of attendees. It often starts as what seems like a reasonably small group but quickly grows—sometimes for good reasons (”Person X is needed in most decisions, let’s include them.”), sometimes bad reasons (being a standing reviewer becomes a form of status). Regardless why, the meeting now has 20+ standing attendees. If you brought something for review, you probably needed feedback from a couple of the reviewers, maybe as many as 5 to 10, but that still left 10 to 15 people who were unnecessary to the review.

This is a bad experience for the obvious reason: unnecessary reviewers can add unnecessary friction to a decision process.

⁠

⁠

In my first EMG meeting, my plan for a new YouTube creator experience was being critiqued by one of the execs working on Google Maps. I watched many teams resist signing up for EMG reviews because it often felt like unnecessary feedback and more likely to disrupt rather than clarify. But it was also bad for a less obvious reason: we got through 1/10th as many decisions. After all, we could only do as many reviews as the schedules of those 20 people would allow.

Coda Catalyst solves both these issues with a new pattern: no standing attendees. Instead, Catalyst allows for

multi-threaded meetings⁠

where dozens of topics can be discussed in just one hour.

Here’s how it works:

Every week, three 1-hour calendar slots are held for everyone on the team (Mon, Tues, Thurs from 1-2pm PST). Everyone at the company is expected not to book anything over this meeting time.

Anyone at the company can sign up for a Catalyst slot in a central doc. As part of that process, you indicate who you need for that topic, divided into their core roles (we call them

Driver, Makers, Braintrust, Interested⁠

The day before the Catalyst, a Coda automation runs to replace the one-hour hold from everyone’s calendar with a unique meeting invite for every topic.

⁠

⁠

Multi-threaded setup with a separate calendar event created for each Catalyst topic.

All of a sudden, instead of covering one to two topics per day, we cover 10+ topics! Each of them have the exact group that is necessary—no more, no less.

A few commonly asked questions:

Why have a calendar hold for the whole company?

Initially, the calendar hold was just for the exec team, the ones that were most commonly needed for Catalyst decisions. But an interesting thing happened. Once each Driver started selecting the correct Braintrust for each decision, it became clear that this was often not the execs.

For example, a product launch might need alignment from specific people in Product Marketing, Comms, Legal, and the Sales team. It turned out these people are quite busy too! So we turned this into a cultural statement—we would hold the slot for everyone in the company. This not only increased the volume of decision making, it encouraged an action oriented culture instead of a hierarchical one.

Why 3x per week?

The frequency of these slots has increased over the years as demand for slots continues to increase. I think we would do it five days per week if we could, but we reserve Wednesdays for a slightly different forum called Bullpen, and Fridays for our weekly company all-hands. So every 1-2pm PST slot is reserved for an all-company meeting for the whole company (but on the flip side, it removes dozens of other meetings).

Also, keep in mind that it’s just a calendar hold. Many people in the company see the hold released the day before, and see a free slot on their calendar (who doesn’t want a free slot on their calendar?). But keeping it reserved gives safety that the necessary people will be available.

All that said, I’d suggest starting with one day and then scaling to more as slots fill up.

Who decides on the people to attend, and what’s with the role naming (

Driver, Makers, Braintrust, Interested⁠

When you copy this doc and go through

Getting started⁠

, there’s a place for you to rename these

roles⁠

to whatever makes sense for your team. Our roles are basically

DACI⁠

, but with our unique names: Makers instead of Contributors (we use that term a lot), and Braintrust instead of Approver (borrowing from Pixar’s model).

The Driver role is crucially important as they are not only supposed to run the meeting, and drive the decision, but are considered responsible for selecting the right attendees. Here’s a screenshot of our instructions page on the roles:

⁠

Can anyone join any meeting? What’s the Join button for?

This was necessary for Coda’s culture, but may not be for yours. Coda’s default for Catalyst meetings is that they are open to the whole company, and anyone can join. So if the Driver left you off the invite list, you can click Join and add yourself to the Interested list. If the Driver is intentionally trying to keep a meeting closed, they can fill in Who’s Invited? with Braintrust Only, and the Join button will be disabled.

⁠

⁠

What if there are conflicting attendees for parallel Catalyst discussions?

One of the obvious consequences of running discussions in parallel is that an attendee may be asked to be in multiple places at once. Our template auto-identifies these overlaps and, with an automation, sends a Slack message to the conflicted attendees and to the drivers so they can resolve.

In practice, this is usually resolved by either moving one of the review slots, deciding that the attendee is not necessary for a particular review, or asking the attendee to provide async input (more on this in the next section).

What types of Catalysts are there? What is the Stages column for?

As our Catalyst process scaled, we noticed a common pattern: teams would come to the forum too late in their process, and the Braintrust feedback would land poorly. Typically the team had already ideated, explored a bunch of options, decided on a particular direction, and were generally just looking for feedback on the proposal. But the Braintrust disagreed with the premise or had a totally different option to consider. The meeting would go poorly and not reach a healthy conclusion.

So we reworked the forum a bit.

We asked teams to indicate which of five

Stages⁠

they were at (Ideate→Frame→Propose→Act→Reflect) and encouraged them to bring tricky decisions in at an earlier stage so their Braintrust could provide earlier feedback. Some teams even created a process for their Braintrust to indicate which topics they were interested in (see our CPO

Lane’s post on Proactive Prompting⁠

for an example).

Oh, and as a small additional signal, we removed the name “Review” from the title of the meeting and just called it Catalyst.

10x faster decisions... with structured decision making.

Our “no standing attendees” format for Catalyst is a game changer for increasing the number of decision reviews we can hold in a week. But we also found it important to address what happens within the review meeting, as small changes can dramatically speed up decision making.

Coda CPO Lane Shackleton described the core of his process in his now famous post on

two-way writeups⁠

. It’s hard to understate how important these are for our decision making culture. I see way too many companies get all the right people in a room, and then just have a free-for-all discussion. Or perhaps even worse, they mis-use their docs, and let the comments drive the meeting. As one of our customers pointed out:

“It felt like the most important decisions in our company were jammed into the 100 pixel panel hanging off the side of our Google Docs. Is that really the best we can do?”

Our template looks like this:

⁠

⁠

Decision docs speed up decisions with structured feedback.

Here’s what we do:

A reaction to indicate when everyone is Done Reading. Important that everyone’s on the same page before we start.

Ask everyone to fill in a Pulse on their position. Hide everyone else’s view until everyone’s done. Remove groupthink.

Order the discussion by votes in the Dory. Don’t let the loudest voice dominate the discussion.

Every company has a unique Decision Doc template - e.g. Zoom uses “

RCR⁠

” (Root Cause Reasoning), Square chose

S.P.A.D.E⁠

., Amazon’s is

PR/FAQ⁠

, Nextdoor has S.P.I.C.E., Luxury Presence uses an

agree/commit⁠

model, etc. I think it’s important to make a purposeful choice here, but it should match the culture of each company.

A few common questions:

We have a slides culture, can I still do this?

Sure! Just embed the slide deck. There’s a template here:

https://team.indiedemos.com/@lshackleton/two-way-writeups-coda-s-secret-to-shipping-fast/example-slide-writeups-7⁠

⁠

Do you do pre-reads? (or “during-read” or ...)

I’ve seen 3 patterns for this: (1) pre-read before the meeting, (2) dedicated time for reading at the start of the meeting, (3) time for a “presentation” of the writeup. At Coda, we bias towards #1, but check the Done Reading button to be sure it happened (if not, we shift to #2). We almost never do #3.

I don’t think there’s necessarily a right choice here, but it’s very important that the choice is commonly understood.

What about async decision making? Do I need the meeting?

Often the Driver will send out a pre-read, gather and address feedback async, and gather enough input to make a decision before the meeting has even started. In those cases, the Driver is encouraged to cancel the meeting — this is a win!

What if the topic is at an earlier stage and not ready for a decision?

One of the benefits of Catalyst is it covers all the

Stages⁠

of a decision, including the ideation stage. At Coda it’s accepted (and encouraged) to bring the team together to ideate on a topic even before you’re ready to make a decision. In fact, you often avoid conflict by bringing in the braintrust from the earliest stages of a project. Lane, Coda’s CPO, highlighted a couple techniques for doing this in his post on

The value of proactive prompting⁠

. I also regularly use patterns from this list of

Gamestorming techniques⁠

to surface the best ideas from the group.

10x easier decisions... with a process that runs on autopilot.

At Google, EMG was “run” by a dedicated assistant. 100% of their job was to handle all the backstage work required for the forum.

My immediate thought: Yuck. What a painful use of their time.

But when I saw what they did, I realized it was very important: making sure the right approvers could attend, check if the presenter was prepared, all the pre-reads were sent, follow-up notes circulated, etc. And if the topic had to move for any reason (critical person not available, writeup not ready, etc), then all of this would have to repeated.

When we started setting up Coda Catalyst, one of the immediate questions was “who is going to run this?” The idea of having a full-time person running it felt nuts. So we put a lot of effort into not just having a great scheduling and in-meeting decision process, but also make sure the “backstage” work is completely automated.

This is where Coda’s all-in-one surface does the heavy lifting to run Catalyst on autopilot. Automations, buttons, and Packs automatically take care most of the minutia in the process, including:

Creating and updating individual calendar events for each topic.

Removing the calendar hold the day before the Catalyst discussion.

Sending a Slack reminder the morning of a Catalyst discussion.

All of these small details add up to a consistent, transparent decision-making process. As you can see from the example Slack messages on the right, we’ve infused each automation with key parts of our culture - like reminding people of their role in the meeting and our internal tagline for the role. When everyone knows what to expect and has confidence in the decision-making process. Not only does this lead to higher-quality decisions that stick, but it makes everyone’s lives easier.

⁠

⁠

Coda automations send out reminders the morning of a Catalyst discussion

Ready to 10x your team’s decisions?

Start by copying this doc, then follow the setup steps in

Getting started⁠

, and customize

Template: Catalyst forum⁠

⁠

Copy doc

⁠

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.