Can’t Just Buy the DevOps
I had a meeting with the head of digital of a big telecom company in Hong Kong. Towards the end of our conversation, this Chief Digital Officer says:
“So I need someone to head up DevOps like yesterday.”
“And what exactly do you expect this person to do given what you just shared about your infrastructure and systems?”
This was after a lengthy explanation by this same person on why the company does not have many developers, mostly buys packaged products not requiring developer resources, and outsources most of their development.
It was surprising to hear that a major telecom would outsource development. If you believe that software is eating the world, then outsourcing IT is tantamount to outsourcing the core of your business. Conversations with other IT executives in Hong Kong however confirmed that outsourcing technology is pretty standard.
The point about needing a DevOps leader really threw me however. It seemed like a misunderstanding of what DevOps even is. I tweeted the following:
I realized that I was listening to someone that wanted to buy a capability. The challenge is that there is nothing you can buy! DevOps is not a thing or a tool or a bunch of people that you slap titles onto that now own “the DevOps”. You might was well buy a box of air or shove money down a drain.
Part of the confusion comes down to definitions. I shared a definition of DevOps before, but Tom Limoncelli recently shared a much more elegant and succinct version with me in a recent conversation:
“DevOps is how we achieve rapid software releases.”
DevOps is about how you get software out into the world faster. Normally this is an arduous process requiring lots of time, people, and coordination. But in the excitement to go DevOps, we forget that what matters most in DevOps is the communication, not the automation.
Most organizations, especially the global type, are not setup to communicate well. They are siloed by group, geography, and function. That creates friction points that slow down communication. Tools will not help in this case, only a fundamental shift in culture towards openness and ownership of code will have a lasting and notable impact.
It is not a people or resource issue. You can use recruiters and job boards to find DevOps people. But if there is no willingness to shift the culture, those people will be setup to fail. Nevermind a situation where all the developers are outsourced. Are you really going to change another company’s culture or create a sense of code ownership?
A smarter approach to DevOps is to take an iterative, small batch approach. It’s better to see what processes and tools work, observe the culture in how people interact, and take note of the things that can speed along knowledge transfer and foster collaboration. Eventually you can scale this into “the DevOps” across the entire organization.
How are you doing “the DevOps’ today? What have been the biggest fundamental challenge you faced in driving change and adoption?
Why do plants have green leaves and not red?
I do hope Spring will come to the Northeast US at some point…
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.
