Popular Articles

The XebiaLabs DevOps Platform provides visibility and synchronizes data across the CI/CD pipeline by connecting issue tracking and ITSM ticketing tools, so that user stories and change tickets are always up to date.

Subscribe for more!

This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.”

Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transformational changes. In fact, it’s incredibly common for software development projects to be late, to be built with poor quality, and to fail to meet the needs of users. Despite all the evidence that we should be doing DevOps, we can’t.

What’s Holding Up DevOps?

So what’s keeping so many organizations from a full DevOps transformation? Pauly Comtois, VP of DevOps at Hearst Business Media, was part of the team that addressed that question in a report called “Individual Contributors – from Holdouts to Holdups.” The report postulates that there may be critical individuals in an organization who are “lone holdouts” to a DevOps transformation. Manage the holdouts, and you increase the likelihood of success for your efforts.

ON-DEMAND WEBINAR

Almost all successful DevOps transformations encounter resistance, often in the form of lone holdouts. Gene Kim and special guest, Pauly Comtois, DevOps VP at Hearst Business Media, share tips on how to better understand holdouts and win them over.

According to the report, the key to managing the lone DevOps holdouts is to first identify them and the behaviors that cause the holdout. Then offer “lightweight, easy to implement, non-destructive/non-threatening approaches to align them with the efforts and – ultimately – provide value to the transformation.”

Identifying DevOps Holdouts – 5 Archetypes

To identify the holdouts, Pauly suggests using classic archetypes tailored for the DevOps context:

The Caregiver – Always avoids conflict and tries to be the peacemaker between individuals and teams. BUT the Caregiver often avoids conflict at the expense of growth and innovation.

The Hero (AKA the Firefighter) – Lives to swoop in and save the day with a technical solution. BUT the Firefighter only engages when they can be the center of the solution and can cloud debate with “facts” that only serve their own vision.

The King (aka The Tyrant) – Takes control of every meeting or conversation, believing that they have the strongest leadership qualities. BUT the King (especially as the Tyrant) tends to take over every meeting or conversation, and overrides, diminishes or steals solutions that they didn’t create.

The Creator – Finds a technical solution to every problem – but only within their own personal silo, leaving a trail of half-finished apps and widgets behind them. BUT the Creator discounts any solution that isn’t focused on technology, and only unveils a “new solution” after they have fully developed it.

Sound familiar? The report identifies others – the Lover, the Rebel, the Jester, etc. – but they all follow a set of common manifestations of “holding out” as individual contributors that can derail an organization’s efforts at transformation.

Common Symptoms of DevOps Holdouts

Some common symptoms of holdouts:

Cynicism – Has seen it all and is quick to say that this is “just like” some other project that they saw fail back in 1986 when they were working on a big Cobol project (which, incidentally, was much harder than this, he’ll have you know). They figure they will just “wait this one out too.”

Disillusionment – Unwilling or unable to take on new challenges, the individual withdraws from engaging with the team, displays apathy, or simply doesn’t show up.

Schadenfreude – Having already decided that the effort is doomed to fail, this person sits back as a spectator and takes pleasure in the misfortune of others.

Active/Passive Sabotage – “If I slow-roll this, maybe it will just go away and I can get back to what I want to do.”

Emotional Outbursts – May start with a technical disagreement, but quickly escalate it and personalize challenges resulting in explosive outbursts.

Not-my-Job – May hide behind a narrow description of his/her job description to avoid expanding their responsibilities and adapting to a new process.

Lone Wolf-ism – Refuses to work with the team, instead believing that they can “go it alone” and get a better outcome. But they can cause confusion among many others who find themselves asking, “but I thought we were doing this other thing…?”

The remedies to these symptoms vary depending on the archetype, but common to almost all is fear. It’s important to understand the individual contributor as a person who is experiencing the situation in a personal context. Then you can begin to understand what they fear and address and mitigate their rational and irrational fears alike.

It’s also important to be aware of people’s self-identities. There’s a huge difference between “I am a developer” and “I am an Ops person.” In many cases, an individual’s self-identity has been developed over years of professional life. You can’t just come in on a Monday morning and expect that to change just because of a proclamation that you’re now “doing DevOps.”

Winning Over DevOps Holdouts

Pauly suggests a few archetype-specific re-alignment approaches.

Caregiver – Provide guardrails to make disagreements safer. You can set guidelines on how to communicate and work through conflict in a way that will provide the boundaries that can make Caregivers feel safer.

Hero – Create a safe way for this person to say ‘no’ and provide processes that don’t leave them to figure it all out on their own. A focus on finding solutions as a team (where all contributions and people are valued) removes the pressure from the Hero and drives a DevOps culture.

King/Tyrant – Make it clear that culture is the ultimate ruler. Ensure that everyone knows that brilliant jerks won’t be tolerated and that everyone will help to provide needed guidance. In some cases, though, it may be that the individual is just not the right fit.

Creator – Showcase their ongoing work in a public forum. They can commit their code in a public repo allowing others to comment and contribute, creating a continuous feedback loop from the team.

While DevOps transformations are organizational transformations, organizations are always a collection of individuals, and some may be reluctant at first. Empathy for and understanding of the individual holdout archetypes can help you realign them.

The Reality of Software Releases

Many organizations model software delivery as if the features that are initially planned for a release are always the features that are actually delivered to production when the release is done. But the reality of software releases is more complicated than that, because it’s hard to predict the delivery of planned features. The XebiaLabs DevOps Platform can help you deal with the reality of software releases. See for yourself!

Start Your Trial

The XebiaLabs DevOps Platform provides the intelligence, automation, and control that technical and business teams need.