When technology organizations run into problems, they often look to tech products to solve them. It makes sense: we build tech to solve problems, so naturally we look to someone else’s tech to solve our problems.
But for any piece of tech to work as intended, you have to make sure everyone on the team agrees on using this technology to solve that problem.
If you’re thinking about rolling out a new tool to your team, you should also be thinking about how to get colleagues and management on board, how to embed that tool in your everyday workflows, and how to assess whether it’s working as it should. Tech that solves human problems needs humans to participate in those solutions.
However passionate you might be, declaring that Tool X will improve every aspect of every business process is unrealistic, and unlikely to earn you the support of your colleagues and managers—especially if you’re asking them to learn something new or tweak their workflows to accommodate a tool whose value they’re not convinced of.
Particularly when budgets are tight, many companies scrutinize tool usage to make sure they’re spending money wisely, not wasting it on shelfware—software you buy but never use. If your team isn’t aligned around the need for a new tool, adoption will probably be underwhelming, and your solution will end up gathering metaphorical dust.
In this article, we’ll lay out some strategies for keeping your new tool from becoming shelfware.
Focus on use cases
You can make a more compelling case for adoption by identifying the most impactful use case for your solution and leading with that. Aligning yourself from the beginning with a specific process like cloud migration or product releases can also help you articulate and demonstrate the value of a new tool.
In a recent post on our blog, Chelsea Troy, a staff data engineer at Mozilla, suggests starting by talking about the problem you’re trying to solve (“We get so many notifications that we miss important alerts and aren’t able to focus on our work”) rather than centering your proposed solution (“Look at this neat tool I found for managing alerts”).
Another tried-and-true method of showcasing a tool’s value and sparking interest among the wider org is to roll it out first to one or two teams in a pilot, like Dropbox did with Stack Overflow for Teams.
Identify your advocates
A successful tool adoption starts with the early adopters, who play a critical role in demonstrating a tool’s value and communicating that value throughout the org. These early adopters are your true leaders, says Stack Overflow engineering manager Peter O’Connor. Identify champions at the individual-contributor level: tech leads or stack engineers who have the knowledge and credibility to drive adoption by demonstrating and socializing the tool’s value.
Once your early adopters are in place, using your tool to solve their problems and telling all their friends about it, it’s time to think about identifying someone in leadership who can serve as an executive sponsor and high-level advocate for your adoption. This person can help ensure that your proposed implementation aligns with your company’s strategic goals, assist in building support and overcoming resistance from other executives, and otherwise provide support and direction to drive adoption. An executive sponsor should understand:
- What problems the new tool can solve, and how that positive change will impact the organization
- Who’s involved in introducing the new tool and how those teams/individuals can support adoption
- How implementation will affect employees, consultants, and customers
To encourage ongoing usage after your initial rollout, it can be helpful to identify power users or advocates who can spread the news about the tool’s value, help others get up and running, and incorporate the tool into your existing workflows.
Build consensus over time
You want people to want to use your tool. For that to happen, you must understand the context of the technical system you’re operating in. “Context is king” when it comes to getting technical teams to make big changes, says Troy: “Who has context on the system is who has power on the team. And that drives more technical decisions than we’d like to admit.”
Understanding that context requires talking to your teammates about what they need—and, more importantly, listening to them. Commit to understanding what your colleagues need and show them that their input matters to you.
Your goal, in Troy’s view, is to create “an environment in which people are able to ask questions and express concerns.” Make your coworkers feel heard, and they’ll be more likely to listen when it’s your turn to speak. This environment, Troy explains, “makes the difference between the big changes that sail through with support and the ones that get stuck in the mud because the team dragged their feet or outright resisted them.”
This view is echoed by O’Connor, the engineering manager at Stack Overflow. Rather than issuing commands and rushing the adoption timeline, he says, teams that roll out new tools successfully ask for input, take time to build consensus, and foster a sense of psychological safety in their teams.
Make adoption frictionless
You can minimize friction around adoption if you invest the time and energy up front to talk with and listen to your teammates, understanding the nature of their pain points and laying out how your solution will improve things. If you come charging in with a fully formulated plan and no interest in a collaborative discussion, teams will be slow to adopt a new tool or simply reject it.
Keep in mind that a tool that fits seamlessly into the ecosystem of tools and processes your team is already using has a much better chance of being adopted enthusiastically than a tool that interrupts an established workflow. That’s one reason why developers tend to adopt our paid platform quickly and easily when our customers introduce it: they’re already used to turning to Stack Overflow’s public platform when they get stuck.
In a previous role, my colleague Ryan Donovan saw firsthand how reluctant people are to use a new tool if it introduces clunkiness to their workflow. He was tasked with helping the engineering org adopt a Q&A product, but people primarily went to Slack for questions.
“Nobody was using the tool because it had a lot of proscriptive processes around it,” said Donovan. “First, all the questions were routed through pre-selected categories that we selected instead of letting the people with the questions select tags. Second, while the new tool had a Slack integration, leadership wanted to route questions to new channels specifically created to host questions. Both of these demanded workflow changes. No surprise that everyone still asked their questions in the team channels.”
Say no to shelfware
You may have noticed that many of the strategies we recommend here come into play before the tool is actually rolled out. That’s because the best way to avoid shelfware is to do your homework ahead of time:
- Learn where your tool can have the biggest impact
- Enlist advocates to demonstrate and socialize your tool
- Build consensus over time
- Minimize friction around adoption
To learn more about making tool adoption successful, register for our upcoming webinar: Five ways to drive tool adoption and avoid the dreaded “shelfware.”