Getting buy in for an idea is an undervalued skill for knowledge workers.

It holds new managers back. It separates senior engineers from staff, principal, and beyond.

There are myriad ways to get buy in. I want to cover three models I’ve found useful in my own career.

Activation Energy

I managed a senior engineer who had “right” ideas that never got buy in. A hyperbolic example follows.

We really need to switch to Python 3, move to protobuf for service-to-service communication, and implement service discovery.

This would come as we were encountering a difficult project challenge at crunch time. The tech stack would be Python 2.7 with Twisted, JSON-based REST communication, and a largely monolithic architecture with a few decoupled services.

This engineer was perpetually frustrated. They had topped out as a senior engineer for over a decade now. Senior isn’t an up-or-out role (a topic for another day). But a key to moving beyond senior is being able to influence the organization and achieve buy in for your ideas.

The coaching I landed on with this engineer centered on activation energy. Think back to high school chemistry.

The organization or tech stack or $X is operating at its current energy level. You have an idea that could bring it to a new, better state.

The energy required to achieve your new state is untenable for the organization.

Could you instead achieve 80% of your goal by making one, palatable suggestion at much lower cost? Instead of changing three variables, what if protobuf alone would help solve the project’s problems?

You’re 1/3 of the way to your technical changes. You’ve got 80% of the benefits. The project was pushed along, not delayed further by your ideas.

Consider the activation energy the organization will need to accept your idea.

Shackleton’s Dogs

This is a variant of boiling frogs.

To be clear, I learned this at Calibrate SF in 2017 from Karen Catlin’s talk, The Art of the Pre-Meeting.

Ernest Shackleton and his crew while stranded in the Antarctic were quickly running out of food.

He concluded: we have to kill the dogs.

But he couldn’t just say that. So, he visited the men at night around their fires. He’d hear them bemoan the dwindling food supplies. He’d empathize and help them see that the dogs ate many seals per day that could feed several men over days.

I imagine he’d ask questions like this.

How many seals did we get today?
How many are left?
Did you get much?
How are the dogs?
Are they eating?
How much?

It sunk in. The dogs were killing the men.

And so, when Shackleton finally proposed that they kill the dogs, the men understood.

I’ve found that when I “know” what the right idea is, most times I shouldn’t tell the team what we should do. I present the same constraints that I’ve considered.

One of two things happens.

The team arrives at the same conclusion.

Or very often they find more accurate constraints and better solutions.

Regardless, because they were part of the process they are bought into the solution.

Be careful. Consensus leadership on everything is ineffective. Many decisions though are worth the wait.

Get the group to consider the constraints of the problem space you’re working in.

That’s Right

The last model comes from Never Split the Difference, the only book I would recommend on negotiation.

This “technique” isn’t about negotiation, it’s about relating.

As an engineer, it’s my tendency to want to be right. And for others to acknowledge it. That’s ineffective.

Others want to be heard.

If you’re trying to convince a person of something, it’s more powerful when they say, “that’s right”, not “you’re right”.

If they say “you’re right” then you’ve lost because now they’ve resigned.

If you echo their positions and they say, “that’s right”, they’re now ready to listen. They know you heard them out.

It’s better to be effective than to be right.