Defining the "Who" and "How"
Nemawashi prepares the ground. SPADE provides the structure. Created by Gokul Rajaram at Square (now widely adopted across Silicon Valley), SPADE is a decision-making framework that eliminates the most common source of organizational dysfunction: ambiguity about who decides.
Think of SPADE as a contract that a group signs before beginning a decision process. It answers five questions, one per letter.
S — Setting
What exactly are we deciding? What is the deadline? Why does this decision matter now? What happens if we don't decide?
This step is more important than it appears. Many "disagreements" are actually people arguing about different decisions. One person thinks the question is "Should we adopt Kubernetes?" while another thinks it's "Should we migrate Service A to Kubernetes by Q3?" Aligning on the precise decision statement eliminates a huge class of unproductive debate.
Example Setting:
Decision: Which container orchestration platform will we standardize on for all new services?
Deadline: March 15, 2025
Why now: We currently run three different orchestration systems, causing duplicated tooling effort and inconsistent security posture.
Cost of inaction: Each month of delay costs approximately 40 engineering hours in duplicated maintenance.
P — People
SPADE defines four roles. Note the similarity to RACI (Responsible, Accountable, Consulted, Informed), but SPADE is sharper — particularly in how it treats the Decider:
| Role | Definition | Count |
|---|---|---|
| Responsible | Does the research, writes the proposal, gathers data | 1–2 people |
| Approver | Has formal veto power (e.g., VP of Engineering). Veto is reserved for existential concerns, not preference disagreements | 0–1 people |
| Consulted | Must be heard before the decision is made. These are your Nemawashi targets | 3–8 people |
| Decider | The ONE person who makes the final call after consulting is complete | Exactly 1 person |
The most critical element: there is exactly one Decider. Not a committee. Not a vote. One person. This is what makes SPADE work. Committees diffuse accountability. A single Decider owns the outcome — which means the decision will get made.
A — Alternatives
The Responsible person must present at least three realistic options. If you only have one option, you haven't thought hard enough. If you have more than five, you haven't filtered enough. Each alternative must include a clear description, estimated cost (money, time, people), pros and cons, and key risks.
Example:
Option A: Adopt Kubernetes (EKS) — $45K/month, 3-month migration, team has partial expertise
Option B: Adopt Nomad — $30K/month, 4-month migration, team has no expertise
Option C: Standardize on existing ECS — $35K/month, 1-month migration, team has deep expertise
D — Decide
The Decider reviews the alternatives, considers the input from Consulted parties, and makes the call. This is not a vote. The Decider may choose an option that the majority disagrees with — if they believe it's the right call and can justify it. The Decider's job is not to find the most popular option; it is to make the best decision given all available information.
E — Explain
The decision is communicated broadly — not just to the people in the room, but to the entire affected organization. The explanation includes: what was decided, what alternatives were considered and why they were rejected, and who the Decider was. This transparency is what builds trust. People can disagree with a decision, but they cannot claim they weren't informed or that the process was opaque.
When interviewers ask "How do you handle disagreements on technical direction?", reference the SPADE pattern explicitly: "I ensure we have a clear decision statement, identify a single Decider, present at least three alternatives with trade-offs, and then the Decider makes the call. After that, we disagree and commit." This shows you have a repeatable process, not just good intentions.
Key Point: SPADE's power comes from separating input from authority. Everyone who is Consulted has the right to be heard. But only the Decider has the right to decide. This prevents two failure modes: (1) decisions by committee — slow, lowest-common-denominator outcomes — and (2) decisions by loudest voice — fast, but lacking buy-in. In practice, the Decider almost always chooses an option that reflects the majority input. But having a single accountable person means the decision will get made, even when consensus is impossible.