Host Intro (Gene Kim)

Next up is Ross Clanton. So Ross Clanton is a very special person to me. I met him years before the first DevOps Enterprise Conference that we had in 2014.

At that time, he was a director of engineering at Target, which is the second-largest retailer in the US.

They went from an organization that had 11,000 IT people, of which 80% were outsourced, to one that is almost all in-house today, that is leaner, faster, smaller, and without doubt, a world-class technology organization.

Last year here at the DevOps Enterprise UK conference, one of the most popular topics was the DevOps Dojo. That was actually invented by Ross Clanton during his Target days, and has probably become one of the most widely used starting points for creating DevOps within large, complex organizations. He went on to become a technical fellow and executive director at Verizon,

and he has served there for three years, driving the technology modernization program there. And so today, he will be sharing real stories of failures and lessons learned in large, complex organizations. Ross.

Ross Clanton

Okay. Hello, London. I am super excited to be here. I've been speaking in the US for four or five years now, and this is my first time in London.

Very excited about it. I'm doing a little bit of a different format than I usually do this year.

I'm kind of telling stories, kind of like failure stories, a little bit DevOps confessional-like.

And it doesn't lend itself very well to PowerPoint when you're telling stories.

So I'm going to try something that could be amazing and it could be just a spectacular failure as well.

Either way, we're going to learn from it.

But we're going to have kind of a live sketch going through.

So let's go ahead and get started.

So I am a transformation executive.

I've been doing this for a while now at a bunch of different companies.

I'm actually kicking off a four-month sabbatical with my family this week.

Super excited way to kick it off in London.

So I'll be taking the next four months relaxing, contemplating life, what I want to do, reflecting. Over the years, I've had a lot of enterprise transformation roles.

It's definitely broadened my perspective around what works and what doesn't, when you're trying to drive change in organizations.

The last six years, I've led two large technology transformations at two Fortune 50 companies, at Target and at Verizon.

I've also been a pretty active member in the enterprise DevOps community.

I collaborate with a lot of the different executives that are doing change in their different companies, a lot of people that are part of this community.

I've done podcasts, white papers, just a lot of things I can do to give back to this community. It's really important to me.

Through this journey, I've gained a lot of experience on the key constraints that impact the effectiveness of transformation enterprises.

So let's actually start diving into some of these lessons learned.

So driving DevOps transformation in large enterprises is extremely hard. To achieve true success, not only do you have to transform your technology practices, you often have to change your culture.

That includes dealing with politics and complex leadership dynamics in companies.

You often change your model and the structure for how work gets done, not just in IT, but also in how IT interacts with the business.

You have to reskill a lot of people with new skills in your workforce. So when you think about this, that's a lot of barriers to deal with.

Why don't we hear more stories about these challenges?

I'm going to ask for a show of hands.

So you're all enterprise folks for the most part.

How many of you, when you do a talk at a conference like this, need to get approval from an internal public relations or communications group?

Can you put your hands up?

All right, so keep your hands up if when you go to them and share an idea for a talk that you want to go talk about massive failures, they're excited about that.

Exactly. That's why you don't hear a lot of these stories.

It's really hard to come and share this stuff.

So I'm going to share some.

This talk is going to get into real-life examples from challenges that I've faced and my colleagues have faced in driving change in complex enterprises. They are going to be based on first-hand experiences and through my direct collaboration with others in this community.

I want to stress none of these stories are attributed to a specific company. Don't try to figure out who I'm talking about.

We're going to keep it a little bit obfuscated, but they are real examples, and the names of the individuals I've changed to protect the innocent.

But I will share a new narrative to these stories at the end because there's going to be some sadness in these.

But before I dive into the stories, I want to talk about the types of failure that I'm going to discuss.

There are many types of constraints that actually impact transformation success, but one theme that I think deserves particular focus and attention is failures in leadership.

And this is things like sponsorship, executive support, leadership behaviors. It's a huge problem, and it's actually something that has come up a lot in my research, and it comes up in almost all of my direct experiences and my colleagues' direct experiences that I'm going to talk to.

So there's going to be a lot of examples of leadership constraints in this talk.

Let's see if you can pick them out.

Now let's dive into the three stories that will underscore many of these constraints. It's time to meet Jackson, Isabella, and Jayden, three fictional transformation change agents all working in different companies. They also happen to be my three kids, which is going to kind of help me keep everything in sync on these

stories. So Jackson is a transformational executive that's recently been promoted to the vice president of the digital portfolio in his company. He's a strong believer and champion of lean and DevOps ways of working.

He's built a strong leadership team made up of some of the best DevOps minds in his company, and best leaders in the company.

This company was also on the heels of a failed SAFe Agile transformation, and his team felt there must be a better way.

So over the next two years, Jackson, his team, and some close partners across the business and technology groups worked together to grow a better way of working.

Jackson started by orienting his portfolio around DevOps ways of working, but he also focused on championing this across his executive peer group in the organization.

He built a continuous improvement practice and actually used that to help teams even in other organizations adopt these practices.

They initiated a talent development program modeled after one of the leaders on Jackson's team to drive improved talent across the organization, and even had another leader on his team that spent time helping middle management learn lean mindsets and ways of working.

Beyond that, Jackson drove alignment with the executives on the one metric that mattered to that technology organization at that time, which was cycle time.

Things were on a really good track.

There's clear executive focus and clear measures.

Teams were starting to see better results.

They were visualizing their value streams, and they were systematically removing the biggest constraints for each team, continuously improving cycle time for each team over time.

They even started to operate as more full stack end-to-end teams, similar to what you would see in a product model.

There's always a but.

But one day, things changed. This company always had a fairly operationally minded CIO.

They continued to face significant digital disruption in their industry. And recognizing his own gaps, the CIO decided to hire a CTO from outside the organization to up their digital game.

This CTO was a self-proclaimed DevOps expert, ushered in to kick the company into a higher gear.

Very quickly, they started undoing the changes of the previous two years, moving the organization back to a functionally siloed model, all in the name of increased efficiency.

Within a few short months, two years of progress was nearly wiped out.

Jackson and change agents across the company revolted and challenged this new direction. Unfortunately, though, realizing that they were in a difficult spot, they all eventually decided to leave the organization over the following months, and they've all moved on to be awesome DevOps leaders in other companies.

All right. That's kind of a sad story, I think, but a good outcome for some of the individuals.

Let's talk about another story.

This is Isabella. So this company was looking to modernize their technology practices, build an engineering culture, and improve time to value of their technology delivery.

Isabella was leading this initiative, reporting to the CTO.

Her and a close band of leaders were working hard to drive change across this very large, complex company.

The CIO at this company was excited about these changes and even set a vision for IT to be an investment center and a destination for top talent. It was a bold aspiration, and it actually served as inspiration for the technology transformation.

While the messaging was set at the top, a few key issues quickly became apparent.

First, the business was still largely viewing IT as a cost center. They had a history of piling up a lot of demand for IT in the form of predefined requirements and expecting IT to just line up and deliver.

Additionally, there was a lot of business executives across the organization.

They all had their own agendas.

In the name of customer service, IT would constantly shift and reprioritize their work, managing their day-to-day work by escalation.

This company had also been attempting an agile transformation for many years without success due to many of these same issues.

Beyond that, the behaviors of middle management didn't change.

Those leaders still tended to operate command and control with a focus on execution at all costs and continued to tell all their teams what they could and couldn't do, putting constant pressure to over-commit on delivery.

As a result, these teams didn't have space to learn.

They weren't empowered to innovate and improve.

And additionally, the quality and delivery was not improving in this organization.

The business was getting very frustrated with IT's capabilities, and they thought IT was a black box with no transparency.

So recognizing this problem, Isabella had been experimenting with some teams and having success, so she suggested moving to a product model, effectively bringing the business and IT closer together.

The CIO liked this idea and attempted to pitch it to the other business executives, but at that point, IT lacked credibility with the business, and there wasn't strong business sponsorship to pursue.

So sad story to start.

Around this time, a new chief executive took the helm of this company.

They immediately asserted that IT was too expensive.

This resulted in increased focus on IT being a cost center.

While the CIO never changed their vision of being an investment center and destination for talent, they started embarking on an outsourcing strategy for IT. This created an even bigger problem because now leadership actions were not matching words. Teams lost trust in management. The organization remained relatively fixed in a legacy model with subpar performance.

There will be a new narrative at the end, don't worry.

I'm going to tie it all together. These are all very sad.

Third story. Jayden had worked in this company for quite some time and witnessed the systemic dysfunction build in the technology organization over many years.

Years before, this company had transformed to a COBIT-based model around plan, build, and run. They'd built a whole bunch of centers of excellence, and they outsourced many of their engineering activities.

Over time, the performance and the cost of the company actually got worse.

This, coupled with increased disruption in their industry, created a ripe environment for change.

So Jayden led the charge to start championing DevOps as a new and better way. At that time, the biggest constraint in the overall value stream for this company was infrastructure delivery.

It took nearly 200 days to get web application environments for development projects at that time.

Jayden pushed to make these problems transparent and to drive improvements.

While he was making good progress on his automation initiatives, he recognized that the operating model was a major hindrance due to all the siloing, and so made a case to change that.

Knowing this, he designed a product and DevOps-inspired operating model, optimizing the infrastructure organization for agility and better integrating it with the development teams.

While he was working really hard to influence this, it faced a lot of resistance from the infrastructure executives, which can be expected because it's a pretty big shift from how they were operating.

After two months of no change, he decided to try a different approach, and he started socializing the model with the development executives to show them how it benefited them. As expected, they were pretty excited about these changes, and they actually worked with Jayden to put outside pressure on the infrastructure executives to make the model happen.

As a result, he actually broadened his role to have more impact across the overall technology transformation.

I would actually say that situation maybe serves as an initial lesson learned on how to navigate leadership challenges, just getting to that point.

But over the next two years, they had a lot of success on their transformation.

They changed the operating model. They changed the culture.

The teams were delivering more value faster than they ever were before.

So things are good.

But one day, this company suddenly hit a rough patch.

They were having a lot of increased instability suddenly, and they were putting a lot of pressure on the VP of operations.

One day, someone caused a major outage due to a router misconfiguration.

It had widespread impact across the whole company.

When they investigated, it was determined that the change was made without a change request.

And even though this wasn't malicious, the VP decided to make an example out of this person so that others would be more disciplined with their changes. As a result, the individual was exited from the company, and the event was actually publicized across the technology organization, even against Jayden's advice as to the impacts on the morale and the culture of the company.

There was a revolt within the engineering community.

How could management claim that we're a culture that embraces failure and focuses on learning, but they take actions like this?

Ultimately, this did not have the intended consequences the VP was striving for.

Some of the top engineering talent in the company actually resented management for this, and it played a role in some leaving over the next few months.

Okay, so let's discuss some of the leadership lessons learned from these stories, and then I'll talk about the new narrative.

I'd equate most of these constraints to the following four categories.

One is lacking strong C-level sponsorship for the transformation.

Two, executive behaviors that are contradicting cultural aspirations.

Three, I'll talk about the frozen middle.

That's a term I've grown to enjoy to talk about how do you help the middle management change.

And finally, technology transformation that's disconnected from business strategy.

All right? So I see people taking pictures, so I'll take a second.

Thank you.

Thank you. So first, lacking strong C-level sponsorships for the transformation.

As we saw in the stories with Isabella and Jackson, this type of change is too significant to drive across the organization without top-level support.

As John was saying earlier, you can actually start to drive change bottoms up, but you're only going to get so far. You only get to the grass ceiling, which I thought was a great term.

Without the C-level leaders championing, the resisters will start to undermine the change in your organization.

You can build momentum bottoms up, as I said, but it's only going to go so far.

This risk also exists when new senior leaders join the company.

Without understanding what the modern trends are in technology, they may tend to rely on what helped them be successful previously, which is exactly what happened with Jackson with his new CTO.

So with C-level sponsorship and business and executive buy-in, you can actually counteract these things.

It's less likely that you're going to hire new executives that don't align with the new ways of working. And even if you do, you're better positioned to deal with any regressions they try to put into your environment.

So let's talk about executive behaviors contradicting cultural aspirations.

As we saw in Jayden's story, this can be a very difficult problem to solve.

What tends to happen in these situations is executives communicate new aspirations that they want for the organization, such as, "We're looking to empower teams to make more decisions," or, "We need to start embracing failure so that we can improve learning."

However, the behaviors of these executives don't always change to support these new aspirations.

And some examples of that include making technology decisions without engaging their engineers, or as we saw in Jayden's story, the witch hunts that result from failure, looking for someone to blame, or over-committing delivery and then having your teams do these death march releases to get stuff delivered. Leaving no room for learning.

This really can derail change in an organization because employees don't typically listen to what the executives say, they watch what they do.

And when what they do and what they say are out of sync, it creates a huge problem.

The best way to address this is to get transformational leaders in place in these organizations. Now, obviously, it's hard to do wholesale and you're probably not going to change out leadership overnight. So you need to invest in your leaders.

You need to coach them and help them understand what some of those new behaviors are, and help guide those behaviors so that they're modeling the way for the organization.

It's also beneficial to define what the new leadership expectations and behaviors are for the organization as well.

So let's talk about the frozen middle.

My feeling about middle management has changed a lot over the six years I've been focused on this. I used to be really negative and felt like there was these really strong, active resisters, and they're just going to fight change.

And what I grew to appreciate over time is that's a really hard level to be at, for one.

You're dealing with the operational needs of your teams every day.

You're managing up to the executives above you.

You've got to manage down. You're buried day in and day out, and then now you're suddenly expected to learn all these new things and help your teams change how they're working. And what I think is more important is you need to invest in these people and help them learn how their roles are changing, how this change adds value to the organization and adds value to them, and what they can do to thrive and be

successful as this change happens as well.

So, pay attention to this group and really work with them. When you start on these changes, focus on the people that want to change, and start small, build momentum with those people, and you'll pivot some of the later adopters that John talked about earlier.

I will say, though, even after your best efforts, some people are not going to get on board. Some of the laggards aren't going to turn over. And the key is to build enough momentum in your change so that others realize that they need to make a decision to get on board or leave. And some will leave, and that's quite okay.

Okay. Finally, technology transformation that's disconnected from business strategy. Often, enterprises just focus on the technology organization when they're doing these transformations.

In doing this, they're actually not tackling the complicated problem of aligning the business. This can create huge problems when you're looking to scale things like your operating model because you're not tackling bigger challenges such as prioritization, funding, and roles across the organization. You won't be able to be successful if the business isn't engaged, and you're not going to be able to get them engaged if you can't frame

your transformation in the context of how it helps their business strategy.

Spend the time early on to understand the business strategy and understand how your transformation's going to help accelerate business agility.

Get business leaders on board with the change.

And I will say, if IT is off pursuing transformation and chasing it because it's a cool thing to do and they see other people doing it, you're going to fail.

You've got to align it with the business.

All right. Let's talk about a new narrative. So we explored these lessons learned.

I now have a new narrative for Jackson, Isabella, and Jayden.

So Jackson, Isabella, and Jayden were all connected through the DevOps enterprise community. They're part of this dynamic learning community.

They recognized that the challenges they would face in growing momentum in their organizations were significant, so they all started collaborating on a strategy.

Seeing how Jayden was already having a lot of success, given the levels of executive sponsorship and buy-in in his organization, Isabella and Jackson made it a top priority to make the case for change in their own organizations.

Both identified the disruptive factors and new threats emerging from more nimble digital competitors in their industries.

They also did deeper internal assessments of their environment, understanding the constraints in their value streams, running things like DORA assessment to measure the current operating environment of their value streams, or even doing voice of the customer to go talk to their business partners and their customers to understand what their pain points were with technology. Additionally, they were armed with

product transformation guidance from IT Revolution books and papers that are helping guide people on these transformations.

One I'm super excited about that's going to be published a little bit later this year.

They could see that the key was to expand from purely a DevOps transformation to a product transformation, which would actually do more to pull the business and IT alignment into scope.

Each of them framed a case for change, anchoring on outcomes and data from the State of DevOps Report that they used to help their executives understand how the business and technology performance could be improved through this change.

Having secured sponsorship in the C-suite, they also took this opportunity to align their executives on what was needed from them to effectively model this change in the organization.

So here's some of the actions that they took.

First, they defined a new set of expected leadership behaviors and incentives and emphasized things like empowerment, responsibility, learning orientation, and collaboration.

They rolled out training through immersive workshops, so these leaders could learn these behaviors in the context of how their teams were working.

They invested in leadership coaching to guide these leadership behaviors and actions and ensure the executives were modeling the way for the organization.

They identified role model leaders and invested in transforming their teams first, and then they held them up as a beacon of success to the rest of the organization, showering them with praise and recognition. And finally, they brought in external leaders from outside of the organization that were driving these transformations in their own companies, and they had them talk to their middle

management and their executives, helping them understand what their learnings were and how they were having success. So after solving these problems, they were well on their way to transformation success.

So what happened to each of them?

So first, after aligning the CIO and the business executives on the transformation, Jackson was promoted to that open CTO role.

This positioned him to quickly build off the success he'd started and expand the transformation focus more broadly across the organization.

As for Jayden, he was able to push his company further into an optimized state. The business was no longer putting pressure on a VP of operations for stability. Those challenges were now funneled directly to the engineering and product leaders, who put emphasis on prioritizing quality and tech debt for their products. The majority of the changes were now fully automated for the organization, and the leaders were well-coached on

treating failures as learning opportunities and never missed an opportunity to continuously improve their products when an unplanned failure occurred.

Isabella built a strong coalition of the willing with other business executives and helped reimagine the operating model for how business and IT would work in her company. She partnered with these business leaders to make the case for how their project to product transformation would improve the business strategy from both a speed and cost perspective.

After receiving support from the C-suite, they decided to start small, with a single line of business. It's really the best way to drive transformation.

You can't go all in from day one. They used the success from that small start with the one line of business to build momentum for the change across the rest of the company.

So some of my advice to you.

I've talked to Gene about this before.

The one thing I love about the DevOps Enterprise Summit is I feel like I'm with a community of my peers.

We have shared experiences, and there's a clear theme in that we're all driving change inside of our organizations.

So what are some of the things that you can do to lead transformation and drive change? First, embrace it. Embrace change.

You need to be resilient and adaptable.

You have to help other people work through their own change journey.

Connect within this community. This is a very powerful community. Help each other.

I owe so much of my career success to the advice I've gotten from others in this community. Get involved, offer your expertise.

You'll be surprised how many people are willing to help you, too.

Find champions, both within the business and IT.

Build your support network, because you're going to need to lean on these people when you're going through these changes.

Establish a clear North Star. You need to inspire your teams and your partners for what the future could look like.

Give people something to aspire to.

Use your outside voice. I've said this a lot in previous conferences.

You need to be vocal not only in your company, but externally in the community as well. You have to be bold and willing to challenge the conventional ways that work has happened.

You have to empower your teams. The only way to truly transform, we can talk frameworks and all this other stuff, the only way to do it is to build high-performing teams and enable them.

That's what it boils down to in every organization.

And finally, walk the talk. You must demonstrate the type of transformative leadership that's required to help teams thrive in these modern operating models.

So this is a call to action to all of you.

Look around. No one else is going to drive these changes in your organizations. You have to be the ones to do it.

So be bold.

Find energy and inspiration from other like-minded people.

Take advantage of your time here.

So one of the most liberating moments in my career happened about six years ago, when I realized that my beliefs were more important to me than my job.

And it was a super powerful realization at that stage in my career.

And when you're able to get to that point, you can empower yourself, and it actually enables you to do some pretty amazing things.

Okay. I always close with what do I need help with? Gene always asks for these.

I'd like everyone listening to this talk to find at least one technology and one business leader in your companies that you can convert into a champion to drive towards DevOps and lean ways of working.

The only way that we're going to get to sustained, scalable success in the industry on DevOps is when we get to a tipping point where more leaders believe that this is the way that work should happen than those that don't.

So with that, if you do like this style of presentation, I'm going to do a quick plug for MindsEye Creative and Ashton Rhodenizer.

She did all the artistry and graphic art for me.

And with that, I am done.