Voices in DevOps – Episode 8: A Conversation with Christina Noren of CloudBees

Guest

Christina has more than 20 years of experience in product, services and operations at successful, venture-backed companies, such as Splunk, Zuora, Portal and Sonic Solutions. She has a particular strength in identifying and refining product offerings in evolving markets. At Splunk, she was employee #12 in 2005 and remained on the senior leadership team through its 2012 IPO. She played a critical role in bringing Splunk’s 1.0 product to market, overseeing requirements definition, product delivery and the beta program. She went on to guide key technical innovations, including search-time knowledge and the Splunk search language. Christina is a co-inventor on the Splunk patent for Machine Data Web.

Transcript

Jon Collins: Hello and welcome to this week's edition of Voices in DevOps. I'm here to speak to Christina Noren of CloudBees. Now, am I going to get your title right? What do I say?

Christina Noren: I'm the chief product officer, the CPO, and the key thing is that for us as CPO, I'm responsible for all of engineering and product management and product marketing and design and documentation. So I run a whole software organization and we're building a product to bring a whole software organization together, so I am our internal… first customer of how do we do we do Agile and DevOps and continuous delivery better; and how do we run a software organization in as professional a way, as my peer running our field organization runs his.

Thank you very much for joining us Christina. What we're trying to get out of this is: organizations out there are struggling with DevOps. They may have started on the DevOps route and they're finding it more complicated than they thought. So I'm really, really interested already in the fact that you're not only kind of a purveyor of DevOps products if you like, but you're also the internal person who makes this stuff happen and therefore you've got to ‘walk the talk’ essentially.

Yeah. Exactly. That’s the term we use.

Good. How did you get here? If I may ask, what enabled you to end up being the CPO of one of the world's foremost... (I mean I don't want to blow smoke but essentially CloudBees, everyone's using Jenkins) everyone in the cloud space has heard of CloudBees, so how did you get here?

Yeah well it's been a funny journey.So CloudBees, you know I've been here just a just over a year and my team is responsible for product management, engineering, product marketing, design, documentation as a holistic function in the company. And I've been in software for 25 years. Like a lot of people, especially women of my generation, I came in through the back door and got technical [experience] on the job and held a whole variety of roles in my early career.

But starting in the early 2000s, I started running product management organizations just as engineering organizations were starting to move towards Agile, and I ran product for a few different companies in the log management space, but most notably I ran the product, I was the founding VP of product management and also started a lot of other surrounding functions for Splunk, from stealth mode when I was employee #12 in 2005 through our IPO in 2012. In that experience and previous jobs and jobs since, I've really found myself trying to figure out how product management and product marketing, the business, support, everything can align with engineering practices that are moving away from waterfall and into Agile; and then being responsible for product at Splunk, as really revolutionary way of looking at what was happening in production.

The sys admins using Splunk were often the ones that started becoming SREs and a lot of DevOps started to happen amongst our customers in those mid-2000s, so the products that I was responsible for... we're a big part of the Ops side of DevOps. So and then in the most recent CPO job I had at a company called Interana, prior to CloudBees, I really saw how implementing CICD completely transformed the rhythms between product management and design and engineering and our outcomes.

So I was kind of primed when CloudBees came calling and why a historically product leader is running a product engineering organization that's building a product primarily used by engineering organizations... that was my first objection. But what they really want is a product mindset, and moving from technology and sales driven to being product driven is something that not only a lot of historically technology companies are doing, but is actually one of the things that companies with traditional IT organizations are doing. They're trying to become product organizations and that's the core of becoming software companies.

Well I'm literally trying to draw pictures as you speak. I've got a mesh is appearing, we've got the Ops side, we've got the engineering side, we've got the product side. And then we've got the Agile thing and I think what's really interesting about what you're saying there is: seeing Agile from an Ops perspective and from a product perspective. And then how that feeds back into development, that’s pretty much the reverse of what other people are talking about.

Yeah. And you can find a slide show that's still up (from 2008) under my name of [me] talking about automating product management in an Agile world, which was kind of my fledgling stage of making peace with engineering doing Agile, which was an early stage of development. But these days you know we really talk about ‘continuous’ and not just continuous integration, continuous delivery, its technical practices, but I've been talking a lot about ‘continuous everything’ as a way of looking at every process in the business that touches software delivery, or that software delivery touches, and realizing that if it doesn't change to be compatible with continuous approaches, it's going to be an impedance mismatch that robs the organization of much of the value of continuous software delivery.

So take me back to 2008 if you will, and I'm wondering about which came first: the chicken or the egg on this one? Is it that the product mindset works better in an Agile way or is it that the Agile ‘continuous everything’ mindset enables better products?

Well I think it's both, but I think... Agile came out of engineers revolting against how ineffective, you know the waterfall methodologies were. And a lot of very simplistic views of what a product manager is doing is maintaining the roadmap, and it's damn hard to maintain a roadmap when engineering is iterating and changing sprint to sprint.

I think today's generation of product managers have really embraced Agile, even if they're still quixotically trying to produce roadmaps. There's a real disconnect there. But I think in the day to day work, good product managers, good young product managers who aren't tainted by the early bad experiences, like they really see their job as supporting that voice of the customer, taking early iterations quite rapidly to customers, a learning mindset, an experimental mindset and so forth.

So now I think Agile is very much at the heart of what a healthy contemporary product mindset is about. But you know as a second time young BPO product manager I was still in this, “Oh my God, my board members expect and my customers, my enterprise customers expect these roadmaps and if they change, it's a big deal and how the hell do I produce these roadmaps?” Engineering is just all over the place doing this Agile thing. Right? That was my very early like “Oh my God I've got to make peace with Agile as a product manager, and what's expected of me is a mismatch with what engineering is now delivering.”

You were stuck right in the middle of a dilemma. And I'm thinking—correct me if I'm wrong and I'm going to ask about 17 questions all at the same time. I'll try and distill it down as best I can. But essentially you're talking about the world of product if you like, so that's the vendors, the software creation from a vendor perspective space.

So one of the questions is around how does that map into what you're seeing with your customers? But another part of it is: a lot of the conversations around DevOps that I'm having and hearing and so on, certainly the more traditional ones, it's about CICD. So it's right in the middle of the development cycle as opposed to where product management fits, which is overarching. What are we going to do next? et cetera et cetera. So there's all these questions milling around in my head.

Yes. So let me jump into that because the interesting thing is that most, and some other analysts have been writing about this for a few years or just like the rise of product management in I.T., but so if every company is becoming a software company, then IT departments are becoming software development organizations and whether the titles change or not, the mindset is changing and those who are ‘getting it’ are actually realizing that even if you're an insurance provider or a financial services company or supply chain or whatever, the idea that IT is serving the business with projects is giving way to a product mindset. And the difference being that a product is a long running, ever evolving, thing that is being provided to a market segment, and we're seeing that product mindset.

We're seeing IT organizations that are really committed to their Agile and DevOps transformations and the cultural part are hiring or turning people into product managers, and they're creating product teams whether or not the CIO's title changes or IT changes as an department/organization name, but they are changing themselves into being product companies whether or not the consumers of those products appear to be their internal users. But increasingly because of mobile and apps and self-service and products like cars that are more vehicles for software than anything else.

Increasingly their end customers are consuming a software product from them. So this is to me very relevant and it's not just for a narrow set of ISVs like ourselves that are producing enterprise software for a living and some consumer tech companies that have software product managers and software products. Every company that is believing that it is becoming a software company in their industry rather than that industry type company where an IT department is serving them, that's the heart of these transformations.

And companies that are just thinking, to go to the second part of your question, that DevOps is just a technology and process adoption of CICD for the build-test-deploy lifecycle; and even more, early stage, just CI for build, test, get your artifacts, and then there's some separate system to serve Ops PNs [or] whatever, deploying that to a complex development environment. If they see it as just that, they're not going to see the full benefit.

But you know it's a good starting place, and it often leads to these kinds of realizations because once you start doing that, then you start realizing that there's not just other problems but there's other opportunities. And if the team starts getting infected with DevOps culture and Agile culture from the ground up, they start saying “We're no longer IT serving the business, we are empowered cross-functional teams delivering products that are constantly growing and getting better and serving our customers better over time.” And that's really the engine of innovation and value in companies today.

So my experience of enterprise software delivery is a bit stale. It's a couple of decades gone and largely it's through the usual analytical research that I keep up to date, but I'm not doing it anymore. Back in the day when I was within this kind of thing, there were requirements teams, and they tended to have every requirement under the sun.

So what I was doing as the precursor of Agile and XP, a DSM consultant, was going in and saying you only need 60 use cases, you don't need 500 requirements in this massive catalog. But so they were doing the kind of product thing, but they weren't phrasing it in that way. And they were doing it wrong as far as Agile was concerned.

I mean 20+ years ago I was in MSN operations at Microsoft, carved out from Microsoft corporate IT to run our online services. And I produced requirements documents just like that and I managed teams of consultants from Deloitte and Andersen Consulting before it was Accenture. You know there were requirements analysts producing these things and nothing was ever on time. When it was delivered, it was never anything that was actually useful. So yeah I'm reformed from that stage too.

It's okay, I've sat through the counseling now. Hi I'm John Collins, and I've done requirements management... So fast forward to the present day and how does it translate into, I'll call it ‘the modern enterprise,’ which could be an oxymoron for some organizations. But when you are working with organizations today that, as you say, every enterprise should be an ISV, how are they actually managing their product orientation, their requirements, how would they frame this?

They're all in transition. And you know I haven't met a lot of leaders in IT or technology in companies in any industry that are at that level or realization of what they need to do with DevOps or CICD that when I sit down with them that I can't have the conversation we're having now and that they're not already working on the cultural change. Their understanding of how far beyond engineering, beyond you know software delivery functions that extends varies. But this is coming from our customers’ experience of trying to get you out of Agile and DevOps to continuous practices, and expectations in the marketplace of becoming software or technology companies and understanding what that means.

And then what we're also seeing is a lot of cross pollination where traditional companies in traditional industries, their IT teams are starting to staff people that have worked previously in the digital native companies: the Facebooks, the Googles, whatever, and they're coming into more traditional companies. You're seeing that more traditional banks are hiring people out of like a Capital One that understands themselves [more] as a technology company that happens to be in banking and it's really good. And so you're seeing the cross pollination, you're seeing these ideas come in. You're seeing people you know that are in the process of reform from what we just described, embrace these new ways.

There's so much maturity around these new ways, and then you start to see sometimes individual pockets of teams that just sort of revolt or do their own thing and start working this way and start learning from outside and showing their organizations the results of a different way of doing things. So it's changing. I think there's differences in how much visibility is at like a C-level leadership outside of the CIO, of what the implications are for the business as a whole. Sometimes it's a new CEO coming in because a board and the overall company sees they need to make this transformation and they're fired up and driving it. Sometimes it's within the IT organization, CIO organization that these new practices are coming and the CIO is explaining to their peers what the meaning of all this change is and why it benefits the organization.

I'd really like to pick you up in a positive way on the fact that you said the process of reform i.e. it is this kind of an evolutionary adaptation to the new world. And then you also used the term ‘transformation.’ And my disdain of the term ‘digital transformation’ is [from] the fact that it's a bit like “we can get you a six pack in six weeks or beach body” or whatever. It's all about this kind of ‘top down’ notion that all you're going to do is just change and everything will be brilliant. Whereas if we do sit more in the process of reform kind of way that makes a lot more sense to me.

Yeah I mean it has to become grassroots whether or not it starts that way. You have to start having these pockets of people who want to do things in a different way. And start spreading that message. And it needs sponsorship and support from an executive level.

We do these CloudBees Days and we just had one in Madrid and in Zurich and San Francisco and Dallas and various places, and there's a number of them and our customers that present tend to be the leaders of, (I know you hate the term) the "digital transformation" efforts or DevOps transformation efforts in their respective companies. They're usually at a mid level of management where they're close to the people on the ground and they're responsible directly to people in senior levels and they're translating between them, and that's universally what they say on stage. They universally talk about how they have to overcome religious ideas at all levels. They have to overcome a lot of existing processes and so forth. T

The only way it works is when the people who are doing the work start finding their own way, their own flavor of doing this. There's the executive support to understand that the SLA, if you will, from an organization working this way is going to be different—that the needs of that organization and the outputs of that organization are going to be different. There's going to be a transition but they need support in terms of budget to invest in the tools, the training, the infrastructure that is new.

So one thing we have to talk about by the way, is just the cloud part of this, which is sometimes... coming in because people want to get the benefits of running the cloud and not running their own infrastructure anymore, and ‘cloud native’ and so forth, That starts to unravel and the people doing application development start thinking about converting legacy applications, microservices, and when you start to get into that culture, you can't hire a bunch of people to work in that culture who don't carry with them the seed of Agile and DevOps practices. All these things are sort of mutually supporting in terms of how these things are coming.

Actually to me amazingly, my year in CloudBees like a year ago, talking to the same customer as this year, the rate of change in organizations that we would consider to be very traditional enterprises with very traditional IT departments, it's just been dramatic in terms of the rate of change and it's been amazingly organic in the ones that are being very successful and management has let that organic process happen.

And I think you've hit on exactly... I don't have a problem with things changing but I think it was this digital transformation as an epiphany. It's a kind of overnight flick as soon as you brought in the term ‘organic.’ I'm thinking about it's a bit like spring. You know it's that kind of transition from nothing growing to suddenly you start seeing green shoots and everything, and it just kind of starts heading in the right direction because everyone's getting it, and I'm much more comfortable with it...

I actually use a lot of garden and organic metaphors when I talk about this, but you know again a lot of people who have been speaking at our events talk this way, and if you think your digital transformation has an end date or has ended, you're not getting it, which is digital transformation is constant, it's a continuous process. And it's a process of constantly adapting new tools and practices and culture. And evolving the culture to be able to be more effective and it doesn't mean you can’t get a small start wherever you want. Start with one small team. Go ahead and start trying to drive nightly continuous delivery to internal servers across a set of projects and see how... and let the behaviors on the teams change as these practices enable them to change.

I'd love to be a fly on the wall of some of those sessions because these are what make the world go ‘round. Picking up on something you said there, it's the difference between... I hear a lot of organizations need a cultural shift. What you're actually talking about is enabling that cultural shift, so kind of getting out of the way of a cultural shift that would be inevitable if you just stop trying so hard to make it happen.

And again I've learned this the hard way, over and over and over again. So just in terms of some internal projects, we've actually been pretty transparent on the blogs and the blogs on CloudBees. We're going through a digital transformation, we're learning from it but we're never going to end that digital transformation. But when I'm trying to drive change, often I end up having to do a reset and instead do different things to get the little seeds of change to flower and grow with at the doer level in the teams.

That's brilliant. So essentially I think I'm gonna have to start wrapping up,not that I think we couldn’t carry on for a few hours. This is through necessity not through desire, but we started talking about a product mindset, [then] moved on to talking about that kind of leadership approach and then we somehow segued into digital transformation approaches and what's going to make a real difference to the organization from a groundswell perspective.

So if you were talking to an organization now and you want to kick off some of these conversations and you want to enable some of that stuff to happen, what would be the first things that you advise? How would you start that conversation?

Well I think if it's... let's just pretend it's an organization that is in a traditional industry with a long standing IT function serving the business. Start by asking if I can, the CEO or senior leadership, do you think that you are on a path to becoming... to where software creation is central to your business? And do you want to learn how to get on that path?

It's one of those questions because they might say, “sure,” and then you'd go out, wouldn't you?

Well then you start to unpack and then you start to say “OK well you know, what are the practices that the companies in the world that are most successful at delivering software, engage in? What's the culture of those companies?” and then ”Do you have a part of your business that is maybe most greenfield, maybe you're starting up a new digital service to replace a very human driven service? And can you staff that with a mix of people who come out of some of these organizations that are natively digital companies and can you cross pollinate that with the people that you find in your organization who are most excited about trying a new way?”

So can you start and get success with a few fresh pockets and learn how to do it, and figure out what are some of the core tools? Obviously, CICD is amongst them but tools like observability, and what does your tech stack look like and figure that out, figure out what is your day to day Agile process? What does DevOps mean? Are you really getting engineers to own production? And with continuous delivery the output of that?

How does the rest of the organization respond and start learning by doing and again get people in that can help coach you? Start but don't bring in brand new teams from outside because the ultimate goal is that your teams and people transform and learn this new way, so you don't lose what you have.

Excellent. Well, I'm gonna wrap up here. Thank you so much, Christina. [That was] Christina Noren who is CPO at CloudBees and that's been highly informative. I know I would say I've learned a lot. That whole product mindset starting point has really influenced my thinking today. So thank you so much for that and thanks for joining me.

Thank you. It was a lot of fun to talk to you.