DevOps: A House Divided

What is DevOps? DevOps is not about tools. It is about culture, enabling cross-functional teams to quickly deliver value in a sustained matter. It is hard to define DevOps, but blah blah alignment blah success blah blah joy. Three paragraphs later, no takeaways. How many posts have you read about DevOps that follow this format? Promoting this vague clickbait as guidance is only doing ourselves a disservice. We’re patting ourselves on the back so hard we fall over.

How did we end up here? I think it’s because we’re still not having real conversations between business units. We find ourselves now with two camps in the DevOps community: technical and non-technical. Either side shifts the conversation to where they feel most comfortable: the domain they work in and understand. Technical folks talk about tooling. Non-technical folks talk about culture. The divide here is artificial, but it’s one we maintain through our expectations and values.

The idea that technical and non-technical skills are exclusive is one of the biggest problems we should use the DevOps movement to tackle. This isn’t just an enterprise problem - small organizations are just as susceptible to this fallacy. It may be easier to try to fix in a startup, but this requires time for introspection. In a culture that values shipping above all else, improving ourselves is de-prioritized.

Let’s look at a couple of these broken expectations and values.

Engineers are good at talking to computers, not people.

Engineers are technical wizards, shipping software is their value to our company. They lack the social abilities to communicate with other business units or customers.

This idea is perpetuated by technical and non-technical people. I am an engineer - I know many engineers that (say they) are fine with this arrangement. It’s easy. We can focus on building and not have to worry about politics. Alas, it doesn’t take long for this setup to fall apart. Engineers end up building the wrong thing because we have, at best, secondhand insight into the issues customers are really facing. We get crabby when the business starts new initiatives that we don’t understand. Non-technical people start treating engineers like children, limiting the damage we can do along with our potential. An “us vs them” mentality evolves.

What can we do?

Being non-technical is okay.

Sales is good at closing out deals. Marketing is good at promoting our brand. This is their value. All of their time should be spent moving customers through the funnel.

This is a tricky, and particularly damaging, fallacy if what you sell involves software. Sales calls where slide decks are being shown to development teams, marketing blog posts that get technical details completely wrong. These are the fruits of this fallacy and can lead to lost sales and negative reputation. The solution here is not to set up a change control process. As Jez Humble says, “the goal of change control is to ensure nothing ever changes”.

What can we do?

I’ve had a good amount of success implementing the above suggestions at Conjur and previous jobs. A bullet-list makes this look easy, but it’s not. You really have to be consistent with your message, work hard to develop the trust of your colleagues, and explain your goals repeatedly to a lot of people. Getting your own team aligned is the easier battle. Let’s start talking about what comes next. @dustinmm80 on Twitter.


Now read this

Writing for Software Engineers: A Primer

READMEs. User manuals. Operation guides. Handbooks. Command-line help. Internal chat. Company blogs. As software engineers, we write often, and in many different contexts. The code we write often doesn’t provide value without some sort... Continue →