The advice process is one of the simplest rules a team can use to distribute decisions: anyone may decide, but they have to seek advice first. That sounds almost too simple. Yet it answers a question that keeps many team leads up at night: how do I stop being the bottleneck without ending up in a team where everyone does whatever they like?
I care about this topic because decisions in development teams tend to get stuck in one of two places. Either with the lead who is expected to sign off on everything, or in meetings where everyone has a say and nobody actually decides. In this guide you get the rule, the steps, a template for asking for advice and a plan for introducing the method in your team.
In short
With the advice process, anyone on the team may make a decision once they have asked everyone affected and the relevant experts for advice. The advice has to be heard and weighed, but it does not have to be followed, and responsibility stays with the person who decides. The biggest pitfall is a lead who overturns decisions after the fact.
What you will learn in this article
- What the advice process is and how it differs from consensus
- How the four steps work in practice
- Whom to ask and how to phrase a request for advice
- How to combine the method with ADRs and introduce it in your team
- Which mistakes quickly destroy the method again
What is the advice process?
The advice process is a decision rule made of one sentence and one condition. First the sentence: anyone may make a decision. Then the condition: before deciding, they seek advice from two groups, namely everyone who will be noticeably affected by the decision and people who know the subject well.
The person deciding has to listen to that advice seriously. Following it is optional. They weigh it, decide and own the outcome. Formally, nobody has a veto. Even the lead gives advice like everyone else, as long as they are affected or bring relevant expertise.
This shifts something fundamental. Decisions move to where knowledge and initiative live, which usually means the person who noticed a problem first. Leads no longer need to know everything in order to decide everything. Instead, their job is to make sure the right conversations happen.
Where the method comes from
The term was coined by Dennis Bakke, who introduced the advice process at the energy company AES and wrote two books about it. It became more widely known through Frederic Laloux’s book “Reinventing Organizations”, which describes companies built on self-managing teams. For software teams, Andrew Harmel-Law’s article on martinfowler.com is especially worth reading. He applies the idea to architecture decisions and sums it up as “anyone can make an architectural decision”, provided that affected people and experts were consulted first.
The advice process compared with consensus and top-down decisions
To place the method, it helps to look at the usual alternatives. The table shows where they differ. Consent, by the way, means a decision stands as long as nobody raises a reasoned, serious objection.
| Method | Who decides? | Veto possible? | Speed | Responsibility |
|---|---|---|---|---|
| Top-down decision | the lead | not applicable | fast, but a bottleneck | the lead |
| Majority vote | the group by voting | no, the minority is outvoted | medium | shared, often unclear |
| Consensus | everyone together | yes, every person | slow | shared, often unclear |
| Consent | the group, if there is no serious objection | an objection triggers joint problem-solving | medium | the group |
| Advice process | one person after seeking advice | no | fast | the person who decides |
The key difference from consensus: with the advice process, nobody hunts for the lowest common denominator. Whoever decides may consciously reject a piece of advice if there are good reasons. That makes the method faster and responsibility clear. At the same time it requires trust, because the team has to accept that a decision sometimes goes against what they advised.
So the advice process is no cure-all. For rules that affect everyone equally and are hard to reverse, such as new core working hours, consent is often the better fit. I explain how to facilitate such a decision in my guide to consent decision making. Trivial matters, on the other hand, need no advice at all.
How the advice process works in four steps
The steps are short. Still, it pays to go through each one deliberately, because the inconspicuous parts are exactly what builds or breaks trust in the team.
The advice process in four steps: spot, propose, seek advice, decide and inform.
1. Spot a problem or an opportunity
Someone notices something: a recurring deployment failure, a library that is no longer maintained, a meeting that helps nobody. That person takes the initiative or hands the topic to someone better placed. From this moment it is clear who decides: the person making the proposal.
2. Draft a proposal
A rough proposal comes before the actual request for advice. An empty “What do you think?” leads to endless discussions. A concrete proposal with two or three alternatives, in contrast, gives advisors something to push against. If you are unsure, test the direction informally with one or two people first.
3. Seek advice
Now the person deciding asks everyone affected and the experts. This can happen in a conversation, a chat thread, a pull request or a regular meeting. A clear deadline matters, so that asking for advice does not become a permanent state. Anyone who stays silent until then has had their chance.
Harmel-Law also recommends deliberately asking people who are likely to disagree. That takes a bit of courage. In return, blind spots come to light before they get expensive.
4. Decide and inform
Finally, the person weighs the advice, decides and informs everyone they asked. That includes a short explanation of why a piece of advice was not taken. This step is forgotten most often and matters most for trust. People who notice that their advice was heard will gladly give it again next time.
Whom do you need to ask in the advice process?
The two groups sound clear, but questions come up in practice anyway. A rule of thumb: the bigger the impact and the harder a decision is to reverse, the wider you ask. A new linter rule in your own repository may need two quick replies. Switching databases, however, affects other teams, operations and possibly the budget.
So nobody has to guess, keep a short list in the team wiki of who is typically asked about which topics. For example:
- Interfaces and APIs: the teams that consume the interface
- Security and data protection: the person responsible for information security or data protection
- Costs: whoever owns the budget once an agreed threshold is exceeded
- Operations: whoever is on call and gets up at night when things break
- Ways of working and rituals: the whole team
When judging who is affected, the word “noticeably” helps. Someone who only notices a change at the margins does not need to be asked. You can still keep them informed. Otherwise every request for advice turns into an email to everyone, which is exactly what the method tries to avoid.
Template for requesting advice
A consistent format saves time on both sides. The following template fits into a chat thread, a ticket or a pull request description:
Request for advice: <short title of the decision>
Decision owner: <name>
Advice requested by: <date>
What is this about?
<2–3 sentences: problem or opportunity, why now>
My proposal:
<what you plan to do>
Alternatives I considered:
- <Option A>: <pros and cons>
- <Option B>: <pros and cons>
Whom I am asking and why:
- <person or team>: affected because …
- <person or team>: expertise in …
My question to you:
What am I missing? Which risks do you see?
The last question is the most important one. “What am I missing?” invites real advice. “Do you agree?” turns the request into a hidden vote, and suddenly you are back at consensus.
Recording advice with ADRs
Advice that was only given verbally is forgotten after three months. That is why the advice process and Architecture Decision Records (ADRs, short decision logs stored right in the repository) work so well together. An ADR captures context, options and the decision. Simply add a section “Advice received” where you note who advised what and when, and how you handled it.
I describe how to set up ADRs in detail in the article Architecture Decision Records: Template and Example. The status “Proposed” fits the advice phase nicely: the ADR sits in a pull request, advisors comment directly on the text, and the decision takes effect when it is merged. A fictional example from an online bookshop:
## Advice received
- Nov 12: Orders team (affected): run the old interface in parallel
for three months. Accepted.
- Nov 13: Data protection (expertise): no concerns, retention periods stay the same.
- Nov 14: Warehouse team (affected): prefers option B. Not accepted,
because option B needs a second data store that nobody wants to maintain.
Introducing the advice process in your team
You do not announce the advice process at an all-hands and hope for the best. A gradual introduction where the team helps shape the rules works much better. This is how I would go about it:
Step 1: Set the boundaries
First, clarify which decisions fall under the rule at all. A delegation board helps you define, topic by topic, how much room the team has. The guide Levels of delegation explains how. Also agree on limits that are not negotiable, for example legal requirements, security policies or an amount above which the budget owner must be consulted.
Step 2: Start with a pilot area
Pick an area with manageable risk, such as developer tooling, team rituals or technical decisions within a single service. Agree on a period of six to eight weeks and say openly that you will review it together afterwards.
Step 3: Create a fixed place for requests
Requests for advice need visibility. A dedicated chat channel or a label in your ticket system is enough to start with. Harmel-Law additionally describes a weekly, open, one-hour advisory forum where upcoming decisions are presented. Nothing is decided there; the forum only gives advice. For a single team, a fifteen-minute slot in the existing weekly meeting is often enough.
Step 4: Lead by example
Use the method yourself, visibly and with the same template. When you as team lead decide something, seek advice first and explain afterwards how you took it into account. That shows more clearly than any slide that the rule is meant seriously.
Step 5: Review and refine
After the pilot period, look back together in a retrospective. Which decisions went well? Where did someone feel bypassed? Who started requests for advice, and who never did? The answers lead to adjustments, for instance to the list of whom to ask about which topics.
Common mistakes and how to avoid them
The lead overturns decisions
This is the fastest way to kill the method. Anyone who has seen a carefully prepared decision reversed afterwards will not start a second request for advice. Harmel-Law considers architects taking back control to be the most dangerous failure of all. If you as a lead have strong concerns, they belong in the advice phase, not in the time after it.
Advice turns into a veto
Some advisors phrase their advice like a condition: “This won’t happen without my okay.” Restating the rule kindly and clearly helps here. Advice is valuable, but the person who started the request is the one who decides.
The same people always decide
After a few weeks you often notice that three experienced people start almost all requests. Quieter team members sometimes need a direct invitation or a small first decision before they trust the process. The foundation is a climate in which mistakes do not put your reputation at risk. There is more on that in the guide Psychological safety in teams.
Feedback is missing
People who give advice and never hear what came of it feel used. A short note in the thread is enough: decided as follows, your point about X made it in, I did not take Y because …
Mistakes get punished
More people making decisions also means more wrong decisions. That is part of the plan. Small mistakes that surface quickly are learning opportunities. If you look for someone to blame instead, you will soon have a team that would rather ask whether it is allowed to decide.
My take
I think the advice process is one of the most underrated tools for team leads. It resolves a dilemma many of us know: you want a self-organizing team, but you do not want to debate every decision in a big group. The rule takes a minute to explain and still reaches deep into team culture.
I do see two limits, though. First, the method needs maturity. In a team where people distrust each other, asking for advice quickly becomes a political game. Second, it does not replace strategy. If nobody knows where the product is heading, everyone makes well-advised individual decisions in different directions. Principles developed together, as Harmel-Law suggests, act as a compass here.
My advice to leads: start small, use the method yourself first and hold back when a decision turns out differently from how you would have made it. That is exactly the moment your team realizes you mean it.
FAQ
What is the difference between the advice process and consensus?
With consensus, everyone has to agree and every person can block. With the advice process, one person decides after seeking advice. Nobody has a veto, and responsibility clearly lies with the person who decides.
Do I have to follow every piece of advice?
No. You have to listen seriously and weigh it. If you do not take it, briefly explain to the advisors why.
Which decisions is the advice process suited for?
For anything that reaches beyond one person but does not affect everyone equally: technical decisions, tools, workflows or spending within an agreed frame. Trivial matters need no advice, and rules that apply to everyone are often a better fit for consent.
Does the advice process work for remote teams?
Yes, quite well in fact. A written request in a fixed channel with a clear deadline also reaches part-time colleagues and people in other time zones. Visibility and the feedback at the end are what matter most.
Your next step
Pick a decision that is coming up in the next two weeks anyway and make it with the advice process: copy the template, ask two to five people, set a deadline, decide, report back. Afterwards you will know fairly precisely whether the method suits your team.
Over to you: how does your team make decisions that affect several people? Let me know in the comments.
Sources
- Andrew Harmel-Law: Scaling the Practice of Architecture, Conversationally (martinfowler.com)
- Reinventing Organizations Wiki: Decision making and the advice process
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)