The defining quality of startups is their velocity. With a strong vision, clarity of goals, and ruthless execution, startups are capable of moving much faster than large companies.

The driving force behind the speed of execution is how quickly startups can make decisions. Startups are unencumbered by the layers of bureaucracy and competing incentives that large companies face, yet startups are forced to make an incredible number of decisions, all the way from its primary strategic goals, to the font size of the terms and conditions.

With technology enabling remote work and asynchronous collaboration, we make more decisions, in more places than ever before. Large decisions are lost in siloed Slack channels, while small decisions take valuable meeting time in standup. Yet despite the rise of remote work and synchronous collaboration, meetings remain the primary venue for decision-making.

To improve our own decision-making process as a semi-remote team at Monolist, we wanted to share our framework for when we have meetings, and what we are willing to decide asynchronously or unilaterally. We hope your team finds value in our process!

To meet or not to meet, that is the question

Meetings are expensive. They take time, they break the flow of work, and they involve multiple people. Meetings, particularly for remote teams, should be used as sparingly as possible.

The first step to any successful meeting is identifying whether it should be a meeting in the first place.

On our team, there are two main occasions for meetings:

1. ✅ To make important decisions
2. ▶️ To execute a task in real-time as a team

✅ Decisions: which ones deserve meetings?

As technology has reduced the barriers to communicate, we are forced to make more decisions every day than ever before. Furthermore, these decisions are happening in so many more places — chats, tickets, pull requests, emails, the list goes on.

Obviously not every decision warrants a meeting, or else no one would get any work done.

At Monolist, we've come up with a framework and process for what kinds of decisions call for a meeting, and which ones can be decided asynchronously and unilaterally.

We think of our decisions in two dimensions:

1. What's the risk of this decision? Is this an important decision? Is there a high cost to reversing the decision?
2. What is our certainty with our decision? How sure are we with our approach? Do we have good evidence or strong priors that point to an obvious solution?

These questions guide our approach to making the decision as a team:

Low-Risk / Low-Certainty

When one of us has to make one of these decisions, we like to:

• Document the proposed decision in a Google Doc
• Use man existing meeting (like a weekly team meeting) to review the decision

Low-Risk / High-Certainty

These are the easiest decisions, and should be made unilaterally by the person with the most context, and subsequently communicated to the team. Examples include changing some copy on a landing page, tweaking a small aspect of the design for a particular feature.

• No meeting necessary
• Give your team a heads-up in a public chat room

High-Risk / Low Certainty

These are the hardest decisions, and should be discussed in a small group, with all members having prepared beforehand. The sole purpose of the meeting should be to make the decision. Examples include large strategic decisions, like how much you should charge for the product, or what you should eliminate from your roadmap to make room for some other feature.

• 🗓 Schedule a meeting specifically for the decision
• 📄 Have each attendee come prepared with a proposal

High-Risk / High-Certainty

An example of a high-risk, high-certainty decision is one supported by a great deal of data – like resolving an important A/B test with a clear winning variant.

• ‍👩‍💼 Identify a clear owner for the decision. This should be the person a) with the most context and intuition about the decision, and b) the person who will end up executing the decision.
• 📄 Document and share the decision, collect feedback asynchronously before memorializing the decision. Set a deadline for collecting feedback.
• ❓If there is disagreement on the document, schedule a meeting to discuss the source of the disagreement.

Guiding principles for all of our decisions

Regardless of whether a particular decision warrants a meeting, we always try to follow a few principles:

1. When possible, decisions should be supported by evidence
2. Decisions should have clear owners
3. Decisions should be transparent and discoverable by the broader team

👯‍♂️ When to have collaborative meetings?

While remote teams have more flexibility to complete tasks asynchronously, there are still certain processes and tasks which are more easily executed at the same time by a group of people.

At Monolist, we like to schedule meetings to execute certain tasks as a group. To determine which tasks or processes we want to work on at the same time, we find it helpful to ask ourselves a few questions.

🤮 Does the task suck?

Humans are social creatures. Doing something hard alone is tough. Doing something hard with someone else next to you doing the same thing is a lot easier. At Monolist, we schedule time to work on our most undesirable tasks as a group. That way, we have designated time to complete them, we are all clearly accountable, and we get to spend time together as a team, which makes the tasks more digestible.

🌮 Are there discrete roles in the task?

Workflows that have natural roles are better completed by a group at the same time. When testing a new feature, for example, it's much faster to have one person person act as the user, one person dictate test cases, and one person take note of bugs than it is to have a single person take on all of those roles in isolation. To learn more about how we do this specifically for bug bashes, check out our blog post Running Bug Bashes Your Team won't Dread.

When we find a process has natural roles, we like to schedule a meeting, assign the roles beforehand, and execute the process as a group at the same time.

💡 Will executing the task or process serve as a good learning opportunity?

Software and medicine are peculiar industries in the sense that they are "always on". Hospitals are expected to be open 24/7, just as websites are expected to have 100% uptime.

For remote teams, that means that certain engineers are expected to be "on-call", potentially in a timezone that no other co-worker shares. As such, it's crucial that remote teams have as much context as possible on the stack in which they work.

When executing a task that has the potential to be a good learning experience for the team, we like to schedule a meeting for everyone to walk through the task. That way, when the alarm goes off at 3:00am in California, it can be fixed at 11am in London.

🗓 What are some good meetings to have synchronously?

• Bug bashes
• Sales calls
• Design reviews
• Blog content reviews

Wrapping it up

The first step to any meeting is determining whether it should exist.

As tools like Slack, GitHub, and Jira make it easier to collaborate asynchronously, the meeting is still a valuable tool to make decisions and execute collaborative processes.

While remote teams can maintain deeper focus while completing tasks, they are naturally more at risk of being left out of the loop. As such, it is important to make transparency and documentation a part of the meeting process to ensure the broader team has context around why decisions are made.

At Monolist, the frameworks above have helped us make decisions faster, with more clarity, while maintaining transparency with the team.

What about running the actual meeting?

Next up in the series, we'll discuss how to run effective meetings when you decide to have them. Join our mailing list to hear about it first!