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?

• Incentivize cross-functional collaboration. Ensure that engineers are also included in the early and late stages of a project.
• Make it a point to share notes with the entire team. Customer calls, engineering standups, business proposals. Assign a scribe for every meeting.
• Get engineers on customer calls. They can be silent participants at first, if you like. A few calls a month (per engineer) limit distraction from their other tasks.
• Use shared tools for communication across business units (e.g., everyone uses Hipchat or Google Drive). Don’t lock people out.
• Don’t put engineers on a pedestal. Relaxing rules for one group causes animosity and inhibits cross-functional efforts.
• Coach engineers on how non-technical processes work. Explain how sales and marketing work. Clarify what terms like “qualified lead” or “net promoter score” mean.
• Stop looking for 10x engineers/ninjas/rockstars. Instead, look for curious engineers that can deliver software and communicate with non-engineers.

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?

• Incentivize technical literacy across your organization. Allow time and budget for people to talk to each other and go to meetups and conferences.
• Treat “I’m not technical” as a problem to fix, not an affirmation of how things are.
• Establish a pattern of knowledge transfers that align to company initiatives. For example, if you’re going to talk about Jenkins in July arrange time for one-on-ones with engineers and marketers/salespeople to ensure you get the conversation right.
• Share drafts of sales and marketing materials so engineers can read and comment on them. Allow enough time for thoughtful feedback.
• Open up demos for the whole organization. Give engineers enough time to prepare a compelling demo.

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.