Engineering Buy-in

Context: I have been a SWE for 6 years, 3 of which were at Apple.

You work at a tech company, and have an excellent project idea that you’d like to pursue. How do you convince those around you?

The most important tactic: individually talk about it with many relevant people, before you finally pitch it to a decision-making group.

Say, there’s going to be a meeting where you pitch your proposal. People in the meeting who are ranked #2-5 by seniority and relevance to this problem will weigh in on it.

Your odds of success go up dramatically if you’ve talked to many or all of them in advance, and addressed their issues or incorporated their additions.

Why does this work?

First, there are some reasons that just involve your proposal being more coherent:

Address non-fatal issues: There’s something you’ve gotten wrong in your proposal, or some sort of non-obvious edge case. Your peer catches it, and you fix it ahead of time.

Understand team norms: Particularly if you’re newer to the team, this sort of meeting is the perfect time to get a sense of what the next steps ought to be - how does an idea become a project on this team?

Reframing: Use the conversations to understand what framings most resonate, and how you can tie this into existing initiatives the organization is likeliest to support.

And there are others that deal a bit more with human biases & inclinations:

Long discussions hurt your odds: Discussions that are mostly positive and wrap up quickly, with no real objections, are much likelier to rapidly result in your proposal being approved. As the discussion gets drawn out, your proposal seems more fraught.

Preempt misunderstanding: Some decision-makers might misunderstand part of your proposal - you can make the discussion go more smoothly if more of them understand your project ahead of time.

Preempt heel-digging: It’s natural for people to have a hard time changing their mind quickly. If someone brings up an objection, and you fully address it, they often will instinctively dig in to an oppositional frame regardless. You can prevent this by addressing their objection ahead of time, and giving them the opportunity to slowly come around to your side.

Bring people inside your circle: A form of the endowment effect, you get decision-makers to feel like they’re part of the project and thus root for your success. It might be expedient to go further in some cases, framing the project as a collaboration - in which case you might borrow some of their reputation.

Practical notes: How do you execute on this?

Different teams have different structures. You likely want to follow existing conventions for both your discussion 1 (1:1 convos), and your discussion 2 (group decision-making).

Common discussion 1 formats:

Send your coworker a Google Doc via Slack, along with a list of 3-4 high-level questions you’d like their input on

Optional: make a new copy of this Google Doc for each person you talk to

Chat with your coworker over lunch/coffee, and tell them about your idea

Slack your coworker with a few lines about your proposal, and ask if they’d be willing to chat more over Zoom, then talk through your idea (with or without a doc)

Common discussion 2 formats:

Send a formal 1-pager to your manager or skip-level manager

Show a demo, and then discuss your proposal during a team standup

Talk through a doc in a meeting with your manager or skip-level manager.

Set up a dedicated meeting to talk about this proposal

Also, during discussion 2, signal the buy-in you’ve gained during discussion 1. Be faithful to the actual level of buy-in. Some examples:

Re-share an existing Google Doc, which already has previous comments from discussion 1 with a high-relevance coworker, which are either positive or issues that have been satisfactorily addressed.

When demoing or pitching, acknowledge useful contributions of relevant people to your proposal.

When you’re done presenting, ask someone who you already know has bought in to speak on your proposal next.

Leaders must engineer buy-in downwards too

It’s necessary to engineer buy-in upwards, when you’re trying to convince your leadership to greenlight a certain project. But this is extremely relevant downwards too - where it switches to being more about team morale instead.

Here are some sample contexts:

You’re a director or startup CEO, planning to make a significant strategic pivot.

You’re a manager planning to build project X in manner Y, staffed by engineers A & B.

In theory, you could just jump to a discussion 2: announce this to the broader team and see what happens. But, you’re often going to take a morale hit - your reports raise concerns, you address these concerns slowly and unsteadily, the atmosphere around this project is dour.

Similar tactics to getting buy-in as an engineer apply here as well: take aside the most relevant parties ahead of time, address their concerns and get their buy-in, and then broadcast their buy-in to the rest of the team.

Engineering buy-in may be good for the company

This whole process might seem a little phony - the quality of your idea hasn’t really changed, why should the company reward engineering buy-in? Some reasons:

This encourages autonomous collaboration - engineers are incentivized to think of proposals that others will work with them on. The ability to collect buy-in is an honest signal of your ability to continue to organize this project, and the extent to which others will support it.

Collective truth-seeking happens cheaply - ideas get refined and iterated on in cheap, small-group manners, and big-group discussions happen quickly. In its healthiest form, decision-makers remain unerringly critical when they hear bad ideas, and sparingly support only the best ideas they hear.

Overall, this seemingly back-channel discussion 1 should perhaps be read as the organic default channel by which new ideas get developed.

Engineering buy-in may be bad for the company

But, there are many reasons this can go poorly. It’s useful to dive into some darker tricks and mechanisms of action:

Seed groupthink: Starting a discussion with the most-respected people all speaking in favor of the proposal can make would-be detractors feel sheepish, and decide to go along with it.

Exclude oppositional peers: If you’re the one sending out the meeting invite, it can be beneficial to sneakily not invite coworkers who you know hold an opposing perspective - and I’ve seen this done to great effect.

Collaborative deception: Teams often misrepresent reality, or overestimate the impact of their projects, leading leaders to lose the ability to understand their own organization. Coalitions where multiple teams act together can allow them to further capture their leaders’ ability to sense-make, to the detriment of the organization. [relevant Emmett Shear thread]

Thus, engineered buy-in can often hurt companies - proposals pitched by the savviest coalitions trump the most effective proposals.

A leader’s willingness to be contrarian & deeply inspect proposals is often very important - as the effectiveness of engineered buy-in indicates that a consensus of your subordinates might be surprisingly weak evidence for the strength of a proposal.

Engineering buy-in may be bad for you

In a healthy organization, you receive credit for your successes and blame for your failures. Thus engineering buy-in is effective if you have underrated ideas, but also lets you shoot yourself in the foot by fooling the organization’s truth-seeking process.

Depending on how trusted you are, you might not even require buy-in to proceed, or end up with decision-makers incredibly excited to support anything you propose. This is a similar idea to Outside Game, Inside Game, ie:

You might find yourself with a great idea, but no buy-in

You might find yourself with buy-in for a terrible idea, and end up holding the bag with no way to execute

You might thus find yourself wanting to reverse the advice you hear here - and ask: I’m getting buy-in too easily on my ideas, even when they’re bad, how do I make my collaborators more critical?

Thanks to Jay Hickey, Panda Smith, and Ross Rheingans-Yoo for feedback on this post.

Liked this post? Get email for new ones