The Meeting That Should Never Have Happened
Stewart Butterfield founded Slack in 2013, but the company nearly died three years later.
Not because the product was bad. Because the decision-making had become broken.
By 2016, Slack had 50 employees. They were adding features fast. But something felt wrong.
Every design decision took weeks. A button color would go to committee. Ten people would have opinions. Meetings would happen. Nothing would change until someone got frustrated and decided unilaterally.
The product felt disjointed. Features weren’t cohesive. The interface was becoming a patchwork of decisions made by different people at different times.
Stewart realized the problem: they were making design decisions by committee.
A committee means everyone has a say. Everyone has equal voice. That sounds fair. It’s actually the path to mediocrity.
Committee design creates products where no decision is strong. Everything is compromised. Nothing is excellent.
Stewart made a decision that changed everything: he removed design decisions from committee.
Instead, he created a process. One person decided. Other people could challenge the decision. But the decision was made by one person, not consensus.
The results were immediate. Features shipped faster. The product felt coherent. The design improved.
Why Committee Design Fails
Committee design sounds like it should work. More voices. More perspectives. Better decisions.
In reality, it’s the opposite.
A committee design decision works like this:
A designer proposes a solution. The product manager suggests a different approach. The engineer raises concerns. The founder has opinions. The marketing person wants something different.
Everyone talks. Nobody decides.
Or someone decides unilaterally. But now half the team disagrees. They’re less invested. They implement half-heartedly.
Or the decision gets compromised. Everyone’s opinion gets incorporated. The result is incoherent.
None of these outcomes are good.
Committee design kills velocity. It kills coherence. It kills ownership.
How Slack Actually Made Design Decisions
Stewart created a simple framework for making design decisions without committee.
Step 1: The Proposer
One person proposes a design. This person is responsible for the proposal. They’ve thought it through. They can defend it.
This person might be the designer. Might be the product manager. Might be anyone. But it’s one person.
Step 2: The Context
The proposer explains the context. Why are we making this decision? What problem are we solving? What did we consider and reject?
Context matters because it helps others understand the reasoning.
Step 3: The Feedback Window
Other people can provide feedback. But feedback is just input. Not votes.
The designer listens to feedback. But they’re not obligated to take it.
Step 4: The Decision
The proposer decides. Based on their judgment. Based on feedback. But ultimately their call.
Step 5: The Commitment
Once decided, the team commits. Even people who disagreed.
If the decision is wrong, you’ll learn. You’ll reverse it. But you don’t second-guess it while implementing.
This process sounds simple. It’s revolutionary.
Why? Because one person is accountable.
If the decision is good, they get credit. If it’s bad, they own it.
Accountability changes how people think about decisions.
Why This Works
The reason this framework works is psychological.
When you’re one of five people deciding something, you’re 20% responsible.
If it fails, you can blame the others. “I wanted something different.”
When you’re the person deciding, you’re 100% responsible.
If it fails, it’s on you.
This creates different incentives.
A committee member might suggest a conservative choice because it’s safe.
A person making the decision might suggest a better choice because they own the outcome.
Stewart realized this. He structured Slack’s decision-making around individual accountability, not consensus.
The Real Impact on Product Quality
By 2018, Slack’s design felt cohesive. Features worked together. The interface was intuitive.
Not because the design was perfect. But because decisions were made by people who owned them.
A designer made a button color decision. It was her decision. If it was wrong, she’d change it.
This accountability meant she thought carefully. She wasn’t making arbitrary choices.
The product manager made a feature priority decision. It was her decision. If it backfired, she’d explain why.
This accountability meant she prioritized thoughtfully.
The difference between Slack’s 2016 version (committee decisions) and 2018 version (individual accountability) was night and day.
Not because the people changed. But because the decision structure changed.
How Different Companies Apply This
Not every company uses Slack’s exact framework. But successful SaaS companies use the principle: design decisions are made by individuals, not committees.
Company 1: The Design Lead Model
One design lead makes all design decisions.
Other people give input. But the design lead decides.
This works when you have a strong design lead.
Examples: Stripe uses this model in many areas. Strong design leadership. Coherent product.
Company 2: The Product Manager Model
The product manager decides.
They consult designers, engineers, and data. But they decide.
This works when product managers think holistically about user experience.
Examples: Some SaaS companies use this. The best ones have product managers who understand design deeply.
Company 3: The Founder Model
The founder decides, especially in early days.
This works when the founder has strong taste.
Examples: Apple under Steve Jobs famously used this. Figma’s founder Dylan Field makes many design decisions.
Company 4: The Data Model
Design decisions are made by looking at data.
A/B test shows one design performs better. That design wins.
This removes opinion from decisions.
Examples: Some SaaS companies use this heavily. Conversion-focused companies especially.
The Key Elements of Each Successful Model
All successful models share common elements:
Element 1: Clear Ownership
Someone is clearly responsible for the decision.
Not “the team,” not “we.” But “Sarah decided,” or “the design lead decided.”
Element 2: Input Gathering
Even though one person decides, they gather input from others.
They’re not deciding in isolation.
Element 3: Clear Criteria
The decider explains what they’re optimizing for.
“We’re optimizing for new user clarity, not power user efficiency.”
This helps others understand why a decision was made.
Element 4: Reversibility
If a decision is wrong, you can reverse it.
This reduces the risk of individual decision-making.
A bad button color can be changed. A bad feature can be disabled.
Element 5: Speed
Individual decisions are made faster than committee decisions.
No meetings. No consensus-building. One person decides.
The Common Mistake Companies Make
Most companies start with individual decision-makers.
The founder decides everything. Works great early on.
As the company grows, people push back. “Why does one person decide for all of us?”
The company adds more people to decisions. “Let’s make it more democratic.”
This feels more inclusive. Everyone has a voice.
But the product suffers. Decisions slow down. Coherence breaks.
Most failed companies didn’t fail because of bad decisions. They failed because of slow decisions.
By the time a decision was made, the market had moved.
Stewart understood this. He stayed committed to individual decision-making even as Slack grew.
How to Know If Your Decision-Making Is Broken
Ask yourself these questions:
Question 1: How long does a design decision take?
If it takes weeks, something’s wrong.
A good design decision should take days, not weeks.
If it takes weeks, you probably have committee decision-making.
Question 2: Do decisions feel compromised?
You make a decision that nobody’s fully happy with.
That’s a sign of committee compromise.
Good decisions are strong. People might disagree, but they understand why the decision was made.
Question 3: Does the product feel coherent?
Do different parts feel like they’re made by different people?
If yes, your decision-making is fragmented.
Good products feel unified. Even if they’re built by different teams.
Question 4: Can people execute quickly?
Once a decision is made, can the team execute in days?
Or do they re-discuss and reconsider?
If they re-discuss, ownership is unclear.
Question 5: Are people invested in the outcomes?
When a decision is made, do people own the result?
Or do they think “I didn’t want this but whatever”?
If it’s the latter, decision-making isn’t clear.
How to Actually Change Your Decision-Making
If your company has committee decision-making, here’s how to fix it:
Step 1: Pick One Area
Don’t change your entire decision-making process at once.
Pick one area. Maybe design. Maybe features. Maybe navigation.
Step 2: Designate a Decision-Maker
For that area, one person decides.
This person has authority. They listen to input. But they decide.
Step 3: Set Clear Criteria
This person explains what they’re optimizing for.
“I’m optimizing for new user clarity” or “I’m optimizing for power user speed.”
Step 4: Make Decisions Fast
This person makes decisions in days, not weeks.
No extended meetings. No consensus-building.
Step 5: Measure the Impact
Track whether this area improves.
Is the product better? Are decisions faster? Are people more invested?
Step 6: Expand
If it works, expand this model to other areas.
Don’t try to change everything at once.
The Fear People Have
When you suggest individual decision-making, people get nervous.
“What if one person makes bad decisions?”
It’s a fair question.
Stewart’s answer: if they make bad decisions, they won’t be the decision-maker for long.
Bad decision-makers become obvious quickly.
If someone makes three bad decisions in a row, they lose credibility.
The organization naturally shifts power to better decision-makers.
This is different from committee decision-making, where bad decisions get buried in consensus.
Individual decision-making makes bad decisions visible.
This is actually good. It creates pressure to improve.
The Role of Feedback
Feedback in this model is important. But different than in committee models.
In committee models, feedback is voting. People vote for their preference.
In individual models, feedback is input. The decision-maker considers it, but doesn’t have to follow it.
This is a crucial difference.
A designer makes a button color decision: orange.
A colleague says “I think blue is better.”
In committee: there’s a vote. One side wins, one side loses.
In individual: the designer considers it. Maybe they agree. Maybe they don’t. They decide.
The colleague has been heard. But the decision-maker decided.
This is psychologically different. It feels less fair. But it’s more effective.
How Stewart’s Model Affected Slack’s Growth
By 2017, Slack’s design was notably cohesive.
New features fit naturally into the existing product.
The interface was intuitive. Users didn’t have to learn new patterns.
This coherence had massive business impact.
New user onboarding improved. Retention improved. Feature adoption improved.
By 2019, Slack went public. Part of the investment thesis was “this product is beautifully designed.”
The design quality wasn’t accidental. It came from how decisions were made.
Strong design required strong decision-making.
Different Models for Different Company Sizes
The model changes as companies grow.
Early Stage (5-20 people)
The founder decides most things.
This is fine. Founders have taste. They move fast.
Growth Stage (20-100 people)
Multiple decision-makers emerge.
The design lead decides design. The product manager decides features. The founder decides strategy.
Clear areas of authority.
Scale Stage (100+ people)
Decision-making frameworks become more formal.
But the principle stays: one person decides in their area.
Committees are used for truly company-wide decisions, not day-to-day decisions.
Data-Driven Decisions
There’s one area where committees can work: data-driven decisions.
If you A/B test two designs and one clearly performs better, you use the better one.
The data decides. Not people.
This removes ego from decisions.
Slack uses this for some decisions. “We tested three button colors. This one had the highest click rate.”
That’s objective. Data wins.
But most design decisions aren’t data-driven. They’re judgment calls.
For judgment calls, individual decision-makers work better.
The Real Lesson
Stewart’s insight wasn’t “remove all input from decisions.”
It was “don’t confuse input with decision-making.”
Input is valuable. Feedback is valuable. Other perspectives are valuable.
But input should inform the decision, not make the decision.
The decision-maker listens to input. Then decides.
This is different from voting where input IS the decision.
Most failing companies have confused these two.
They treat input as votes.
Successful companies treat input as information.
What This Means for Your Product
If your product feels disjointed, your decision-making is probably disjointed.
If your product feels coherent, your decision-making is probably clear.
If you’re shipping features slowly, committee decision-making is probably slowing you down.
If you’re shipping quickly, someone is probably making decisions clearly.
The product is a mirror of how decisions are made.
This Week
Pick one small design decision you need to make.
Instead of bringing it to committee, make it yourself.
Gather input. Consider it. Then decide.
See how long it takes.
See how the team reacts.
See if the outcome is good or bad.
If it’s good and fast, expand this approach.
If it’s bad, you’ve learned something valuable about yourself as a decision-maker.
Either way, you’ve broken the committee cycle.
That’s how change starts.
Also Read: Figma Shortcuts Every SaaS Designer Should Know (That Save Hours Weekly)
