00:00:07

Good afternoon. I'm Amy Bachtel. I am so excited to be here with, thank you for joining me today. This is my fifth or sixth DevOps enterprise summit, and I really wish we could be together in London. Hopefully next year, I look forward to meeting you. Susie chasm said, fear kills more dreams than failure ever will. As a transformational leader, I don't want to kill dreams. I want to help companies realize them, but to do that, I need to be a fear Tamer. I have been practicing DevOps for over seven years at three very different companies. Company. One is a, mid-size not for profit, federally funded research and development company. It has been named to computer world's best places to work in it for many years in a row. It is where I put in my first CICB pipeline and saw colleagues that I love get their nights and weekends back when releases became daily, predictable and reliable.

00:01:16

It is where I began my career in dev ops, but in 2015, I got the opportunity to bring that experience to more people. And I left a company that I was at for 16 years and people that I loved to join a much larger effort at a fortune 100 company to say I did a 180 in my career is an understatement. And for four years, I was at a company learning how to execute a transformation at scale in a heavily regulated, highly competitive for profit environment. I came in with very little knowledge of the cloud and scaled agile. And four years later, I left as a cloud solutions architect as a director in a large organization inside the company, leading a project to product transformation. And for four years, I got the opportunities to be a part of one of the largest, most progressive digital transformations of our time. But that company was well into their journey and maturing. And I had learned so much and I decided I wanted to help another company do this. That was at the beginning and where that second company was five years ago. And I took an opportunity to join S and P global and lead in their adoption of cloud and dev ops. And today I am the head of the DevOps in cloud engineering enablement platform.

00:02:51

I'm hoping the next move is to retire. Most people know SMP standard and poor for the stock and index ratings, but S and P also provides energy and commodities, data, and market insights to businesses all across the world to help them make critical decisions. SMP is primarily a data company with many years and petabytes of data that are accessed and analyzed all day. Every day I work in S and P is market intelligence division supporting a large web based platform for our customers spread across the world who use the data and analysis. They need to make decisions about economies and finances. Um, they use our platform that in products that are accessed, um, throughout, uh, cities in large countries all over the globe. So my challenge is providing a development and cloud infrastructure platform that will accelerate the rapid delivery of value of new and differentiated data sources to our customers and large quantities and distributed across the globe. And to reduce the amount of time that we begin identifying new data sources from the time they're identified and injustice and in use and to our customers. It's a tall order.

00:04:21

I took the first several months of my job to listen and learn and talk and empathize with my stakeholders and internal customers. I conducted empathy interviews, and I learned about the architectures and the challenge challenges. I also learned a lot about what they're afraid of and their concerns, and there was a lot of fear. Um, I held my first all hands. We hold all hands and town halls within S and P. And I did this in may, and I did that to help establish that mission and vision and some of the tenants that we were going to work by for our dev ops and cloud engineering enablement department. I established the mission that says we're going to make it convenient, make it easy for development teams that are building applications with our platform to be able to continuously develop, deliver, and operate compliant and cost-effective applications in the cloud.

00:05:18

At scale, we have a vision of creating autonomous teams focused on rapid innovation that deliver value to the customer who are focused only on delivering value. And don't have to worry about the burdensome overhead of wasteful processes in that all hands. I also presented this slide. What do you see? I see lots of change it's everywhere. And I see a rugged, dry terrain and a mountain that you can't see past, and you don't even know what's behind it. And like many organizations in the midst of a digital transformation. My organization has been through a lot of change changes in technology, leadership, organizational structure, and most recently changes in where we work due to COVID. We went to a completely virtual workforce, like most companies, if not all companies. So we know and understand that in today's environment and with today's technology and the competitive market that we need to worry about. What's behind that mountain and we're kind of afraid of how we're going to get behind the mountain and what's behind the mountain.

00:06:39

So yes, we need to build systems that we can scale that are agile, adaptable, and resilient and tolerant of this changing environment. I believe that that system is built using CICB pipelines, cloud containers and microservices. And these are the foundations of our engineering enablement enablement platform that will help us to achieve the mission of being easy of driving autonomy in our teams. But it's not just about the system or the technology. We also need to be people that need to keep pace with change that are more agile, adaptable, scalable, resilient, and tolerant of change. I find it so ironic that change something that is so reliable yet, something that makes us so uncomfortable that if it is so reliable and something that we can always count on, then why don't we take comfort in change? Why is it that change fosters fear?

00:07:48

I read a book thinking fast thinking slow. And in that book I learned around about prospect theory, and I learned that as humans, it's human nature, that we would rather avoid loss avoid. It's better to not lose $5 than it is to have the possibility of finding $5 that wouldn't given the circumstance to choose avoiding losing $5. We would choose those circumstances. We assigned too much weight to outcomes with low probability and too little weight to outcomes with high probability. So I have to ask, would we rather be comfortable and stagnate to avoid boss or be uncomfortable and avoid being uncomfortable and grow?

00:08:35

It is my job as a transformational leader to address that fear, that fear of loss, embrace that discomfort and loss and shift my customers and people I work with to focus their value, to be on the games I am stranger to change and the fear of change. Uh, I detailed my journey of the organizations that I have transitioned to. I made two very significant changes in my career in the last four to five years. Was I afraid very much so. Was it uncomfortable? Yes, but I didn't let fear and discomfort hold me back. I saw that the joy of the gains I perceived in my new opportunities exceeded the pain of that loss, but I still had to deal with the fear. And I did that by recognizing it developing a plan and a plan B listening to my instinct and having a point of view that I'm about to share with you about how to execute on a dev DevOps transformation.

00:09:43

I developed a system called the C-suite that enables organizations to help tame the fear and support a more comfortable change journey. You could call it comfort suites. I deliberately choose the word system rather than framework or methodology or approach. Uh, my background is a systems engineer and as assistance engineer, I am trained to recognize the components and patterns and how they interrelate to create value and to understand how upstream and downstream changes in these components affect each other. And what happens when one of those components is changed. So I'm going to take you through the C-suite.

00:10:24

The first C is cross-functional teams establishing teams that are both dev and ops functions. They're T-shaped, multidisciplined, they're not full stack engineers on a team. It's a full stack team of engineers. They have a, you build it, you own it, or Y BYO approach where they have to own and operate the application for its full life cycle. And they practice agile. These are cross-functional teams that are balanced with knowledge and skills that cover the entire stack and enabled the collective ownership of the application for its life cycle, from cradle to grave and from code to customer a cross-functional team where ops is embedded in that team that removes the incentive. That usually is a competing incentive between dev and ops and removes the us versus them mentality. When they were siloed, the team cross skills and everyone learns and grows. And the customer wins from that.

00:11:27

In my experience, it's changing to this team structure and potentially depending on how you do it, if you're changing the reporting structure is the largest source of fear and a dev ops adoption for both the people that are managing these people. And for those people to move into a new team construct, you can help allay some of those fears by giving them a really well-constructed architecture and system that enables no fear releases, give them a system that gives them the ability to deliver predictable high quality releases of value into a scalable, resilient, highly available and high performing cloud environment, provide them with reusable code libraries and codified stacks that they can get do stand up on demand environments. They meet compliance and security and their engineers aren't in fear of being nagged and confronted by auto audit and InfoSec investing refactoring the code legacy code into microservices for applications that you are invested in for the long-term Practice, continuous feedback and flow, the third component and the CSP. These are your engineering practices implement an engineering excellence program. It will improve developer engagement, raise motivation, positively impact, quality, and speed up time to value. Make these practices measured, visible, and a dashboard so that they can see and get feedback on their progress. Drive them to compete against themselves and improving their practices. Think of it like a swim team or a swimmer who gets in the pool every day only to drop time from their previous time. This is a great way to do that

00:13:23

Competency center. I like to call this the no fear center. Nothing says we are here to help you and for you to be successful, then giving them a competency center staff with highly skilled masters, that coach teams and individuals to adopt new ways of working in new skills. It is in the center of competencies that team can co-create and innovate and accelerate their learning and have access to depth, adaptive resources, and references and knowledge that will help them, uh, adopt these skills and knowledge faster. What I've seen to be the most successful and shepherding teams who are changed like this in a center of competency is what is an immersive learning model or a dojo. This is where teams can co locate for an extended period of time with the masters and the coaches and, and adopt the tools and practices, according to a challenge that executes on their real backlog. So they're still delivering value at the same time that they're learning. Um, it's where they can go and learn in a psychologically safe environment and where it's safe to fail. Imagine if you had a center of competency for everything that you had to go through in life and how much easier it would make things

00:14:46

Build an internal community. In 2019, the state of DevOps risk says that the high performers favor strategies that create community structures at both high and low levels in the organization, including communities of practice, making transformations more sustainable and resilient to reorgs and product changes. It is the communities that will help scale the transformation across the enterprise. I want to touch on hackathons. Um, I have been participating in hackathons for a couple of years now, and they are the most effective way to jumpstart innovation and to problem solve. I've seen solutions from a hackathon solve complex problems that a room of experts couldn't solve that's, uh, for two days, communications communicate success frequently and loudly provide people with a platform to shout their success from the mountaintops, use leadership to communicate and repeat that message and mission over and over at town halls and all hands. The more stories that are told and shared, the more people will accept that this is here and it's here to stay that acceptance and sense of conviction from leadership in the community. And their peers will provide people with a sense of security and stability that they are longing for. And it changing in a chaotic environment.

00:16:17

The last component in this C is customer-focused outcomes, measure value and results and show the data that supports what you're doing with your dev ops adoption is working and tie it to actual business results, avoid the vanity metrics that show productivity, but probably not much progress, focus on outcomes rather than output and employees see the difference and can tie what they're doing to those results, the want to do more and the want to go above and beyond. They will know that this is working and they will stay the course at the heart of this at the heart of a transformation and at the heart. And in the middle of the C-suite is the most critical element to taming fear culture, creating an environment where failure is celebrated is part of learning where people feel accountable and have ownership that are, feel safe to speak up and challenge status quo. This gives them that comfort and conviction. Then this journey that erodes up their fear as part of changing culture, validate what they're feeling. There's a concept that I have used, and I've used in my own changes called name it to tame it, that once you name the emotion, it will inform you and not overwhelm you.

00:17:43

These components in the C-suite work together to form what I use as a called the flywheel and helps to drive self-sufficient Y Y B w you, you build it, you own it. Y BYO teams, it tests my strategy and how the components of the C-suite work together to drive momentum and change and moving towards the mission. I use this with my internal customers and stakeholders, to give them an idea of how this system works together for that momentum for sustainable transformation. This is how it works. You establish your cross-functional dev ops team, That team accesses the resources and gets the coaching support from the center of competency to start with Next. They use those resources and that support to develop their application using agile test-driven development CICB practices, their engineering excellence competencies. The app that they're built is deployed to and operated on the platform. Using the architecture previously described As a continue to develop and deliver they're monitoring and measuring the results of their processes internally, and the impact on the market externally. And they use that monitoring and measuring to get feedback to continuously improve and inspect and adapt and evolve the quality of their application. And when the application has met the requirements and is in full operating capabilities in the market, they use their community to communicate and demo and share the results. Furthermore, they take what they built and they package it up to be reusable

00:19:28

And put it back into the resource center for their peers and colleagues on other teams to use. And then at that point, what they've done for other teams, then self-service to on demand, codified resources and references that allows them to accelerate the go to market and times of value for Greenfield applications. And then over time, this improves business results as they're able to rapidly innovate and disrupt the market.

00:19:59

So when I begin with an organization, um, I make it clear what my success criteria is for DevOps and that how the, this C-suite system supports achieving these successes. Uh, my number one priority, and number one criteria for success in adopting dev ops is at the essence of DevOps, which is the collective ownership between dev and ops for the quality, reliability, availability, stability, and performance of the application for its entire life cycle. Following that is success criteria. Number two, where teams can rapidly experiment and release high quality software frequently at any pace at any time without disruption and seamlessly to the customer. Uh, I want to emphasize that I use at any pace at any time over deploying daily, because I believe in the supply versus demand of the market. And I believe that we don't really want to exceed the development pace faster than what our customers can absorb, or then what the team can do. I don't, we don't want them indexing on speed. Over quality. Last is restore the entire environment and its application with a single command. And when a hundred percent of the customer facing long-term investment applications have met this criteria, then I think an organization can claim DevOps.

00:21:28

I also use the C-suite to establish the work streams and a roadmap that shows the path forward and how we Oregon. It also helps to help us organize around the work. Uh, this makes the strategy actionable and executable. It establishes milestones and the capabilities that they can track against. I mentioned earlier that having a plan and a path forward helps ease my fear and anxiety, uh, having a roadmap and a competency model such as this, uh, it helps them to organize and execute and we'll do the, um, the same for those going throughout this change. And so over time with that roadmap and with that flywheel and with that success criteria, uh, the virtuous cycle of continuous improvement and competency will perpetuate. And the line spade between dev and ops as ops becomes a more embedded function into that application team.

00:22:27

But this takes a while. It takes a long time to do longer than what you would expect. Uh, I worked at three very different companies with what I consider unique change profiles, and this is the profile or the factors that influence their ability and rate of adopting DevOps. So every one of these companies want with dev op has to offer, but just like people, their personalities and profiles impact the rate and success of that adaption, they will get there, but will they get there fast enough in order to protect themselves from being edged out by the competition or, uh, for God forbid, uh, completely disrupted and want to focus on company too, because it was the biggest and most aggressive than the three. And yet, uh, it was at least three years before they really saw the benefits of DevOps. Uh, it was about three years before they claimed they were going to be a dev ops organization before they could get a Greenfield product out the door to the market in less than three months.

00:23:34

So why is that? There are circumstances out of our control, regardless of fear, that will make dev ops adoption harder than it needs to be, no matter who or what the organization is. I have four factors identified here, the top four too much change at once. Adopting agile dev ops in the cloud is a lot for an organization to take in steep learning. Curves will slow you down context switching, um, and just overall the, uh, absorption rate of the learning will change at the pace complex undocumented legacy systems. You open up the hood and find out that it's tangled Christmas lights, that what you thought would take six months actually takes a year and a half organization. And leadership changes as companies are learning to adopt a new operating model with cloud and dev ops. Um, they make some hard decisions about people who are along and bought in versus not, and some have to go.

00:24:36

And then also as like I did, um, when I learned and I developed, uh, the aptitude and the ability to lead transformations, I wanted to go help other organizations do the same and sought new opportunities, last cognitive overload teams that are given too much work and too much a steep learning a new skills and can't get the work done. Uh, there's a lot about cognitive overload and a great book called team typologies that I believe men well Paez is talking about at this very moment. So these circumstances are normal. There's nothing wrong with an organization that can't achieve the dev ops adoption at the rate they had hoped. And so we, they're going to have to inspect and adapt and adjust expectations in timeline, which brings me back to this slide. I've shared with you, my strategy and method for structuring your transformation that provides organizations with methods, components, and roadmaps, and a path forward gives them the confidence to take on such a large and ambitious journey.

00:25:45

And at this point, I want to revisit these question marks and see if we can fill in the circles. We talked about if change was so reliable, then why don't we take comfort and how fear gets in the way. So how can, based on the C-suite giving people a path forward and a system designed to enable them for agility, adaptability, scalability, how can we use the C-suite to allay those fears and tame the fear, give them people to help give them cross-functional teams that cross skill, give them a community of practice where they can go and learn from their peers and give them a center, a confidency with the resources, the references, and the mastery and coaching to accelerate their learning and be psychologically safe place to fail. Give them the platform that gives them no fear development and releases and gives them a safe way to rapidly experiment, provide them with leadership and strong communications that show and influence the culture and showcase the success and progress. You do these things, you will tame the fear that holds you back so that when you see that mountain with the rugged terrain and you were leery and anxious about what's behind it, just know that following the C-suite and having a way to provide that comfort and change will lead to a landscape like this. There's still mountains. The journey is never finished, but it's peaceful. It's beautiful. It's manageable.

00:27:33

And I want to leave you with this in a, what I consider a coincidence maybe, but when I was developing this presentation, I was away in a beautiful Lakeside home of joining a weekend with my college girlfriends. When I looked up on a bulletin board and I saw this, we are all held back by fear. I disagree. Don't be held back by your fear. Let fare, let fear be your fuel. Thank you.