You're moving to a DevOps model for all or part of your organisation: well done! Somebody, somewhere has made the leap. Let's assume, for the sake of this article, that you have management buy-in: whatever hurdles needed to be jumped, whatever mountains needed to be climbed to get that momentous "Yes." You've got tooling agreed, you've worked out your processes, and now all you need to do is convince people to get involved. Should be easy, right? If only.
It turns out that not all people are as enlightened as you, the reader of this article. Not everybody likes change, and if there's one thing you can be sure of, it's that DevOps will bring change to your organisation—how you work, what you do, how you interact with other people within the team and beyond.
I'm going to describe five types of people or roles who may push against a move to DevOps, along with a few thoughts about possible tactics to help move them along. We should remember, however, that you may not be able to move everybody along, and that there may be good reasons why people don't want to change what they do, including the fact that what they do at the moment may work pretty well, both for them and for the organisation.
[Download the Getting started with DevSecOps guide]
Not invented here: Fear of the unknown
"We've done it this way for the past [1/2/5/10/25] years, and it's worked till now." We've all heard this. It may be true, or it may not, but if your management has decided that a move to DevOps should be undertaken, even if the existing practices have been working, there's probably been a realisation that things could be more efficient, or faster, or more secure.
One of the defining points about this type of person or role is that it often exhibits as a team concern. Teams become used to a particular way of doing things and settle into roles and routines that work for them. What you're suggesting is upsetting that team and making people do different things. You should consider how to make the most of the team as it exists now, maybe even transitioning members of that team together or making a point of celebrating their successes, rather than suggesting change is needed because they have in some way failed.
My domain: Fear of loss of control
As a security person by background, this is one I'm very aware of at a personal level. People who have gained a high level of expertise in a particular area or domain often feel threatened when asked to change how they work or apply their knowledge. They will often feel they are being asked to give up control and "water down" their expertise in a new world where "everybody is the expert."
What's important to stress in this context is that, rather than diluting their expertise, this is an opportunity to apply it across a broader set of processes. Testing experts need to explain to developers and operations folks, for instance, how testing methodologies can be exposed in their realms. Typically, exposing experts to a wider audience will be seen by them as a positive and, although there will always be "ivory tower" type personalities who struggle to interact in a more team setting, using them in ways where they take on a "consulting" type role may offer positive opportunities.
Stuck in my way: Fear of the new
While very similar to "Not invented here," this is more of an individual than a group trait. Knowing what your tasks will be on a day-to-day basis may feel stultifying to some but can be very comforting to many, which is why they may not want to move to a world that seems much more "freeform" and unstructured. Not everybody can become the sort of generalist who thrives on understanding all the different parts of the DevOps cycle.
The good news is you will still need people who are ready to settle down on specific tasks and complete them in particular ways. In fact, though there may be initial concerns about moving to a different way of working, explaining that team members will have a fair amount of control over exactly how they perform particular tasks may be a positive message when trying to help this sort of individual. Hopefully, you will be including training—whether formal or informal—as part of your transformation to DevOps, and the chance to learn new skills (thereby increasing individuals' mobility and career prospects) may also act as an incentive.
People managers: Fear of losing power
In many organisations, particularly those with a strongly developed hierarchy, managers have a great deal of control over how their staff are deployed, what their tasks will be, and how their career progression is managed. All of these can be directly at odds with a more open DevOps approach. For managers who have built their own little empire, controlling their reports and subreports like pawns around a chess board, a move to DevOps will be challenging. For managers who are keen to grow members of their teams into more expert employees, who measure their success on how many other teams ask for their reports to be seconded to their teams, and who enjoy seeing new skills and career progressions taking place, DevOps should be an exciting opportunity.
Part of any fix to the problem of resistant people managers is likely to be for executive management to offer both a carrot and a stick. The carrot can include changing how people managers are rewarded into a mechanism that embraces these new behaviours, while the stick may involve removing team members from those who are obstructive or changing those managers' role definitions.
Unions: Fear of lack of certainty
In certain industries and geographies, there are strong unions. A core mission of unions is to protect workers from exploitation by management who may try to impose changes on workers that will not benefit them. Unions are by default (and understandably) suspicious of changes introduced by management, so any move to DevOps that has been "blessed" by management may raise concerns and resistance from unions and members of unions. In some cases, employees may have very carefully described job roles that make it difficult to introduce ways of working where they are expected to take a more generalist role and learn new skills—both characteristics of DevOps.
The good news is that DevOps can provide more control to members of the team, in many different ways, somewhat reducing the control exercised by the management function. Explaining this and ensuring that appropriate checks are put in place to safeguard jobs will be key tasks in convincing unions and their members that this is a good change for them. The other thing that should happen, of course, is that management should have included them early on in the process to make sure there has been buy-in from the beginning, rather than a decision "sprung" on them at the last moment.
Some final thoughts
As we progress to a bright new future, it is worth bearing in mind that a general good for all does not always translate into a positive change for every individual. It is hard to argue that the construction of sewerage systems is anything other than a general good, but it hits those whose only job has ever been collecting the waste from the streets. Hopefully you don't see your move to DevOps as the construction of a new set of sewers for your organisation, but be aware of those for whom change can be difficult and disruptive. There can be a human cost to even the most well-intentioned development.
For me, the most important point to remember is that when people get defensive—and occasionally aggressive—it is generally because they feel threatened, and in all these cases we've examined, change can be threatening. These people are your colleagues, they are people, too, and they should be treated with respect and consideration as people, not just as roles or obstacles to be overcome. In some cases, preserving the status quo in particular parts of your organisation may be the safest approach—for now, at least.
Comments are closed.