It’s the Culture, Stupid
American politics has certainly gotten more “entertaining” in recent years. That was not the case a few decades ago when politics was rather boring. So when the slogan “It’s the economy, stupid” hit the 1992 US Presidential campaign trail, it woke the public up.
By 1992, the US economy was in a deep funk. The US markets were still reeling from a devastating stock market crash in 1987. Then in 1990, the US Congress passed a budget that increased taxes, despite President George Bush’s earlier campaign promise “Read my lips, no new taxes.”
The result was a resounding victory for Bill Clinton and the rest of the decade saw strong economic growth. While I do not necessarily credit economic fortunes to whoever sits in the White House, Bill Clinton did get the sentiment right. What American’s care about most is the economy.
Last week I was in Las Vegas shuttling back and forth between the DevOps Enterprise Summit (DOES) and Money 20/20. While I did not see all of the talks at DOES, one message clearly weaved itself through the underlying theme of the conference. When it comes to DevOps, culture matters.
A brief history might help to explain why. When John Allspaw and Paul Hammond presented their talk “10+ Deploys per Day: Dev and Ops Cooperation at Flickr” at the O’Reilly Velocity Conference, it fundamentally changed the IT world. Around this time Patrick Debois and Andrew Shafer had been talking about “Agile Infrastructure” and upon hearing the Velocity talk, Patrick launched DevOpsDays.
Culture was the spark that helped ignite the DevOps movement. The Allspaw and Hammond talk focused on cooperation between Dev and Ops. Debois and Shafer sought to understand and solve the lack of cohesion between the application and infrastructure teams. What they and the early advocates of DevOps came to realize is that it comes down to building a culture of trust.
Then culture didn’t seem so important. The early message of culture change was drowned out by the huge investment in automation and tools. The number of vendors and consultants multiplied exponentially, all offering to support DevOps. It created an environment where companies were rushing to implement “the DevOps” before understanding what DevOps entailed.
I have the privilege of speaking to many companies and IT leaders, so I have a good sense of what DevOps means to these organizations. Every enterprise is doing some form of DevOps, where they have a dedicated DevOps team staffed by DevOps Engineers, and implementing lots of DevOps processes, systems and tooling.
Sadly, it is mostly automation and little to do with culture change. They do a good job when it comes to implementing CI/CD tooling. They deploy code a bit faster than before, but there is little real impact on business results. In fact, faster deploys are hurting the customer experience according to DORA because the medium performers are churning out code with more defects.
When I bring up culture change, the response is usually about adoption of their CI/CD pipeline. But that is a vanity metric. All your engineers might be using it, but what was the outcome of this automation?
Perhaps it is best to start with my tweaked version of a definition from the IT Skeptic:
DevOps brings together Development and Operations to work collaboratively at the culture, system, practice, and tool levels, to achieve accelerated value to customers.
Definitions will differ based on perspective. Some focus on faster deploys, some focus on systems, and for others it’s about collaboration. However any organization ultimately exists to serve its customers. It is therefore important to tie anything IT related to customer outcomes, whether that is the external customer or an internal business stakeholder.
Automation by itself does not necessarily lead to desired outcomes. If you roll out a new mobile app faster, but it crashes all the time or is painfully slow, is that a good outcome? Would that lead to finger pointing between engineering and ops? Does that sound like culture change has occurred?
Read my lips, it’s the culture stupid. Without that, organizational silos will remain, work will be output based rather than outcome based, and attempts at collaboration will be undermined by misaligned incentives and skewed performance metrics. Automation is a step towards knocking down silos, but first people need to feel safe that automation and all that entails is a step worth taking.
Next week I will share ideas on how to instigate change. In the meantime, let me know what your experience has been with culture change.
What has worked or not worked in deploying DevOps? Was your focus on the technology first or the culture first?
What are the Windows A: and B: drives used for?
Honestly never really thought about this until I read this question …
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.
