Many months into being CPO at CloudBees it’s high time that I start sharing my thoughts about our domain and the continuous economy it powers in public. So consider this the opening post of many to come.
What’s top of mind for me is that we at CloudBees are in the midst of a big new phase of our own DevOps transformation: “Continuous Everything.” Let me explain.
Like so many of our customers, we’d been using many of the technologies and practices of DevOps (like CI/CD) within engineering, and we (of course) have a team full of people passionate about DevOps, yet we still had many symptoms of the ills DevOps is supposed to cure.
Sales and marketing wanted more, faster. Developers were frustrated that it took too long for their work to reach customers, that they had too little and late actual feedback, that there was too much gatekeeping by other groups and too little ownership. Product management felt pressured to publish and stick to roadmaps with features and dates promised to enterprise customers, the board and execs without the ability to respond to changes in the market and act on new ideas not enough visibility into what engineering would actually deliver. Product marketing felt like they didn’t really know what was coming till they were already late on a big set of enablement materials needed by sales to sell new features or products. I could go on, but you get the idea.
You may be shocked about how open I’m being about all this but I think pretending otherwise defeats a core tenet of DevOps -- the willingness and ability to honestly assess where you are as a foundation of continuous improvement. I don’t think there’s any shame in it, unless we’re unwilling to face and fix it.
My contention is that 99% of enterprise software companies in our size range with similar customer lists (we are active in 43% of the Fortune 100) are exactly the same. Similarly, most companies in industries like banking, pharma, manufacturing, logistics and the like are at early stages of transformation. Most are using the technologies and practices but have a long way to go to get to the standard of elite DevOps performers’ metrics on deployment frequency, MTTR and the like.
For the most part it’s still primarily the digital native consumer or totally self-service cloud infrastructure companies (or the few legacy companies that have totally transformed into the equivalent of digital natives) that are far ahead. Think Facebook, Netflix, AWS, Google, etc. Why?
Well, to me it’s because these digital natives can more naturally do what I call... Continuous Everything. What I mean by that is that every function of their business was built or rebuilt around the idea that their product is continuously evolving without long lead times, and often using experiments that mean that the product is not the same at the same moment for every customer everywhere. That includes sales, marketing, finance, legal, support, technical communications and just about everything else. They don’t have pressures spilling over from earlier eras of discontinuous approaches to go-to-market, compliance or operations. (Although let’s see what happens with the Facebook backlash...)
By contrast, all the things that surround software development in traditional businesses are deeply structured to expect big releases with long lead times and ostensibly predictable year or more roadmaps. And enterprise software, particularly self-managed software that customers install themselves, is still a traditional business. “What’s your roadmap?” is the most common question a product leader like me gets from customers, boards, sales, analysts and more - even analysts covering continuous delivery and agile! As are the majority of banking, pharma, manufacturing, logistics and the like before deep digital transformation.
So here at CloudBees, a big part of what we are doing to go through our own digital transformation is systematically reinventing every business process surrounding software development as Continuous Everything - and retraining all of our nervous stakeholders to understand why this is a good thing.
I’ve finally sworn off of roadmaps rather than continuing to try to explain that they don’t have to have dates as I’ve done for 10 or so years. Instead we’re adapting sales’ model of forecasts to what’s in the software delivery pipeline. I’ve brought with me and am adapting work in agile, or continuous product management and live crowdsourced docs that I started years ago when I was first grappling with agile as a young product leader at Splunk . We’re shifting product marketing work left, so that when a release comes out the release notes and enablement “write themselves” as part of the output of a pipeline. We’re looking at ways to incorporate behavioral analytics to automatically feed back on the success of hypothesis driven development as customers like Microsoft Bing and Hootsuite did in my previous role at Interana . Observability replacing simple monitoring plays a role too in shifting ops left, as I am learning on the board of Honeycomb.io . Marketing, support, sales, legal and finance are learning to work with us in product in a continuous way.
What’s interesting to me is that I’m hearing more and more of our customers in other industries, and the analysts that cover them, talk about similar issues they are facing. At CloudBees-sponsored DevOps World / Jenkins World Nice, multiple customers talked to me about the need to change outsourcing contracts, compliance, marketing and more to be continuous and not project or planned milestone driven.
Here’s what I now believe is true:
Any function that is discontinuous in a software business is an impedance mismatch with continuous agile and DevOps practices in engineering and will neutralize the business impact of these practices.
And since we’re in the business of building the world’s first end to end system for software delivery, we’re going to turn what we do and what we see our customers needing to do into extensions of the CloudBees Suite as we go - way beyond what we all think CI/CD is today.
Check back here and I’ll report progress and details of how we’re approaching topics like:
Continuous documentation
Continuous product management
Forecasting vs roadmaps (think Waze vs a train schedule)
Continuous marketing
Continuous support
Continuous sales enablement
I’m also working on telling the story of my own 15-year journey from resisting to embracing the continuous movement, as well as some accelerating thoughts on the massive positive social impact of the whole thing.
Christina
(P.S. The title’s allusion to “including this blog” is that part of why it took me so long to start posting here at CloudBees is that all of these ideas were forming fast and furious and I was trying to get them all coherent and essentially writing a dissertation not a blog post... till our wise board member Bob Bickel nudged me into realizing that was extremely waterfall and non-agile, non-continuous of me and certainly not in the spirit of blogging. In fact, blogging is continuous delivery of ideas!)