Nemawashi + SPADE — The Complete Decision Lifecycle

Putting It All Together

These two frameworks are not alternatives — they are complementary stages of a single decision lifecycle:

┌─────────────────────────────────────────────────────────────┐
│                    DECISION LIFECYCLE                         │
│                                                               │
│  ┌────────────┐    ┌──────────────┐    ┌──────────────────┐  │
│  │ NEMAWASHI  │───▶│    SPADE     │───▶│ DISAGREE&COMMIT  │  │
│  │            │    │              │    │                  │  │
│  │ 1-on-1s    │    │ S — Setting  │    │ Full execution   │  │
│  │ Gather     │    │ P — People   │    │ No sabotage      │  │
│  │ feedback   │    │ A — Alts     │    │ Retrospect later │  │
│  │ Incorporate│    │ D — Decide   │    │                  │  │
│  │ Close loop │    │ E — Explain  │    │                  │  │
│  └────────────┘    └──────────────┘    └──────────────────┘  │
│                                                               │
│  Timeline:       Days/Weeks      Hours/Days       Ongoing     │
└─────────────────────────────────────────────────────────────┘

Phase 1 — Nemawashi (Days to Weeks):
The Responsible person (from SPADE's P) conducts 1-on-1s with all Consulted parties. They gather concerns, incorporate feedback, and refine the alternatives. The proposal that enters the formal meeting should be materially different from the one you started with.

Phase 2 — SPADE (Hours to Days):
The formal decision meeting happens. The Setting is clear. The People know their roles. The Alternatives have been refined through Nemawashi. The Decider makes the call. The decision is Explained broadly.

Phase 3 — Disagree and Commit (Ongoing):
Everyone executes. Concerns are logged for future retrospectives, not used as ammunition during implementation.

A DevOps Example — IaC Standardization:

Your platform team wants to standardize on Terraform for all infrastructure-as-code. Here is how the full lifecycle plays out:

• Nemawashi: You meet individually with the security team (they want policy-as-code integration), the networking team (they use Pulumi and don't want to switch), the app teams (they just want it to work), and your VP (they care about cost and hiring pool). You incorporate the security team's requirement for Sentinel policies into the Terraform option. You add a migration support plan for the networking team.

• SPADE Setting: "Which IaC tool will be our standard for all new infrastructure by Q2?"

• SPADE People: You are Responsible. The VP of Platform is the Decider. Security, networking, and app team leads are Consulted. The CTO is the Approver (veto only for existential concerns).

• SPADE Alternatives: Terraform, Pulumi, AWS CDK — each with cost analysis, migration effort, hiring market data, and ecosystem maturity assessment.

• SPADE Decide: The VP chooses Terraform, citing the larger hiring pool and ecosystem maturity, despite the networking team's Pulumi preference.

• SPADE Explain: A company-wide document explains the decision, the alternatives considered, and the migration timeline. The networking team's concern is acknowledged explicitly: "We heard the Pulumi preference and have committed to a 90-day migration support window."

• Disagree and Commit: The networking team disagrees but commits to migrating their Pulumi modules to Terraform over the next quarter.

Key Point: The total elapsed time for this process might be 3–4 weeks. Without the framework, the same decision could take 3–4 months of circular meetings — or never get made at all, leaving teams on divergent toolchains indefinitely. The framework doesn't eliminate conflict; it channels conflict into a productive structure with a guaranteed resolution point.