I've talked at a few conferences lately about my experience building a component library, and without exception, I always hear the same thing: "This sounds great! But how do I get the buy-in from my manager or team to actually do it?"
The key to getting buy-in for anything is to convince people that their investment level will be small as compared to the worth they derive from the finished product. Remember that investment comes in many forms – money is the obvious one, but investments also come in the form of time, energy, talent, adjustment to routines, etc. The more you're asking of people, the better the "reward" will have to be. It's not always an easy hurdle to jump, but it is crucial – skipping the step of getting buy-in will leave you high and dry, either without the resources to bring your idea to reality, or (even worse) with a beautiful finished product that goes unused. It's an important skill for developers of every level to master, and being able to effectively get buy-in can help you advance your career and climb the ladder.
We talk about as "getting buy-in" as one skill to be mastered, but you can really break it down several smaller steps, each of which I'm going to talk through in detail. Because this sprung from my conversations about component libraries, I'll use that as the example of the action we're trying to get buy-in for. The steps involved are as follows:
- Knowing your Material
- Knowing your Audience
- Making your Case
- Answering Questions & Fielding Critique
- Following Up
Knowing Your Material
Before you can convince anyone else to take an action, you need to know exactly what's involved. It's not cool to persuade someone to do something you don't entirely understand – not to mention, you won't be very good at convincing anyone if you're unable to explain or defend it. In our hypothetical component library situation, you'll need to start by figuring out what would actually be involved in the creation and maintenance. Would you use a framework? What, specifically, would be involved in the setup process? How would you get components out of the library and into your app? What types of components would be valuable? How much upkeep would it need? Where do you see this fitting in your team's current development process?
You don't need to have encyclopedic knowledge of your subject, but make sure you're educated at a high level on what the general process would look like and how it might affect day-to-day processes (both positively and negatively) and be prepared to talk about it.
Knowing Your Audience
You'll have a much easier job convincing someone to do what you want if you know what they care about. That's the kind of thing that makes a person sound like a B-movie villain who just kidnapped someone's dog, but it's true – and it's why things like user personas exist. If you know what motivates someone, you can craft an experience that caters to them and it will be exponentially more effective in getting them to take a desired action – whether that action is clicking the "Add to cart" button or starting a component library.
There are big generalizations you can make about personal motivations; for example, pretty much everyone is motivated by the idea of less work and more money, so those are pretty safe bets. However, if you know more about a person or group of users, you can go beyond the general and start to speak their language. Some people are very analytical – they like to see the hard data. In our component library scenario, this person might be most effectively bought in by arguments about improvement to sprint velocity, reduced number of bug reports, and reduced lines of code. If you know someone is really lazy (🙋♀️), you could persuade them by talking about how much easier it will be to just import pre-written components and how much time they'll save. If you know someone is a big-picture thinker, talk about the long-term benefits: stacking smaller components together to make more complex ones, developing a cohesive design system, better UX.
Every person has an angle, and it's your job to find what it is. It's an exercise in empathy; put yourself in their shoes, and imagine hearing your proposal from their perspective. If you have a group of folks with different motivations, include at least a few things that will appeal to each person. And if you really, genuinely have no idea...stick to the "less work, more money" approach – it's always a winner.
Making Your Case
This is the most central part – letting stakeholders know about the problem you're trying to solve, and why your idea is the right solution. Many people imagine this as a big speech at a high-pressure meeting, and it scares them away from putting their valuable ideas through the buy-in process...but, that's not the way it has to be. Not everyone is a skilled public speaker and, while that's a great skill to develop, it's not the only approach you can take here. You could just as easily make your case using a slide deck with speaker notes, a written proposal, a pre-recorded video, or one-on-one discussions. If you feel comfortable addressing a group in person, then by all means go for it – but also know that it's not the only way to achieve this, and it shouldn't be a blocker.
That being said, the crux of this step is being able to communicate why your proposed action is valuable. This is where the "Know your Audience" thing comes in – you need to make your case based on the motivating factors of your team. Whether that approach is going to involve laying out all the facts and then holding a Q&A session or making an emotional appeal followed by a group discussion should be based on who you're talking to and what they care about. Remember that you're not making the case to yourself (because hey, you should already have you convinced) and what sold you on the idea may not be what sells others.
The most important part of this step is ensuring that it's a conversation and not strictly a presentation. People will have questions, and it's important to validate and address their concerns, even – and especially – if they push back on your proposal. Which brings us to...
Answering Questions & Fielding Critique
Inevitably, someone will want to know more about a specific part of your plan. This is where that first step – Knowing your Material – comes back into play. By this point, you should feel like a subject matter expert on whatever you're proposing; fairly well-equipped to answer most of the questions that come up. If you're not there yet, take it back to step one. Remember, though, that the term "expert" is relative – you don't need to know everything to be a subject matter expert, just more than the other people in the room.
If questions come up on the spot that you're not sure about, don't let it throw you. It's totally fine to say "Good question. I hadn't considered that, but I'm writing it down." or "I was generally thinking about something like X, but haven't researched that specific scenario." In that situation, it can also be useful to turn it around and say "I'm not sure. How do you think we should handle that?" or "I don't know – what's your gut feeling on it?" This can open up a question into a discussion, which is often a useful way to tease out any bumps in the plan you might not have thought of on your own.
There will also be people who don't love your idea, and that's okay too. Don't take it personally – constructive feedback is valuable, rejection is normal, and the world will keep turning. The more you do it, the more you get better at absorbing the value and letting the rest roll off your shoulders. It's a bummer when things don't go exactly as you hoped, but it's also important to remember that there's a big difference between "not right now" or "not exactly how you described" versus "not ever, no matter what". Your plan may need adjustments and you may need to make compromises. It might not happen on the timeline or with the scope you had originally imagined.
But you also don't need an immediate 100% stamp of approval for your proposal to be a success – all you need is enough room to get your foot in the door and prove the value. In our component library situation, maybe your team just doesn't have the time or resources to do a full UI audit and get Storybook set up the way you want. Are there ways you could scale that plan down, to meet your team where they are now? You could set up a "shared components" folder in your app to start collecting the components that will one day become your library. That doesn't take as much up-front investment as setting up a full library (and you won't get all the benefits), but it's absolutely better than nothing. And more importantly, it can be enough to prove the value of your idea, so in another couple months you can say "Look how useful this collection of components has been – imagine if it also had documentation and a way to preview the components!" If your original plan doesn't get the buy-in you wanted, strip it down to MVP and see if you can start there and build up.
Following Up
Getting that "yes" feels good, but remember that it's not the end – in fact, it's just the beginning. Once you have your approval, it's important to strike while the iron is hot. If you let it sit for too long, it will inevitably get back-burnered, and you'll have to go through the buy-in process all over again to get everyone back on board. Write stories, draw up a timeline, put together a committee – whatever you need to do to capitalize on the momentum you have. It's also useful at this point to open it up to other people who may be interested in working on the project with you. The more people are involved in the work, the easier it is for them to stay invested – something happening off in a corner without them is unlikely to stay top of mind.
In the case of a component library, you need everyone to actually use it once it's set up – just getting it going isn't enough. If you get that "yes" and then hole up to work on it all by yourself, it will (a) take much longer and (b) feel like "your" project that other people may not be comfortable working on. Whereas if you start with a group, right from the beginning it feels like the library belongs to everyone – and because they've all put in time and effort, they feel more invested in its long-term success.
If you got feedback and need to adjust the plan, it's important not to let the ball drop. Again, time is of the essence – you'll have more success if you can make the changes quickly and get it back in front of people while they still remember it. You may need to go through a few rounds of iteration before getting the "yes", and it's your responsibility to write those emails, schedule those meetings, etc. Nobody else is going to champion your idea, so you have to own it until it's done.
And if you got the firm no, it's time to wait it out. Don't push or nag, or you'll just turn people off entirely. Let it rest, maybe make a few tweaks, and then put it in your back pocket while you wait to see how things shake out. Likely, you'll have a new opportunity in the future to bring it up again, possibly to a more receptive environment. Maybe there will be staff changes and one of the naysayers will rotate off your team, or you'll encounter a new problem that more easily allows you to highlight the value of your plan as a solution. Or, possibly, something will happen to show you why you got the "no" in the first place and you'll gain a fuller understanding of why your idea really isn't the right answer.
However it ends up – yes, no, or somewhere in-between – there are great benefits to be had just for going through the buy-in process. It gives you experience in researching and putting together a proposal, it helps you know the people on your team better, and it shows leadership that you're a motivated person who's invested in improving their work environment. Best case scenario you get all that, plus the thing you were lobbying for. A lot of people find getting buy-in to be an overwhelming or intimidating process, but you can handle it in the same way you would a complex code issue – break it down into small pieces, and tackle it step by step!
Top comments (0)