Getting your manager to say ‘yes’ to DevOps tools

This post originally appeared on The New Stack here.

Have you ever found yourself in a situation where you have discovered a new tool that may be able to solve a problem for your team? Did you bring it excitedly to your manager only to be shut down by a conversation about cost/benefit analysis and return on investment? It can be difficult to introduce these tools when you are not the person that makes those decisions.

What I want to offer is a method for applying a DevOps mindset to tool adoption. With DevOps, we are always working to be more iterative, as well as think bigger about the way our choices are affecting others on our team, as well as end users. We can approach adopting a new tool in the same way: when trying to make a change, go in stages, test and prove, and consider all involved. In this article, I will show you how, and include specific language you can use with your manager and others on your team that will help you along the way.

Emphasize the problem, not the tool

Before any conversation begins, we need to identify the action item. No manager wants to have meetings that don’t have actionable insights.

Our action item is not to migrate our entire org’s repos to a new tool that you discovered over the weekend (even if you know it will solve many of your team’s problems). Our action item is specifically this: Obtain permission to explore implementing a new tool. Approval for exploration is what we are looking for at this stage.

Now that we have an explicit action item, it is important to consider how we frame our ask. Managers regularly deal with people who are pitching new products to them. Marketing and sales pitches highlight the benefits of using the product/platform; a win to be achieved. However, you can take advantage of loss aversion, which research has proven is a stronger and more impactful motivator than potential gain. Frame your ask as a way to mitigate risk or loss, and you’ll have an easier time getting agreement from your manager.

So, what is the problem that this tool solves? As an example, if we were angling to implement CircleCI, we are proposing to solve the problem of our developers waiting on changes to pass through the queue.

Say: “Our engineers are bottlenecked by the queue for code changes. I have an idea that could eliminate that as a blocker.”

Don’t say: “I found a great, new tool that will increase deployment of code changes.”

Use data

Developers can generate data, so include some specific stats in your ask. Managers love data! Remember, you are “bouncing an idea” off of them that you hope to get permission to explore. It is very important that you are clear about what needle you are trying to move. You want to avoid saying things that are difficult to accurately measure (like sentiment), that are not specific enough, that aren’t evidence-based, or that can’t be backed up with data. To get buy-in from your manager, show them the numbers.

Say something like, “We are losing two hours of productivity per developer per day due to queuing and I may have a solution.”

What you should avoid saying is, “Our engineers are not happy with waiting on the queue.”

Get a buy-in from your team’s least likely fan

Once you have permission from your manager to explore, it is important to loop in others who are going to be affected and who have opinions about the new tool — especially others who have more expertise regarding the tool or its adoption. Don’t consider it an effort to avoid stepping into anyone else’s lane, but an opportunity to get valuable feedback on the tool. Strong opinions are often formed by experience and avoiding any major pitfalls out-of-the-gate (especially those that could have been prevented) is going to benefit everyone.

Again, you want to explore whether or not this tool could be used as a solution. You are not trying to convince anyone to adopt it yet. They will respond better if you are requesting assistance versus arguing a position. Show that you value their opinion and that their input will be utilized. Circumventing potential detractors is no way to introduce a new tool to your team nor is it a good practice to have with your teammates. To get buy-in from your most cynical teammate, show them that you appreciate their experience and knowledge.

Say: “I am interested in learning more about your experience around this tool.”

Do not approach this person saying: “I talked to our manager and already got approval to implement my solution.”

Go for small successes

Our ultimate goal is the adoption of the new tool. We’ll get there by showing others that it works and we need to show them right away. This means that if we can get a small project up and running with our new tool, we will have some validation as we work through the challenges of integrating our tool more widely. When you start small, you also get a lightweight, working demo to share. Show that our solution works for one project and then iterate.

Tell your team: “Hey, I spun up a small project to show off the performance of this new tool.”

Definitely don’t say: “I’ve integrated a new tool into our production pipeline and I’m looking for feedback.”

Demo, share, and invite questions

“Hello World” demos are great to quickly see a product in action, but they are not designed to solve a real-world problem. This “Hello World” demo for CircleCI 2.0 is quick to spin up and you get a green build within minutes. It also introduces the CircleCI config file.

Luckily, the demo has documentation for all of the lines of code. When you share your new tool, you should include a walkthrough of a Hello World demo and then show off your small project. This provides a ground floor example followed by one that, while not overly complicated, is a real-world solution. You gain the opportunity to discuss the differences between the two config files. This shows what direction you are considering to move in and keeps questions from ranging into the obscure. Then, get others thinking about the ways that they could use the tool by inviting suggestions as to what project to target next. This is also a great time to let others show off their expertise. Ask your team if they see any issues down the road that introducing the tool may create.

Ask: “Now that you’ve seen what the tool has done for this small project, what other projects could use this boost in performance? What areas of the integration do you think that I have overlooked? Do you see any potential pitfalls or roadblocks?”

Don’t say: “After showing this one example, I have proven the value of the tool and I’m ready to implement full adoption.”

With this as a guide, any engineer should feel more comfortable about introducing a new tool to their team. Identifying problems on your team and effectively proposing solutions is paramount to a successful engineering career. Best of luck!