Decision Making

When Pagedeck had ten people, nobody needed a phrase for this. Anything that had to be settled got settled by Grace, and when Grace was out, by whoever had been closest to the problem longest. No one asked who decides, because the answer was obvious.

At forty-five people the answer stopped being obvious. Eight people sit in the room, all eight are qualified to have an opinion, and not one of them has ever been explicitly handed the right to end the discussion. Eight opinions come out and no conclusion does.

That is what happened with the proposal to cut the storage limit on the free plan. In the first meeting Mia brought server cost figures and made the case. Sofia raised the contracts already in progress that had been sold on the current limit. Ravi said he couldn't guess how far signup conversion would drop. An hour later the sentence that ended the meeting was "let's pick this up next time." Two weeks on, the same item came back, this time with Theo in the room, so the background had to be explained from the start again. In the third meeting Grace asked who actually decides this. Nobody could answer, and that unanswered question was the reason the meeting had run three times.

What was missing was not data and not opinions. It was an agreement about who decides. Without a named decider, a meeting stops being a place where conclusions get made and becomes a place where opinions pile up. The pile comes back out at the next meeting, and if the attendees change in between, it gets rebuilt from nothing.

Decision making fills that empty slot before the question arrives. Three things go into it: who decides this, whose input gets collected first, and what someone who still disagrees is expected to do afterward. The shape usually lands in one of three places — consensus, where the group waits until everyone agrees; input-then-decide, where everyone is heard and one person closes it; and delegation, where one person owns the call outright and the rest are told the outcome. None of the three is right in general, which is why the rule gets written per kind of decision. Put a pricing change to a five-person consensus and three weeks pass without an answer; route a button color to the CEO and the CEO becomes the bottleneck.

The terms under decision making fall into four groups: who gets which part (role definition), how far the invite list reaches (who is involved), what attitude is agreed in advance about making and accepting decisions (principles), and where all of it spins in place (risks).

Role definition is the group that puts name tags on the people attached to one item. There are three, and the first fork is whether you draw a table or hand the whole thing to one person.

1. RACI — a table that splits involvement four ways: responsible, accountable, consulted, informed. Who does the work, who owns the outcome and gives final sign-off, whose opinion has to be asked, and who only needs to hear the result. The rule carrying the most weight is that accountable is exactly one name. On a pricing page redesign, responsible is Noa and Theo, accountable is Mia, consulted is Sofia, and informed is everyone else.
2. DACI — driver, approver, contributor, informed. It looks like RACI with different letters, but the unit is different. RACI divides up how a piece of work gets run; DACI divides up how one decision gets made. That is why the decider occupies an explicit slot, and why anyone holding a veto, such as legal or finance, is written down as an approver instead of being folded in with the people giving input.
3. Single-threaded owner — one person who works on one thing and carries it to the end. Instead of drawing a table you hand the item to a single owner, which is the opposite move from the first two. The load-bearing half of the name is "single": no second assignment. Teams create the role after watching someone with three simultaneous projects fail to push any of them across the line.

Who is involved is the group about deciding whom to bring in. Stakeholder is its name, and it covers everyone affected by the outcome or able to affect it. For the free-plan storage change that means sales, who sold against the old limit, design, who has to redraw the signup flow, and engineering, who has to change billing. The judgment call is scope. Invite everyone affected and the decision slows down; leave a few out and they overturn it later. Going from four people to eight halves how long each one gets to talk and adds days just to find a slot, but dropping the engineer who owns billing produces "we can't ship this" two days before launch. So most teams split the list into people whose input is collected and people who are only told the result, and the two frameworks above write that split into the table. The line is drawn by whose work changes, not by seniority. A director two levels up who will never touch the outcome belongs in the informed column, and the contractor who has to rewrite the invoice template belongs in the consulted one.

Principles is the group that settles attitude in advance. There are two: one about what happens after a decision, one about how fast to reach it.

1. Disagree and commit — say the objection before the decision, then execute alongside everyone else even when the call went the other way. It exists to stop the pattern where someone says nothing in the room and "I was against it from the start" in the hallway. It asks for two things at once, and that is the part teams miss. Demand the commit without genuinely providing the room to disagree and the phrase turns into a way to shut people up.
2. Two-way door — decisions cheap to reverse should be made quickly rather than debated. Changing button copy can be undone tomorrow, so it gets thirty minutes; replacing a pricing structure or a data model takes months to walk back, so it gets picked apart. Give every decision the same weight and the light ones eat the time the heavy ones needed.

Risks is where the first three groups collapse. Bikeshedding is the example everyone recognizes: hard items pass quickly because few people can argue about them, and the hours pile onto trivial items where anyone can have an opinion. A data migration plan clears in ten minutes because nobody can challenge it, and the next item, naming a button, takes an hour. Meetings without a written decider and a written stakeholder list drift this way by default.

The four groups stack in order. You settle who is involved before you can divide roles, roles have to exist before the principles do anything, and risks grow in whichever of the three is left blank. All of it runs on top of the channels that collaboration mode lays down. Collaboration mode decides where and how the talking happens; decision making decides whose words at the end of it count as the conclusion.

"I'm the decider on this one. Get your comments on the doc by end of day and I'll post the call tomorrow morning."

Not a consensus item — one person closes it, and the window for input now has a deadline.

"Isn't this a two-way door? Let's just try it and roll it back if it's wrong."

The cost of being wrong is small, so test it by shipping instead of discussing it further.

"We have three approvers on this. Make it one and move the rest to consulted."

Several people hold a veto, so nothing can close. Redraw the role table.

Pagedeck sorts decisions into three buckets. Copy on a screen, button placement, anything cheap to reverse — whoever owns that screen simply decides. Scope of a feature or a launch date, anything touching several teams — Mia collects input and then decides alone. Pricing, hiring and outside contracts — Grace decides. Those three lines sit on the first page of the handbook and every new hire reads them in week one. The buckets exist because being wrong costs different amounts: the first can be fixed the next day, the second costs a quarter to unwind, and the third has already been promised to someone outside the company.

The free-plan storage item went into the second bucket. Mia was the decider, Sofia and Ravi and Theo gave input, and Grace was informed of the outcome. The meeting ran once and ended in forty-five minutes. Sofia disagreed the whole way through and then wrote the notice email to existing customers herself — not because her objection evaporated but because there had been a real place inside the meeting to raise it. Without that place, the same objection comes back the night before launch wearing a different shape. What changed between the three-meeting version and the one-meeting version was not the quality of the analysis or the goodwill in the room. It was a name written down before the meeting started.

The most common mistake is reading "we need a decision rule" as "we're concentrating power in one person." Naming a single decider sounds like an announcement that nobody else's opinion counts, so the reaction makes sense. What actually gets fixed is not the size of the authority but its location. Decisions were already being made by someone before anything was written down; the someone just changed from item to item and nobody could predict which one it would be. Writing the location down tells everyone else when and where to put their input. Leave the slot blank and it gets filled by whoever talks loudest or ranks highest, which is the default in the absence of a rule rather than a more democratic arrangement.

The second mistake is believing one method can cover everything. Simple rules get followed, so the urge to standardize is strong, and a proposal to standardize on consensus is especially hard to argue against because it sounds fair. But the cost of reversal is not the same across items. Require full consensus for something reversible in a day and you have spent eight people's hour for nothing; let one person settle in twenty minutes something that takes months to unwind and the bill arrives later with interest. What actually happens in teams that standardize is not compliance but abandonment. People start skipping the rule on urgent items, and once it has been skipped, whether it applies next time depends on how someone feels that morning. Rules that survive tend to sort decisions into two or three kinds and attach a different method to each, and the sorting question is always the same one: how much does it cost to take this back.