Pre-read 6: The Law of Buy-In
People accept the leader first, then the idea. Technically correct proposals die because this order was reversed.
The standard first: Working Backwards and DACI
Amazon's PR/FAQ process (from the book Working Backwards) treats buy-in as a designed process, not a talent. Before writing any code, you write the press release for the finished product, plus a FAQ answering every hard question. Then you revise it through review after review. Bezos put the PR/FAQ documents for S3 and EC2 through more than ten drafts. The document is not paperwork. It is a buy-in machine: every reviewer who shapes a draft becomes a part-owner of the idea.
DACI (Driver, Approver, Contributors, Informed) solves a different failure: proposals that die because nobody agreed who decides. Naming the Approver before the debate turns an endless discussion into a decision with a date.
Two quieter tools complete the set. They are also this week's managing-up module. SCQA (Situation, Complication, Question, Answer) compresses your pitch into the two sentences a busy executive will actually read. Nemawashi, a practice from Toyota, means preparing the ground: walk your proposal around in private, one conversation at a time, before any meeting where the decision happens. If a stakeholder sees your idea for the first time in the meeting, the meeting is where it dies.
Everett Rogers' research on how ideas spread adds the order: win the early adopters first. The majority follows people, not arguments.
The law behind the standard
Maxwell's law explains why all this process is needed: people accept the leader first, then the vision. If they have not accepted the messenger, the message gets a polite hearing at best. The engineer's version of the mistake is believing that being right is enough to spread an idea. Your dead RFC was probably not rejected. It was heard, by people who had not yet accepted you, and it slowly starved.
The order matters: who, then why. Before you push a proposal, check whether people have accepted you, not just heard the idea.
On your track
- IC (Staff/Principal): compare the RFC that died unread with the one that landed after three private conversations. Same quality of idea. Different buy-in work.
- Lead/EM: a failed reorg dies the same way a failed RFC dies: idea heard, person not accepted. Headcount requests and priority changes follow the same law.
The story: Slack's pivot
Stewart Butterfield's company was building a game called Glitch. The game failed. He told the team they would instead bet everything on the small internal chat tool they had built for themselves. On paper, that is a terrible pitch: give up the mission you joined for, and follow me into a side tool. The team followed, and the side tool became Slack. They did not accept the vision. There was barely a vision yet. They had already accepted Butterfield.
Before the session
Come with one question this reading left you with. Starting points:
- Think of one proposal of yours that died. Be honest: did they reject the idea, or had they never accepted you?
- What initiative do you need support on right now? Can you say it in two SCQA sentences?