Anywhere there is lack of speed, there is massive business vulnerability:
Speed to deliver a product or service to customers.
Speed to perform maintenance on critical path equipment.
Speed to bring new products and services to market.
Speed to grow new businesses.
Speed to evaluate and incubate new ideas.
Speed to learn from failures.
Speed to identify and understand customers.
Speed to recognize and fix defects.
Speed to recognize and replace business models that are remnants of the past.
Speed to experiment and bring about new business models.
Speed to learn, experiment, and leverage new technologies.
Speed to solve customer problems and prevent reoccurrence.
Speed to communicate with customers and restore outages.
Speed of our website and mobile app.
Speed of our back-office systems.
Speed of answering a customer’s call.
Speed to engage and collaborate within and across teams.
Speed to effectively hire and onboard.
Speed to deal with human or system performance problems.
Speed to recognize and remove constructs from the past that are no longer effective.
Speed to know what to do.
Speed to get work done.
— John Mitchell, Duke Energy.
When enterprises need to change urgently, in most cases, The Problem is with the organization, the system in place. Individuals, like technology, are highly adaptable and can change. They’re both silly putty that wiggle into the cracks as needed. It’s the organization that’s obstinate and calcified.
How the organization works, it’s architecture, is the totally the responsibility of the leadership team. That ream owns it just like a product team owns their software. Leadership’s job is to make sure the organization is healthy, thriving, and capable.
DevOps’ great contribution to IT is treating culture as programmable. How your people work is as agile and programmable as the software. Executives, management, and enterprise architects — leadership — are product managers, programmers, and designers. The organization is their product. They pay attention to their customers — the product teams and the platform engineers — and do everything possible to get the best outcomes, to make the product, the organization, as productive and well designed as possible.
I’ve tried to collect together what’s worked for numerous organizations going through — again, even at the end, gird your brain-loins, and pardon me here — digital transformation. Of course, as in all of life, the generalized version of Orwell’s 6th rule applies: “break any of these rules rather than doing anything barbarous.
As you discover new, better ways of doing software I’d ask you to share those learnings a widely as possible, especially outside of your organization. There’s very little written on the topic of how regular, large organization managing the transformation to becoming software-driven enterprises.
Know that if your organization is dysfunctional, is always late and over budget, that it’s your fault. Your staff may be grumpy, may seem under-skilled, and your existing infrastructure and application may be pulling you down like a black-hole. All of that is your product: you own it.
As I recall, a conclusion is supposed to be inspirational instead of a downer. So, here you go. You have the power to fix it. Hurry up and get to work.
This post is an early draft of a chapter in my book, Monolithic Transformation.