DevOps is a flat circle

Moving from an engineering role into a highly technical sales role provides an amazing vantage point from which to observe both the beginning and end of DevOps.

Starting with the end in mind, the term DevOps has become unfalsifiable. It covers tools, processes, metrics, psychology, and marketing. I challenge anyone working in tech to identify the parts of business that couldn’t be reasonably covered by the term DevOps. I’ve run this thought experiment, and I had to go to some absurd lengths to find departments that fell outside the spirit of DevOps.

Sales and marketing contributed to this by brainstorming ever more creative ways to attach their brand to the notion of DevOps. Researchers compete to add yet more nuanced layers to the academic field of DevOps without ever offering strong opinions on what DevOps is not. Anachronisms like “You build it, you run it” were never reexamined against the exploding complexity of IT ecosystems. Thought leaders are consumed with inventing new Dev-Something-Ops paradigms, but never manage to articulate how these new responsibilities would be distributed in a DevOps team. Too many teams cannot answer the question “What am I not responsible for?”, and worse yet, are led by managers who are suspicious of the question, wary of enabling troublesome thoughtcrimes like Maybe it’s OK to not be a Kubernetes expert.

And yet, the core ideas that gave rise to DevOps are as powerful as ever.

After evolving Dev and Ops teams with their own (often competing) goals and metrics, reporting to distinct management hierarchies, and forcing them to communicate via support tickets, enterprises were left wondering why the customer seemed to come last and why the teams ended up distrusting each other.

There was a valiant effort to perpetuate Conway’s law by adding ticket SLAs, enforcing respectful discussions, taking discussions offline, creating amorphous “centers of excellence” that walked a fine line between grouping people around a shared goal while never threatening existing rigid hierarchies, and educating everyone about the X/Y problem.

But ultimately the answer was as obvious as it was brilliant: create a single team with shared metrics, reporting to a shared management hierarchy, and working backwards from the shared goal of delivering value to the customer.

As obvious as those initials insights were though, working with large DevOps teams makes it clear we are in a post DevOps world. You built it, you run it does not scale to 5000 developers when cloud providers are inventing new paradigms every 5 years. DevEx both supports and rebukes DevOps by calling out high cognitive load as a core factor in inefficiency. DevOps teams are finally treating the question “What am I not responsible for?” as a sign of strength and maturity instead of an excuse not to do work.

But it is also easy to see history repeating in the interactions between sales and DevOps teams. They are separate parts of the business, communicate via tickets, and driven by competing schedules. Product cycles are measured in years, engineering cycles in months, and sales cycles in weeks or days. Placing a field in a support ticket with the instructions “Considering the X/Y problem, describe both the problem you are trying to solve and your attempts to solve it” will only take you so far. Sales teams see the inability of the product to solve a customer’s problem as a failed test, product management sees it as a data point to be folded into long running research, and engineering just prays that no one demands they shoe-horn in an ill-conceived “short term” fix that they end up having to support for the next 10 years.

Meanwhile, no one asked the customer what they think.

At the risk of being just one more budding thought leader looking to hitch their wagon to the DevOps train, I can see a reasonable argument for DevSalesOps. Obviously we must resist the urge to make developers play the role of CSM, TAM, SE, or AE — giving a developer a SalesForce login or asking an AE to submit a pull request must be considered red-lines. But when history starts repeating where customer’s priorities are lost to the rancor generated by distinct management sales and engineering hierarchies, competing priorities, and comms-by-ticket, it is worth acknowledging that DevOps has been there and done that.