Consent decision making is my go-to tool when a team needs to agree on how it wants to work: review rules, on-call duty, the definition of done, meeting times. A decision stands as soon as nobody has a reasoned objection left. So people don’t have to be thrilled about a proposal. They only have to be able to live with trying it.
I care about this because shared decisions tend to fail in one of two ways. Either the group talks until the meeting runs out of time and nothing changes. Or someone says “Let’s just vote”, and the outvoted minority only half-heartedly goes along with the result. My article on the advice process covered decisions that a single person makes. This one covers the other case: the group decides together, and you facilitate.
In short
With consent decision making, a proposal is accepted when nobody has a reasoned objection, so you don’t need everyone’s approval. That makes team decisions faster than consensus and more durable than a vote. The biggest pitfall is the objection round: without a clear test, every gut feeling turns into a veto.
What you will learn in this article
- how consent differs from consensus, majority vote and the advice process
- how to facilitate a consent round in nine steps
- how to test whether an argument is a real objection
- how to resolve objections without talking a proposal to death
- which mistakes break the method in everyday team life
What is consent decision making?
Consent means a proposal is accepted when no serious, reasoned objection stands against it any more. The bar is not “Does everyone like this?” but “Is there a serious reason not to try it like this?”. Sociocracy 3.0, a freely licensed collection of patterns for self-organization, sums up the goal as “good enough for now, safe enough to try”.
Two terms are central, and as a facilitator you need to keep them clearly apart:
- Objection: an argument showing that the proposal brings a risk or consequence the group should avoid, or that there is a worthwhile improvement. An objection blocks until it is resolved.
- Concern: an assumption that isn’t backed by enough reasoning or evidence yet. Concerns are heard and written down, but they don’t block.
An example makes the difference tangible. “I don’t like mandatory pair programming” is a preference. “Our two part-timers are only here in the mornings, so nobody is left to pair with in the afternoon” is an objection, because it points to a concrete consequence. “I have a feeling this will slow us down” starts out as a concern, and it may well prove justified at the next review date.
That is why every consent decision comes with a date on which the group reviews it. This date is the real reason the method works: if you know the decision will be back on the table in six weeks anyway, it is much easier to say “I’m not convinced, but I have no objection”.
Consent vs. consensus, majority vote and advice process
Consent and consensus sound almost the same, yet they lead to very different conversations in a meeting. With consensus, everyone keeps looking until each person agrees. With consent decision making, it is enough that nobody has a reasoned objection. The table shows how the common approaches differ:
| Approach | When does the decision stand? | Strength | Weakness |
|---|---|---|---|
| Manager decides | when the manager has decided | fast | little knowledge from the team, low ownership |
| Majority vote | when more than half agree | fast, simple | the minority’s arguments are left out |
| Consensus | when everyone agrees | high ownership | slow, one person can block without a reason |
| Consent | when nobody has a reasoned objection | durable and still fast | needs facilitation and practice |
| Advice process | when the decision maker has sought advice | very fast, spreads responsibility | doesn’t fit when everyone has to carry the rule together |
My rule of thumb: if the decision mainly concerns one area of responsibility and one person will implement it, use the advice process. If the team sets a rule that everyone is expected to follow afterwards, use consent decision making. Keep manager decisions for cases where legal requirements, budgets or security leave no room, and name them openly as such.
Where consent decision making comes from
The idea comes from sociocracy. Dutch educator Kees Boeke used it at his school, and his former student Gerard Endenburg applied it from 1970 onwards to the electrical engineering company he had taken over from his parents. This became the Sociocratic Circle Organization Method with four basic rules, the first of which says that consent governs decision-making.
Today you mostly meet the method in two forms: classic sociocracy and Sociocracy 3.0 (S3) by Bernhard Bockelbrink, James Priest and Liliana David. S3 is more modular. You can adopt individual patterns such as “Consent Decision-Making” without restructuring the whole organization. For a single development team that is the more pragmatic way in, and the process below builds on this pattern.
Consent decision making in nine steps
At first glance the process looks formal. That is on purpose: especially at the beginning, the fixed order helps because it stops the group from drifting into a debate about principles after two minutes. Plan 20 to 40 minutes for a manageable proposal. As the facilitator, you can use the sentences in quotation marks word for word.
The consent decision making process: after the objection round, you either test and resolve an objection or go straight to the decision.
1. Clarify the purpose
Before anyone judges a proposal, it has to be clear which problem it is meant to solve. Describe the reason in one or two sentences and get a quick okay from the group, ideally in writing beforehand. “We want to agree on how quickly pull requests get a review, because changes often sit around for several days. Does this description work for you?”
2. Present the proposal
The person who wrote the proposal presents it. A good proposal states what changes, who is responsible for what, when it takes effect, when it will be reviewed and how you will know whether it works. If one of these is missing, it will almost certainly come back later as an objection.
3. Ask clarifying questions
Now only questions that help people understand are allowed. “Does this also apply to hotfixes?” is a clarifying question. “Why not just two approvals?” is already an evaluation and belongs in a later round. As the facilitator you say: “Any questions so that we all understand the proposal the same way? Let’s hold back opinions for a moment.”
4. Quick reactions round
Going around the group, each person says in one or two sentences what they think of the proposal. Nobody replies to anyone else, and the author doesn’t defend anything. This round makes sure that the quieter people have spoken once before objections come up. Often a lot gets cleared up here because misunderstandings become visible.
5. Ask for objections
Now for the core: “Does anyone have an objection or a concern?” Let people show their position at the same time, for example with hand signals or cards. That prevents the first voices from influencing everyone else. If there are no objections, jump straight to step 8.
6. Test one argument at a time
If there are objections, take only one at a time and test whether it really is an objection. The next section explains how that works. If it isn’t one, record it as a concern and go back to step 5.
7. Resolve the objection
A confirmed objection is not a no. It is information on how to make the proposal better. The group amends the proposal so that the objection is cleared, and then you ask for objections again. This loop of asking, testing and amending continues until nobody has an objection left.
8. Celebrate the decision
Sounds silly, but it matters: say out loud that the decision stands and read it out once. “So from Monday on: every pull request gets a first review within one working day. We’ll look at it again on January 15.” That way everyone knows exactly what was decided.
9. Record concerns
Finally, collect the concerns and write them down together with the criteria for the review. Some concerns are worth a short discussion, others are fine as a note. At the review date you bring them out again, and then you’ll see whether a gut feeling has turned into an objection. An architecture decision record or a short wiki page is enough for storing them.
Objection or concern? How to test an argument
The test decides whether consent decision making stays quick or whether every “I’m not sure about this” becomes a veto. Sociocracy 3.0 suggests three questions, which I translate for development teams like this:
- Effect: Would the proposal fail to solve the problem from step 1?
- Side effects: Would it cause harm or risks, in the team, in neighbouring teams or for customers?
- Effort: Would it waste time or money, or is there an improvement whose benefit clearly outweighs the effort?
If the person answers at least one question with yes and can explain why, it is an objection. Personal preferences, criticism of the method itself or “I would have done it differently” don’t make it through.
Running the test in the meeting
A short three-step routine works well. First, ask the person to explain their argument. Then ask whether everyone has understood it. Finally ask: “Does anyone see it differently, fully or in part, that this is an objection?” If nobody disagrees, the objection is confirmed. If someone does, let that person explain their counter-argument and test it the same way. Afterwards ask the original person: “What is left of your argument?”
That sounds like a lot of effort, but in practice it rarely takes longer than five minutes. It also has a side effect I really like: the group discusses arguments, not people. Whoever raises an objection puts it to the whole group for testing instead of having to defend it against the author.
When someone is unsure
Encourage people to bring up an argument as a possible objection when in doubt. One test too many is better than a withheld objection that comes back three weeks later as silent resistance. This only works if nobody in the team gets funny looks for raising an objection. My guide to psychological safety in teams shows how to build that foundation.
Resolving objections without talking a proposal to death
Once an objection is confirmed, first ask the person who raised it: “What would we need to change so that your objection goes away?” Usually you get a small, concrete amendment. If they have no idea, ask the group and let one person phrase the best suggestion. Only if that doesn’t work either do you open a short, time-boxed discussion, for example five minutes.
There are also ways that don’t change the proposal itself:
- defer the objection, with a name, a deadline and a next step
- ask a small group to work out an amendment
- leave the proposal unchanged and watch closely when a change would cost more than it brings
- move the review date forward so the risk is limited in time
The last point in particular resolves a surprising number of objections. “Let’s try it for three weeks instead of three months” often turns a perceived big risk into a manageable experiment.
Example: a team sets review rules
To make the process tangible, here is a made-up example. A team of six builds the booking app for a bike rental. Pull requests often sit for two or three days. Mia writes a proposal: “Every pull request gets a first review within one working day. One approval is enough to merge. Review in six weeks based on the average time to first review.”
In the clarifying round, Jonas asks whether “working day” counts differently for his part-time colleague Lea. Mia clarifies: the team’s working day counts, not the individual’s. In the reactions round most people like it, while Lea is sceptical.
When Mia asks for objections, two people raise their hands. Tom is concerned that a single approval lowers quality. During the test he can’t back this up any further, so it goes into the notes as a concern, with a reminder to watch for bugs after merging at the review date. Lea, on the other hand, brings a clear argument: changes to the payment integration could go live with just one approval and without a second experienced person looking at them. Nobody disagrees, so the objection is confirmed.
Lea suggests that changes in the payment module still need two approvals. The group adopts this, Mia asks for objections again, and no hand goes up. Decision made, after 25 minutes. Tom’s concern and the metric for the review go into the team wiki.
Common mistakes with consent decision making
The proposal is too big
If you want to decide “our entire development process” by consent, you will collect objections without end. Break big topics into small proposals that can each be tried on their own. One proposal per round is a good guideline.
Discussion before the proposal
When the group first wants to “openly collect ideas”, the meeting quickly turns into an endless brainstorming session. Generating ideas together is valuable, but it belongs in a separate step before the consent round. The round itself works on a written-out proposal.
The manager facilitates and judges at the same time
If you facilitate as the team lead, your comments carry more weight than everyone else’s, whether you want them to or not. So hand over facilitation as soon as you have a strong opinion on the proposal yourself, and then raise your objection like everyone else. Rotating facilitation, which many teams know from the retrospective, works just as well here.
No review date
Without a date, every decision feels final, and people become more cautious with their consent. Write the date into the decision and send the invitation right away.
Objections turn into vetoes
When one person keeps raising objections they can’t back up, one thing helps most: following through with the test consistently. If a pattern remains anyway, a one-to-one conversation is worth it. Often a permanent objection hides an issue that has no place in the group.
When consent decision making doesn’t fit
Not every decision needs a group. For technical details that one person is responsible for, the advice process is faster. In an acute incident, a clear call matters more than an objection round. And for decisions made outside the team, such as budget or staffing, a consent round would fake a say that doesn’t exist. In those cases be honest about who decides, and still collect the team’s arguments.
My take
I think consent decision making is one of the most underrated tools for team leads. It doesn’t require a new organizational structure, a certificate or any software. It only changes the question you ask at the end, from “Who is in favour?” to “Who has an objection?”, and with it the whole dynamic in the room.
I get critical when the method is introduced as a cure-all. If you decide every little thing by consent, you build yourself a new meeting bureaucracy. And consent doesn’t replace leadership: someone has to trigger proposals, clarify the frame and make sure decisions are actually implemented and reviewed. In my view, that is exactly the job of a leader who wants to hand decisions over to the team.
FAQ
What is the difference between consensus and consent?
With consensus, everyone has to agree. With consent, it is enough that nobody has a reasoned objection. Consent asks about resistance, not enthusiasm, which is why it usually reaches a workable result faster.
What counts as a serious objection?
An argument showing that the proposal misses its goal, causes harm or wastes resources unnecessarily. Personal preferences and unfounded fears don’t count; they are recorded as concerns.
How long does a consent round take?
For a well-prepared, manageable proposal, 20 to 40 minutes is usually enough. It takes longer at first, because the group is still learning the process.
Can you use consent decision making remotely?
Yes. You can share the proposal and purpose in writing beforehand. For the objection round, reactions in the video call or a quick poll in the chat work well, so everyone answers at the same time.
Your next step
Pick a team rule that is wobbly anyway, such as review times, meeting rhythm or how you handle bugs during a sprint, and write a proposal for it with a review date. Print the facilitation card and run your next decision with exactly these nine steps. Afterwards you’ll know whether the method suits your team.
Now over to you: how does your team make decisions that affect everyone, and where does it get stuck most often? Let me know in the comments.
📄 Printable cheat sheet – The facilitation card with all nine steps, facilitator phrases and the three test questions for objections. Download PDF · View online
Sources
- Sociocracy 3.0: Consent Decision-Making (CC BY-SA 4.0)
- Sociocracy 3.0: Objection
- Sociocracy 3.0: Test if Arguments Qualify as Objections
- Sociocracy 3.0: Resolve Objections
- German Wikipedia: sociocracy
This post was created with AI assistance.
👉 Next step: More for team leads: my cheat sheets put the essentials on one printable page.
📬 Stay updated: New articles on serverless, AI and leading tech teams via RSS, browser push or the weekly newsletter (in German).
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)