To create a successful DevOps culture, you need support and commitment from both IT and business executives, which can be a challenge to obtain. Many managers, technologists, and business leaders are still not sure what DevOps is, much less why they need it, and the abundance of materials from vendors trying to capitalize on DevOps’ status as something of a buzzword does not help the confusion. As such, education on the benefits of adoption of DevOps core values must be a high priority for anyone looking to lead a digital transformation at their company. Although you’ll be faced with many challenges in this process, the major ones you’re likely to encounter can be boiled down to two generic points: uncertainty about what DevOps is and uncertainty about how it will benefit the organization. In this post, we discuss these challenges, and I provide you with practical strategies for educating stakeholders on how DevOps can optimize business.
Many companies and decision-makers don’t fully understand what DevOps brings to the organization, and because of that, they don’t understand where the changes need to be made to truly make a positive impact. They are looking for a silver-bullet solution or product that doesn’t exist.
When bringing the concept of DevOps to organizations where decision makers are not sure of what DevOps really is or the value it provides, I tend to start from the opposite end of the information spectrum and educate on what DevOps is not. This approach helps to clear up some of the reductive ideas that many people have about DevOps.
We’re doing DevOps by using a configuration management tool.
DevOps is a philosophy. An approach. A method. It is not a product. You can’t “buy”
DevOps (or its accessories) just to say that you have it. No matter how many companies
are trying to sell you a “complete DevOps solution,” DevOps is an entire culture that
must be adopted and embraced by the entire organization.
By using Agile techniques for automation in the cloud, we’ve successfully achieved
DevOps.
DevOps is not a synonym for other industry terms like “Agile,” “cloud,” or “automation.”
Even though certain elements of these practices and tools do intersect, you cannot
equate them to one another.
We’ve created a new DevOps team to make communication between our Dev and Ops more
effective.
One of the goals of DevOps culture is to help eliminate siloed structure, improve
communication between development and operational groups, and cross-educate those groups
make them more efficient and effective. Creating a new siloed group does not contribute
to any of those goals.
We’ve given our developers pagers and made them responsible for operations.
DevOps is not a method to reduce staff and stack cross-department responsibilities on
remaining people. It logically expands the area of responsibility for each group and
defines the processes for all technology groups to work efficiently together. As
example, it extends developers’ responsibility for success of the application after
deploying it to production, both reducing the load on operations team and providing a
subject matter expertise in production troubleshooting.
The DevOps model is not mature yet. We’ll give it a few more years.
Both engineers and organizations have been applying DevOps principles for years prior to
when the term was coined. Companies that understand the need of cross-department
collaboration successfully streamlined execution and increased the success rates in
time-to-market and quality of products. The toolset that is most commonly associated
with DevOps-related concepts are (arguably improved upon) derivatives of what were used
well more than a decade ago.
We finished our reorg; now, IT consists of DevOps, QA, Security, Database, and
Networking groups.
DevOps is, in a certain sense, a misnomer. Initially intended as a method to improve
efficiency between development and operations group, the concept has logically expanded
to cover other technology units, as well. And with the end goal being optimization of
service delivery for organizations, the more successful companies have begun to span
principles beyond technology groups, including marketing, finance, HR, and other
nontechnical business units. DevOps is about a culture; a set of processes and practices
that optimize service delivery for organizations. The other often-discussed concepts,
such as automation, tooling, and staff responsibility, should be tactical
implementations for the overall digital transformation strategy.
The term DevOps has many different perceived meanings, which often leads to misunderstanding about what it actually is. When the term was first introduced, it was intended to define a relationship between development and operations groups. Over time, the definition has been expanded; DevOps is not just about interdepartmental communication; rather, it’s about building the culture and providing value to an organization. DevOps represents an organizational culture aimed at delivering business value quickly.
After you’ve established a baseline definition of DevOps for teams at your organization,
you need to make sure that both technical and business units agree upon and understand
the overall strategy and goals of a DevOps transformation and are comfortable with the
changes required to put DevOps principles into practice. To accomplish this, you can use
the CAMS principles as a blueprint to assess and outline areas of impact and potential
improvement for your organization.
Remember that you are not picking tools or implementing an isolated processes. DevOps is
about a culture shift, to promote collaboration and empathy both within and across
diverse business units.
Focus on removing manual steps from your value chain (where appropriate). Keep an eye
towards the end goal of improving the time from inception to delivery to customer.
Much like performance and security, threat measurement should not be merely a feature or
an afterthought, but a core requirement for each component in your delivery model. Keep
in mind that you can’t improve what you can’t measure.
Creating robust feedback loops is key to a successful continuous improvement model. And
being transparent with information made available (success and failure alike) will
contribute to culture of collaboration and empathy.
After the key areas are outlined, it’s time to focus on the effects the changes would
have for individual groups and people.
Change is crucial to long-term organizational success, yet it is often met with resistance by individuals. Despite being vital to success, change can easily be perceived as having negative connotations and consequences, such as increasing individuals’ workloads, creating potential failures, compromising product quality, and reducing the size of the staff. Overcoming resistance to change is especially difficult when working with organizations and individuals who don’t believe that they have an immediate, acute problem and those who perceive change as a threat to their current role. There are a number of common reasons for resistance to change that tend to fall into three main categories. You should address each of these reasons as part of a buy-in acquisition from all groups.
Complacency is often a problem in organizations and individuals with a history of success without recent reliance on innovation—“If it ain’t broke, don’t fix it,” as the saying goes. As one of the more egregious examples, many traditional retail businesses either passed on or procrastinated on a strong push from many organizational leaders to shift the priorities to online venues. On an individual level, not keeping current with your industry can make your skills quickly outdated and, as a byproduct, have a negative impact on any solutions you propose based on then-current knowledge. Remember, continuity when you aren’t going anywhere is stagnation.
Fear for job stability is perhaps the most common reason that contributes to resistance to change on an individual level. Some people are worried about stepping out of their comfort zone, either technically or socially, or hesitant to change their routines. Others feel that they won’t be able to make the transition very well, either because the change may force them out of the job if they don’t pick up new skills, or due to automating themselves out of a job—a frequent concern during a DevOps transformation. Lack of Trust Trust is a key factor in getting a cross-departmental buy-in for change. If management doesn’t believe IT can successfully manage change, they will be skeptical of any innovations that require their buy-in. Similarly, if organizations continuously reject grassroots innovation, it disincentivizes engineers from providing value through change. Not trusting that change will better your situation creates strong resistance.
The previous three categories, at their core, essentially boil down to an aversion to change due to risk and money factors. Though those concerns can be valid, they are often driven by a fear of the unknown, which is amplified by the lack of understanding of reasons for change. And a lack of understanding stems from a lack of clear communication. As such, when preparing a compelling case to get a buy-in, there are a number of strategies that you can use to communicate clearly and directly with your stakeholders across teams to help them embrace change. Let’s take a look at some of them.
Consider each audience. When you’re presenting to executives, you should focus on the impact of change to improve organizational goals, but when you’re trying to get a buy-in from the people in your group, you need to consider their individual concerns. When presented with a change to their routine, people’s first reaction is usually, “What does it mean for me?” Address that question first. • Discuss how individual job descriptions will change. • Outline a plan of action to train people if needed. • Talk through group structure changes. • Perhaps most important, address any potential personnel changes head on.
Explicitly tell people what’s going on. Given incomplete information, people will speculate and make assumptions, forming a resistance to change before the change is even communicated or understood. Even if you don’t possess all the details, update the people involved and acknowledge that information will be made available as soon as it’s available.
Involve the people in conversations who will be affected by the proposed change about the purpose and effects of change, and involve them early and often. Get them excited about the change by focusing on how the changes will improve the business, which will benefit everyone at the organization. It’s less likely for individuals to oppose to change when they are part of the decision, let alone if they feel there is a personal connection or benefit associated with it. After you have secured buy-in for the overall strategy, you can begin focusing on defining individual implementation tactics with an eye out for the strategic outcomes. As part of this exercise, you should define goals and outcomes that would signal incremental success of changes in your group.