<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2018-05-01T11:38:36.657Z
2018-05-01T11:38:36.657Z
Stuart Ainsworth
<p>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.</p>

<p>But "traditional" IT is <em>all about</em> 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 <em>exactly the same</em> to the greatest extent possible, and you need to have a plan for resolving the deltas. <a href="https://www.theregister.co.uk/2018/04/24/devops_dba_work/" rel="nofollow noreferrer">DevOps doesn't really address</a> 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.</p>

<p>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. </p>

<p>I will wager that some variation on this theme is the root cause of <a href="https://www.theregister.co.uk/2018/05/03/tsbs_middleware_nightmare_execs_grilled_by_mps/" rel="nofollow noreferrer">TSB's woes at the time of writing</a>. They failed to exercise sufficient care with the stateful parts of their system.</p>

CC BY-SA 4.0
2018-05-04T06:59:20.380Z
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
CC BY-SA 4.0
2018-05-04T07:31:36.043Z
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
CC BY-SA 4.0
2018-05-04T08:22:27.310Z
I see; possibly there different opinions. https://devops.stackexchange.com/questions/3911/limits-of-or-preconditions-for-of-blue-green-deployment
Ta Mu
CC BY-SA 4.0
2018-05-04T05:33:24.280Z
2018-05-04T07:38:30.937Z
2018-05-04T07:38:30.937Z
Gaius
<p>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. <a href="https://trunkbaseddevelopment.com/" rel="nofollow noreferrer">Trunk-Based Development</a> - 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.</p>

<p>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.</p>

CC BY-SA 3.0
2018-04-30T17:34:10.227Z
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
CC BY-SA 3.0
2018-04-30T17:44:16.220Z
I'd rather say opposition in the "automation is killing jobs" category :)
Dan Cornilescu
CC BY-SA 3.0
2018-05-01T00:26:55.023Z
Okay: true, though this is not bound to a specific stakeholder group I'd say.
Ta Mu
CC BY-SA 3.0
2018-04-30T17:29:35.817Z
2018-04-30T17:29:35.817Z
Dan Cornilescu
<p>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. </p>

CC BY-SA 3.0
2018-05-01T15:14:04.810Z
2018-05-01T15:14:04.810Z
xtreampb
<p>What are typical stakeholders and their reasons not to support/enable DevOps principles?* </p>

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

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

<p>I can think of these typical examples:</p>

<ul>
<li><p>Developers, either junior or more experienced who would like to "just do their job they are paid for - establishing software solutions and coding them"</p></li>
<li><p>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.</p></li>
</ul>

<p>Others?</p>

<ul>
<li>(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?")</li>
</ul>

CC BY-SA 3.0
2018-04-30T16:21:01.047Z
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
CC BY-SA 3.0
2018-04-30T17:14:04.303Z
;) so would be the question less open put as "is this the complete list of two items?" (Y/N) :-)
Ta Mu
CC BY-SA 3.0
2018-04-30T17:33:37.973Z
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
CC BY-SA 3.0
2018-04-30T17:48:37.947Z
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
CC BY-SA 4.0
2018-05-05T17:24:50.537Z
This would probably be better as an open-ended question with the examples you had in mind posted as an answer.
Xiong Chiamiov
CC BY-SA 4.0
2018-05-05T17:37:54.153Z
@XiongChiamiov not sure what do you mean please share your answer option
Ta Mu
<culture>
Understanding DevOps opponents on stakeholder level beyond typical examples
Ta Mu
# Understanding DevOps opponents on stakeholder level beyond typical examples

(Asked by: username_0 on 2018-04-30)

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

**Tags:** culture

> **Comments:**
> **username_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... ;)  
> **username_0**: ;) so would be the question less open put as "is this the complete list of two items?" (Y/N) :-)  
> **username_1**: 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?  
> **username_0**: Honestly I asked myself what are other examples of the stakeholder groups; if there are really only those two I'm fine with them.  
> **username_2**: This would probably be better as an open-ended question with the examples you had in mind posted as an answer.  
> **username_0**: @XiongChiamiov not sure what do you mean please share your answer option  

---

## 4 answers

### Answer by username_3 on 2018-05-01. Score: 2

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.


---

### Answer by username_4 on 2018-05-04. Score: 2

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](https://www.theregister.co.uk/2018/04/24/devops_dba_work/) 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](https://www.theregister.co.uk/2018/05/03/tsbs_middleware_nightmare_execs_grilled_by_mps/). They failed to exercise sufficient care with the stateful parts of their system.

> **Comments:**
> **username_0**: Thanks for this insight, @username_4; 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?  
> **username_4**: 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  
> **username_0**: I see; possibly there different opinions. https://devops.stackexchange.com/questions/3911/limits-of-or-preconditions-for-of-blue-green-deployment  

---

### Answer by username_5 on 2018-04-30. Score: 0

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](https://trunkbaseddevelopment.com/) - 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.

> **Comments:**
> **username_0**: 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)  
> **username_5**: I'd rather say opposition in the "automation is killing jobs" category :)  
> **username_0**: Okay: true, though this is not bound to a specific stakeholder group I'd say.  

---

### Answer by username_6 on 2018-05-01. Score: 0

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.


---

