You have an idea at work. You’ve discussed it with some of your coworkers and garnered enough support to bring it into a forum. You’ve begun the process of encouraging decision makers to buy in. Folks are thinking about what you said, and they’re considering solutions.

But folks are busy; they won’t spend more time on your idea than they think is absolutely necessary. How are they making their decision? And how much time will they spend making it? If you understand what’s happening in the decision-maker’s head, you can cater to it—and that makes decision-makers more likely to green light your idea.

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

As someone who professionally evaluates new technologies for use, let me explain how I evaluate technologies and how we might use them:

1. What is our pain? This might take a while to figure out. Don’t rush this, because your coworkers have to feel that pain to care about your solution, since switching costs also cause pain. If you want to speed up this step, expose your coworkers to the pain you’re trying to solve. Guide them into situations where they’ll experience it for themselves instead of lecturing them about it. See part 1 of this series for more details on how to do that. The more people are complaining about a pain, the higher I’m prioritizing a way to fix it.
2. What is the probability that this solution can solve our pain? Once I know we need a solution, I need to know if your solution is going to work for us. If it takes more than 10 minutes to figure this out, the solution needs a better pitch. Whole startup businesses are expected to answer this question in one minute. I expect one decision to be capable of the same in 10x that amount of time.

   As for the probability itself, of course, the more likely it is that this tool can solve our pain and the more sure I am about that probability, the more likely I am to move on to the next question instead of tabling the idea.

3. What pain must we undergo to determine for sure if this tool can solve our pain? Is it a 45 minute proof of concept? Is it a day of experimentation? Is it a weeks-long integration that could dead-end? Those are in order of likelihood that I’ll support undertaking it, from highest to lowest. Of course, if several of your team members are on board with investing their time in this investigation, the happier I am to commit our time to it.
4. If the tool can solve our pain, what pain is it creating that replaces our current pain? Would I rather have this tool’s pain than whatever pain this tool solves? A proof of concept in our specific use case helps answer this question. Plus, once we have a proof of concept, the default has changed. Before we had a proof of concept, the default was to leave it the old way. Now, the new way exists, which is a big deal. The default is no longer the old way—it’s somewhere in the middle. This is fantastic news for your solution. You’re out of the phase where you have to change the status quo. Now, you have only to establish a new status quo where your idea is in effect.
5. What does using this tool require me to agree to? Legal may have to approve the license, and I may have to move some priorities around. But once I ask this question, I have flipped into ‘I’d like us to try this’ mode. At this point, I’m on your solution’s side.

The do’s and don’ts we’ve discussed in parts 1 and 2 of this series are designed to help you lead me, or any decision-maker at your company, through this list of questions to the conclusion that we should try out your idea. It will help you bring your team to collectively figure out the pain. It will help you to harvest your team’s objections and learn to address them. It will help you build pitches and identify resources that fall inside the time limits your decision-makers have for answering the early questions. And it will help you garner the support you need from your team to get the resources (time and effort) needed to answer the later questions.

Conclusion

We like to think of ourselves as makers, but we also need people skills and organizational skills to accomplish our goals in a team setting. Remember, the same refactor with different socialization can make you look like a hero, or it can make you look disruptive (in the bad way). As you grow in your career and you have more large changes and sweeping recommendations you’d like to make, building support for those recommendations becomes just as important as your technical skills.