Why should every C level executive need to know about DevOps / Continuous everything?
Updated: Apr 28, 2021
- (opinion) by Guy Halfon
And no, I’m not implying all CEO’s need to know how to code now like Elon Musk or stranger examples like Jimmy Fallon or Ashton Kutcher
Whether you are the CEO of a shiny new "special delivery to the moon" Software as a service, or a run of the mill bakery plant, It’s pretty clear that software is now governing your entire company - be it your line of business applications, such as manufacturing and sales or HR and Offices Logistics.
We’ve known for a while that if your business doesn’t evolve and become fully computerised, it would lose its competitive edge to the other players of the game. It became obvious when it came to selling on the internet, and it's obvious when we are talking about robotics on the manufacturing floors of car makers.
It seems we are on the brink of the next great manufacturing revolution - the revolution of DevOps and Continuous Everything.
Big banks of the world already know this, and now even much less sophisticated businesses are starting to understand.
Fintech companies disrupted the banks business because they had less regulatory overhead, and they came up with brand new ways to do old things, sure. Amazon inc. is a great company - why wouldn’t it wreck havoc in the groceries or insurance markets once it decided to step in? Wix.com is skyrocketing in a market treaded by giants and no one thought could be shaken. The last century has been full of different market disruptions, seemingly unconnected. Are these all just a coincidence? What do all these business have in common that allows them to self propel themselves at amazing speeds, leaving their legacy competitors way behind? What kept HBO and Disney away from Netflix for so long?
All these companies have one major trait in common. A culture that gives everyone involved a crystal clear goal - deliver fast! - test fast, fail fast, and progress faster.
What is DevOps?
From Wikipedia - “DevOps is a set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality”
Development, operations, shorten, continues and quality - These are the traits DevOps is actually about.The creation of a continuous flow of improvement by change and of course while maintaining quality.
How does it work?
let’s break it down to the following key aspects -
Automate everything - every aspect you can thing of should be automated. Manual operations should be reduced to a bare minimum. be it testing, deploying, securing or any other aspect you can think of, no more manual stuff, not even ticking a checkbox.
Create tests for everything, monitor and measure everything - you start your planning of anything new by planning and developing tests for its outcome. When talking about a whole new feature, you are asking what would define it as a success in engagement perhaps, or reducing latency for example, and this goes down into the code itself of course (see TDD). Then, you release your invention on a test group, and you will be able to know if it had had a positive impact or a negative one before releasing it to the rest of your customers.
Make it a priority to destroy organisational silos - there should be no “us” and “them” in the flow of delivery. For example, security can’t “sign off” anymore, but rather hook into a process without slowing it down (How? Automation of course).
I'm in. What questions should I be asking my team?
IT and Engineering departments are mostly measured with concepts such as Time to market, ROI, TCO and maybe even “what technology are we using” (are we Microsoft? Linux? Virtualisation? How much did we move to the cloud?)
While these are all important questions. they don’t really plug into the bigger picture of a business. TCO will not bring us new business, and will not make sure we are not wiped away by the next product revolution. After a while ROI isn’t asked about either. Instead, Evolved business are asking themselves an entirely different set of questions to asses their DevOps maturity:
How many new features do we release every day?
You should be releasing a lot. because that means you have achieved velocity while maintaining stability. It means your teams are trying new ways to push your business forward by testing new software on your customers and releasing.
Are we monitoring all our important business metrics?
Monitoring business metrics means you are focusing on what matters. This is a hurdle many teams fail to overcome. they keep looking for failures in software/equipment etc. and never progress to looking at engagement, sales etc.
Is our infrastructure geo redundant and always on (vs highly available)?
It’s a fact that most Disaster recover plans are never really tested, because testing them brings huge overhead, and rolling back even more so. So when there is indeed an incident, you are never really prepared. The mature approach is running simultaneously from different locations so when one fails everything continues as normal until it returns, increasing resilience again.
Is our spending mostly OPEX (And not CAPEX)?
When you are invested, it’s harder to change, people have to justify the dumping of a long term investment. You won’t judge your team for switching an OPEX, and this will allow them to adapt new tech faster.
To sum it up, to increase your company’s velocity and bring it on par with the startups of your industry, you will have to change your company culture. your team will need to think like a startup - allow them to look a little less far ahead, push them to test and fail rapidly, and hopefully they will succeed much faster as well!