How Coda’s Meeting Operating System Ensures Every Conversation Has a Home

This blog is full of advice for running a great meeting. Of course, teams don’t run just one meeting. Teams run lots and lots of meetings.

Now, if you have oodles of spare time, you can design each and every one of your team’s meetings from scratch using the advice you’ll find here. No one has those oodles, however, which is why—despite the ready availability of all this super practical how-to goodness–lots of folks just make stuff up.

Other teams find a better way. They design their meetings up front, then codify these designs into a Meeting Operating System that makes it easy for them to run those meetings over and over again.

A Meeting Operating System (MOS) provides the backbone of an organization’s Communication Architecture, and consists of three main components.

1. Performance Criteria
   Basic rules or principles that apply to all meetings.
2. Meeting Flow Models
   Sequences of specific meetings used to achieve distinct business results.
3. Support
   Training, technology, and resources.

In the past three articles, we looked at Meeting Flow Models in detail. Today, we’re going to zoom out a bit and look at how those Meeting Flow Models work as part of a larger MOS. Next–you guessed it–we’ll zoom out even further to look at the overall Communication Architecture.

Now, let’s dig into a real-life example. I’m super excited and grateful that our friends at Coda agreed to share their MOS with us all. Who is Coda, you ask?

Meet Coda

Coda is a technology startup company headquartered in Silicon Valley. They aim to reinvent the collaborative document, making it easy for people to create documents as powerful as applications.

I first met the Coda team when their solution architect, Al Chen, contacted us about sharing their approach to note taking on our blog.

Read Al’s article on Taking Effective Meeting Notes: Where Technology Meets Organizational Culture

I was intrigued because for many tech startups, “meeting” is a dirty word. Tech CEOs may proudly cancel all their meetings or declare their office a “no meetings” zone. Of course, they can get away with that because they’re often working with small teams that talk to each other all day – which reduces the need for meetings.

What works when you’re a tiny business, however, doesn’t work as you grow. Failing to recognize this creates mayhem in most startups as they’re repeatedly forced to change how they work. “Oh dang. Maybe we do need meetings. Urgh!” they realize.

When Shishir Mehrotra and Alex DeNeui left Google and Microsoft to start Coda, they knew they needed to prevent that chaos.

Their mission to reinvent the document is hugely ambitious, which means they can’t waste time also reinventing how to work every few months. To prevent that, Coda’s founders implemented a variation of the Meeting Operating System (MOS) Mehrotra helped develop while he was VP of Product at YouTube.

Why Coda Focused on Meetings

Shishir Mehrotra shared what he experience at YouTube before they implemented an MOS there.

“All of these symptoms of an ineffective meeting system – they’re not obvious in the meetings.

It’s like, maybe people don’t feel like they have the right goals, or they don’t feel like they’re clear on the decision-making process. They’ll attribute it to lots of other things. They think it’s just the culture.”

Shishir Mehrotra, Coda Founder

By contrast, companies that establish a meeting operating system like the one used at YouTube and then at Coda don’t have to rely on guesses or assumptions. They define how to run each meeting, then schedule meetings at predictable intervals so everyone knows what kind of conversations they can expect to have when.

This predictability gives teams a clear way to work through all those decision-making and accountability issues which otherwise drag them down, and it sets a deliberate pace for the work. Put it together, and you establish a calm environment that’s very different from most startups. This predictability is one reason employees call Coda The Grown-up Startup.

Coda’s meetings system works by accomplishing these three goals common to every effective meeting operating system.

1. An effective Meeting Operating System defines how to run different types of meetings, NOT topics.

Coda’s core Meeting Flow Model includes three major categories of meetings.

• Cadence meetings, where teams come together to check progress on day-to-day work.
• Catalyst meetings, held twice per week to work through new ideas and make decisions.
• Context meetings, held three times per week and used to make sure everyone is up to speed with the latest news.

While everyone at Coda knows the timing and type of each meeting, they don’t always know what they’ll discuss.

For example, recently the team worked through and made decisions about a nuanced product feature in the first Catalyst meeting of the week and in the second, they decided how they’d transition to the next phase in the company’s growth. Their process for running Catalyst meetings works equally well for big and small decisions alike, which frees them up to focus on the details involved rather than worrying over how they’ll get to a decision in the first place.

In addition to their core MFM, Coda also has annual meetings (board meetings, retreats, and multi-day hackathons) and sprint meetings.

What’s a “sprint”? Software teams that use an agile software development approach break the work down into bits that can be finished within a predetermined number of weeks called a “sprint”. At Coda, each sprint lasts 5 weeks. Like most agile teams, Coda runs several meetings during each sprint where the team sets priorities, checks their work, and reflects on what they’ve learned.

Coda’s sprint meetings support their primary line of business – building and releasing Coda software. When you’re working in a fairly new company with a focused product line like this, the difference between your core Meeting Flow Model and the line of business Meeting Flow Models can get pretty blurry. You can see this in how Coda meets. Their core Catalyst meetings may address a product feature question or a larger business model question.

By contrast, here at Lucid we manage several different product offerings, which means we have more distinct MFMs. Our core MFM includes the meetings we run to set strategy and manage the business overall. Then, each of our major product lines has its own set of meetings. You can see one example in the Software Pilot Program MFM I shared in the previous article.

Large organizations with multiple divisions and complex portfolios use an even wider variety of MFMs: a core MFM that aligns the whole company, one for each major line of business, one for hiring and onboarding, and more. Given all that, you can easily see how big companies that haven’t designed their MOS end up in an overwhelming death-by-meetings doom loop.

How Coda’s Meeting Types Align with the Lucid Taxonomy

At Lucid, we’ve found there are sixteen distinct types of meetings companies build into their systems. These types are like building blocks which you can string together to achieve all kinds of interesting goals.

Like Coda, most companies don’t necessarily use the same names for their meeting types that we do. Instead, they give their meetings special names to best reflect their unique culture. Coda’s Catalyst meetings run like what we’d call a Decision Making meeting. Their Cadence meetings work like Team Cadence and Progress Check meetings. The terms are different, but the functions are largely the same.

I think this example is super useful, because I know people can get stressed out when they look at this taxonomy and try to figure out exactly which kind of meeting they need. There’s no call for that. The taxonomy should be used to broaden your thinking and inspire ideas, not to lock you into some kind of uptight meeting-perfectionist’s box.

Coda’s taxonomy was influenced by this taxonomy, but they didn’t worry about dogmatically adhering to it. Neither should you.

2. An effective Meeting Operating System is documented, used, and maintained.

In Coda’s first year, they embraced the well-documented system Mehrotra helped develop for YouTube.

Since then, they’ve had ample opportunity to revise their system because that documentation is embedded in the tools they use to run meetings. They’re evolving.

For example, an early version relied on the “pigs and chickens” metaphor to explain meeting roles. Pigs are committed, chickens are just involved. But when team members pointed out that they didn’t really care to be called a pig or a chicken, these names changed. Now, they identify the Makers, Braintrust, and Meeting Mollys for every meeting.

“It’s not as clear as pigs and chickens, but it’s working for now. I’m sure it will change when we find something better,” Mehrotra admits.

Sometimes Coda team members ask when they’ll be “done” refining their meetings so they can move all these how-to details to a central location.

The answer?

“Never. We’ll keep it right there for every meeting,” says Mehrotra. With the how-to info in every meeting invitation, new employees quickly get up to speed. This also helps the Meeting Molly (their name for the person leading the meeting), who can reference it any time the group gets off track.

Want to see an example of a Coda meeting template?

Coda uses their software to document their MOS and support their meetings. Here’s a Coda template for managing their Bullpen meetings (more on those below).

3. An effective meeting operating system expects the unexpected.

At Coda, they avoid ad-hoc meetings.

If the team needs to schedule extra meetings, that means there’s a flaw in the system. Something broke down and we should fix that.

Shishir Mehrotra

Ad-hoc meetings—those meetings that aren’t planned but get added whenever something comes up—can quickly take over the calendar. That said, every company has things that come up that don’t fit into the regular meetings.

To prevent calendar creep, Coda built an “escape valve” into their system called the Bullpen. There are no set topics for the weekly Bullpen and only one rule: you have to be there. When the team knows that they’ll all be in the same place and free to talk soon, they bring the ad-hoc stuff to the Bullpen.

The Bullpen dedicates time and space for all the conversations that don’t have a home in other meetings, and as a result, it’s one of the most productive times the team spends each week. It’s a super clever innovation and a great example of one way to solve for the “stuff comes up” problem experienced in every business.

Other companies with a solid meeting system solve the problem other ways, but in all cases, they’re achieving the same standard.

The litmus test for an effective meetings system is this:
Every conversation has a home.

If that’s not true for you—if your team runs from meeting to meeting without ever quite knowing how to get decisions made or who to involve—that’s not a generic culture problem. That’s a design problem you can begin to solve by implementing an intentional, predictable Meeting Operating System.

Take Aways

So what should you take away from this?

For those of you running technology startups, maybe you’ll pick up Coda’s example and adapt it for your business. When you don’t already have a system in place, you’ll get results faster when you start with a good example like this.

For everyone, I’m hoping you see what it takes to achieve consistently excellent meetings throughout your organization. By now, you should realize that:

• Meeting success does not come from learning how to use an agenda. 
• Meeting success does not happen by limiting meetings to 15 minutes.
• Meeting success does not happen when everyone has to figure it out for themselves.

Meetings success happens by design. Organizations that enjoy consistently effective meetings use a Meeting Operating System designed for their unique business and culture.

Or, as my partners put it, if you’re a leader, it’s time to stop being victimized by your meetings. Take control and design your success.