Andi Mann, Sageable | DevOps Experience 2022

Hey, everybody, super excited to be here for the never experience. The strong group. My name is Andy man.

I'm sageable. I'm a global CTO and founder of this small advisory consulting firm today. I'm going to talk to you about devops everywhere that I drive Innovation.

Let's get started. Okay, 30 minutes. That's all done.

So we look I'm gonna see the agenda for now and let's work with some heuristics. Left in devops acceleration, right? We know that we don't research.

I'll show you later on there a little bit later. We know you know, you gotta project your timeline. You'll never get online.

And so everyone goes And without ever actually no hold over the face. And so you don't deliver until later. It's pretty straightforward now with devops.

We all know same phases have happened. But we bring ups and Dev collaborate communicate, right and then we get to deliver faster. And this is the research we've done so devops report or many many others including myself.

I've done research that proves this devops accelerates delivery. so cool thing is shift left works for business Cycles, too. I'm going to share this chart with you this for from yarn Hagen with apologies to him because I redraw his charts because I couldn't find the original dick.

I saw him present this a code in Copenhagen a while ago. Shift lift works for business Cycles you think about the cycle of product? I'm not talking about software products here physical product.

Building coming up with a new source pan coming up with a new widget you introduce you ideate you introduce you grow your Market you mature that market then over time at the clients you start to balance your portfolio between cash cows Innovative, you know rising stars and so forth. I'll talk about Horizon Theory well, So our new product introduction typically looks like this every business has this cycle every business that sells a product or service has a cycle that is like this. Sometimes it's different link.

So for a long lasting durable products and services, it might be the maturity phase is very long or rapid iterations Cycles think mobile tech or social media, for example, and the maturity phase is very constricted. But this is a pretty typical phase approach to product and delivery think about you know, the delivery timetables for a new cassette player. How old am I?

A new audio device and you iPhone and it'll go through this same phases. now when I want to look at a new product, so sometime in maturity I start to look at that and I start to think about well, when am I going to reduce my next new product? You better cannibalize yourself a little bit.

So with shift left, we know that delivery times are short. We know that delivery time is accelerated. And so New product introduction is accelerated.

Now the if you want to do some trigonometry, I guess your military the area under the curve is revenue, right? So you may or may not get less Revenue to get faster. The other thing is you can start new product introduction faster because you've shipped right?

So just heuristically this makes sense to me the idea that if we bring these business Cycles forward if we apply devotes principles, we shift lift. We move faster then we get to introduce new product fast. We get more Revenue in the door faster we get to be competitors to Market with Innovation because we do it faster.

This is very powerful. So that's a heuristic and I'll spend the rest of the session today talking about how this is proved out in data and practice and I'll talk through these different areas. You can read the agenda on screen.

You can certainly read the abstract and I'll talk to you a little bit about devots practices and principles and how they drive this Innovative culture to deliver products and services faster beat competitors. Also by the way, driving security safety and a bunch of other so let's go So starting out. I wanted to find devops like I spend a lot of time on this, but firstly the idea of devops culture So what is culture it's an output not an input.

It's a result of things you do. Right? So the things you have in your Society your group your community your team your company have beliefs.

You have a way of life you operate this way. You work together. That way you behave these are things you do, right?

The culture comes from the things you do if you do do anything. No, we'll be able to enjoy your culture. So to start with culture is a system of doing things.

Devops is a culture devops is a different way of doing things. It's a method. It's a canonical definition not standing times much time arguing this but collaboration communication integration between devonops.

Canonically. I would expand that to lots of other people right devops everywhere. I also believe that it has a point we do this for reasons.

We loved it. We love Tech. I'm a gate for life, but we do it because we get to deliver better software faster.

so canonical definition of devops Pretty useful that's what I'm going to work with. Another canonical definition is cams or counts, right? I hate pronouncing the Ellen that word that's weird.

But anyway, this is devops in action. This is some great people go dominate words amongst them a good mate of mine came up with this idea of culture automation measurement sharing. These are the practices of devops is the things you do to do devops.

So I'm gonna work through those as well. So that gives us a whole bunch of terminology right patterns culture and practices that I think will drive there Innovation. I'll show you why over the course of the presentation.

So we'll talk about things like test-driven development systems thinking we'll talk about that wall of confusion again, you coming out of some some very smart thinking before my time of what devops really means. What is it to do Devils? So I'll go through this.

This is essentially my agenda. So let's start with ideation. This is the first part of an innovation pipeline coming up with the ideas now ideas are sort of Easy by the way.

Everyone's got good ideas. around that but but innovation in sport When you think about the art of innovation and ideation of special you're open spaces, that's a very devopsy thing. If you've ever been to devops days our brainstorming hackathons, right?

These are all team activities. they all work for business ideas too, by the way. So yeah, I've had hackathons on business models.

You don't have to sit there and hack on code to have a hackathon. It also is a team sporting ways of how you get together and do it. So I really believe in small teams right two Pizza teams for Aviation bring experts together.

Train them and squads, you know, get your two Pizza teams your experts to work together on ideation. I'm very technical and specific Concepts and ideas. But then you bring the whole field on the team for the real game, you know, you might train your offensive line your defensive line separately.

If you're a Ruger like me, you might do your your forward pack different from your backline. You can do that in business as well. You take your dba's and get them to brainstorm on efficiency and productivity and then bring them into the whole team building the entire application so that they can contribute ideas right a teen sport, but two Pizza teams work here.

You know, you want to engage across teams across departments even across company boundaries, by the way, I'll show you some data on that break down these silos breakdown these walls of confusion, right and connect teams in connecting teams enhances inside of systems thinking and the ability to innovate on bigger goals on bigger picture goals, if you know your role in the system, you can innovate on stuff that's not necessarily right in your wheelhouse, but you can work with your team members. Um, yeah, and again these small groups these like-minded individuals these experts to brainstorm on the most difficult parts of what you're doing and then coming together really does help you finalize ideas with your all your stakeholders. We get the best contributions from the experts as well.

And by the way bringing in a diverse set of contributors is really important. It is again a devops feature a practice a methodology is you know, this empathy and diversity that we like to focus on and try and do better at diverse participants have more in right they have more empathy for more customers and more use cases. So they will come up with more ideas that will come up with ideas that a homogeneous group will not come up with because they differently that's a good thing.

We want that in Innovation planning. By the way, deeper engagement with a broader Market also in general is a broader pool of ideas. So no Empower all your contributors establish open and self-directed dialogue.

Acknowledge your system experts get them to share brainstorm with others practice active listening to their ideas all ideas regardless of where they come from think about that active listening is really interesting topic. I prime practice that myself. And and listen to all ideas.

There's something a CIO of a large Bank in Australia told me when I was writing a book about innovation. this book I always meet with interns once a month because they don't know what they're not allowed to do. This is the art.

This is another aspect of diversity bringing more ideas and more voices into the ideation. Like we do with devops bringing teams together people together different type of skill sets together and connecting collaborating communicating integrating those ideas. You get more ideas better ideas.

Now, I will just point out ideas are easy execution is hard Steve Jobs said that Innovation is saying no to a thousand good ideas. So be careful about how you rotate Twitter to ideation, but applying different principles were certainly help you. now when we think about delivering those products Then we go different self phases.

Right? So we think about devops practices to introducing new products. I've done this myself in multiple businesses now mostly software products, of course, but the idea of starting lean right Define a minimum set of capability to solve for yeah on the picture on the right there.

You can see the agile method of building a car start with a proof of concept or an MVP. So that means that it's functional from day one. So a skateboard is functional a wheel is not well, we'll sort of function will tell civilization that but a scooter is functional a bike is functional and motorcycles functional right?

It's functional at every step. So you start with a minimum viable concept and establish a minimum set of capabilities to solve for so are we talking about here is test driven development per proof of concept in BP, and then it's alright in collaboration with business with customs and with partners by the way, very agile right getting closer to your business then to your technology part of the agile manifest. Measure and share that success or failure analyze it your measurement and sharing is important in devops.

It's important in Innovation Cycles as well measure what you've done have you been successful have you met that minimum spare? Our customers interested in is this going to help prepare you forward and then you gate the bad ideas double down on the good ones. So we're talking about fail fast and fail forward there.

sharing results or finding the plan working with stakeholders The back Loops continuous feedback very devopsy, right incremental Innovation is super powerful by the way not all innovation has to be radical Innovation. This is rid of approach to incremental Innovation Innovation is also super powerful. And then adjust and deliver change in those phases that increments, right?

So it's continuous Improvement continuous delivery rinse and repeat. It's relative to development. Right?

None of these ideas. None of these principles are unique. to software delivery They're all applicable to all sorts of innovation other delivery products and service delivery and let's face it.

We still have our ideas in devops from manufacturing. Anyway, right lean can man and on chord values so management a whole bunch of stuff. So understand that this Innovation cycle is very much applicable even outside of devops to all sorts of innovation Cycles.

now we talked about cans now. I want to talk to you a little bit deeper on that in some research. I collaboration sharing Drive Better Business results.

This is my assertion the benefits actually increase based on Research. They've done through many years in the state of devops reports check that out by the way, Papa Labs. I was a co-author on multiple versions of that did the research Sharing across boundary lines of supercritical the more you share across more boundary lines the bigger the results the more you share across broader boundary lines.

So not just within scrum team not just between teams between departments between business units even between companies and you get incrementally better results. collaborative development delivers better results sharing known good patterns and known good practices drives business that let's see the data that says that no opinions are very free. Data is harder.

so let's start with measurement. Sorry with culture so cams right culture automation measurement sharing. Let's start with culture.

When we did research with the state of develops report, we looked at different businesses to figure out whether they would doing devops. Well, right how mature were they with their devops. We looked at many different practices including these signature metrics on in terms of meantime to repair mean time to deliver cycle times these sorts of things with the state of devops report, but came up with young 2015 not and we found that when you have a strong devops culture, and by the way, we measured that.

We get better results if you're a higher Evolution business, you have more sharing. This is correlation. Not necessary causation be clear about.

But it does mean that I am more likely to have better evolution in my devops maturity and all of the benefits that go along with that faster delivery. If you're errors in production faster recovery times these sorts of things. If I share patterns and known procedures and processes between teams between departments within departments and even across businesses.

So that applies also to automationly a in cans right? So as we look at these high automate High Evolution businesses, they are more collaborative, but they also have more automation. More applying more automation lifts, your maturity level in the devops stakes and that correlates directly to Better Business outcomes.

So when we look at this chart, for example on the right hand side the high Evolution businesses are rotate more broadly toward automating services at the top end you can see most sellers available for self-service. But then when you get down to who gets a manager control them you get to this great level of collaboration with automation tools that deliver results. So then you get the measurement side, right?

It's really important. I believe in this deeply I'm gonna driven guy. You got to measure what you're doing if you can manually measure that's a start.

If you can manually measure what your system is doing, that's good. But then if you can measure business level impacts and I talk with this about with my clients all the time, you can measure activity and Technical metrics and they can be important uptime availability throughput cycle times Etc. But think about the business metrics right customer a customer retention time on site can't fulfillment card abandonment Revenue per customer.

Same Source sales, right? You can actually correlate that back to product and delivery. You can actually correlate software delivery, too but conversation.

You are able to generate and access both system metrics and business metrics automatically. It correlates very well with this ability to be in that high Evolution bucket that cohort of businesses that perform and deliver software better. And then we look at.

Sharing culture, right? This is the s in cans. When you're sharing this way was saying not just within teams not just between teams or even organizations or departments, but actually between businesses or companies sharing outside the organization, by the way, I've seen this a lot in things like hackathons in things like open spaces at devopsides in areas like a collaborative development.

I mean where I live in Both around but soon in San Francisco, but Boston is collaborative culture has expanded and so you can go to your local wework or a coffee shop and sit down and sit down and work with someone who's maybe not in the same industry. So maybe not a direct competitor, but someone is doing similar thing. I certainly have bought gone through this as an IT person working at a bank working with other it people at different banks.

Yeah, we competed but as it people we had common problems and we shared known patterns and and known Solutions and it made us all better. So when you think about it in those times, it's really quite clear. If you can learn from others in your position, even in different organizations, you're gonna get more perspectives.

You're gonna be able to do what you do better. again, the heuristic is Magic since but again those about so one more thing about collaboration by the way and sharing Is coming up? Yeah is this idea that collaborative development actually helps you align with your Marketplace again.

This is what you need to solve. This is something that applies generally across Innovation. It's a devops anti-pattern.

a known bad thing to do to have solid thinking right. We all know that. Devops is significantly about breaking down that Silo between Dev and Ops.

So that's the anti-pad that happens in Innovation too, by the way. You can collaborate better. Then you get more ideas more inputs, right you correlate with these positive patterns systems thinking brings more people into the environment into the Innovation planning.

They know what their role is in the system. They understand how Innovation their area can connect with other people's Innovation. So here we start thinking about t-shirt people and I shaped people right having skill sets that I can collaborate in within the system.

I know my role in the system, but I can expand to help others in my system as well and they can Flex to help me. He's ready to development, right? We see there and I love by the way this this this picture.

I'm sure you've all seen it a little bit small text, but everyone gets a different viewpoint on requirements, right? If you all read them separately you share a jira with a bunch of different people in different departments and teams in isolation and get them to come back and tell you what it says and you'll be fascinated by the variations. So this iterative element collaboration lets you develop agile in an agile manner that helps build this product and iterative way.

So you get your requirements, right these clear requirements fast feedback loops. When you try out an MVP or a proof of concept is this what you asked for. He's really delivery and collaboration means you're gonna get a better product Market you because you're continuing to review the requirements with stakeholders internal and external.

And you're getting closer and closer and closer to what you want to actually deliver without going on Divergent courses. Remember that chart we chose early the very first slide. I showed right continuous course correction.

That's what agile and collaborative and iterative development. Does it lets you continually realign to make sure you're on target? And so you don't end up actually building a three-seated swing.

When what the customer really want was a tire. I love that so. Collaborative and development does not just accelerate and ensure product Market fit by the way collaborative development also ensures you actually deliver.

their Solutions Sample, we see patterns Oh by office space. This is this is my Generations Silicon Valley hbr, right the parallels are so strong. They were written by the same people so I could swap this out for HBO Silicon Valley meme but this whole idea that you have these barriers and these silos in communication and I get it I communicate well as a technologist a lot of technologists don't so we need thing people like product management product marketing.

We need business liaison a whole bunch of business analysts, you know, it's also aspects of flow and specialization and tea and I shape people that you want to focus the right people in the right area, but you'll also need to have this collaborative Focus to deliver the right Solutions again adults anti pattern is this limited communication gated Communications or where there are experts who tribal knowledge. They don't give up. So that's an antipath.

The corresponding positive patterns of systems thinking you think about the agile Manifesto as well being closer to my business than to my system. So you're really collaborating on that Innovation cycle. And again, there's nothing in any of this which is unique to devops all software this applies pretty broadly innovation even devops knowledge.

Yes. I just said that phrase right? I know geology a lot of devops is a cultural change.

It's a methodology. It's not a technology buy it. It's not a project devops is not a technology.

My you know, there are Technologies which help you do devops reason being even tools are an artifact. They're cultural artifact. Devops is significantly about a cultural change remember, it's the things you do which resulting cultural change.

And so the tools you use will result in cultural change. Just think about that if I'm using a tool that is not shared. Maybe it's a repo only my code is in the repo not sharing not collaborating.

If I'm using jira or GitHub or if I'm using a shared repot here if I'm using GitHub or shared repo like that. It'll almost in my codes exposure to other people. So now I'm sharing right the tool actually changes the culture in some cases right and else's culture.

But so you see for example cloud. Computing very strong part of the devops lenscape let you iterate start small grow big scale with speed and quality so that it works really well for any electronic or digital product or service one trying to live. Using cloud computing to do UB, please and pocs at low cost at speed and quality with security and so forth really powerful.

Using the compute power management repeatable and mundane process and using human power to drive creativity imagination human processes, right? This is also very logical and makes sense. We've done this in devops for a while.

Automation also by the way, improves security where petability compliance auditability reduces errors and risks reduces lead times so much goodness here collaborative tools for collaborative work streams. So sharing roadmaps in jira, everyone knows where we're going we can pivot we can align we can course correct sharing Revenue goals in a Performance Tool like ladders so that we know what our business needs and we can always continually course create. Shared communication slack and zoom and others who all those Broad Town Hall meetings.

So that's common communication. So the Technologies can accelerate Innovation is well. Up and don't forget to bring his along a lot of you will be this going.

Oh man. This is this is great. But how can I do this?

My management won't support me, right? If I'm says a culture as a practice is not 10, right devops is understandable even by managers. I should know I are one you can explain the key principles of collaboration communication integration that will understand in engage your Leaders with Innovation process.

You know, this is collaboration brainstorming in ideation. You'll have to engage them approvals get them early just like we did with Ops in the day of Cycle Show alignment show that you're aligned and aware and part of the system and you're focused on business outcomes. Not just playing with tools or or getting to be old cool code.

Empower the management executive to select the right ideas to fund them. and deliver execute so execute with collaboration show continuous improvement show that it's worth investing start small so that the investment small grow with authority. De-risk as well managers Executives will be very concerned got a D risk this stuff high levels of communication iterative development.

So you don't fail big phase instructions continuous delivery. Also automation will help you de-risk secure known good processes with audits Trails. There's a great way to de-risk your Innovation practice.

All this helps you push back on the ideas that you don't have cost and resource to do Innovation, by the way, push back with data, but push back with trusted advisors, too. Let me know if you need my help. But really no you mckinsey's lights you got this whoever it is.

Whoever your boss listens to because devops freeze up time for Innovation. So again instead of devops report this time from 2017 shows. Devops practices make time for and resource availability to do innovation.

You'll spend less time on unplanned work. Well from the puppet state of Devil's reports. And so you have time you have a resources what else you're going to do with that?

Go innovate. And make sure you break down the silos with integration of your new products, right? I won't go into the whole Horizons model from but understand the teams is a anti-patner for anyone not just a devops.

Like a devops team or devops techn. ology you might need well at least in the short term, but make sure you integrate this long-term thinking in Horizon 3 with near-term delivery and Horizon to and selling what's on the trucker's Horizon one. Because if you don't you end up with another silo.

So you need to plan strategically deliver tactically and bring everyone into both sides of that process Engineers. Our first class citizens in Innovation Innovation is first class citizen engine. So that's my time what I mean is I think I missed a couple of things but this is essentially my summary all of these things help you drive Innovation.

I think I hope today I've shown you the data and explained why that works. So thank you very much for your time did have a couple of questions but I won't have time to answer them. Unfortunately.

So look contact me contact the media sageable on Twitter. I'm on master. Of course as well messed it on now or just reach out and review through textual.

We'll get back to you at the end of the day. Thank you so much for coming and watching my session here at the tech strong devops. Here it's real.

I have to talk to you again soon. Bye.