When you are working in any sort of leadership role, you'll have to get people to work toward initiatives that you're leading or make changes you're proposing. Whether you're a line manager running a team day-to-day, or a principal engineer pushing technical initiatives forward, it all comes down to the intersection of people and technology.

When you are in one of these roles and you're championing an initiative, it can feel like the goal is to get people to agree with you on the proposal. But what you really need is for people to actually do the work, not just say that it sounds good. There's a big difference, because it's much easier for someone to agree something should happen than to actually do it themselves. This is especially true if the work is time consuming, unpopular, or difficult.

One way to get people to go from agreeing it should happen to actually doing the work is to get buy-in. When you have buy-in, people will actively work toward the goal instead of just agreeing to it. Getting buy-in is hard. It's also extremely rewarding, and it's how you get real work done as a leader. Without it, the work falls away when you're not around. With it, everyone will push forward together.

Do I have buy-in?

It can be tricky on the surface to tell whether you have buy-in from the folks you need to work with. Buy-in necessarily includes people saying the work should happen, and it also includes internal willingness to push things forward.

Here are a few signals that you might have buy-in.

Are they making suggestions? If people are engaged and making suggestions on how to improve a plan, even one they disagree with, it means they're committing to making it work. This is a good sign that you are getting or have buy-in. On the other hand, if people just say things like "it does sound like we need that" and loosely affirm without committing, they're probably not bought in.

Are they giving anything up? Decisions that matter involve trade-offs. After all, if there's just upside and no trade-off, a decision isn't really needed. With those trade-offs, the people you're getting buy-in from usually have to give something up to work toward your goal. Maybe a feature is deprioritized on the roadmap. Maybe you don't use the programming language they prefer. Whatever it is, if they're giving something up as part of agreeing, that's a very strong signal that you have buy-in.

Are the details concrete? If someone agrees something should happen, then it may or may not—but more likely, not. On the other hand, if they have a concrete and detailed plan for how to make it happen, it's more likely it will. We see this all the time with voting: if you just want to vote, you might not, but if you lay out when you'll vote and how you'll get there, you're much more likey to follow through. And that's why it's such a strong indicator: if you have a plan, you're likely bought in enough to do that planning; if you don't, you're not.

Have they said no to parts of it? If you suggest something and no one pushes back and no one says "no" (or gives skeptical glances and is non-committal), then you probably haven't hit buy-in yet. There's always a no of some form, to some detail. If you haven't hit any form of push-back then you're almost certainly seeing simple agreement, not buy-in. If you get some pushback and then people agree after the plan changes slightly, it's more likely that that's now actually buy-in.

My strategies for getting buy-in

As a principal engineer, I have to get buy-in for initiatives—whether they come from me or from someone else—as a large part of my job. My primary job isn't the code or the architecture: it's the upkeep of the entire sociotechnical system that is the company I work for, including our engineering teams and our software. In my time as an engineering leader, I've been able to add a few strategies for getting buy-in to my tool belt.

First, explain the problem and listen. Before I start advocating for a plan, I take time to listen to the people who will be on the project and the stakeholders for it. With internal engineering projects, this is usually talking to engineers and product managers and designers. In these conversations, I brief them on the problem I'm thinking about, including the impact of it. Usually I do this async ahead of time, with a quick recap at the start of our meeting. Then I ask a few questions and sit and listen. These listening sessions help us dial in what the direction should be, and it helps people understand why the problem matters. It also helps me catch things earlier if it doesn't matter, and cut off work before we invest in it. And it helps when you listen, because people feel understood and can better take in what you suggest later.

Explain the why. Sometimes leaders fall into this trap of just telling people what should happen. This works sometimes, and you have a certain amount of capital to do it. But it's better if you explain why something matters and the impact of it. When people understand why their work matters and that it can make a big difference, they're a lot more motivated to work make it happen, and more willing to work on things they usually avoid. Even when they'd make a different decision, understanding why we're going this direction helps people disagree and commit, and feel okay with it.

Help with clarifying the trade-offs. When we're making these decisions to prioritize one thing, we'll have to give something else up. To make it easier to commit to the plan, I help with figuring out the trade-offs. This takes a few forms. Sometimes it's talking to product managers or talking to stakeholders to explain to them why there's a trade-off and what it entails, and advocate for something or another. These can be uncomfortable conversations, and taking them on can get you buy-in because you're making that commitment easier by removing an uncomfortable task. And sometimes it means just talking with someone to help them work out what the options for trade-offs are and which ones would make sense.

Figure out concrete plans together. Just like with voting, a concrete plan makes an action more likely to happen. You can leverage this quite effectively. I like to work with people to figure out, concretely, when in their work stream something will be done and who will do it. If you're able to get this level of detail, it usually means you get buy-in. And if you're not able to, then you'll see exactly what's in the way of getting there, so you can go back and change your initiative or find a more effective way to advocate for it.

Work on building trust. This is a long-term one, not something you can do for any given initiative, but it's imperative. If you don't have trust between you and your coworkers, everything is much harder. While this is a whole topic in itself, there are lot of things you can start doing to build it up over time. Things I like to do here include transparency, owning my mistakes, public praise (with consent), and virtual coffee chats or in-person meetups! When you have a high-trust team, it's a lot easier to get buy-in. Many of these activities, like listening and planning together, are dramatically easier with trust than without it (if they're even possible without it). And hey, an excuse to get coffee with the cool folks I call coworkers? Never going to pass on that one.

As always, if you have any signals or strategies that I've missed here, I'd love to know! My email is below, and I reply to every reader who writes to me.

Thank you to Adam and Dan for reviewing earlier drafts of this post and giving me very useful feedback.