What are typical stakeholders and their reasons not to support/enable DevOps principles?*

Background: in small to medium organizations, certain level of DevOps is not a very big problem due to thinner silos and faster communications paths.

But how do you do DevOps at large organizational scales and which groups of stakeholders do you deal with?

I can think of these typical examples:

  • Developers, either junior or more experienced who would like to "just do their job they are paid for - establishing software solutions and coding them"

  • Management/Deciders concentrating on the service aspect in terms of man-months, where you find out a thing like a toolchain is non-existent to them: they recognize people doing their work on computers, not more.


  • (And how can DevOps be a benefit to them? - as a side thought to be separate question, "how can DevOps be a benefit to stakeholder group X?")
  • 1
    This question is confusing. You are asking a very open, list-based question, but you are excluding "typical examples". Those typical examples are typical because they are the good ones... ;)
    – AnoE
    Apr 30, 2018 at 16:21
  • ;) so would be the question less open put as "is this the complete list of two items?" (Y/N) :-)
    – Ta Mu
    Apr 30, 2018 at 17:14
  • I don't know, Peter, I'm just having a hard time answering except for listing many things that have been listed already, or writing a generic essay about DevOps... . Or are you looking more for anectodes, like Dan's answer?
    – AnoE
    Apr 30, 2018 at 17:33
  • Honestly I asked myself what are other examples of the stakeholder groups; if there are really only those two I'm fine with them.
    – Ta Mu
    Apr 30, 2018 at 17:48
  • This would probably be better as an open-ended question with the examples you had in mind posted as an answer. May 5, 2018 at 17:24

4 Answers 4


People resist change, particularly when it's perceived to be outside of their control. Organizations that have been around a while naturally devolve into silos, and organizational structures often reflect that (e.g., database administration teams often manage all of the databases for the org, even though they are often distanced from the business purpose of those databases). DevOps has the potential to disrupt silos, and may cause realignment of org structures. For example, you could have product teams composed of developers and operations people (like DBA's) that focus solely on a single product.

For some mid-level managers, that could threaten their sense of job security. The benefit of a DevOps mindset is that it encourages everyone to understand the value stream to the customer, and the relationship of all the roles in delivering that value. IT could mean that the manager of DBA's suddenly has to understand development processes because they're now managing a product team.


DevOps fundamentally is an arbitrage play: it exploits the idea that if the things you are developing and operating are known to be stateless and immutable and ephemeral you can move very quickly, because there are a bunch of things you just don't need to do. And this is true, you can, and you don't.

But "traditional" IT is all about managing statefulness and controlling the transitions between states (or "mutation" if you prefer). A database server, a file server. A database server for example: once you have made changes to a schema and data has gone in, you can no longer "roll back" because you probably have nowhere you can put that data that satisfies the constraints of all the stakeholders. If the database server goes down you can't just spin up a new one, it has to be exactly the same to the greatest extent possible, and you need to have a plan for resolving the deltas. DevOps doesn't really address this and even worse, the typical DevOps pitch includes some jabs at "traditional" IT for being slow and obsolete, without any acknowledgement that maybe there were reasons for things to be done the "old fashioned" way other than the practitioners being dinosaurs.

What that sounds like to a stakeholder is that DevOps people are willing to take risks with the company's most precious assets - customer records, accounts, inventory control, all the other things that typically reside in the stateful parts of the technology infrastructure. Therefore to work with and bring on board skeptics the very first thing you must do is convince them that you have mitigated all the risks of operating the stateful parts of the infrastructure in a DevOps fashion.

I will wager that some variation on this theme is the root cause of TSB's woes at the time of writing. They failed to exercise sufficient care with the stateful parts of their system.

  • Thanks for this insight, @Gaius; how does this relate with the blue/green deployment where they say, traffic is replicated in a way that a test system is filled with production data?
    – Ta Mu
    May 4, 2018 at 6:59
  • A test system being filled with production data is something that you would very much want to avoid; blue/green is therefore a technique that can only be applied to stateless components
    – Gaius
    May 4, 2018 at 7:31
  • I see; possibly there different opinions. devops.stackexchange.com/questions/3911/…
    – Ta Mu
    May 4, 2018 at 8:22

At one point a higher level tools manager, asked to review/vote on a proposal for using a CI tool which would allow gradual elimination of long-lived branches and migration towards true CI methodology (i.e. Trunk-Based Development - TBD) for a large scale product line, opposed it. The stated reason was belief that it wouldn't scale to the very large team (1000+ developers) working on the product.

I may be wrong, but I got the feeling another reason behind the vote was fear of having his ranks (which included an army of sync-masters for driving the many, quite difficult branch merges) shrink - in TBD there wouldn't be any such branch merges for them to work on.

  • So do you mean in general we humans, also in IT, would struggle to vote for automation disrupting our work? (despite of DevOps hope to have more interesting tasks then on kong term)
    – Ta Mu
    Apr 30, 2018 at 17:34
  • I'd rather say opposition in the "automation is killing jobs" category :) Apr 30, 2018 at 17:44
  • Okay: true, though this is not bound to a specific stakeholder group I'd say.
    – Ta Mu
    May 1, 2018 at 0:26

The biggest challenge I've encountered with people resisting the change is the reason of not seeing the value of it, or build automation in general. His idea was, we were our getting product(s) out the door, and on time. So why do we need to "create work" for ourselves, and take a developer off of working on a product. After 4 years since then I've finally got the owners on board with CI by capturing metrics on how much time is wasted copying files manually from bin folders to SVN for qa to copy from SVN to environments. This along with the overhead of managing what build is in what environment and other pitfalls of you are testing the wrong build etc. He has finally came around, but I think he feels that the time could be put to other tasks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.