Nemawashi: how to prepare a decision before the meeting

These separate nemawashi from a routine pre-meeting briefing:

Scale the effort to the decision. A small change may need a few conversations; a proposal that spans several departments needs a plan. The test: can you name something you learned that changed the proposal or confirmed an important assumption? If all you have is that people listened politely, keep checking.

A practical sequence. At Toyota the draft is often an A3, a one-page summary of the problem and proposal that is revised after each conversation.

1. 1

   Frame the problem before defending a solution. Describe the situation, its consequences and the decision needed. Separate what you know from what you suspect. Mark the brief as a draft and say which requirements are fixed, which are open and who decides.

2. 2

   Map the people whose views matter. Think about who will use the process, maintain it, fund it, approve it or deal with its side effects. Note each person's role: decision owner, specialist adviser or affected participant. Ask each contact who else should be involved.

3. 3

   Hold short, low-pressure conversations. Present the proposal as something to improve, not to endorse out of loyalty. Give people time to think, and offer a written reply if that suits them better. Ask before passing on sensitive comments.

4. 4

   Revise and work through trade-offs. Sort feedback into missing evidence, operating limits, resource needs, competing priorities and disagreement about the goal. Check facts, take resource conflicts to whoever sets priorities and keep a short change log. Do not promise one team speed and another flexibility.

5. 5

   Check support explicitly. Ask each person where they stand on the revised version. Silence, attendance or a friendly chat is not commitment. Recheck with people affected by later changes.

6. 6

   Move to the formal decision. Present the proposal with its reasoning, alternatives, resources and remaining concerns. Say who was consulted and what changed. Afterward, tell contributors what was decided and which of their points shaped it.

A well-supported recommendation to stop is a valid result too.

Open questions draw out what the proposal misses:

Listen for conditions as well as preferences. We could support this after training needs a different response from this does not address the problem. Record the substance of each concern without turning the notes into a list of who is resisting.

Four simple categories help. They are a working aid, not a traditional Japanese scale:

Then pin down what support means. If someone supports a pilot, do they provide staff, review the results or simply agree it can go ahead? Keep open objections visible for the decision owner rather than averaging them away.

Nemawashi and consensus building overlap but are not the same. In Japanese companies nemawashi often comes before ringi, the formal circulation of a written proposal for sign-off across departments and levels. Keep the stages apart:

Someone may understand a proposal without supporting it, or support it without the authority to approve it. You do not need a new approval system to borrow the idea. Keep your sponsor, committee or sign-off route, and do the consultation before it.

Broad support leaves practical questions open. Check the groundwork against four things:

Look for concrete outputs: a corrected assumption, a new dependency, a changed sequence or a confirmed resource. These say more than a final meeting that ends without disagreement. For example, ask the team that would run a new report to produce a sample and explain each step before you ask for approval.

Three illustrative cases:

Across all three: consult before committing, let feedback change the proposal and keep support separate from authorization.

Plan a consultation stage when several of these are true:

• Other teams must change: Another team will change its work or provide resources.
• Assumptions need testing: Only the people affected can check them.
• The method is open: The outcome is clear but the best way to reach it is not.
• Mistakes are hard to undo: A missed dependency would be costly to fix later.
• There is time: The proposal can still be revised in a meaningful way.

Set an end point and say what would justify going ahead, changing direction or stopping. Keep it short for small, reversible choices inside a delegated role. In an urgent situation, follow the response procedure and consult as far as time allows. Do not invite debate on a fixed requirement; ask instead about the real choices, such as sequence, communication or how work is shared.

For each item, point to the document, conversation or commitment behind your answer, and mark unknowns as unknown:

• Problem: People describe the issue and the intended outcome the same way.
• Evidence: Key observations are checked and remaining assumptions are named.
• Participation: Affected people and specialists had a real chance to contribute.
• Alternatives: Credible options were considered, including waiting or saying no.
• Revision: You can say what changed because of the consultation and why other ideas were declined.
• Support: Each stakeholder has stated a position on the current version.
• Resources: Staff, time and money are confirmed by the people who control them.
• Concerns: Open objections are visible and fairly described.
• Authority: It is clear who approves and which procedure applies.
• Follow-through: Owners, review points and reasons to reconsider are set.

Not every uncertainty has to disappear. Separate the uncertainty the organization accepts from a missing condition that blocks approval, and put that difference in front of the decision owner. Nemawashi often feeds hoshin kanri catchball, where plans pass between levels before they are fixed.