How to bring a new tool to your team (and not get squashed in the process): 5 tips for successful adoption

Bringing any new tool into an organization can feel like an uphill battle. It’s difficult to overcome inertia, even with the promise of improved workflows and happier teammates. Any change is hard, harder still when colleagues have grown attached to “the way we’ve always done things.” How can you get your team to see the light when you know there’s a better way?

We’ve spoken to many individuals over the years who have successfully brought CircleCI into their organizations, so we’ve asked them what tips they had for others working to adopt a new tool.

While these were shared specifically from folks who had navigated the transition to CircleCI, they should be useful to anyone trying to think through how to successfully guide your team to a change.

If you’re interested in trying CircleCI, or another tool, but not sure how to introduce it to your team, read on for five tactics we picked up from our customers about how to bring change to your organization.

Get buy-in from your manager.

Here’s a general tip for getting along with your boss: don’t surprise her. It’s probably a good idea to let your manager know when you are experimenting with a new tool or process. You never want to put your boss in a situation where someone else asks them about something you are doing that they don’t know about. This does not tend to end well.

It’s worth thinking through how you will loop your team lead in with your planned experimentation.

For example, consider how this conversation might go: “I’ve been noticing that our builds are taking up to 30 minutes to run, and that we have a lot of queuing on the team. I was thinking about trying a new, free tool on the new microservice we’re building. Do you mind if I spin that up in my free time to see if it works? I’m on track to meet all of my other goals, so this will just be a side exploration that we can potentially bring back to the team.”

Contrast that with, “Our builds are taking 30 minutes and the whole team is wasting time queuing. We need to stop all of our product work to focus on fixing this, and I’d like to be taken off all of my cards until we’ve identified a new solution and implemented it.”

It’s not to say that the latter approach isn’t the one that’s most effective to solving your teams’ issues, but getting someone to say yes to this is going to be an uphill battle. They have to be fully aligned that this is the most pressing need to solve, believe you can solve it, and have the political capital to tell their peers that feature work will slow or stop. That’s a tall order!

You’ll likely be more successful by framing this as a side project that will satisfy your curiosity, may help the team, and won’t distract you from your stated goals and priorities. A good manager is generally looking for things to say yes to – they want to give you room to experiment.

Ultimately, though, use your best judgment and your inside knowledge of how your manager is likely to react to choose the best course of action. If you know that your boss will definitely shut down any side projects, the old maxim about asking for forgiveness and not permission may be true for you.

Start small, and build momentum.

It can be tempting to go after your biggest, most complex repo to show that it will work for your hairiest scenarios. Don’t. As with any tool, there’s a learning curve, and starting small will help you ultimately move faster.

Starting small will also likely be the least impactful for your team, and allow you to experiment and build a level of comfort before you share your learnings with others. There’s a reason the Fortune 100s often have innovation labs or Project X teams where new ideas are tried, away from the core lines of business. It’s easier to experiment on the sidelines, fail fast, and try something again outside of the spotlight.

For those who are fans of personal finance, you can also take the snowball method and apply it here: start with your smallest, easiest projects to migrate to a new tool or process, get it going, and then move on to your next project. While this may not lead to the biggest immediate impact, the momentum in and of itself should help you get to your final adoption goal, faster.

Think about the person on your team who is most likely to dislike this change. Go talk to them.

If you’ve been on your team for any length of time, you probably have an idea of who is going to be most reluctant to the change you are suggesting. (If you can’t think of anyone, ask some trusted colleagues, privately, about who is going to hate your new idea the most).

Maybe there’s someone on your team who is responsible for maintaining or managing the existing tool or process you want to experiment with replacing. Or perhaps your colleague had a bad experience with a tool in a previous workplace, and talks about how terrible it was every time you bring it up.

Regardless of that person’s motivation, it’s always best to be direct and straightforward with the folks you think will be most resistant. Book some time with them, or ask to get coffee or lunch so you can get their input.

Your goal in this conversation isn’t to convince anyone that your way is the best way, but rather, to learn from your colleagues and understand their potential objections. Why do they hold the opinions they do? What are they trying to accomplish? What fears do they have around potential change?

Consider saying, “I’ve been thinking about this issue I’ve noticed on our team, and I wanted to explore some ways we might fix it. I know you’ve spent a lot of time thinking about this and you have some strong opinions. Can you tell me more about how you came to them?”

People generally respond well to being included in your thinking, especially at an early stage, and also to being asked for their thoughts and insight. Contrast this with the alternate scenario: Imagine you’re a subject matter expert or domain owner for something on your team, and then you find out someone else (who may not be a close colleague of yours, or who might be on a different team) is poking around your area of ownership. You would probably be much more annoyed, and much less likely to cooperate, than if you had been looped in from the beginning.

Frame the change as a risk to be avoided, not a win to be achieved.

Don’t neglect the “why” of the change you are proposing. Your team is busy, you have a million priorities, you might be over budget, under-staffed, and behind schedule. How do you help your team align behind your idea, and spend time to make a change?

The famous psychologists Kahnemen and Tversky talk about framing bias as a key driver in how individuals make decisions, and especially, how different arguments, or frames, are more likely to inspire people to make changes. Humans are much more loss-averse than gain-seeking, meaning they are more motivated to act in order to avoid a negative outcome rather than to achieve a positive one.

How can you use this to your advantage?

In practical terms, if you frame your suggestion as a net benefit (“we’ll be so much faster and our team will be happier”), you’re less likely to be successful in persuading others to join your cause. Changing your frame to potential loss (“we’re losing 2 hours of productivity per developer a day waiting, and people are so frustrated they are going to quit”) is much more motivating. It’s science!

This may also help you avoid the stereotype or misconception of wanting to use something just because it’s new, shiny, or different.

Demo, share, and invite questions.

Once you have your new tool up and running, invite your team to come and take a look. Lots of engineering teams have demo lunches or show and tells where individuals can share what they’ve been working on and what they learned. This is a great time to show off what you’ve learned, and why you like it.

One important thing to remember: be honest and transparent about areas you haven’t explored yet, or where something isn’t working as you’d like it to. It’s much better to have an honest, authentic list of pros and cons, than it is to share something as being, “THE MOST AMAZING THING EVER.” Inviting open dialogue about where a tool is working well, or hardly working, is a great way to get your team brainstorming solutions with you, instead of thinking that your presentation is too good to be true, and looking for faults.

This is also a good way to build organic momentum for a new process: your goal should be to leave a demo with your colleagues asking for a way to try it out for themselves.

Remember: a tool is not a silver bullet.

If your team has goals around moving to continuous delivery or adopting a DevOps mindset, remember that changing your tools might be one tactic, but it’s not a strategy for driving change.

Sometimes teams make the mistake of thinking that they can “do DevOps” or “start the digital transformation” simply by adopting a tool. While changing your tools might help you get there, there’s often underlying organizational process or a team dynamic that needs to shift as well. If you change your tools without changing your culture, it’s likely that the same problems will persist, just in a new wrapper. Don’t let this discourage you from trying new things, but do keep this in mind as you think through what’s realistic to accomplish, and in what time frame.

Have more tips to share? Let us know. How have you been able to create change on your team?