Making the move to DevOps can be a daunting undertaking, with many organizations not knowing where to start. I recently had some fun taking a few DevOps assessments to see what solutions are currently in the market. I varied my answers from an organization that fully embraced DevOps to an organization at the beginning of its journey. Some of the assessments provided real value, linking me back to articles on culture and methodologies, and others offered me a tool to bring all of my DevOps dreams into reality.

First, I have to say that I believe that tools are absolutely essential in the DevOps journey because they can provide software that allows users to continuously deliver, automate, or monitor a service. However, DevOps isn’t a product and tools alone can’t get you the necessary processes that allow you to fully realize the value of DevOps. With DevOps, people are what matter most—without the people, you won’t be able to build mindset and culture required to fully and successfully embrace DevOps.

Don’t Win at DevOps; Become a Champion

I recently had a conversation with PagerDuty CEO Jennifer Tejada regarding being a winner versus a champion. She talked about how winning is fantastic—you get a trophy, a title, or maybe even a few million dollars if it’s the lottery. However, when looking at the big picture, winning is all about short-term goals. In contrast, being a champion means focusing on long-term successes or outcomes. This conversation got me thinking about how the same principles can be applied to organizations embracing DevOps.

One of my favorite examples of DevOps tooling is XebiaLabs Periodic Table of DevOps Tools:

As evidenced by the table, there are numerous tools that fit into the DevOps categories. However, too many times have I seen or heard stories of organizations “transforming to DevOps” by purchasing tools. As I mentioned earlier, while tooling is an essential part of the DevOps journey, a tool alone does not create a DevOps environment. One has to take into consideration all the factors that make a DevOps team function well: collaboration, automation, taking ownership, breaking down silos, and defining processes, along with continuous improvement/continuous delivery.

Making the decision to purchase tooling is a great step in the right direction; what’s more important though is to define the “why” or end goal behind decisions first—which brings us back to the mentality of a champion.

Take a look at Olympic gold medalist Michael Phelps, for example. During his swimming career, Phelps was the most decorated Olympian of all time, and he also holds 39 world records. Phelps didn’t stop at 1, 2, or even 20 wins; he aimed for being a champion. All of this was done through commitment, practice, and focus on the desired end state.

DevOps Defined

Though there are hundreds of definitions for DevOps, most everyone can agree on the core tenet outlined in the State of DevOps Report: “DevOps is a set of principles aimed at building culture and processes to help teams work more efficiently and deliver better software faster.”

Culture and processes cannot be changed with a credit card. Tooling can enable an organization to better collaborate or automate or continuously deliver; however, without the right mindset and adoption, a tool’s full capability may not be achieved.

Let’s use Slack as an example. One of my former colleagues who transitioned to a new company was at a conference and heard how amazing Slack was for teams transforming to DevOps because it opened up channels for collaboration. He convinced his manager that Slack would solve all of their communication woes. However, six months after they adopted Slack, the majority of the teams were still using Skype, including the manager. Slack ended up being more of a place to talk about brewing beer than a tool used to bring the product to market faster. The issue was not Slack; it was the lack of buy-in from the team and organization, and an absence of knowledge around the full functionality of the product.

Making tooling and best practices work for the team and achieving short- and long-term goals is where our conversation around being a DevOps champion comes up. For instance, what is the overall and far-reaching goal for the team or organization? Once the goal is identified, how do you get buy-in from key stakeholders? After buy-in is achieved, how do you implement the solution?

Organizational Change

Change is hard for many organizations and individuals, and meaningful change does not happen overnight. It’s important to understand how people and organizations process change.

In the Kotter 8-Step Process for Leading Change, the first step is about articulating the need for a change, creating the urgency around the why, then starting small and finding and developing those internal champions before trying to prove wins (or in this case, to purchase a tool).

If people in an organization aren’t aware a problem or that a better way of operating exists, it will be hard to get the buy-in necessary and motivate team members to adopt new ideas and take action. People may be perfectly content with the current state—perhaps because the processes in place are adequate. Or it might be that, at a minimum, the current state is a known factor. However, for the overall team to function well and achieve their shared goals in a faster, more agile way, new mechanisms must first be put into place.

How to Be a DevOps Champion

Being a champion in the DevOps world means going beyond the win. It means delving deeper into the team/organizational structure and culture to identify outlying issues beyond tools, and then working with others to embrace necessary change that lead to defined results. In short, you’ll need to go back to the beginning and define the end goal. Here are a few simple questions you can ask to get started:

• What are your core values?
• Why are you trying to become a more agile company or team?
• What obstacles are your team or organization facing?
• What will the tool or process accomplish?
• How are people communicating and collaborating?
• Are there silos and why?
• How are you championing the customer?
• Are employees empowered?

After defining the end state, find other like-minded individuals to be part of your champion team and don’t lose sight of what you are trying to accomplish. Be cognizant when making any change to start small—such as starting with one team or a test environment. By starting small and building on the wins, internal champions will start creating themselves.

Remember, companies are happy and eager to try to sell you DevOps. But at the end of the day, DevOps is not a product; it’s a fully embraced methodology and mindset of automation, collaboration, people, and processes.

*The original version of this article was published earlier on opensource.com.