PurePerformance - Value Streams – Tying Business Results to your DevOps & Cloud Transformation with Adam Dahlgren

Episode Date: September 26, 2022

In economic turbulent times leaders get asked questions like: “What’s the return on investment of your DevOps or Cloud Transformation? Did we really get better and more efficient? Or did we just blow a lot of money out the window?”Connecting business results with your technical initiatives is what would answer those questions. To learn how this works we invited Adam Dahlgren, SVP Product at Allstacks. From Adam we learn about Value Stream Management, how to align with your top level OKRs and how to improve your DORA and SPACE metrics. Because as Adam says in the beginning: “Inspection is coming especially during turbulent economic times and they will question your investment in transformation projects!” If you want to follow up with Adam check out the following links we discussed:LinkedIn: https://www.linkedin.com/in/adam-dahlgren/What are DORA Metrics: https://www.allstacks.com/blog/dora-metrics/?hsLang=enWhat is the SPACE Framework: https://queue.acm.org/detail.cfm?id=3454124Allstack: https://www.allstacks.com/DevOps World sessions from Allstack: https://events.devopsworld.com/widget/cloudbees/devopsworld22/conferenceSessionDetails?tab.day=20220929&search=dora

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have with me my wonderful guest who's trying to make me laugh right now, Mr. Andrew Grabner. Hello, Andrew. Are you not going to respond to Andrew? How about Andy? That's much better. I wanted to Americanize you.

Yeah, I know. Andreas, what did you do again? I was just talking with one of our famous... Was that your impersonation of your mom? No, way back you said the only person who calls you Andreas is your mom. And you say, Andreas, what did you do again? That almost sounds like a mom thing.

I know, I know. I was actually just talking with her or texting. But it was much a nicer conversation because she's inviting me for or us for lunch on sunday and with us i don't mean you but no i said yeah well tell her i said hi i will there's an old sign there's an old sign on your live sketch with mark walberg and he's at his he's he's sort of like yeah tell your mother I said hi. Like to everyone, it's just weird. Anyhow, so tell your mother I said hi. There you go.

I will. I will. But you know what we should do? What should we do, Andy? We should actually make sure that we are not consuming all the time with our little banter here, but actually introduce our guest. Sounds like a wonderful idea. More banter. More banter. more banter.

Oh, he spoke before we called his name. That's all good. It's not the first time that this happened. We just love pointing it out to make the guests, to throw them off right before they come in. We just, we zing you right there then. Now that you've ruined the show,

we can introduce you. Introduce yourself. Yeah, it goes over. Hi. Hey, I'm Adam you. Exactly. Now introduce yourself. Yeah, it shows over. Hi. Hey, I'm Adam Dorgan. That's it. That's it. We shut it down.

Well, Adam, thanks for being on the show. And I call you Adam because I don't give you another artificial name like Brian gave to me. Really excited for you to be here. I told you earlier that we are, we often, most of the time we get guests because we either meet them in our work or I meet them at conferences. But in this time, actually, you were reaching out to us

because you said that you have something that would probably be interesting for our community, for our listeners. And I said, what could that be? And then you said, well, there is a lot of talk about in organizations after 10 years of things like DevOps and the agile transformation and then moving to the cloud. And a lot of IT organizations are really

have invested a lot of time, a lot of money, a lot of resources. What's the return on investment? What's the return on investment of all the innovation we have kind of sold that comes through DevOps and Agile? And when you said that you have an answer to this, or at least you shed some light on how to better measure the actual impact to really tell organizations and actually the people that support projects

like the DevOps transformation, Agile transformation, which metrics, which KPIs to use to actually say, and actually what we're doing is good or maybe we're really just burning money. And so I really want to hear from you about what do you tell organizations that need to figure out, are they on the right track?

Are they spending the money wisely? Is the return on investment really what they were hoping for with the DevOps transformation, Azure transformation, whatever transformation they call it? And I want to now give you the word, and then we'll see where this discussion takes us. I will take the word.

Thank you, Andrew and Brian. Now that I've ruined your show a couple of times. Great to be here. Adam from over at Allstacks speaking to you from Austin, Texas. I think it's a cool topic. I really appreciate you guys letting me on. Look, you both and your company represent a big chunk of the movement that's happened, uh, in this broader, uh, lane, if you will. And the business backdrop matters a lot. Um, down market has come around that'll not a lot of people, many, not, not a lot of people, but many folks in our broader technology industry really haven't seen some of the tightening that's happening now.

And for those who've been in leadership, you know, maybe one one cycle of it, but it's been a while. And that market backdrop is, oh, we have this this pretty big run of years where budgets got approved for all the transformation work. And then the next, you know, it was, it was do my agile transformation, get my cloud move done. Let's start working on the next, the next iteration of how we work better together. And then there's tools that come with it and there's DevOps that happen. And then there's all sorts of new proliferation of, of tooling there. And really from, from my vantage point, um, and based on my background, I've seen a lot of years where those budgets just kept getting bigger and we did a lot more really cool, awesome things. And some of the inspection is now coming in this

down market that's, that's, that's coming around now. And, and what that means is you've got executive teams who are kind of saying to CTOs, CIOs, hey, you know, we've approved most of your requests for going on a decade, certainly five to seven years. We're wondering, you know, how much better are we for the increased investment that we've been funding for a while. And we're hearing a lot, you know, the, the, these executive teams will say, we're, we're hearing a lot about the metrics that you're tracking. And frankly, many of them might be drowned in dashboards and metrics that they're tracking and they're still sitting there wondering like, but for the business, where are we better? And how are we better? And, and what's driving that. Right. Um, and so that's

where I've got a lot of interest, uh, in that interplay between the software organization and the, and the business and that push pull of, we need to treat this company like a technology company, like a software company, because that is how we will grow. And at the same time, we need to be able to account for what we're doing and how it's making us better or not making us better as it may be in some cases. And so where Allstacks comes in, right?

So I saw a product executive by background and help lead Allstacks. And our angle in the world is really just as an intelligence layer across these, these different streams of data, we call it value stream intelligence. And so we, you know, kind of play with a lot of similar data that, that you guys in your company help generate, right. And, and,

and drive off of and provide a lot of workflows for. And so those questions, the, the dialogue at the executive team, um, that's been the thing that's been coming up in a lot of our exploration is because we're still, we're still small enough, you know, we're just as interested in where might the market be going and what are the executives saying? And, and, and also not just the executives, but they're, they're the champions who work for them, who will end up really driving a lot of technology adoption. What problems are they trying to solve? And what answers are they being asked to come up with that are really, really high overhead for

them? And that's where this thing really sticks out is when CIO, CTO is pressed at the board level, let's say ELT level for show me the alignment of the P1s for this business, the highest level OKR, right? The objective at the top of the tree, if you will. Show me the alignment of our spend and effort, output and outcomes toward those key things. And you guys, your heads are nodding. Like you can just imagine how much work that might be for the director who is supporting the VP, who is supporting the CTO, who's being asked to answer that question. Conventionally, it's let's try to export things from six different systems. Let's do some mappings. And then at the end of it, it's some guesswork to say say generally where do we think we're allocated and that that's sort of the problem space that's just really interesting and i think is ballooning right now because of the down market

that's an interesting problem go ahead yes yeah no i was just i was just wanting to say that, and kind of relating it to my day-to-day work, I mentioned in the preparation of this call that I was just at DevOps Days Boston. That's why I'm actually here in Boston right now as we're recording this. And DevOps has been around for 10 plus years

now. And I think that's obviously part of the question that executives are asking. What's our invest in DevOps and does it pay off? What was interesting this time, there were several keynotes. One of the keynotes was from two Googlers and I've known at least one of them for a while.

We had him on the show as well, Steve McGee, talking about S3 practices and obviously always the topic of SLOs, Service Level Objectives, come the topic of SLOs, Service Level Objectives come up. Yeah. So SLOs is something that is also very present in our day-to-day work, or at least in my day-to-day work as I speak with our users and our community. And I learned something in the last two, three years since I've been talking about SLOs, because initially I always thought SLOs are something like where you put kind of your objectives on technical metrics like you know your response time is obviously important your failure rate your maybe even your memory consumption stuff like this but what I really

realized is this doesn't make sense at all because what we really need to do is we need to make sure that we are understanding what the objectives of the companies are and we need to define SLO service level objectives maybe it's not the right we need to define SLO, service level objectives. Maybe it's not the right word. Maybe we should rather call it business level objectives or simply just KPIs, OKRs, whatever it is. We need to understand what are the top level priorities. And then we need to align the work of both, let's say,

DevOps roles and SRE roles to make sure whatever we do is aligned with our top level objectives. And I work with a lot of organizations. And the hardest thing when I talk with people is they don't even know sometimes what their top level priorities are and how they contribute to it and what type of work they do contributes to which top level objective. And it's just mind boggling, and it's it's but as you said, right, it's now as kind of the market is changing, these questions will come up from top down.

And this finally, hopefully, forces a lot of organizations to really understand, figure out how does their individual contribution really support the top level goals. And then you have to measure it. How did the people in the room at DevOps Days this time around respond to that material? What came out from there? So I think it was really interesting there was I think people understand that it's important that the concept of SLOs and everything is truly important but I think

the practitioners in the room most of them still are completely disconnected from the top which is also the same thing that I've experienced in my last year or two since I've been working with this. And that's why when we now do, I call them SLO workshops, I really say it's great to

have SREs in the room, but what we really need to have in the room is a business representative that owns a critical piece of an application that owns the service that you're delivering. Because without them, we don't know how we can break down the top business level goals to something that we can measure on the app side, on the infrastructure side. That's interesting.

I'm stuck in thought. Brian is a very contemplative face. Yeah, I mean, I think one of the biggest challenges I'm stuck in thought. Brian is a very contemplative face. Yeah. I mean, I think one of the biggest challenges with any and all of this is that we don't usually measure success. We measure failure more. Right. If you think about it, one of the changes in that aspect, which I'm curious to understand how that might apply in these worlds, is you go to any hospital pretty much and you'll see a board and it's days without a safety incident, right? So they're measuring the positive of without

as opposed to with. And I think that same challenge exists in the technology world, because if you are doing DevOps right, if you do have a good set of tooling and you are following best practices you're not seeing it's not like bunny rabbits and flowers are popping out of your organization it's just things are running right it's when the absence of that stuff is when you start seeing the problems so how do you take and quantify and show hey, all this money we spent is doing good because we see nothing. And I think that's, but to Andy's and your point, the idea of what is that business objective? Then how do you turn that into something quantifiable, measurable? And then how do you even gather that data to be able to back it up? That's a tremendous challenge, I think.

We've only touched upon it a little bit in terms of performance improvements. If you take a look at your cloud spend, and I think we got this idea from, I forget who we got the idea from, Andy, originally, but it came up a way long time ago, if I improve the performance of my code or my application, we can have less cloud spend.

That's one little piece, but that's not even directly tied to the business objective right so it's the words and letters you know that we find ourselves uh bandying about i think end up mattering a lot you know uh andreas is like doing those those workshops and and starting with okay what ares? Like, is that the terminology we use? And then does anybody actually understand how that ties back into the business that, that right there, that's probably, you know, a couple hours of conversation on podcasts alone, because if you think about it, like those SLOs, I'm not the expert on the, the, on the etymology of that necessarily, right? But it comes from... The feeling of that comes from uptime.

It's like service maintenance. And that's how it's framed. Okay. So if a DevOps team is really contextualized as the thing that will perpetuate service uptime, and everything that is not at whatever four nines or whatever level you're at is negative, then that's the wrapper they exist in. For me, certainly as a product leader and a company builder, gosh, someday when I lead a nice big company

that's got a whole bunch of DevOps people, I want them to feel part of a software team that is delivering really amazing experiences to end users. And I want them in that context. And I want them to be able to celebrate the fact that they cleared and plowed and planed and then basically fabricated a road or a pipe that everything could move down so smoothly that all the great experiences delivered. And most don't have that. Right now, it's the service piece of the SLO is sort of dangled over their heads.

That's about it. Yeah, and I think too, with that said, there's a lot of people operate within the confines of what they're supposed to do. So we speak to a lot of traditional SysOps people, right? And we're always trying to have that visionary conversation of like, you know, why do I care? They care about, do they have enough compute in their servers?

Are their network switches operating as it's supposed to be? And we're trying to present the bigger picture of, well, what are you supporting? The applications that are running on them. And those applications are then being interfaced by your customers. And you should, even though you're not responsible, you should care at the top what those customers are feeling. But traditionally for decades, it's always been like, I'm SysOps, my role is to care about this. Someone else can care about that. Maybe it's,

I have enough work and enough worry, whatever it might be, could be just the ingrained thought processes. But I think to your point exactly, if you and your role are not focused on where it ends up, you will be at DevOps World, CloudBezes conference. And you got two sessions. They are talking about value stream improvements and effectively using DoraMet the space framework which is great i think Dora metrics is something that that i'm also very familiar with and that we are bringing up in our conversations with with our clients really helping them with observability to speed up delivery and also ensure that their systems stay resilient you have a talk uh it's called Too Many Streams, Tying Business Results to Your DevOps and Agile and Value Stream and OKR Efforts.

Value stream, and you brought up this term in the beginning, is also all over your website. Yeah. Can you enlighten us a little bit on what you do and what you think, what are value streams for those people that are not that familiar with? And how does it really help us to kind of, what we just said, how can we enlighten people?

How can we educate people to really understand what should they all be working on and what should they be proud of in the end? How do value streams help? Yeah. So at a really macro level, the thing that's important to me, setting aside our Allstack-specific platform

and data sources and how we do all the things, it is important to me that over time, we get better and better at acknowledging that pretty much all of the businesses that we interface with, the big collective we interface with, are technology companies who rely on people who write software and design software and test software and deploy appreciation for what it means to deliver great software in context for the end user, for the customer. And so at a really high level, if you have these different prongs of the stool of business leadership, tying a really coherent software organization more closely with finance and marketing and operations,

you know, every, everyone basically who would report to a CEO, uh, you know, I'm kind of hell bent on, on working on that problem space. So in, in value stream, um, you know, it's, it's interesting, my, our world at all stacks you go about four or five years back and nobody really knew what to call it. It started with just like, people are trying to figure out some metrics. Okay, cool. Metrics. Well, talk to the engineers, metrics for metrics, say kind of a bad idea, really not helpful, easily gamed. And early on, what we did was we just went out and spent, our CEO and I, Hirsch, we spent about a year just demoing to every senior leader we could possibly meet at pretty large, we'll call them mid-sized to enterprise companies, and exploring the problem space. And pretty much what we found was metrics for metrics sake. Yep, everybody agreed.

Really nice to have, not the painkiller. But context around how the specific initiatives that were reaching a board and executive team level, how those were going, where the risks lied in those areas, what the technical roadblocks would be for you to accomplish those goals. Those are things that they were really hungry for. And it turns out that a really good composite of all the metrics that provide signal up to higher levels, if you can do the mappings, can give you a lot of data really fast to give you a sense for, is it getting better? Is it getting worse? And so then we started to unpack

that, go through what data streams might be accessible. And we're adding more by the quarter. But really start with, where is work happening across these technology teams that could give you a sense for, am I on track? Am I off track with the things that I actually need to traffic to the end state, to the final, final deployment state and maintainability state for my customers? And so that's the world I've been living in going on five years now. it has now really with value, with the value stream concept. So taking these different data sources as an overlay and tying it back to business value and not solely talking about, you know, just a technology, uh, lane, just a

technology number. Right. Um, it's, it's easy to argue that a lot of the metrics that many people are oriented around are things like velocity, right? Things even like a more, maybe a more, um, useful now, uh, thing to look at being, uh, cycle time for code reviews, right? Growing then into the DORA metrics, which are very important. And the ability of Ms. Forsgren and that team to bring that into the mainstream and for Google to push it, we all know it is getting a lot of airtime. And then that grows in further into space, which I think space is fascinating. The space framework is really fascinating. And yeah, another plug for our CTO's talk at DevOps World, we're big believers in that really holistic, more business contextualized

view. And also individual, not just teams as widgets, but the individuals and the tone of that team and how capable they are together of, of achieving your goals. We just think that the space framework has great legs. Um, I'd love to know, like when you're at DevOps days, this last time, how close are we to, you know, Dora kicking over to space more formally? Is Dora still the linchpin stuff people want to talk about? At those meetups, is space starting to get a lot more attention in that room? I'm pretty interested in that. Yeah, I think space. Thanks for bringing it up.

The talk was only about Dora, to be honest with you. I haven't heard space there, but you know it's a single observation point that i had from this conference and i also didn't have uh i mean i had many discussions but i'm sure it was a topic somewhere but i didn't i didn't see it i didn't hear it um also the two googlers on on stage they were definitely pushing pushing dora um hey, can you go into what DORA is briefly? Obviously, I have no idea what that is, and I'm sure a lot of our listeners don't. Oh, come on, come on.

DORA? I know DORA is an explorer, and, you know, that's about it. Exactly. No, DORA, it's basically the four kind of metrics that the DevOps Research Institute came up with. It is lead time. So I always, Brian, if you remember, maybe one of my slides where I have DevOps and SRE

kind of holding hands, I always say on the DevOps side, you have lead time for change and deployment velocity, the two metrics. And on the other side, on the SRE side, you have change failure rate and time to restore service so these are kind of the four metrics that tell you how good are you in delivering software and how good are you to keep your your system healthy and resilient so these are the the four

dora metrics and um they've been you know dora has been as as Adam said, you know, acquired by Google, I think it was this year or last year. And it plays pretty well, obviously, in what Google has been kind of promoting over the years with their SRE initiative. What was really interesting, and this was also a comment from one of the guys on stage, he said he didn't know about DevOps until two years ago when he went to his first DevOps conference and then he listened to what DevOps is. And then he said, well, this is what we've been doing at Google anyway, but we just didn't call it DevOps for them. It was always site reliability engineering. And he also made a good point.

Don't get stuck on the name. Get stuck on what you actually need to achieve. And I think this also comes to your point, right? You want to obviously increase velocity, but you want to make sure that what you're doing to achieve. And I think this also comes to your point, right? You want to obviously increase velocity, but you want to make sure that what you're doing really supports the business. And this, again, for me, is so interesting that

we haven't, it seems we really haven't figured out how we connect. I think we tried to close the gap between dev and ops, but it seems we haven't closed the gap to the business. And this is what we need to do. What's funny is like, and you can't,

things like business operations, that already exists as a word, as a term, right? It's completely taken, right? You start to unpack, oh, what might you call when you tie corporate level objectives that make their way into a product planning phase that then eventually make their way into something that gets designed and built? What would you call that? It turns out that if you go to sort of the definition of the value stream concept, that that's the closest that, that I've really found. And that's where we all stacks and myself have kind of hung our hats for that

exact reason, because a lot of the other words would be very jumbled if you tried to use them. So should we call it value ops? You know, I've actually heard value ops bandied about, you know, um, and I've, I've heard it used in, in a number of different flavors. Um, and maybe something will emerge on that front, right? That remains to be seen. Uh, I'm not necessarily the one forcing it to be called a certain thing. What I, what I can say is that when you, when you unpack the

spirit of it, right. To the leaders of the, of the, of the teams and the companies, they say, Oh my gosh, yes. I have a technology team that largely feels, um, disconnected from business results. And I have business leaders, marketers, sellers, operations, people, finance people who are saying, wow, we spend, we spend a lot and put a lot of attention and effort into this technology thing. And it's hard for us to gauge what to expect what's coming and when, and like, there's that third rail out there of, of, you know, committing to dates and, and, and, and how hard that really can be. And it is really hard. I honestly think, uh, what we hear, what I hear in, in engagements with, um, with large companies is like, they're just trying to get directionally

some sense of what to expect and early detection when things that they do expect are not as they seem. Um, so it is still, it is still sort of at that level, not at a micro inspection level, so much as directionally, are we on the right track that we have decided for ourselves? And, and are we, are we putting our dollars in the bins that we've said we're allocating toward? That's a fascinating thing to turn on some data for a CTO, CIO, CEO, where they're saying, yeah, these are my key initiatives. Look, there's an OKR that has mapped its way into JIRA, or ADO, or something like that. And then I've got code being written here, and I've got deployments happening over here. And when you really go and look and tie these all together, you can see that the deployed work

on a quarterly basis is 30% associated with those top objectives when those executives might have thought it would be 60, 70% allocated. Even that line of sight is possible now. That's kind of what we're working on. And now, you know, we kind of live in that planning through to deployment phase and are always expanding in both directions over time. But the lights can be turned on at that level now. And that's a pretty cool thing. And if done right, if the spirit of that is done right, it does bring a DevOps team closer to the folks who are actually writing the Greenfield products

and closer to the folks who are actually writing the greenfield products and closer to the folks who are planning the stuff. And then brings real context to the executive team. The upshot often is plenty of times where we've noticed, oh, executive A over here from the business side just suspects that nothing's going on nobody's home on the technology side and that's often not the case it's actually let's turn this data on tie it all together and allow them to advocate for themselves and gain the respect that they deserve for what they are bringing to the table um So it does cut both ways. Hey, quick, a couple of questions. I know obviously with Allstacks you have a product that helps organizations to kind of connect all the dots. Do you think a product is enough? Or do

you, when you approach organizations, that you really need to consult them, that you really need to sit down with them and actually have a conversation with them. Because that's what I see in my SLO workshops, that a lot of light bulbs light up when you actually bring the business into the room with DevOps and SREs. And it feels like just selling them

just a tool maybe would not be enough. Yeah, long-term mindset over the rest of it, honestly. Being able to lead with data to frame a conversation, that's maybe what is new because enough years, decades have passed in the agile into DevOps transformation. The tools have been built to empower all the different steps along the way, all those different individual contributor roles to accomplish their tasks. And now those have become super platforms, as you guys know.

So now that all that data is available and can be tied together, and there is such high signal there, you can turn the lights on at a couple levels higher. It's two and three and four levels higher than the individual contributor that then can reframe the conversation. And when you pair that with, I would argue that it's always been a mindset problem first, a willingness, mindset, openness thing. But when you pair the mindset approach with some very real baseline data, your current state actuals, it's a little bit more to work with. And that's exciting.

I think with the teams responsible for doing the work, obviously they're going to do their part to achieve the goals. I think the other half, and I'm asking this in terms of, is this one of the challenges you see out there, right? Is from the top half down, from the business side to the tech side, quite often, I think from the business aspect, maybe you have your quarterly company meeting where they review the latest stock or financials.

And to some people, it means something. Other people, it doesn't. It sounds like this requires a lot more of an effort from the business teams to engage and show those results and show the rewards that the company is reaping and how that can help out the regular to everyday workers uh to that so is is this a challenge or is it pretty easy to get the buy-in from those business teams to find ways to engage the teams in those when you find i say find but sometimes what it really is is establish a a cross-functional thinking engineering leader a vp not not even always a cto like a vp a director someone on the um eng ops side somebody on the pmo supporting the the technology team when when you get someone who can then recognize, all right, there is context that needs to be brought from the business and access that needs to be requested. And then there are also stories and context that needs to be wrapped around our technology work to then be relayed back.

And you start to get those folks who are inclined to do that and haven't had a good way to approach it yet. Um, that's where a little bit of magic happens. And in every company like yours and anybody around that size or much bigger, there are multiple of these people. They just need to be found. It's about getting to them and activating them from there. The, the, the newness that the difference, it just, it hits different to say, here's where we are. Here's the context of how things are going. These are the more business minded business, uh,ied objectives. And here's what to call out in terms of what's not on track,

what we need to zoom in and focus on. That, again, is a little bit, it's a mindset thing. It turns out that in almost every org, there are at least a handful of these folks. They just need to be activated. That more than, you know, they just need to be activated. Um, that, that more than, you know, it's not a sales leader, uh, getting to a level of credibility with the data to come to the engineering team and then have this two-way conversation. That's absolutely not it, right? Maybe someday there's some, some big transition into the future with this big, big, big cross cross

cross-functional generalist type person that you see, but it doesn't need to be that right. It's actually enablement for the technology team context for the work that is being done. The, the investments that are being made, brought back to the business team. I just think about like knitting them tighter, more tightly together and making sure that like the stakeholders, stakeholders for technology teams often feel like

if they pray, if they're, if they're asking a certain way, they're undermining. And, and if they go sleuthing about to try to get smart on it, they're also undermining or they're just sneaky or right. And then also there's the,

there's the, sometimes the feeling from, from business teams of like, well, you know, just trust me. If you ask me something, it means you don't trust me. And really like, if we're, if we're not focused so much on highly technical things and actually rolling them up to, to strategy and business choices and like directionally, we need to accomplish this thing to ship a feature

and you can focus on it like that. You're not getting too technical. You're at a place where there is good enough context and shared understanding to have a two-way conversation. And then you invite the two-way conversation at that level. Wow. A lot more than I was expecting on that. That's awesome. Thank you. I, you might say that like, you know, on the, on the, is someone doing like some consulting and are you deep into these kinds of like, this is where I live. I exist in this interplay, you know,

uh, cause it's hard and messy and ugly. And usually it involves very well-intentioned, very smart people who are really just stuck in old ways of thinking between business and operations and technology. You focus on your job, I'll focus on mine. Hey, one maybe final question, because I know we are kind of getting closer to the end here. Looking at our typical audience that we have here in our podcast, I think a lot of them are listening to Brian and myself because we are and have been in the performance, engineering, and observability space for for quite a while um we have a lot of observability data right we have data from

end users through real user monitoring uh all the way down to your host met to your memory consumption whatever it is um what and i and i know that you know looking at some of the stuff that you're doing, you're extracting data from different tools, from your DevOps tools, from your monitoring tools. What is it? What type of data do you typically extract from observability platforms that then actually

give visibility and then kind of connect? What's funny is as we talk about how to frame things in a more positive, growth-minded way, right? If all you're doing is bringing back escapes or we had a critical P1, a SEV1

that got trafficked back through and that was where everybody focused and that's the thing that's being contextualized. Um, that's not the whole story. And so for, for us roadmap wise, what we're really excited to do more of is, Hey, here, here are the areas of the platform that are actually interacted with in the, in the most positive ways. Positive is a very broad generalization. But here from a performance data, here are the places where we have really high NPSs that have been just humming for a long time

without any real occurrence of problem, where we've been shipping new functionality, where we see more and more and more interaction because because there are user data layers that can be tied in with the performance of the applications which i think is that's the like the coming thing from a where does observability meet observability and performance meet like customer happiness, which I think that probably your listeners are pretty hungry for because they've really not been able to be in that context. And admittedly, like we all stacks and like everybody else in our space haven't all built

all of that yet, but that's the story goes there, right? That that's the pathway that, that you take where you can tie things end to end. Um, and I'm certainly like hot on the trail, uh, to get that, that part of the, of the story tied up, um, to be able to say, Hey, look, your, your, your operations team, they're actually the stars for this part of the application for our 80% of our most valuable usage is coming from this thing where we haven't had any issue in two years. And oh, by the way, we've been able to layer all this new functionality on top of that place in the application without any incident whatsoever. That is something that should be able to be celebrated. It's like a direct line to the business. Awesome. Brian. Yes. What is Dora? Say that again? What is Dora? Oh, what is Dora? Yeah.

What is Dora? I just want is DORA? I thought you said, what is STORA? What is STORA? I just want to make sure you learned something today. Yeah, DORA is four metrics that have been proposed up and adopted by Google, but I forget where they originally come from. I can't name all four of them at this point because I didn't write them down. But you have two from, I think, the SRE side and two from the DevOps side. Is that my... That's the way I present it, but I think...

Just regurgitate. You get a B minus on that. Okay, I'll take that. I think the only time I got anything below a B was in college when I blew off a class. So I'll be happy with a B. I didn't get a C. This has been fascinating.

It's funny. Andy introduced this whole beginning of the show. You came to us and we usually find our own people. And a lot of times people coming in are just, oh, yeah, I wrote a book or this or that. And we always look at it skeptically. But we looked at this topic and we're like, this is an interesting topic. And it really, really was really appreciate this information. This is thrilled to do it. Yeah. Really thrilled to do it. Thank you.

Thank you for making the time. I appreciate, appreciate all of your listeners. Enjoy being tangential overlapping in, in this, in this data space, certainly appreciate all the things that you guys in your company have done to advance the concepts. And yeah, I mean, we'll, we'll be out there. We'll be over at DevOps world. Hope to run into some of your people if you guys aren't going to be there and, and more of the DevOps conference circuit,

certainly as the world opens back up a little bit, that's exciting and fun. Yeah. So, yeah. And we will make sure for all the listeners that are still listening in, check out the links. We'll definitely put links to DORA, to Space. DORA and Space as well.

And also, obviously, to AllStacks so that people can see what you guys are doing to your sessions at DevOps World. And yeah, I think in the end, the message for me is whenever you build something new, always make sure that they understand who you're building it for, what is the business objective, don't just do things without knowing that it actually has an impact to the bottom line or to the top line, however you want to call it. I think that's really important. And yeah, that's all I have to say. Adam, maybe last question.

Social media, LinkedIn, we will obviously post that. Are you also active on Twitter or anything else? You know, my tweeting has consisted primarily of complaining about the Buffalo Bills in years past. So I may be picking up the tweeting again with the Bills playing better. That might be something coming hot. I've been terrible on there. LinkedIn for sure. And yeah, mostly I do the LinkedIn thing and lots of podcasts.

So you're originally from the Buffalo area or upstate? I am. Yeah. I'm from 44 miles due south of the stadium is how I like to say it. That's the landmark, right? That's the center of the world up there. Yeah. I'm from the middle of the middle of nowhere, like the middle of the forest in Western New York.

So. Nice. All right. Well, it was really awesome to have you on. Thank you so much. Thank you for checking us out. And, um, you guys have a, you guys have a great, you guys have a great podcast and a great audience and really appreciate the shot. Thank you. All right, everybody. We'll see you next time. And, uh, thank you. We'll talk to you later. Bye.