My preferred mindset for group decision making

2025-03-15

I recently read about Coda’s Catalyst framework for company decisions. It’s inspriring to read on how a common activity—making decisions—can be approached in a different ways.

Even though I find their framework promising and would love to experience it firsthand, it isn’t a personal framework or mindset. It requires company-wide buy-in, is deeply influenced by company culture, and might feel overwhelming to some.

So, I wanted to share my preferred mindset and framework for making decisions in any organization. These are personal actions and language that can be applied in any group setting. Even if others don’t follow them, approaching decisions this way brings benefits.

In any organization, how decisions are made often determines not just what gets done, but how engaged and aligned team members feel throughout the process.

Much of what I’ll write isn’t new (many companys have shared their process), but rather my perspective, based on experience and reading, of what can be done at an individual level.

Main Concepts

My philosophy focuses on three main concepts:

Roles: Clarifying who owns, decides, and contributes to each decision
Decision Stances: Distinguishing between agreement and commitiment
What’s up for discussion: Defining clear boundaries for each decision conversation

Roles of the Participants

The most important thing in decision-making is understanding the role each participant is playing.

Coda defines roles like Driver, Maker, Braintrust, and Interested. The RACI model uses Responsabible, Accountable, Consulted and Informed. And there are many more alternatives

The specific roles and their names aren’t what matters most—many will work. What’s important is recognizing that not everyone plays an equal part in every decision. Understading this may avoid making decisions by comittee, which often results in mediocre and uninspiring outcomes.

My usual approach

Who’s the owner? Who is responsible for presenting a proposal, gathering feedback, and leading the process to completion? This might not be the person making the final decision.

Who’s the decision maker? Who has the knowledge and authority to approve or reject the decision? Often, multiple people decide on different aspects. For example, an executive may approve business rules, while a developer decides the technical approach.

Who’s relevant? Who, while not directly involved, will be affected by the decision or has expertise that could inform the choice?

Determining these three roles, even informally, makes decision-making much smoother.

For example, when launching a new product feature, the product manager may be the owner, the department head the decision maker on business priorities, and representatives from engineering, design, and customer support would be relevant participants providing crucial input.

A caveat: In many organizations, formal roles don’t always align with reality. A senior employee may officially be an advisor but, in practice, holds significant influence and acts as the decision maker. Conversely, a director might follow a discussion but delegate the actual decision to someone more involved. Acknowledging this reality rather than pretending formal roles always dictate decision authority can prevent confusion and frustration.

Decision Stances

Once roles are clear, understanding how people respond to a proposal is the next priority. Zac Hays has a great guide online that really influenced how I think about decision stances, and clearly differentiates agreement from commitiment

He offers a clear vocabulary for expressing commitment to decisions. His approach emphasizes that agreement isn’t necessary for commitment, which resonates with my experience.

When people react to a proposal, they generally fall into three categories:

Agreeing and committing – The simplest scenario. Someone supports the proposal and is ready to help implement it, even if minor refinements are needed.
Disagreeing but committing – This is where Hays’ framework is particularly valuable. Someone may believe the idea isn’t optimal but recognizes that perfect consensus isn’t required. They’re willing to fully support the decision despite their reservations.
Cannot commit – Sometimes, someone strongly opposes a proposal because they believe it’s unsafe to try or potentially harmful. In these cases, they’re not just disagreeing but indicating they cannot in good conscience support the decision.

When someone disagrees, especially if they’re not the decision maker, it helps to clarify their stance: “I understand you have concerns, but can you commit to this decision even though you disagree? Or do you believe this is not safe to try?”

As Hays points out, commitment should be binding. If you disagree but commit, you shouldn’t try to revisit the decision later just to remake your argument. The decision is made, and everyone moves forward.

The key distinction is between:

“I disagree with this decision, but I can commit to making it work.”
“I cannot commit because I believe this approach is unsafe or irresponsible.”

This mindset is even more critical when you’re the one disagreeing. Clear language is your best ally:

“I have reservations about this approach, but I can commit to it and I’m ok moving forward.”
“I cannot commit to this proposal because I believe it poses significant risks that haven’t been addressed.”

The right words and tone depend on the context and your ability to read the room, but having this clear framework helps everyone understand where they stand and what’s expected after the decision is made.

Documenting these levels of agreement (perhaps in meeting notes or a decision log) ensures there’s a shared understanding of where everyone stands and helps prevent revisiting settled decisions unnecessarily.

What’s Up for Discussion

The third key concept for effective group decision-making is clarity on what’s actually being decided.

In medium or large projects, multiple teams are often involved. Take, for example, a new product feature that affects both business strategy and technical implementation. A product manager might draft a proposal requiring approval from business stakeholders and technical review from developers..

The best approach, in my experience, is to split the decision-making into multiple clear discussions. In this example:

First, discuss the business logic and rules of the feature with business stakeholders, making it clear that technical review is still pending.
Once that’s finalized, meet with the technical team to explain the approved business decision and focus on technical implementation.

The technical team should have space to give input on business decisions, but everyone must clearly understand what part of the proposal is open for discussion at each stage.

This is a simple example, but failing to define discussion boundaries leads to confusion and frustration. What seems like a single decision is often a series of smaller ones.

This ties back to roles. Even within a single proposal, roles shift throughout the process, and people must be comfortable with their expectations.

If you’re in a decision-making meeting and aren’t sure what’s up for discussion, asking directly is a smart move: What specifically are we deciding here? What’s out of scope for this discussion?

If the scope shifts during the discussion (as often happens), it’s worth pausing to acknowledge this change: “It seems we’ve moved from discussing the feature requirements to debating the timeline. Should we table the timeline discussion for now and finish our original agenda first?”

A mindset, not a framework

When everyone understands their role, can express their level of agreement honestly, and knows exactly what’s on the table for discussion, decisions become smoother, faster, and more likely to be implemented with commitment rather than compliance.

By applying these principles individually, even without organizational buy-in, you can improve decision quality and reduce frustration in nearly any group setting.

References and futher reading:

Written by a human, edited with the help of AI.