Reading Time: 10 minutes

This is the first post in a three part series about how to socialize your ideas to get your team to adopt them.

You’ve discovered a thing you’d like your team to adopt, and you’re really excited about it. Maybe it’s a new tool or technology, like ARKit. Maybe it’s a game-changing, large-scope refactor. Or maybe it’s a new process, like weekly retros. Whatever it is, you’d like to get started right away. Surely your coworkers will agree, right?

Don’t be surprised if your new hotness doesn’t elicit joy from your team. In fact, they’ll probably push back on you. Change requires an investment of time and effort from your whole team. The team might have to give up some productivity while they learn a new skill or get used to a new thing. Those investments can be a pain. If your team isn’t convinced that your tool will reduce some bigger pain, they won’t want to take on the investment pain.

In order to get the team on board, they have to understand the pain your idea solves. If you keep hawking the tool before they understand that pain, they develop an emotional aversion to the idea: ‘Oh my god, Steve the Retro Evangelist is bringing up retros again.’*

* I have been Steve the Retro Evangelist. I have since learned.

So, how do you socialize a new tool on your team? Let’s go over some do’s and don’ts.

DO NOT: Present your idea for the first time in a meeting with the entire team. 

Meetings disrupt our work. We have to change gears from building things, and we don’t get back into the building gear for some period of time after the meeting. Meetings are also expensive. If you have five people in a room and they make an average of $100k a year each, a meeting costs the company $250 per hour ($50 an hour * 5 people). Your coworkers know that. As they leave their desks to walk to a meeting they are thinking “this better be relevant.”

Presumably, if the whole team is together, they know the topic they’re there to discuss, and they’ve agreed that it’s relevant. You show up and drag the topic onto your new thing. No one in this meeting has had the chance to agree that this thing is relevant. So you’re co-opting time that people have given to something relevant. Co-opting people’s time without their consent annoys them, at best. It’s an emotional hurdle you don’t need in your effort to get your idea adopted.

DO: Start with one on one conversations.

Talk to your coworkers one on one about your idea and ask them for their opinion. When people feel like you care about what they want, they’ll care more about what you want. Start with folks you trust to always be honest with you. Opt for people who share your day to day experience at work and who might also have firsthand experience with the pains led you to this idea in the first place. The pain is the star of the show here. We will keep coming back to this.

Talking to folks one on one also gives you a chance to practice your pitch a few times before you present it to any higher-up decision makers. You can find out what people’s main concerns might be and adjust your pitch to address those concerns. You’ll be able to weed out mistakes in your pitch to make it more convincing when it’s time to present to the yay-or-nay person. And when you do make that pitch, you might even have coworkers who you can recruit to your cause.

DO: Surface the pain to your coworkers.

What is bothering you about your team’s current workflow that motivates you to push your solution? Are you annoyed at having to write the same code over and over in different places? Are you tired of trying to poke your way around an opaque tool? Are you losing track of things that cost you time and money? Before you push your solution, pull your coworkers to it by making sure they feel the pain that you feel.

Before I do a major refactor, I’ll deliberately pair program with key people on my team on the kind of problems that my refactor would solve. I want them to experience the pain firsthand; I want to hear them say ‘oh my god this is annoying.’ After I have that admission of pain from a critical mass of people on my team, I’ll propose my solution, and I’ll offer to spearhead the refactor. I will craft a concise explanation of how our workflow changes after the refactor, and I’ll point out why I think the new way is nicer for us than the way we’re doing it now.  I have ‘negative testimonials’ about the old way, which I can whip out to capture the attention and agreement of others on my team. This approach allows me to muster support for my refactor and then, in spearheading the refactor, look like I’m taking one for the team.

Imagine the same scenario, same refactor, but instead of socializing my solution, I go off on my own, do the refactor, and push. My team didn’t understand the pain that the refactor solved, so all they’re seeing is the pain of learning the new way to do things. To them, it looks like I made a unilateral decision that screwed them over—the opposite of what a team player would do. Keep in mind, in both circumstances, I wrote the same code. The only difference is how I introduced it.

It’s the same for you. Instead of shoving in a solution by yourself, start your socializing journey by exposing other people to the pain that you feel. That way, you can get support for resolving that pain. If you have a good solution, then you’ll have support. Or maybe someone else will have a solution that you like even better than yours. Let your team help you!

DO NOT: Expect people to know what your solution is or what it does.

As you introduce people to your idea, you want them to feel comfortable with the suggestion rather than defensive. If you explain it really fast or use a bunch of really specific terms that your coworkers don’t know, folks might feel awkward stopping you to ask what you’re talking about. If someone does stop you, be sure not to feign surprise.

DO: Prepare a 1 minute elevator pitch that starts with the pain, then describes your solution and how it can solve that pain.

You’ve done a little socializing already by exposing coworkers to the pain and hearing their thoughts about whether/how it might be solved. Here is your moment to start introducing your solution. You want your initial explanation to be short and focused on the pain your coworkers have felt. No one wants to feel lectured in a one on one conversation. So stick to a pithy statement and then prepare to answer your colleagues’ questions.

Most of your time talking to colleagues about your solution should consist of asking questions. What are their concerns? How would they feel about the change?

You also want to answer their questions. If you don’t know the answers to their questions, you have more homework to do. Don’t make up an answer. Say you don’t know the answer and go look it up. This is one big advantage of the one on ones: find out what you need to know to competently defend this idea in front of higher-ups or a room full of people.

In particular, don’t be shocked if a colleague mentions a prior solution that sounds very similar to yours. I can’t tell you how many times I’ve had what I thought was a new idea, only to find out someone else tried it 5, 10, or 30 years ago. In fact, when it comes to software, I’m pretty sure I haven’t had a single completely new idea yet. This happens. You don’t have to feel bad about it. It validates your intuition: someone else thought of this! That means you’re not completely off your rocker! (Or if you are, you’re not alone). The solution itself might not have worked out for some reason. Awesome. You want to know all about that, too, so you can foresee potential issues with your idea and examine if your use case or implementation is different from the failed case in a way that it might succeed this time.

If your colleagues’ questions and comments lead you to believe they might be open to the idea, you can offer to send them a little more info that they can look at on their own time. This is a step forward! That said…

DO NOT: Send your colleagues more information on your idea by passing them a link to a 3 hour online course.

Your colleagues’ time is valuable. Just because you have an itch to do this particular thing doesn’t mean your colleagues will carve out three (or four, or five, or eight) hours outside of work time to train themselves on  this thing you want to do. In addition, even if they were willing to try, three hours is a long time and creates a large opportunity for your potential allies to get frustrated or discouraged. You want to minimize the time it takes for your colleagues to get their questions answered about your idea. Don’t worry: if their initial, shallower questions have the answers they’re looking for, they’ll ask deeper questions later.

DO: Choose an article that takes maybe 10 minutes to read, preferably one that links to more info.

See above. Try to find one that someone else wrote, rather than writing one yourself. You’ll have a stronger case if you can marshal broader support for the tenets of your idea.

Conclusion

You have an idea to help your team solve a problem. That’s awesome! More power to you. But we’re not at the implementation step yet: first you have to get the backing of your team. I hope this article puts some tools in your toolbox to help you succeed in socializing your idea. Instead of presenting the idea for the first time in a large meeting, start talking to your colleagues one on one. Show them the pain that you’re experiencing that led to your idea. Do they also find this pain painful? Ask them what they think of your idea to solve it! They might have questions or concerns: these are opportunities for you. You can do your homework and find out the answers to these questions so that, if team leaders and decision makers ask them later, you’ll have informed answers at hand. Prepare a short pitch about your idea that doesn’t require your coworkers to know everything about your proposal yet. If your colleagues still seem interested after the pitch, you can find some additional material to send them—but keep it short so they’ll actually look at it!

Once you have some grassroots support, it’s time for the next step: scaling up your effort to convince more team members and decision makers to try your idea.

If you liked this post, you might also like:

Leading a Software Rewrite at your Company

Adding Members to your Software Team

Modern Professionalism: It’s Not About the Suit and Tie