Understanding DevOps opponents on stakeholder level beyond typical examples

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.

Others?

• (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?")

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.

StackExchange DevOps Q#4019, answer score: 2