Why DevOps can be stressful

In a later blog we discuss three types of people who deal with DevOps in different ways. Ostriches, Change junkies and Naysayers. The titles say it all. But what has that got to do with stress and how do we address it. This blog aims to help the owners of the DevOps journey to destress adoption. Tools and process are straight forward in a DevOps journey its the culture that takes the longest time.

In a general sense change is stressful for people in life or work. In the days of the cold war people who were marrying, divorcing or grieving the loss of a loved one were prohibited from having access to the nuclear codes. Stress makes people edgy, irritable and forgetful all at the same time.


We have an emotional part of the brain and a logical part of the brain. As adults our logical part is bigger than the emotional but there are more connections from emotional to logical. We react to change emotionally unless we deliberately engage logic. When we do that, we reduce stress

Stress usually manifests itself as absenteeism and increased attrition rates all of which impede the businesses ability to function normally. One of our larger retail banking customers provided counselling to people who were exhibiting signs of stress in the face of a fundamental change in their business model.

So we know stress is bad for staff and the business but why is changing an IT process stressful in the first instance. The intellectual view of any professional is that we are trained to accept that we must adapt to survive. My about to be graduated 22 year old daughter just said to me over lunch that no change is more scary than change. But emotional views that generate stress tend to override rational thought in the face of change.


Where there is a change of IT process sometimes there can be a sense that a person’s recent work has been somehow invalidated. In IT terms we see Silicon Valley as thought leaders so if they are embracing DevOps as the norm we must understand how it can impact work. For example the Valley would say that cloud in any of its forms is a logical end point for many DevOps journeys (this will be the subject of an upcoming blog) but for many Ops people cloud is perceived to mean no Ops and is seen as a threat… how do I pay next month’s bills? is a stress inducing thought for anyone.


The emotions these thoughts generate impede clear thinking which would say that there is as much opportunity as threat in a changing world. New process and new tools lead to new career opportunity and perhaps higher earnings but that’s rarely a first or even a second thought.

Today in our market there is a shortage of people to work in public, private and hybrid cloud environments. More data than ever is being stored processed analysed and archived but that’s never understood early on plus there is a reality that in order to realise the opportunity staff may have to switch employers.

Dev’s correctly assert that waterfall works well and while it may not be perfect at least deliverables to the business are agreed in a structured fashion. Its also true to say that not all business applications are suited to an agile approach. But it’s nearly always true to say that systems of differentiation and innovation do require an agile approach if the business is seeking digital opportunity. So putting IT in a place where its empowering competitive advantage leads to greater job security but again thats rarely a first thought as people can be defensive if the communication is not managed well.

In meeting the various people on Dev teams its important to make sure that learnings and processes that have been painstakingly acquired are not recast as ‘we’ve been doing this wrong’… its more like ‘ we can do this better reusing core skills we have acquired’.

Simple tools like the ‘penny game’ can illustrate this point and it’s important to note that code still has to be written and unit tested etc so the fundamentals are the same and the requirement for them to be good coders is as important as ever. We are just re-ordering tasks to reduce context switching and provide greater focus on single tasks until they are completed where done means in production.

And yes there are new requirements.

They are asked to own code into production and learn how to control infrastructure as code. Personally I have yet to meet a Dev that didn’t want to play with new toys but there are exceptions to every rule and how these are managed is critical.

We have also seen teams that have been on a death march project resist the idea of owning code into production and thats normal so timing training and change to happen on a new project as opposed to just after a death march is only good common sense.


Ops folks who say ‘our systems are very stable’ have a point. They will acknowledge that they can be slow to release but question does it really matter – it didn’t seem to matter last year and the year before. Positioned incorrectly and driven by naysayers this can lead to a sense that DevOps is a passing fancy and concepts such as smaller changes lead to less risk are pooh poohed.

IG a financial trading platform company had a project to ‘get their Friday evenings back’ . This was a four year journey from start to finish but eventually people realized the personal win for them was more social time at weekends. They moved to a situation where they were releasing smaller changes more frequently with better resiliency processes including blue green deployment. And they get to go to the pub on a Friday after work and destress!


And there are interactions between the different groups of naysayers, ostriches and change junkies which amounts to conflict. Not to mention the conflict between silo’d dev and ops teams. Conflict is stressful and again emotions abound. People who dug one another out of tight technical or professional situations in the past disagree about the need for change and do not discuss it rationally. Camps form and positions entrench.

As a solutions business we observe the formations of these camps and sometimes broker truces through leading training or leading projects ‘independently’ to bring new process in the course of delivering a project of value to the business. We work with larger indigenous organisations with more established work practices as compared with how US based decacorns or even local unicorns work but even in those organisations that have modern HR process and contracts silo’d thinking can emerge and building a new team ethic is a challenge.

Leaders need to understand what type of person as an individual they are dealing with, respect that persons strengths and weaknesses and be aware of the individuals emotional state of mind when engaging staff.

For ostriches education is the best way forward. Once people realise that DevOps is an industry wide evolution and they are learning and growing, the penny drops and they adapt. They overcome the irrational fear of the unknown, logic prevails and stress levels return to normal.


For the change junkies it will be important that their roles are lauded without rubbing anyone’s noses in it and they should do their utmost to bring people with them on the journey without making it sound like a revolution; the only way; or their own personal invention and preference. Perhaps toning it down summarises best whats required and let results and actions speak for themselves.

For the naysayers there has to a tougher line. They are the most difficult to persuade and educational efforts, one on one sessions and case studies or reference site visits to other companies where their peers are adopting DevOps processes should be utilised. It’s important to identify and tackle these folks up front. Identifying them is easy – right now as you read this article you know who the strong characters in your dev and ops teams are.

A focus on naysayers early on is advisable and can unfortunately lead to a parting of the ways but we have seen situations where the naysayer turns into a leader for change. In one of our clients a character who was disrupting the left to right flow came on our DevOps foundation courses and went back to his team to explain that he was a DevOps fan all along.


At another course there was an open conflict and a naysayer was persuaded that resisting change was futile. Naysayers tend to be stronger characters and provided their emotions do not overcome them entirely they can emerge as the best DevOps advocates because they have really understood why a change is required. Often times the most difficult to win over become your best champions.

Sometimes people just cant or wont be led. In these scenarios they have to go and that is painful and stressful for all. But get it done and do it early so that those who remain are clear about your purpose.

I hope you found this article useful. Daysha doesn’t do ‘change management’ so this was an attempt to round up our learnings on ‘culture’ change as we have seen it in our DevOps journey with various clients.