Long Live DevOps | Predict 2023

here Hey everybody. Welcome to predict 2023 mining is Sharon Florentine. I am the managing editor here at Tech strong group.

It is awesome to be here with you today. And with my excellent panel, we are gonna kick things off and talk about the topic is Long Live devops. And I know you've seen a lot of predictions over the last couple years about the fact that devops is either dying or already dead.

We obviously strongly disagree with that and we think that there is a bright future for devops. But so we're gonna dig into a little bit about that today where we think devops is going a little bit about where it's been whether or not it's been able to fulfill the promises that it has made and that have that people have made about it. That's just a little Sir, but before we really get into it, I just want to say thank you to my awesome panel for being here today.

I think I've got the best panel of the day, but that's just me with me today are Chris McHale who's the co-founder and CEO of spk and Associates John McKinney SVP and GM of intelligent Z optimization and transformation at BMC and Jeff. Kai's director of product marketing at atlassian. Welcome folks if you want to take a minute or so and introduce yourselves and then we will kick things off.

Chris you go first. Sure. Yes as Sharon mentioned on co-founder and CEO of SDK and Associates.

We're located in the San Jose area Silicon Valley area and we have been really all about Automation and it or technology really to support product development specifically these days software and so we're we're evangelists for devops. Some love John want to go next? Yeah.

Thank you Sharon. Sure. And as you said I am the general manager for BMC software's intelligency optimization and transformation business units also known as our Mainframe business and what I thought was funny sharing you said is devops dead.

I've been in the Mainframe business for a few years and I've heard is the Mainframe dead. Look the mainframes not did devops isn't deadness not gonna be dead in the next 20 to 30 years. So looking forward to the conversation here today.

Awesome. All right, Jeff. You're up.

Awesome. So I'm the product marketing director for our Enterprise agility Solutions atlassian. But what you really don't know is that I started off as a developer live the life of making all the mistakes feel like I got kicked out of that was an architect product manager.

It's funny as I've I've seen, you know and been faced with the problems of of how do you deliver value faster? Look at my own mistakes and the journey, you know, the fundamental tenets of devops and you know integrated product teams at the at the ultimate end of it are still there. No one's ever said gosh.

We need to deliver value slower and less reliably and with less trust to our customers ever. It's not you know, no one's ever said that and that is the fundamental tenant of where devops comes in awesome. Awesome.

All right. So one of the big promises that apps made or that devops was supposed to deliver on is that it was going to break down those silos between Dev and Ops right devops. Do you think that it has made good on those promises?

I mean are the silos gone now why or why not you're grinning Jeff so I'm gonna go right back to you. Well, so, you know we deal with a lot of folks that the Enterprise level many many of those folks are highly regulated environments. And so, you know, the cab comes in to say thou shout and and you've got to have XYZ in place and still still requiring a fair number of things that have to come, you know to be validated because if you don't get it right in a regulated environment, like it's not just you get fines and so forth, like people go to jail in and ultimately you have to look at, you know, being trustworthy to our our customer base trustworthy Computing is the initiative.

How do you how do you make that and deliver value as fast as possible? Devopsis not dead. It's going to help us forward.

It's it's making progress but running into some of the cultural and and you know, logistical aspects some organizations. I've talked, you know. Compensate Ops on how much up I you know uptime do you have and that's your that's your value that you provide.

Well, that's my value. I'm gonna put that anything is disrupt that like development shipping code into production and then development is up, you know, maybe they're compensated for how much stuff they're pushing to production. Oh my gosh.

We're if we don't address the culture and the organizational problem and get people aligned that look livering value reliably to our customer base. That's the point and have everybody on the same page with that joint goal. We're not going to get there.

Okay. So John, let me let me ask you how you think this applies, you know in your space in in the Mainframe space. I mean, what are you seeing on this front?

Yeah, I think yeah, you're asking about the silos and the promise that devops and you know, what we're seeing is that you know devops is now extending into core platforms. So for many organizations, the Mainframe is absolutely one of their core platforms, but it's maybe been a little bit slow to the party if you will in terms really embracing devops and automated pipelines and workflows. So we absolutely see that and as Jeff was saying, you know customers are really focused on what's the what is the business Journey?

They're trying to deliver. And most applications today are a hybrid application, right? It may start on an edge device or a mobile device and you may interact with a number of cloud and core systems and they really recognize it's really important that they have more Automation and connections between those systems so that they can have a fully automated and audited and process driven process.

So that just as Jeff was saying right everyone wants to develop and deliver capabilities to their clients faster, but they want to do it with higher quality code with less business disruption and the promise of devops and automating those flows is absolutely a key to making progress in that Journey. So that's a great segue because my next question deals with Automation and Chris. You know as has the automation promise really been fulfilled for devops.

I mean, how's that been working out and is it? You know, is it doing what it needs to do to increase developer productivity and velocity and delivery speed. Um, I think it has but things a little bit of a spectrum right?

So this isn't a black and white yes or no answer at all right in our business we deal with a lot of we're a services or a consulting company. So we deal with a lot of different clients of different sizes. And we also have quite a number that are in medical device.

So they're very they're highly regulated and it really comes down to I mean to answer your question, I would say yes absolutely automation has happened. It's happened a ton. I mean we're seeing more and more of it.

We try to Advocate more and more of it and we Implement quite a lot of it at our clients but it's a little bit like the fellow who wants to lose 100 pounds and says, well, I've lost 60, you know, so you get another 40 to go. I think that's the thing with Automation and it also depends on I would say the the a little bit of the size what I'm going to talk about the regulated, you know environment for just a second. Automation in a regulated like a medical device environment is definitely their friend the more you can automate something the the more insured you are about the quality which is of course the goal of anything in regulation in medical device.

So that's something that we really try to promote and push but there it does have its limits to terms of what what can be done. Yeah understood and I guess It seems like depending on the size automation can look different. Yeah, for sure.

Yeah, I think the smaller and the software companies the exclusively software are much more able to to do that. But the the mechatronic companies like a medical device, there's definitely some limits as to it can be done. Yeah valuable too.

I I know one of the favorite books I ever read on devops was about really applying devops principles to Firmware and HP with their LaserJet line and you know, the the model of look in order to get the automation. You've got a decompose your application. You got to build and gating you've got to up your testing and there's there's just a whole journey that valuable and and deciding, you know, which areas do you make that investment into which product lines which ones are going through change a lot of value in that Journey?

Yeah. A button, you've got a device like you're talking about the printers. I'm thinking about the devices.

There's a certain you could you could you know infrastructure as code a lot of that stuff, but it's just not worth it at a certain point. So there's a limit. Comparison I would add that.

I think you know, we believe there's gonna be a bit more of an emergence of what maybe I'll describe as a cross-functional pipeline. So, you know as we were talking about before right you've got these complicated business services and there's a lot of Automation and has been in the different silos, but they've not been really connected very well. And and so we're starting to see you know, organization is really looking at more of a cross-functional you might call it a single but it's really more about it integrated connected pipeline across these different elements that helps drive a greater sense of quality as well as improve the speed right?

So, I think that's one of the things that we're going to continue to see developing and that's why I think it's so important that every vendor, you know, so like Jeff and myself representing and Chris from the consultant right that you really focused on integrating right being able to enable clients to integrate the automation that they're In and delivering because there's any number of elements and almost every Business Services going to have a different components. So you want to standardize and be able to standardize you need to be able to integrate those different elements of your pipeline automation. and testing yep.

It's a good point, you know, I it what a great way to think about. This is like, you know, it's it's easy for someone in a you know, way off place to think well just automate the whole thing, you know, just just decompose everything down to you know, infrastructures code just automate your data and get that tilted up just automate all you know, that's an investment. You know, when we when I think about the Journey of devops and automation.

um really have to look at not just the devops journey, but the agile Journey have to look at the architecture one of the things we've been talking a lot about inside of atlassian is you know, if if you're on this journey as a product person You ought to start looking and making that work visible? And so we start talking about this value stream approach. Well, wait a minute if we're gonna look at the work of automation at risk reduction and at debt and refactoring code, why don't we put all that in from our agile journey into part of the types of work that we look at instead of just, you know feature defect and so we're starting to look at these things of saying well, there's features there's defects.

Well, there's risk, how do we automate the pipeline itself? How do we introduce security testing, you know white code what all the various checks, you know Library validation to you know, licensing even and get that up into the pipeline or even further left, you know, if you got to do a threat model get that into part of the task at the developers do before they start coding instead of waiting for the very end like in a regulatory environment you go to in front of cab. Did you do a threat model?

No, what is something really bad is there you're not You know, so feature defect risk and the last one is technical debt because you know in the journey probably you're gonna have to decompose your application. You're probably going to break it apart. All of that is part of the investment and better include it as you look at how you're approaching your devops journey.

Yeah, I think and we definitely see some of that Jeff when we talk about core systems, right? So yeah, you know a variety of core systems will have you know, components of the application or business process that might be, you know, fairly large right? So when you have something that might be tens of thousands of lines of code, it's hard to build, you know, a really finite testing around that right.

Where do you start to Jeff's Point earlier? So that's where we see, you know clients looking at how they address some of this technical debt how they break down some of that code into smaller components which enables them to do better testing, right? So now I can really isolate and test the thing that's changed where when you're looking at, you know, this 10,050,000 line of code.

It's kind of hard to do that because there's so many different processes that are handled within that one component. totally so I'm going to go back a little bit because we were talking about measure measurement and how we determine. When something is valuable, so that brings me to of course the metrics discussion.

You know, how how do we measure whether or not these things are working? How do we know that? We're delivering value or that something is sufficiently fast enough or quality enough and you know What do you do if it's not?

Yeah, I would I'll jump in and just say I think we would all agree right that is the older guys, right? You can't approve what you what you're not measuring right. So measurements are absolutely critical and we definitely see more and more clients really getting in and wanting to understand the metrics and there's a variety of metrics, you know best practices around the door metrics Etc.

So it's really about having the metrics to understand. What is your development flow and velocity? What's your air Escape rate?

You know, what's your meantime to resolution? And we see more organizations really looking at that as part of that devop process as part of that continuous improvement process. So where where was I spending my time on this most recent Sprint right?

How and where can I automate some actions to improve and get better in the next spread? Right? So that's part of the continuous improvement process and the only way you can really do that effectively is you need to measurements and metrics to be able to do that.

And that's something that we see more and more adoption in the coming year. And and that's a capability that that is extended and is available to core systems now which again you look back a few years ago. It wasn't and now it is We're seeing a lot of investment in this area, which I think is absolutely critical and necessary.

I would say for me personally speaking the ability to have dashboards to use that term, you know, so basically whether it's single pain or or multiple, but this is I think true for for anybody in any kind of leadership or project management product management position. You have to be able to see it immediately. I think if you have to wait, there's some psychological problem with that that you even if you get the report later, there's a disconnect, you know between what has happened.

So having those real-time dashboards and of course, you know, a lot of the tools we work a lot with Cloud bees. They've got some fantastic tools that do feed in to dashboards, but there's usually work sometimes a lot of work that needs to be done to integrate a lot of the the reporting and the metrics from the different tools so that you have something that pulls it all together in Sure, and you can make decisions and understand where your problem points are. So I think that that'll Concepts a really important.

The metrics are absolutely critical. I mean you you can't improve anything until you know measure what what's going on. Boy, these are like love this topic.

So I'm a help start the value stream management Consortium, which is about hey provide metrics on your pipeline and and not just your pipeline from idea to delivery and and she'll value through and so the fundamentals of it is like why don't we ask questions? Like how long does it really take from the time we think of something to get it to the customer so often from a devops perspective, it's just about how long does it take, you know from check-in to get it to production. And what was my failure rate?

I think probably my the biggest thing that I heard about quick story. I had a customer call and somebody said basically that they were gonna get you know, MBO on you know, their deployment frequency and I was thinking oh my gosh, that is like the wrong answer how what an easy thing to make a whole bunch of money on because you know, if I want to increase my deployment frequency, I can do that. Snow project start checking in comments every single day and you know, why don't we measure keystrokes and figure out what we're going the biggest piece of advice that I've ever gotten and given on that is start with where you're going.

What is it? You're really trying to accomplish and then use metrics to manage your journey. If you will remembering that our goal isn't just getting you know stuff through from check into production, but it's the entire pipeline.

Sometimes it may be best to look at stuff. That's before you get to the devopsy side the fuzzy front end and if it takes you 18 months to figure out what features to build and you expect them out and then find it by the time it gets to development. Now you're okay.

Why is it taking so long? Well, there might be a problem another area that you should focus on the devops side is good though, because you know, if it takes you another six months just to release it. Well now, you know where that problem is.

That metrics will help guide this journey, but you better do a value stream. From idea to production to know where that is pull those metrics out and then figure out which ones will actually help you achieve your goals. back to the planning side Please I hope there's product people listening this who would normally think I don't give a crap about devops you do because it's part of the investment balance that you should be making.

What are your metrics for your deployment frequency? You know, how often do you fail more? You know, what is the time it takes, you know, and and the cost of failure.

What what does it take for you to recover from that how long That's an investment that you ought to be making as a product person because you can fix that and it reduces risk improves, you know customer trust and and those metrics are Central and and key to what you should be doing. Yes, someone in the audience made the comment that there should be effort put to you know, even go so far as to Define unit cost. so like really getting down into up, I get I'm I'm gonna extrapolate from that and say like, you know, really get granular about what You're what you're doing and where you're going.

Yeah, they'll correct me if I incorrectly. Need assumptions there. Well, and and you know, if you the from a investment point of view, it is interesting, you know to look at what does it cost us to deliver a feature.

Well, it depends how robust how trustworthy how modeled is the pipeline how reliable a lot of different aspects because you can deliver feature cheap, you can deliver a feature expensive you can deliver feature that's more robust for the long term. There's Investments. Sometimes it may make sense.

Just get this little thing out. Nobody's gonna use it. Nobody cares, you know on the website if you get it wrong, it's not a big deal to to change a couple of words here and there boy, I don't I'm really gonna get shot for that.

I'm sure I was gonna make the comment that it's the fast good and cheap pick any two like, right. where but where do you want the where do you want the Yeah, I was gonna to add chair and I think as Jeff was saying, you know, I think we absolutely believe there's a tremendous benefit in doing value stream mapping right to really understand the process and you know, we have a number of clients have gone through that and then they're kind of taking some of the next steps. Right?

So some of the next steps are using metrics to understand how they're different development teams are performing, right? So again, it's a little of an apples and oranges because they're having different projects, but you can see where you might have a little bit better flow velocity. You can see where you might have a little bit higher level of quality.

So they're digging into understand with metrics what's different what's different about these teams and what they are looking into metrics to finding you know, what tools might they be using are they using something different on this team versus that team so they're able to ask those next questions and maybe able to provide some additional training or maybe some additional tooling to help, you know, their Teams, you know all are executing more at some of their best teams level of productivity. So there's a lot that can be done with metrics to help every team improve and that's why I think we absolutely see more of that being utilized in the coming year. One thing I would just jump in and last comment on metrics is that I think it's really important to push all of that down as low as possible because you don't want to be providing this information, you know at a certain level of the of the hierarchy or whatever you want to call it.

Um, and then not download, you know Engineers are all smart capable people and the more information they get but in addition to that knowing what they're being measured on and what is important to speak to what Jeff was talking about spending time really defining what what is important to measure here, but then pushing all that down as low as possible. So people can look at it themselves and correct themselves and check themselves. That's the most efficient way to do it.

I think yeah, I mean devops was born again because Ops your compensated on making sure nothing goes down Dev your compensated on making sure you can get as much crap across the fences. You can go think. There's a problem.

Want to create it again? Hey, Dev, how fast can you deploy code? Let's see what happens, you know shorten, you know, if they're good things, you know, but manage that way well and what you're really saying there too is that you have to take some of those metrics and spread them out across the dev and the Ops, right?

So don't just make OPs responsible for uptime make them all so looking have them look at the speed of velocity of release and Etc, you know, exactly, you know, one of the cultural things I heard like, I wish I could articulate the same way I heard it but it was effectively enable the teams to make improvements themselves and have that be a culture and if the culture is one of experimentation with cross-functional autonomous teams, And then allow them the space to experiment. Hey, we tried automating this we tried, you know refactoring why whatever different kinds of pieces and see how it improved in general. They'll do the right thing need better.

That's where your product team can really help out on the Investments of well. Gosh, we're seeing we're delivering too many features on this we better go make this area more robust bolster up the pipeline refactor the technical debt. Maybe we just need to focus on bug fixing but balancing all that and then using metrics to show how we're doing and remembering that the metrics aren't just how well do we deploy the code?

But at the end of the day the outcome is, you know, is it getting used what's our adoption rate some of the pirate metrics that a product leader would think about Beyond just you know code delivery those are important, but they're all in conjunction to together to see how we're doing. and absolutely, you know. problems problems for devops to have right?

We're not figuring out can we do this? Can we make it faster? Can we deliver it at higher quality?

We've already done that now now we're we're you know, we're refining the things that we've already. Figured out we can do and do well or at least that's my that's my opinion. So we've been talking about metrics and uptime and measurement and all that and you know, we hear and see a whole lot lately about observability.

So obviously observability is kind of putting all of those pieces together using the metrics using the feedback using the pipelines to figure out when something goes wrong. Where did it go wrong? How did it go wrong?

How can we fix it? You know, how does how does observability support devops Mission and related but not you know exactly what the heck can we do with all of that data that we're generating? to inform observability and I know that was like seven questions at a time.

I'm sorry. I wish I'd jump in I think you know one of the things that that we've all seen over the last couple of years is you know, the tremendous increase in the use of AIML, right and observability is probably one of the Prime spaces, right? So I think we're going to see more where you think about devops and especially, you know from an Ops Team.

They might be taking the lead on this from the operational systems, but really leveraging AI ml to do you know causal analysis and we talked earlier about silos. So one of the challenges with these, you know business processes that are on multiple different architectures is there's a lot of AIML silos today, right? So you have a little AIML where I'm doing observability on this component.

There's another one on this component another one on this component, you know, I think we're gonna see more of a convergence where these different AI ml planes if you will are feeding in and integrating so that you can really understand what Is the AIML telomy on these different elements and how do I bridge that across so coming back to the developer? Right? I'm responsible for the business service.

It's a complex Business Service. There's something that's going wrong. Where is the problem in it?

Right because in some of these elements it might be the developer code. It might be how that code is interacting with a massively shared infrastructure component. So that's where observability can really help teams much more rapidly detect where the issue is so they can more rapidly resolve the problem.

So I think we're definitely see more AIML observability across the stack. I think I think it comes back a little bit to back to the silos. Right?

So even if you have AIML if you have silos of information. You you can if you sit there and stare at it long enough. I mean done this so you can make the connections but that it is just a really ineffective way to do it.

So you have to find ways to integrate this data to integrate this information and the AIML can help you with that but but understanding what to look at and how to correlate and connect it and sometimes just getting back to that dashboard again. Just getting a picture of the different disparate pieces of information on one visual page allows you to draw in and make connections and draw conclusions that you otherwise couldn't have we do a lot on the op side of devops and we've seen some real benefits from putting time and effort into pulling all that data together. Yeah, and boy couldn't agree with all that more.

It's interesting as as the journey we talked about how the Journey of devops is mixed with metrics, but it's also mixed with this discussion of I have to effectively decompose my monolithic applications and to smaller components. Well, the the in state of that now produces new problems. Okay, you took your entire monolith and now you've got thousands of micro services with dependencies and they're all in production.

And who knows which one does what which where's your listing of them? What health if I have one component that fell one percent of the time and now I'm increasing its usage. Oh my gosh, how do I know that?

Where did it you know looking at the chain of events John you're talking about the AIML that's like that. Of course, you have to kind of know this. Hey, I'm noticing a pattern that when this component here starts to fail over here.

This one's also failing. Good, that's it. Why you have to have this stuff in place as you are in this journey to figure out where do you need to increase your health?

What is your devops health? It's not just about your metrics. It is about your observability of like how's it working in production so that you can then continually Yeah for sure.

So we've got about 15 minutes left here. So I want to ask you each to weigh in on what you think. The biggest objectives for devops should be going forward in 2023.

Whoever wants to go first. But a little bit look wherever you're at. Keep investing if I had to say one thing it is.

Look to an organization. That's a across functional product team. Meaning you build it you own it as a team.

Now you're all aligned on the same goals. Look at your entire pipeline. And look at how you can fix things from idea to production knowing that from check-in on through and the Automation and all that is entirely, you know important.

Make investments of work since you know now we're asking developers do everything make it visible. All the various work types what they are, you know, it's beyond developers are doing more than just future defense make invisible. Decide as a product team.

How much investment you should make each one? Introduce the automation as you go make visible. How you're doing in a culture where it's about experimentation, you know, I love Chris that you talked about like we should just be able to get these metrics all the time and make them transparent completely, but they have to be automatic.

It can't be somebody. Let me go figure out what my deployment frequency is in calculate it what it was six months ago doesn't matter what it was six months ago matter what it is today. And put all these pieces together and just decide what your next step in the journey is going to be as you're in this space and make that be your culture whatever you're at and whatever you're doing if that's your culture.

You'll make the night the right decision on what the right next step is. That's a great point it it looks a little different for everyone based on where they are. So Chris.

What do you think? Yeah. Sorry, go ahead.

I would Echo a lot of what Jeff says and and go a little slightly different direction. First of all without any doubt. It's a cultural approach right devops is and and Jeff is absolutely right, you know, even if you're 20% of the way there 50% or whatever you view 100% of devops in your in your company would be just keep working at it.

It doesn't stop it's it's really a continual Improvement continual quality improvement of what you're doing terms your processes and Automation and all of that. I would say on the culture side what we've seen in a lot of our clients is if devops and and this mindset in philosophy is really embraced at a higher level in the company and an executive level. It will be and can be successful and sometimes you have to educate your Executives and educate that team a little bit more if they don't live and breathe.

In the space from a business perspective you have to to sort of but will effectively educate them and tell them why this is valuable and why it helps the bottom line why it helps all of these things because they have to really Embrace this and and the final comment I would make on in terms of the culture in terms of where it's going. We there's this interesting thing we've seen because like I said, we're a little bit more on the up space. Um, there's there's a definite different personality type in Dev versus Ops.

It's very different and and you have to work really hard. You can break down all the silos you want people have to be communicating and they have to respect each other's point of view because they have very different points of view forget about the metrics for a minute. They're just different people and so really encouraging them to talk to each other take risks together and work together.

I think is a huge part of this we haven't really talked about but we see as being very important. Yeah. All right, John you get to wrap up the crystal ball conversation.

Yeah, I would I just kind of add to what Jeff and Chris were saying for people that are listening. You're not alone. Right?

There are more people than ever before that are on this journey and what's important is to either start the journey and if you're already on it, you know, I have every confidence that you're continuing on that journey and it's about continuous Improvement whether you're on the deaf side or the op side, I would say you both are really after the same thing, right? It's just two different elements of it. You're trying to deliver more value for your organization.

And the way you both do that is you have to deliver new capabilities, but you got to do it in a way that it performs it's available and it's resilient. That's why both teams working together is so important. I think we've shared a lot of different ideas here if some of the things that we talked about seemed a little bit Futuristic.

What I would say is I think everything that we've talked about you can do today. And you can reach out into the community. You can reach out to any of us on the panel, but you can reach out to peers and you can find people that are having success that are on a journey and I would encourage you to collaborate because you know, this is a tremendous Community everyone benefits when we're sharing information with each other when we're sharing best practices and how we can improve so I would say get started and continue the journey because there's a lot of value you can really bring to your business and you know when you have those kind of successes frankly, it's just fun.

It's fun, right so get after it have fun and you're gonna have success for your organization. So true awesome. I I love that.

You know, I just a really reiterate that point. There's nothing stopping you from making metrics about your improvements and celebrating your successes. Because you can do this at any point in time.

You don't have to convince anybody and the most biggest cultural change you'll ever make in your organization is having a success story where like hey our team we decided to automate blah and it was cool or it was a disaster and here's what we learned and and what a cool thing to then be able to promote that because ultimately you're gonna have one of those were it rocked not only did Rock but it improved the value delivery and look what we're doing now. That culture is, you know, it's infectious like people want to do I want to do that what you do? How'd you do it?

It's nothing stopping you from doing that, you know having that story so just get going. Hey, this is so I mean that I left sorry. It's so true.

I'm so excited because that's so true. It's I always tell my son even when you screw up, even when you fail it teaches you something you didn't really fail. You learned more about how you can succeed next time.

And you know, he looks at me and he rolls his eyes. But I mean, that's right. That's this whole that's devops.

That's what's gonna keep this going to the Futures all these people. Screwing up a little bit going back figuring out how to make it better continuous Improvement. I think also some people um, if they're starting this journey, they don't know where to start because it seems absolutely immense and it seems overwhelming but it doesn't have to be I mean most people start in like the cicd space, you know, first and foremost because it's It's a category and you can kind of focus in on it.

But I would just say pick the thing that is causing you the biggest problem. What's taking the longest what what is causing your your developers and operations guys to fight all the time just find the one thing and just take it one bite at a time. Now just take that one thing go ahead and figure out what's gonna make it better is automation gonna solve it like what or is it communication?

Sometimes it's not technology. It's just simply talking to each other more on a more frequent basis. I mean can be very low Tech but you can just take one bite size problem and and start there.

Yeah boy, that's and and remember when you're on that Journey, you're promoting a strategy and promoting a strategy is a there's a pattern to it that you have to incorporate look for the ideal that you're trying to get to that's your hypothesis. Look for what the direction is that you have to get done and then you're gonna have to repeat that. You know that goal that hypothesis looking for the obstacles and what kind of outcomes where you get and you're gonna repeat that over and over again and get feedback on it while you're on that Journey.

You've got it people bought in. more awesome. Awesome.

All right. Cool. Thank you all so very much for being here with me today.

I know. It's early for some of you and I extra appreciate that. I hope that you all out there in the audience are gonna stick around because we have a whole day of awesome predict sessions and Keynotes and speakers ahead for you.

Thank you all so much for joining us and hopefully see you again soon. Thank you Sharon. Yeah, thank you so much Sharon you bet.

It was great to hang out with you all.