Visible Shades of DevOps Cultures

UFC 147

Ops vs. Dev

It’s an understatement to say there’s been a huge amount of buzz around using DevOps as a solution to help solve operations and development problems.

DevOps eBooks, Books, Blogs and Podcast are now flooding the Internet with content about a topic very few really seems to understand or agree on.

Shades of DevOps

So far I’ve been a part of 3 implementations of DevOps, 2 of which failed in my opinion due to a lack of understanding, ego, grandstanding, and culture clash.

And the other is underway and seems to be working, so far…[update it also failed].

On Shades of DevOps we’ll visit the visible culture challenges and opportunities organizations have as they work through the pitfalls and mistakes of their DevOps implementation.

Why not just read a book and form a team?

Because DevOps is not an easy change for the legacy IT Department to make, and in some cases, it may not be worth the trouble.

But for those groups willing to press-through, the value-add is a high performing organization and better IT service delivery.

3 Basic Shades: White, Grey and Black

Lets focus for a moment on the title “Shades of DevOps.” This title perfectly sums up DevOps because there is no one way of approaching it, however; to make things easy and beneficial we’ll look at 3 basic shades: white, grey and black.

  • White – Dipping your toe into the murky waters but not really ready to get wet. Now you can actually say you’re using DevOps but you really aren’t.
  • Grey – Wading in slowly and learning from your mistakes but only going waste deep. No real value has been gained except finding the threshold where the pain is too much to bare.
  • Black – Jumping in head first and chaos ensued from clashes between Ops, Engineering and Development tribes. OMG, what have we done?

All joking aside, in my opinion, DevOps is more of a culture than a methodology, software tool, or even a practice.

Problems between development and operations have existed for years because IT Operations and Engineering see Development as a “THEY” instead of  “WE.” [We’ll go deep into this in later posts.]

#1 Obstacle – Are You A Control Freak?

I’ve been in closed door meetings with executives and I’ve heard every excuse there is why IT can’t offer the level of service developers are asking for.

The main problem being, “How do you maintain control of your staff and resources” when the solution to solve the service problem is a sharing culture that collaborates extremely close with (development)?

Obviously vendors would disagree with my views because they want to sell you software tools and training for how to use DevOps.

Sorry to rain on your parade but the real solution cannot be purchased; I will even go as far as to say it will be impossible for some organizations because the people trying to institute DevOps want to maintain absolute control.

“I will even go as far as to say it will be impossible for some organizations because the people trying to institute DevOps want to maintain absolute control.”

Control is Kyptonite

In DevOps, control is like kryptonite that drains the value-add from a DevOps seedling.

One day you don’t decide you are now a devOps shop and form a team, it’s more of a decision you make to start changing how you think.


From a leadership perspective start communicating and considering the following:

  1. Development is your partner. Schedule meetings with them so you can start understanding what they need.
  2. Why are you protecting prima-donna’s who nobody wants to work with? They are the biggest a-holes and roadblocks to progress [get rid of them]!
  3. Are you focusing on what is important based on delivering great services to your customer or are you building “The Great Pyramids” for egos so you look like you are accomplishing great things but in reality adding very little value to the company [but you look good]?
  4. Who benefits from the projects in the queue or backlog [time to re-prioritize]?
  5. Do you have any of your best talent meeting and working with your customers daily so osmosis is happening [seeing and feeling the problems will help solve them]?
  6. Are outside forces such as vendors or political agendas blurring your focus and causing you to make “stupid” decisions [an MBA doesn’t make you immune to STUPID]?
  7. Are your leaders, managers, and executives part of the problem? Are they telling you what you want to hear? [read the emperor’s new clothes]
  8. Does your hiring process weed out hiring staff that are counterproductive to a DevOps culture? [Here’s 3 DevOps Interview Questions to get the focus on the right mindset]
  9. Are you rewarding those who collaborate and are cultivating a DevOps culture? [Bonuses are great incentives]
  10. Finally, did you ask yourself if you are the problem? If you are a prima-donna with a political agenda that has everyone buzzing around you building the Great Pyramids, then forget about DevOps solving problems. [change direction]

Wow, that should hopefully stir up some interest on what DevOps is about!

BTW, I’m not asking for you to agree with me because in the end the bottom-line is results. And hopefully Shades of DevOps will help you think differently about – well – DevOps.

DevOps References:

Now it's your turn...