How To Get Buy–In From Management

When I’m helping people learn new techniques for shortening feedback loops in continuous delivery and getting the whole team engaged in building quality in, I’m often asked how to get management support for these efforts. In my experience, development managers as well as executives often don’t really understand quality or why the company should make a big investment in it. Everyone says they want the best quality, or that they want to succeed with continuous delivery, but not everyone knows what that means in terms of time and effort.

Without going through all the science behind it, I can share with you that logic and facts are not that effective in persuading people to do something they don’t want to do. Evangelizing does not work either. How do we get the people whose support we need to make real changes on board with those changes? I’ve learned some ways to help influence and persuade people in other roles and on other teams to understand the value testers and testing can add throughout the infinite loop of software development, in building and releasing features, and learning from production use.

Find the pain points...

Listening can be an effective way to influence someone who may be resistant to the change you need. Understanding their concerns and perspective better helps you communicate more easily with them. It helps you get a sense of what they value.

I once led a QA team in a siloed but “trying to go agile” organization. We testers felt we’d be more effective if we worked together with developers, but they resisted our efforts. Finally, I invited the development managers to a short meeting, and asked them, “What is your biggest pain point?” They agreed it was requirements. Either the analysts took so long to write the requirements that there wasn’t enough time left to actually build the features, or there were no requirements at all, leading to confusion.

I thought about this and said, “How about an experiment. Instead of using a requirements document, we could write high-level acceptance tests that would show developers how the features should work. We could try this for a month and see how it goes.” They agreed to try. We wrote simple tests for each story, in text documents (this was in the early 00s, and we hadn’t discovered wikis or other online shared docs yet). The developers found them sufficient to start working on the stories, so we continued with the practice. It was a step towards people in different roles working more closely together.

...and make them visible

Once you’ve identified pain points, make them visible. Got a huge backlog of bugs? Put a graph showing issues created and resolved, along with the average age of reported bugs, on a big monitor where everyone can see it. Is the team getting bogged down with rework? Track metrics like story rejection rate and cycle time and put that on a wall or monitor. Look for patterns in log data such as server errors, and make those visible with graphs.

Back when a team I was on was struggling to get a passing continuous integration build every day, we kept an online calendar where days with a successful build were green, days without a successful build were red, and no build due to miscellaneous problems was yellow. We shared this with executives, and they’d come over and start asking about the problems if they saw two or more red days in a row. Making a problem visible is a huge first step to finding a solution.

Show what's in it for them

Reciprocity, or repaying in kind, is a common practice in many cultures. Do something nice for the person whose buy-in you seek. It’s human nature to see a person who did you a favor, even a former enemy, as a friend. Try to get them started one step down the path to change. Are you a tester wanting to get involved with production monitoring, but that’s handled by a separate Ops team that doesn’t talk to you? Go ask someone on the team to come explain their production monitoring process and tools to you and the other testers. It’s a great way to start building a bridge between your teams.

We humans also socialize well around food. When I’ve wanted my team to try out a new tool or practice I learned about at my last conference, I’ve issued an invitation to a 30 minute workshop on it - providing some delicious treat that I know my team loves.

Instead of extolling the virtues of some new idea or tool, look for ways to make it look like something your team is already doing. “We’ve had some success incorporating API tests automated with tool X into our continuous integration. Tool Y is a similar API test tool, but it also provides this coverage reporting feature that would help us make sure we’re automating the right tests. What if we try it out as we develop our next new feature, and see if it adds value?”

Speak their language

Executives, business managers and stakeholders may not know the latest buzzwords and terminology used by the delivery team. Take time to learn their language so you can have good conversations. I’ve found that time invested in learning the business domain pays off. It enables me to explain how the change I want to try will add value for the business and its customers.

Someone in finance may want to know what impact a software process change or new software tool will have on the bottom line. Remember that it’s not only about the cost of what you propose to do - it’s also about the cost of not doing it. Quantify technical debt and educate folks on the business side about how it slows teams down.

Find your allies and potential allies

Most people don’t like change. If you have an idea that you think will help the team improve something, you can probably count on a range in level of support or opposition among others in your organization. Start by talking to the people you think will support your idea. Then all of you can talk to people that you think can become allies with a bit of persuasion.

There will probably be one or more people who are going to resist your idea no matter what. Remember, you are selling yourself as much as your idea. Look friendly. Smile! Compliment something they are doing. Listen to their objections, let them talk - they may get into areas where they aren’t so sure of their own opinion.

Ask for their help - they may have valid objections or different ideas. Ultimately, just accept that you and your allies can’t convince everyone. Work towards getting enough support to try a small experiment.

Small, frugal experiments

If you want your team or company to try something new, propose an experiment that will only take a couple of weeks and doesn’t require a big investment. Come up with a hypothesis and a way to measure progress. If there’s not a big downside to trying something new, people will be more willing. Once they see the results, they may be more open to the change.

For example, “We believe that using example mapping to discuss stories in advance of iteration planning meetings will result in better shared understanding of the stories and lower rejection rate by the product owner. We will know we have succeeded when our rejection rate goes down 10% and our cycle time goes down 5% after the next two-week iteration.” The example mapping framework is free, the meetings will only take 30 minutes and involve three or four people, and it’s only for one iteration, so it’s not a big investment. Even if the exact goal isn’t achieved, the team will be able to judge whether the idea is potentially helpful.

Many of the ideas I’ve explained here come from Linda Rising’s work. See the resources at the end of this article to learn more from Linda. The patterns for change that she and Mary Lynn Manns explain in their books Fearless Change and More Fearless Change have been invaluable tools to me over the years as I’ve tried to become a more effective agent for change.

We all can use our influence. We can be catalysts for change. Be patient, and try for tiny steps along the path to something new. Getting buy-in from enough of the important stakeholders to try small changes means more opportunity for experimenting and learning. Small changes lead to continual improvement.