Rohit Antao

Well, good evening, everyone, and thanks a lot for your time here today.

My name is Rohit Antao. I'm a partner at PwC, and I'm honored today to be presenting with Adobe here on their journey to DevOps in the enterprise.

With me, I've got Toni Vanwinkle, John Pritchard, and Stuart Wong, and we'll get into the introductions shortly.

Just to give you a quick overview of what we intend on covering over the next 60 minutes: we really want to start off by just level-setting. We had a couple of questions in the last session. In the enterprise, and especially those enterprises that have been around for a while now, for the past 10 years, well-established, with a global footprint, applying and adopting DevOps practices can be a very different beast.

So I want to spend a little bit of time talking about that particular challenge, and especially the new business imperatives that these businesses are facing over the next couple of years.

From there, we want to shift gears and really talk about Adobe's journey and focus on three major areas.

One is the operating model implications. What does it mean to really move to this from an operating model and organizational roles and responsibilities context?

The second is architectural implications, really in terms of an organization that has this complex landscape with legacy systems, with systems of record, systems of engagement, and in Adobe's case, a broad portfolio of SaaS offerings that they offer up to their end customers. What's it look like to adopt DevOps in an environment like that?

And then thirdly, and probably most importantly, is the leadership implications. What does leadership look like in this new world? What are some of those changing behaviors as it relates to the leadership model?

So those are the three primary areas we want to cover.

As I said, when you look at what's happening today, there's a fundamental shift really taking place in the use of technology in the business. More so than ever before, we're finding technology platforms being leveraged increasingly to digitize engagements with customers, with partners, with your employees, and with the ecosystem at large.

But one of the more fundamental shifts that's happening right now is the use of technology to fundamentally transform business models, to fundamentally transform how a lot of companies, irrespective of the industry, are really innovating and rolling out new revenue models.

And as you look at it, here are a few examples of organizations that are really disrupting age-old experiences, be it about ordering a cab or going to a restaurant or looking up services. These new entrants that are showing up in the marketplace are fundamentally disrupting the age-old models that we've had in terms of how we've gone about business.

When you think about this new ecosystem that we're getting into, it becomes fundamentally important that IT leaders are really in lockstep with the business. But when you look at a lot of IT organizations today, especially the ones I just talked about, the large enterprises that have been around for a while, moving forward with a certain mandate and agenda, with a lot of those organizations, you do see a lot of challenges in really adapting to this new world.

When you think about it, a lot of these IT leaders in these organizations have spent the last couple of decades really optimizing for reliability. The amount of due diligence they put in place to be able to build these digital platforms that delivered results efficiently, effectively, and in compliance with the laws, the regulations, the compliance requirements our businesses were being held to: that was the focus.

But when you go back to this new model we're entering, it's really that balance. How do you balance that optimizing for reliability, but also focus on high velocity? How do IT leaders really start to strike that balance of these two new worlds that they are now having to balance all together?

Keeping that in mind, when you look at the delivery pipeline, all along the way you'll see, again, much before dev and certainly after ops, we see speed drags all along the way.

In the past, over the last decade, we've been spending a lot of time really optimizing function by function. You had the planning teams, the PMO teams put in place more robust PMO processes. You had the build teams go and adopt Agile, look at PaaS. The same with infrastructure and ops teams. A lot of the optimization we were doing over the years was really in functions.

As these same organizations now are really being pushed to reduce cycle time, it's no longer cutting it to be able to optimize in functions. You've got to really figure out: how do you start optimizing for flow? How do you look across this value chain and look at how you optimize in order to really drive time to market?

At PwC, when we look at the whole DevOps space and what it means to the community, we really look at it broader than something that just solves for dev and ops. We really look at it as a broader opportunity to take some of the practices, the principles that are emerging from this movement, and really rethink how IT is delivered in the enterprise, all the way from how you innovate, from how you experiment, to the way you fund, the way you plan, and certainly how you develop, deploy, monitor, and improve that throughout.

At least what we've done through working with industry leaders, through working through clients, is really identified what are some of those subset of core capabilities that have a direct correlation not just to speed, but also to high quality. And the key being that it is a lot more than just CI and CD that helps reduce cycle time.

For those of you who've sat through some of the presentations, you'll see some of those themes come up in terms of, be it test data management, be it dealing with the integration issue, dealing with cloud. All these are pieces of the entire puzzle that we're trying to really put together.

Which brings me to my last point here. That model you saw there can be extremely overwhelming to look at in one go. But the other thing we fundamentally believe is this is not a one-size-fits-all. There are different parts of the business that have a very different need for speed. There are different parts of your business that are supporting and driving very different business imperatives.

As you embark on this journey, how do you take a model that makes sense for that portion of your business, as opposed to applying it horizontally against all your practices?

With that said, I'd love to invite Toni Vanwinkle up to the stage to really start talking about how Adobe really navigates this journey in DevOps in the enterprise. Toni?

Toni Vanwinkle

Great. Thank you, Rohit.

Terrific. So I'm excited to be here today. I know that I'm in between this talk and the Exploratorium, which is going to be really cool tonight. So hopefully this discussion will be meaningful and valuable to you.

Munan, are we rolling? Yes. Something here. So let's...

One more time.

Oh, awesome.

[Video plays: "Dream On" by Aerosmith.]

I love Adobe videos. It's like I am so done with my presentation right now. We are so cool.

Let me tell you a little bit about the company. Adobe has actually been around for over 30 years, and so that's pretty remarkable when you start to look at a video like that. So much creativity, so much innovation, so much innovation on the edge of technology.

What we're seeing is a real push around these digital experiences that we're living every day, that we are enabling. Over 12,000 employees, close to $5 billion in revenue, moving towards a target in the next year of being the best in class in what we do, and I think that we're already there.

Adobe is also a good-spirited company. Seventy percent of our work environments are LEED certified, giving back to the community more than 1%, and we have over 3,000 patents that have been put out into the community of innovation.

So it's pretty remarkable to work for an organization like this. And you kind of wonder, well, then, do you really struggle with innovation? Do you struggle with issues of delivery and velocity and quality? And we absolutely do.

Today, I'm really happy to have two of our innovative minds and leaders here to talk about our journey through Agile and DevOps.

You may have been reading the headlines. I joined Adobe in 2009, and Adobe was just embarking on a transition. We were moving from shrink-wrapped products into a whole SaaS subscription model, and this was a new way of thinking.

While we were innovating within that shrink-wrapped market, it was a change to say, "Now let's be always on. Let's be ever in front of our customers. Let's move from transactions to interactions." And that had great implications on the way that we delivered software.

So the expectations of our customers is that their software will be available all the time. You can imagine this transition. Go down to Fry's, buy your Photoshop, install it on your computer. Oh my gosh, it doesn't work. It must be me.

Instead, today, they go to adobe.com, they download their software, and they say, "Oh my gosh, it doesn't work. It must be you." That's a huge move.

So I see that that resonates with you.

We want to be able to make that shift gracefully, make sure that we're meeting customer expectations, and also power innovation. That also reflected in what we needed to do from an IT perspective.

We needed to look at our IT shop and say, "How do we deliver things that are relevant to the business that are also going to power and fuel that innovation that we deliver to the customer?"

Our IT organization actually is in the reach of the product. Anytime you go to adobe.com, you're actually experiencing IT. We can't hide behind the veil of back office. We're actually right in front of that experience and that relationship with the customer.

We also needed to look at how we enable our engineers to innovate on a day-to-day basis. That couldn't be done with heavyweight structures that kept them mired in, "How do I check the box to make sure I'm complete with this, and how am I complying here?" We needed to think that differently and break the mold.

And then the last thing here is around powering this customer experience.

What I want to do is actually bring home this point of not all teams fit into one model. So it's not a one-size-fits-all.

Rohit put up a couple of pictures of cars, and every time I see that presentation, it just brings me back to my midlife crisis. And so there was a conversation that I had with my son about buying a vehicle, okay?

I had this thing in my mind: I wanted a two-seater convertible. Now, how many of you have a dream car? Couple of you, okay. So can you tell me what your dream car is?

Audience

There's like a Mercedes convertible. I don't know what it's called, but it's silver and it looks cool.

Toni Vanwinkle

Okay. And it probably costs a lot of money. Another volunteer?

Audience

I only get to rent it.

Toni Vanwinkle

You in the yellow shirt. Your dream car?

Audience

Porsche 918.

Toni Vanwinkle

Nice. One more dream car.

Audience

Porsche GT3.

Toni Vanwinkle

Very nice. So did you three drive those dream cars here today?

Audience

No.

Toni Vanwinkle

No. Okay, so you probably have something else at home.

Audience

I had to take my dream plane, though.

Toni Vanwinkle

You had to take your dream plane. Okay.

So let me take you to my conversation with my 14-year-old son. I said, "Mommy's going to turn 50. I get my two-seater Mercedes. I'm going to be wonderful in that car. I'm going to have my scarf, my hair's going to be blowing, and it's going to be wonderful."

And he says, "Eh. What about Dad?" So he knew he was in the second seat, like Dad was going to be left behind.

And he said, "Well, what about the dog?" And I'm like, "Oh, gosh."

"And then grocery shopping, Mom. You got to go grocery shopping. Where are you going to put the groceries?"

Suddenly my image, my desire to have this brand-new thing, was out of context for what I needed.

I think that's the thing that we need to think about in business today. My two-seater convertible turned into a BMW SUV, which still ain't bad. It still has the sport setting, so I feel a little bit like I'm driving the sports car, but I have the functional utility that I need for my family.

And this is the first principle that I think that we all need to embrace. What problem are we trying to solve with DevOps? What problem are we trying to solve with Agile? Think about that first.

These are three models that we have in our organization. There are many more. Our product teams are experimenting with DevOps, and they're doing wonderful jobs in sparking innovation, improving quality, reducing their cycle time, and leaning out their process to deliver and design wonderful products like we see in Photoshop.

The first person I'd like to introduce is John Pritchard. John, come on up. Tell us a little bit about yourself. John is the senior director of Adobe I/O.

John Pritchard

Thank you.

So you guys saw the video. Cool. Photoshop, 25 years old. We're in the process now of taking all that magic that has run traditionally on the desktop products and extracting them as discrete microservices that run in the cloud and wrapping an API around that. That's empowered basically our complete mobile offering at Adobe.

So Adobe Color, Adobe Shape, Photoshop Mix, all these mobile apps allow you to do stuff traditionally you could've never done except on a desktop. Those all wrapped as an SDK and a set of APIs, and I run the API platform for the company. So my charter in life is exposing all those things out of the cloud to enable all those mobile experiences.

Toni Vanwinkle

Right. The way that I would describe John's world, it's kind of a unicorn in the enterprise. When we first started this, we said, "John, we need to let you innovate." And we gave John everything he needed to do that innovation and incubate this Creative SDK so that we could grow that bigger.

And now John's run against a problem. He's successful. He is wildly successful. In fact, his product will be the single place that we do integrations across the company. It's actually pretty remarkable.

So now what do we do, John, is the question as we go through the next phases of our conversation.

The second person I'd like to introduce is Stuart Wong. Stuart is the director of our enterprise sales solutions. Stuart, tell us a little bit about yourself.

Stuart Wong

Yeah. So I didn't get all the funding and the leeway that John got.

Toni Vanwinkle

No. No.

Stuart Wong

I actually have to support enterprise sales and legal services. A good chunk of my work and my team's responsibility is to ensure that those business functions continue to operate.

But recently, with the business transformation, we've had to become much more agile. We've had to react to go-to-market changes that are coming at us quicker and faster than ever.

That's part of the journey that we've gone through: how do we embrace the principles of DevOps in this type of traditional enterprise world, enterprise applications that value stability and a constancy around that process?

So we get to sell what he puts together, together with the product engineers, but we have to do it in a way that supports our legal teams and our enterprise sales teams, and they don't like change. So it's kind of an interesting balance between those two.

Toni Vanwinkle

Yep. Stuart is the anti-unicorn. He's the typical enterprise application, that stuff that needs to be really stable. You just don't want to mess up your sales process. You don't want to mess up your legal environment, and he needed to break the mold of that.

And by the size of his team, I think he needed more than two pizzas.

Stuart Wong

Yeah.

Toni Vanwinkle

In fact, he has a global team, so he needed to share that pizza around the world.

So let's talk a little bit about how Stuart overcame the barriers and the things that he needed to do to be successful with his team. You want to come on up, Rohit, and join the conversation?

Rohit Antao

And Toni, before...

Toni Vanwinkle

Yeah?

Rohit Antao

...it'd be great to also provide a little bit of an introduction to the function that you run and how it supports and enables a lot of the other teams out here.

Toni Vanwinkle

Absolutely. I'm the senior director of service management for our cloud technology organization. Really, at the end of the day, my job is to make services successful at Adobe.

I run all the traditional, what you would call ITIL processes: change, release, incident, problem, event. I don't tell people that, but I help to enable that in our company so that we're providing the right feedback loops so that our services are at the best level that they can be.

Rohit Antao

Great. Thanks a lot for that, Toni.

So Stuart, I'd love to start with you. We've all heard that phrase around, "Structure shapes culture, and culture eats strategy for breakfast." Keeping that in mind, as you've gone down this path of embracing DevOps practices and principles, I'd love to get a better sense of the shift your organization's gone through, be it in terms of the roles, responsibilities, the culture of your organization.

I realize that there are also outsourcing providers that enable you. Would love to get your comments on what that shift's been like for you.

Stuart Wong

Sure. Perhaps a little more context around my organization. We're about 50 headcounts across the different geos here, and I'm sure many of you guys in enterprises as well also may have workforce parameters that you have to work within.

So you can see, my teams are approximately 50/50 split between North America and the rest of world, and that ratio is probably going to stay the same for a variety of reasons that you guys probably are familiar with.

That being said, if you look at the journey that we've gone through, or that my teams have gone through over the last three, four years, it's really around moving from a waterfall-type mentality. I think I heard a question in the last session: really, how do you make that change? So how do you go from a waterfall mentality into more of this Agile scrum, and then where we are right now, DevOps?

We've had to undergo that transformation, and really it's not just my teams. One part of the interesting journey is that our business partners were just as eager to move into this direction, but they didn't really understand what the implications were.

What ended up happening is that we actually did the business transformation projects, jumped in headfirst into the whole Agile scrum model, and we ended up trying to go after two-week sprints.

Part of the transformation was working with the business, working through those steps, and understanding what the challenges were. We finally ended up with the business basically turning back and saying that the two-week sprints are too much. So we settled on more of a cadence around one month.

Really, the takeaway from that is that partnering, this is not an IT journey by itself. Part of the team structure is actually embracing that partnership with the business and understanding that it takes everyone in that team in order to be successful.

There are business change management implications, there are workforce implications, and all of this has to be worked through at the team level.

So I think part of the structure and the culture that's changed or evolved for us is that it is really not a top-down mandate. A lot of the success that we've had has come from the grassroots, so figuring out how to enable and empower the teams to figure out how to work in this type of Agile environment. That's kind of the takeaway from that.

Rohit Antao

John, on that same note, I know your team is more of a startup, a unicorn within the broader Adobe. Whilst I know there are certain directional changes you've made in terms of the roles and responsibilities, I'd love to get your take on how does your team interact with the broader Adobe? What kind of interaction models and mechanisms have you put in place, and what are those dependencies you have with the broader enterprise?

John Pritchard

Yeah. I'm in a sort of quasi-cloud infrastructure role, really close to the product development teams. Again, they're developing feature and function that we're hosting in the cloud, and my team's charter is how do we expose those as SDKs or APIs.

It's a regionally and globally distributed organization, so I think that's probably the key takeaway and love to share some insights on that. Running an eight-person co-located DevOps team is easy compared to running anything globally distributed DevOps team.

I think communication and trust become really hard to achieve when you have teams that are distributed. So on the communication side, I think things like feedback loops and ceremonies become very important.

We run scrum as well. We are on a two-week cycle, continuous integration, but a delivery about every 14 days. I think we put a lot of emphasis into retrospectives. That's important for things like, what went wrong? We made an estimate around velocity that we didn't achieve. What was sort of the barrier to that?

I think having a really planful and mindful retrospective behavior offers a lot to a team, especially when you get into the ops side of DevOps. Because once you get your product launched, things start going wrong. You have field requests or you have incidents, and retrospectives are really a good opportunity to ask the question about why, and then what monitoring could have been in place that may have caught that.

So those two things I think have been really key.

We use a lot of communication-like tools. Slack's really popular in Adobe. I don't know if you guys are users of that, but we have a really creative thing we do with activity streams. All the monitoring tools we use, we have those all piped into Slack, into a single activity stream, and I sort of refer to those as tacit feedback loops.

So Jira incidents and Jira issues and Zabbix and New Relic's reports, all that stuff is sort of feeding into this activity stream that's running for your project. Even though no one's really talking at a formal meeting, there's all this emitting of knowledge going on. And so you can often get a cadence or a pulse of where things are.

I've found that super helpful in having my product engineers also in those activity streams, and we often end up discussing things sort of in real time.

Rohit Antao

Got it. You brought up a great point about things do go wrong. They often fail. For those of you who attended Dr. Spear's presentation yesterday, one of the comments he made was how high-performing organizations really pause and learn from these failures.

You also brought up postmortems, and there's been a lot of talk in this community about blameless postmortems. That takes a lot of effort. I'd love to understand, as you've gone down this path of doing postmortems, really learning from failures, how have you made it safe for people to really share their lessons learned? What have been some of the struggles along that path? And it's an open question.

Toni Vanwinkle

I think that one of the things that we do is, first of all, we provide consulting help to teams like Stuart's and other teams across the company around how to perform a blameless kind of postmortem, where we're really tackling the problem, not the people.

One of our jobs as leaders in the organization is really to protect them and fly some air cover for some of the energy that does come from top leadership, and give that feedback to top leadership and say, "Hey, we need to kind of change the culture of the organization and the messages that we're sending."

I think it's really about this mindset of having the teams tackle the problem, not the people.

Rohit Antao

Got it.

Toni Vanwinkle

And that moves you forward in a better way.

Stuart Wong

Just to add on that one, again, John's from the unicorn team. He got to build his team from scratch, so he can actually hire that mindset.

I'm coming from an organization, I've been at Adobe about 12 years now. When we're coming from a waterfall mentality and engineer or functional and technical folks that were hired into specific roles like an SAP engineer or an SAP consultant, functional consultant, or Salesforce or what have you, changing the mindset and moving in this direction is actually quite a big change for many people.

So that was one of the biggest challenges, and we continue to go through that evolution right now. But I think what's interesting about that is that even getting folks to understand and appreciate the retrospective and the value that it brings, part of what I'm trying to instill in the teams is the idea that you design, you develop, you deploy, you operate, and you support.

So trying to get that feeling of ownership of the actual deliverable or the platform is actually a change in the skill sets and the mindset and the approach to work. That's an ongoing evolution. Some folks take to that more easily, and others require a little more nudging and mentoring around that.

John Pritchard

I was going to offer my own experience is you guys will go through a blamestorming phase. The only way to get to a blameless model is to go through it. That's been my experience, even with my unicorn team that I handpicked.

Until that trust gets established between the teams, your first couple, I think, retrospectives, everyone defaults to what went wrong and who caused that. Until that trust gets built in the team, you don't get into that blameless mode.

As much as we can sort of talk about how to get there, that's been my experience: it's a painful process you've got to move through.

Rohit Antao

John, that brings up another good question. Whilst you are a unicorn, you operate in a startup mode, you're still within the construct of a large enterprise that's been around for several years, global, have to comply with all these laws and regulations. How do you balance that act between being nimble like a startup and fulfilling the responsibilities that you have as part of a large enterprise?

John Pritchard

My experience is that most DevOps initiatives start as a rebellion inside companies. You're rebelling against either process or a lack of velocity. It is an interesting thing that all rebellions, those rebels end up forming governments after the rebellion is done.

Toni Vanwinkle

Yes.

John Pritchard

Right? So process is usually the enemy.

Toni Vanwinkle

I love that.

John Pritchard

What I've done as a model in our organization is to really get around fit for purpose. We'd have a discussion that says, "What are we trying to accomplish? And what is the people, process, technology necessary to make that happen? What is the fit for purpose to achieve that end goal?"

You appreciate that some of the governance techniques or technology standards or the way that you've done things are maybe appropriate and fit for purpose for those systems that they were authored for, but maybe not what you're trying to accomplish now.

As long as you keep your leadership mindset focused there, you can sort of keep re-vectoring them back to the, "What's the end goal we're trying to accomplish, and what's the fit-for-purpose way to get to that point?"

Rohit Antao

Got it.

Toni, on the line of process, many organizations, and I'm sure Adobe's been one of them, have made large investments in process improvement in the IT space, specifically around service management and ITIL.

As you now look at this next era of where you're evolving to, given where Adobe is going, and you look at all those investments and work that's been done in ITIL, what do you see as some of the synergies and conflicts between these two approaches?

Toni Vanwinkle

Yeah. I thought about this a lot. Do we all go back and get rid of our ITIL certifications and throw away those V3 books, and none of that matters anymore?

The reality is, I think it's a jumping-off point to set up teams for success. I think that the principles that are out there in ITIL or in service management at large can really be leveraged to really power this revolution.

The funny story about what John is saying is you go into battle and then after you form government. Well, when John knocked on our door and said, "Hey, service management team, maybe we need a little bit of help. We've gotten really big and popular, and maybe we need to operationalize this at an enterprise level." And it was really a dance, I think, when the team was first established and where the team is now, between what we do in the services organization and processes to make sure that John was successful in each phase of his evolution.

I think it's our job as practitioners to understand that you can't just put the government down just for the sake of government. You need to have it really facilitate the business and the need for the business.

The reality is we are in front of our customers. We hold your data, and we are a great place to have security vulnerabilities and all of these things. We need to have compliance. We need to play right so that you're safe as customers.

Those types of things serve the business. They serve you. And those are the types of things that are important to the business. But process for the sake of process is just not.

So, short answer: lean it out. Make it fit the business model, and I think it's a great leverage point for continuing the DevOps journey.

Rohit Antao

That's great.

To shift gears a bit here, and move from the operating model implications to more of the architectural implications, Stuart, maybe if I can start with you. When you look at your landscape, you are dealing with a pretty hybrid landscape between SaaS, on-premise, legacy, some of the new apps. When you look at the whole automation space, would love to get your perspective on some of the strategies, tactics, and obstacles you faced along the way as you really tried to apply automation to reduce cycle time there.

Stuart Wong

Yeah. Attending the DevOps conference last year, going through the literature, as I'm sure many of you guys have done as well, trying to figure out how DevOps plays in an enterprise application space is something that's always escaped me.

Over the last couple of years, I think what's become apparent is that there are differences between enterprise applications DevOps, so to speak, and coming from a product space, which is more aligned to where John is coming from.

Really, with SaaS-based applications, the portfolio of SaaS or cloud-based and on-premise applications that we have, the focus for my teams is around the integration. We focus on end-to-end business processes, whether it be enterprise selling process or the revenue-generating contract process.

The importance for us is figuring out how to deliver value across that end-to-end business process, and we really focus on the integrations.

Where we apply those DevOps principles from an architecture perspective is trying to figure out what can we measure within the application itself, because they always come with a certain degree of visibility in terms of monitoring, alert mechanisms, et cetera.

But where we really have fallen over our own feet is around the integrations. Integrating Salesforce upstream with lead management systems, midstream with master data systems, or even downstream with order processing or legal contract systems. Any point of failure in that process is a potential impact to revenue.

So from our perspective, trying to understand how that cloud-based architecture, on-premise architecture, as well as integration technology, that stack, how does that all come together? And how do you integrate that and implement it in a way that we can scale across those platforms?

Because the Salesforce platform not only supports sales, we're branching out into the service area, renewals, onboarding, that whole area. So the idea around that is how do we get better at monitoring those integrations and then figuring out those feedback loops in order to recover and automate where possible. That's kind of the areas that we focus on.

Rohit Antao

Great. Along the same lines, John, in your world, what are some of those key architectural principles that you've based your platform on as you've driven it forward?

John Pritchard

Resonating a bit with Stuart, I think culture of automation is probably really key. To get to the Ops side of DevOps, you're really trying to drive velocity, and to drive the right amount of velocity, you're trying to implement as much change as you can with the least amount of failures, which means you need insight into your system at different levels.

We often refer to that as monitoring in depth. You've got monitoring at various levels outside your system, so it'd be CloudWatch, New Relic, AppDynamics, some of the different monitoring tools, and how are you fusing those together? So culture of automation, I think, would definitely be one.

We tend to have a very open source bias on my particular team because we're cloud native. Our own experience has been a lot of things you're trying to accomplish in the cloud are sometimes best done with some of the open source frameworks that exist out there.

And then other very technical architectural principles around a focus on asynchronous messaging, isolation, and then the key thing I think is around architecting for failure.

I often challenge my team to not think about high availability as much as recovery, recoverability. So when something fails, how does it come back on its own?

Stuart Wong

Those principles actually extend very well into the enterprise space as well. Historically, we've built such tight integrations between our enterprise applications that SAP goes down for maintenance, we basically lock all our users out of Salesforce, and that's for, it could be, a whole weekend, which is kind of crazy.

Some of the principles that we've learned out of this DevOps journey is how do we loosely couple so that if SAP goes down for maintenance, that folks can still log into Salesforce, continue what they're doing. They may be inhibited in certain areas, but at least they can continue to do the majority of their work.

So that idea of loose coupling has been a hard lesson learned and has created a bunch of technical debt for us to go after. But at least we acknowledge that, and we're going to try and improve that incrementally.

Rohit Antao

Toni, while we're on the architecture topic, there's been more pressure on a lot of the application teams in terms of reduced cycle time, time to market. How do you balance it out in your world in terms of maintaining some of the requirements around quality, security, compliance? How do you balance out those two and sometimes competing needs?

Toni Vanwinkle

Sure. I think it kind of came out in some of the words that Stuart spoke about, which is the teams really have to own the end-to-end product, and that means not just building the product, but actually operating the product.

I'm a big supporter of fixing quality at the source. So how could we left-shift the quality? Starts with the mindset, and then I think you go next to actual automation.

But the reality is that we've kind of had this philosophy of separating functional and non-functional requirements. I think that security and quality need to move to a functional requirement. They need to be an embedded part of the way that we design the product.

This gets back to fault tolerance. This gets back to designing for resiliency and things like that. So I think that's where we balance it. We can certainly give frameworks for that, but the teams need to build it in.

Gene has a comment.

Q&A

Q: Toni?

A: Hi, Gene.

Q: Can you describe in more detail how you created a looser coupling between SAP and Salesforce?

Stuart Wong

Yeah, that's a great question.

Right now we're experimenting. Previously, in my world, I just worked within Salesforce and the immediate boundary systems. What we've realized is that we have to partner more closely with that SAP platform team. They're innovating in their own ways.

So they've created now, when production goes down, there's a read-only SAP system that's stood up. It was basically a replica of production.

Even then, we have tight integrations. We're trying to figure out if we're doing messaging to or from SAP, how do we build in the queuing mechanisms to make that transparent to the Salesforce user?

Those are some of the concepts that we're playing with right now, and we're going to continue to push in that direction to try and isolate that user experience from a sales perspective with anything that happens on the back end.

John Pritchard

I'd add, I think there's a nice convergence of trends happening now with microservices, asynchronous messaging, and recoverability, so that you get the concept of isolation between microservices and how do teams organize around that, and then how to use asynchronous messaging to allow that queuing mechanism, so that you can't have a system go offline without breaking the whole system.

Rohit Antao

Okay. Just to shift gears now, more towards the leadership side, one of the areas I'd love to get a perspective from all of you is: how do you measure success?

That's one question, and the second one is: what kind of investments are you making in the DevOps space as you move forward?

Stuart, maybe if we could start with you.

Stuart Wong

Sure. From an investment perspective, let's start with that one. And it also feeds into the leadership part here.

Somebody needs to stick their neck out on this, on the DevOps initiative. So the sooner you identify that champion, I think the better. Part of that is also an investment. You're rolling the dice on your credibility as well as that of your team, your extended team, and the initiative and the value that it could potentially bring.

We bit the bullet early, partnering with the Agile training teams. We identified a challenge within the teams onshore as well as off, that one of our transitions was to tell people that you are the CEO of your own service and to behave that way.

But in my one-on-ones and further probing, I asked how many of my team have actually been a CEO and actually knew what that meant. So there was a little challenge in terms of translating what that actually meant into an individual contributor or even a line manager's job.

So what I landed on as a metaphor is, most people own an apartment or a house. Money comes in, expenses go out, you have repairs, maintenance, support, and you have home improvement kind of things. I think that analogy resonated better with my teams.

But the idea there is that we invested in training people, getting them speaking the same language, and one of the other pieces that we identified is we said, "Everybody needs to figure out how to solve a problem, root cause it."

When you talk to engineers, they have a certain methodology. You talk to the functional guys, they have a different methodology. So we actually invested in training all the onshore as well as the offshore teams in A3 thinking.

That was a bit of a gamble there to see if that would resonate with folks. Everybody believes they have their own way of solving problems, but it actually resonated quite well from the ground up.

So we invested a lot of time and effort, not only in training the individual contributors, but as well as the line managers and the level above, so that they could continue to mentor and promote that A3 problem-solving process. Those are some of the investments that we made in my organization.

Rohit Antao

Great. John?

John Pritchard

Yeah, I think on my side, external to your team, I think your leadership looks at your velocity and how reliable your team is. One of the great benefits of DevOps is you tend to get faster and more reliable.

I would say personally, what I look at is our rate of change and our rate of failures of those change. At some point, you're going to reach a sweet spot where you're changing fast enough, where those are relatively low failure rates.

However, the most important metric that I actually look at, and I actually think one of the most valuable outcomes of DevOps, is turnover rate. I have extremely low turnover rate because people don't want to leave the team.

They're starting to enjoy, it's a great time to be in software again. I think when you have this ownership model where you've built something and you're running it, you start to get connected to it. People just don't depart from that.

That's a huge benefit in terms of churn on the team, having to relearn processes and procedures, relearn techniques, is having a core team that actually is very stable.

Rohit Antao

Got it.

Toni, on that point, from an organizational change management, I know you've been doing a lot in that space. Would be good to share some of the investments you've made, how you're looking to continue that journey.

Toni Vanwinkle

Sure. The first area is really sponsorship. Many people talk about the grassroots nature of DevOps, but DevOps in the enterprise requires two pieces. It needs the grassroots piece, and it also needs some strong sponsorship.

The second piece you've probably heard is, organizations don't change, people do. The way that I would state that is, organizations change through people.

What we've tried to work on is investments in becoming certified in things like A3 training, so that we can go out to teams like Stuart's team or out to the business and product teams, and start to teach methods for people to define the problems that they're trying to solve.

The reality and what studies show is that people don't respond to, "Let's give you a couple of bucks, and suddenly you'll take the hill for the team." What people respond to is how they hear the message, how they see the message, and the credibility of feeling the change in the organization.

I think the credible messages come through the sponsorship. The feeling it and hearing it come through the cohesion of the teams. So we need to do things to facilitate that.

Part of what we do is facilitate communities of practice. For example, we've kept the Agile community alive, and that is an organic community where anybody can contribute to the intelligence of the team and what they're experiencing.

We have Agile Talks, a lunch and learn. We bring speakers from around the world to talk about their learnings and try to inculcate that thinking into the organization. So lots of investment in the space of organizational change.

But we also have investments in kind of feeling the change in what you do. We've asked teams to really take on a couple of really fundamental things.

First of all, have a pitch for the services that you provide for the organization, have a roadmap so that you know where you're going, and have a dashboard that measures the success and shows that you're approaching the goal that you're trying to lean towards.

I think these tools help us kind of start that journey of marching through the process and really feeling the change.

Rohit Antao

We've talked a lot about the change our teams have to go through. One of the significant aspects of this movement is also going through the change leaders have to go through.

Each of you are leaders of very large parts of Adobe organizations. I'd love to get your perspectives, each of you, in terms of what, as a leader in your organization, what do you see as that shifting leadership style, mandate, and approach to leadership?

Toni, maybe we start with you, and we can work our way up to Stuart.

Toni Vanwinkle

Sure. One of the shifts, there's a great book out there called Leadership Agility, and it talks about five modes of leadership. One is this expert mode, and you retain these as you grow as leaders. There's the expert, there's the achiever, and there's the catalyst.

I believe that we need to move from expert to catalyst in order to drive change in our organization. We need to retain that sense of, "I need to achieve my goal." We need to retain our expert knowledge, but we really need to grasp this leadership skill or capability of being a catalyst for change.

Rohit Antao

Right. Got it.

John Pritchard

I think my observation would be that a key to success for any DevOps initiative is allowing the team to self-organize. That can be a sort of frightening space as a leader to be in as you're sort of allowing your team to make decisions on their own methods, their own technology, their own processes that you may not have experience with.

So your job becomes sourcing good talent, establishing trust between the players on that team, but allowing them to self-organize.

As easy as that may sound, that is actually very difficult for successful leaders of the past. If your success is based on your own expertise or intelligence or technical depth, forming a team and allowing them to do their own thing that they're really good at can put you in a little bit of exposure position.

Rohit Antao

Right. Going back to that first comment, the old way of thinking about it is structure shapes culture, and so a leader feels the need to be able to shape that structure.

John Pritchard

To lead. Yeah.

Rohit Antao

To lead. Exactly. Stuart?

Stuart Wong

Yeah, and to build off of that type of an approach as well, kind of the evolution of the leader around this DevOps practice, I think traditionally in the enterprise space, you try and squeeze every single ounce out of that development or the team that you have. There's very little time to work on technical debt, so what we're calling technical debt in the DevOps world.

So figuring out how to create that time, 10 to 20%. Everybody throws out 10 to 20% as a number. Apply that to a 40- to 60-hour work week, you're looking at four to eight hours. That's a significant chunk of time to carve out for everyone in your team to figure out how to embrace this DevOps, how to chip away at technical debt.

I think that's part of the leader's responsibility, figuring out how to create a compelling story for their business partners, as well as any of the other key stakeholders that influence how that team is deployed.

So convincing, figuring out how to convey the value of that, and then executing with the team, encouraging your team to take advantage of those four to eight hours and turn that into something where you can actually come back to the business and say, "Look what we did in terms of we reduced technical debt. Because we did that, our next three or four sprints, our velocity is going to increase," or, "We're able to do this," or, "Able to innovate in this area."

I think that's been a challenge. It continues to be a challenge with many teams, but I think that's something that does fall squarely on the shoulders of one of the managers or leaders.

Rohit Antao

Great. Appreciate that.

The final question I have, really two parts to it, if each of you could share two things. One is, as you look at DevOps in the enterprise, in your mind, what is that critical success factor?

And number two is, to Gene's ask at the start of this conference, a challenge you're still working through and you'd love the community here to help weigh in if they have perspective there.

So maybe we just go around the table. Toni?

Toni Vanwinkle

I think the critical success factor in my mind is really be clear about the problem you're trying to solve. Is it quality? Is it velocity? Is it technical debt? Be very, very crisp and clear about the problem you're trying to solve.

I think the thing that at least my team continues to struggle with is the language. When I say DevOps and somebody else in the organization says DevOps, we actually don't mean the same thing.

I could say that to John, I'll just use John as an example, and he'll go through a toolchains conversation. I say that to a member of my team, and we go through a culture change conversation.

The reality is it's all of that bundled together. So somehow we still need to work on this speaking the same language across the enterprise so that when we say we're going on X journey, we know what that means together.

Rohit Antao

Great.

John Pritchard

I'll start with, I think my challenge I'm still living through, I keep joking that I need to start an article called "Unicorns Don't Run in Herds." Because the experience of going from an eight-person DevOps team to a 16-person globally distributed team to a four-scrum team, I've found that some of the behaviors start to break down.

There's some institutional learning that I think we still, as an industry, are going to figure out about running DevOps at scale, distributed. I'm still challenged by that. Having a team in Romania, in the US, and in India, and how do we keep those guys connected so there's some handoff, but there isn't sort of a formation of a dev group and an ops group in different geographies, which is sort of the easy tendency to try to drop into.

That's still a bit of a challenge, keeping the guys connected.

The secret, I would say, is it's a lot of people problems, more so than technology. So if you're starting a DevOps initiative with a tool, I think you're set up for failure. If you're starting a DevOps initiative with a cultural mindset of, "You build it, you own it," I think you're set up for success.

Rohit Antao

Great. Appreciate that.

Stuart Wong

Yeah. Actually, I'd like to second most of his comments there.

In terms of the challenges, global distribution of the teams. I'm in a bit of a more challenging situation. His are actually co-located within region. Mine are actually spread. One scrum team will be spread across multiple regions.

So I'm trying to figure out how to manage that, and I don't have an easy answer. If any of you guys do have an answer, please let me know. But I think that continues to be one of the challenges, particularly for enterprise or large organizations that have requirements to build out capabilities in different geos.

So handling those time zones is... We actually have a DevOps track specifically focused on work-life balance. How do we improve that given the parameters that we've been dealt? That's going to be an interesting evolution to see how that DevOps track moves forward.

In terms of critical success factors, based on at least the last three, four years that we've been doing this, start small. Don't start with a major business transformation project like we did. Start small, and it's really all about the people. It's not the technology.

Q&A

Q: Is DevOps better for work-life balance or worse?

Stuart Wong

It can be better, and it is...

John Pritchard

It can be worse.

Stuart Wong

Yeah. That's the trick, though, I think. Well, not the trick, but I think that's part of the challenge, figuring out how to use DevOps to create that better work-life balance.

I think it is possible. We're showing it in different pockets. But it also comes down to a mindset shift, and people need to figure out how to step back and trust either the handoff to another geo.

And to John's point, if you're creating dev here and ops there, then you kind of defeat the whole purpose of that DevOps. So how do you create that consistency in the DevOps mindset across geos is really what's key for us.

Audience

Can I do DevOps my life? So it's figuring out smaller chunks of things I can do for my life and deliver it.

Toni Vanwinkle

Absolutely. I think it's a critical success factor because the reality is our teams want to do great work. And if you check in with them on how they're feeling about that meter of contribution, I think that's a good measure. The humans is a good measure.

Rohit Antao

So, with that, any more questions? Just wanted to open it up before we wrap up.

Looks like we're pretty good. So thank you all for your time today. I know we're running up to the next presentation here, so appreciate it.

I think if we just move to the last slide, I've got everyone's contact information here. So again, feel free to reach out if you have any additional questions.

Speaker

Thanks for having us, guys.

Speakers

Thank you.

Thanks.

Thanks.

Thanks, guys.