 Technology is usually not the problem. It's almost always a people process issue. And interestingly, from a state of DevOps perspective, we started studying culture with the first state of DevOps report in 2014. And we have continued to look at culture and the impact of culture every single year. Hi, this is Yoho Sapin Bhartiya and welcome to another episode of Tier for the Stock. And today we have two guests, Eric Maxwell, DevOps Transformation Practice Lead at Dora and Google Cloud, and Steven Kim, CTO of Carrick. Eric, Steven, it's great to have you both on the show. Thanks, nice to be here. Nice to be here, Jan Swap. It's my pleasure to host you folks here. And today the focus is going to be on the state of DevOps report in 2003. Let's just kind of jump into the report and talk about what is the goal of this report. We just finished our ninth year of research and the goal has been consistently to understand what are the capabilities that drive specific outcomes that we're looking for. And so the outcomes that we're all looking for are organizational performance, team performance. We've looked at what drives software delivery performance, operational performance, et cetera. And then we have identified many capabilities that influence the performance in those areas. If we just look at the, in general, the whole evolution of IT space, when I say IT space, I'm talking to the old, very old data centers. I'm in modern in the whole cloud, native SaaS-based space. The things have evolved, things have changed. Also, if you look at the whole CNCF landscape or cloud, native landscape, we hear about new technologies. It's hard for me to keep up with that. Think about organizations, they do want to kind of dip their toes in the latest technologies, the latest jargon, the buzzword, which can be kind of overwhelming and dominating for their developer team. So did you also kind of, was there any focus in this report to actually also understand how organizations are trying to maintain a balance between what's coming new and what's stable that they can use for the next 10 years? Interestingly, we just released what we call DoraCore and the purpose of DoraCore is specifically to take our findings as a comprehensive look over the years and what are the things that we've continued to validate year over year and to formulate the core model. And so the purpose of that is, okay, you want to get started, you want to know what are things that we have found in the research? What are things that are tried and true in ways that you can apply the research to improvement now? And then, if you want to go above and beyond that, you can take a look at the individual years because we study different things, different years. And then you can take a look at the individual models that we produce on a year to year basis. And you can use those to kind of do more experimentation and kind of go into different directions. But the purpose of CORE was to present that view of things that we've found and revalidated many times. Yeah, and those things that Eric's talking about are really wonderfully useful maps for us to go to navigate when we're trying to navigate through the kind of change that you're talking about, Swap. And it's not, you talk about technology change, which we can plainly see, but it's also organizational change that really is what we're navigating in professional services. Also, Carrick is a professional services company, an organization wanting to go to make any monumental change. Move over to GCP, move over to the cloud, move over to containerize, move over to a new way of doing their development processes, cannot look at just the technology. That's important. That needs to be there, obviously. But really, what was really neat for me in the Dora report, and I think a lot of things that Eric, we're really lucky to have him with us, can help us understand better are what sets certain teams and organizations to be better positioned to take on change. One of the things that we have to go and do well in order to help the organization and the teams navigate through that change. And so I would really love it if during this time while we have Eric, we kind of dig into his insights into the organizational team and culture aspects that are covered in Dora, in the Dora report that you can go to see for yourselves. That'd be really cool for me. Can you also talk a bit about what are some of the key findings of this report? I want to look at from two perspective, one of that these reports give us a kind of glimpse of the major trends. At the same time, there may be some gotcha moment where like, hey, we did not even expect that, but I think that it stood out. At a high level, you know, we've kind of identified five key takeaways from this year. One being that you can be as fast, as stable and as reliable as you want to be, but none of that really matters unless you have a nice healthy culture. We also see that user centricity and focusing on the user, so adopting a product mindset and letting, you know, the user drive everything that you do is a key indicator of successful teams and successful organizations. We also looked at documentation again, which I know to some people might be kind of a boring topic, but some of the findings that we have in the way that quality documentation amplifies technical abilities. As an example, we see a 12.8x improvement in trunk-based development for organizations that have high levels of documentation quality, which I think is quite amazing. It kind of turns a maybe a boring topic on its head and makes it much less boring, you know, to people that are looking to improve. And then, you know, we looked at flexible infrastructure, which was a highlight. And so like previously, what we did was we kind of looked at the NIST five characteristics of cloud computing and we asked, you know, are you taking advantage of these characteristics? And we kind of used that as a proxy for using cloud. This year, what we wanted to do was we wanted to separate those things and understand, you know, what role does cloud play? What role does flexible infrastructure play? And does cloud enable flexible infrastructure? And what we found, you know, as practitioners, this is probably a kind of a no-duck kind of mode. A lot of us have been talking about this for a long time, but what really matters is how you implement cloud. And if you use cloud without flexible infrastructure, you actually see a decrease in performance metrics. But if you use cloud by taking advantage of the characteristics of flexible infrastructure, that's kind of where you see improvement. And then we also took a look at individuals that identify as being underrepresented and how does work distribution affect those people? And so, you know, from a highlights perspective, that's, I would say those are kind of the top five. Eric, when I was listening to you, I felt that, you know, it was more about people there, you know, you're talking about moving fast, user-driven documentation. These are all people-centric problems. And I felt, I have seen that technology is the easy part. People is the difficult and challenging part. Can you talk about, when we do look at, you know, this report and then we look at organizations, you know, they are also evolving with the evolution of technology. So can you also talk about what kind of different organizational cultures you're seeing there? You know, you bring up a really interesting point about technology and, you know, with the customers that I work with and I'd be curious to hear Steven's experience as well, but technology is usually not the problem. It's almost always a people process issue. And interestingly, from a state of DevOps perspective, we started studying culture with the first, with the first state of DevOps report in 2014. And we have continued to look at culture and the impact of culture every single year. And so, you know, this year is no different. One of the things that we always look at is a Westroom-defined generative culture. And so this talks about cultures that, you know, have high levels of cooperation, high levels of information sharing that have, you know, low levels of hierarchy, more kind of flattened structure where, you know, messengers aren't shot, so to speak. You know, embracing change, embracing learning environments, these types of things. And we see that organizations that embrace cultures of this type have the highest level of success. I am an engineer after all. Technology is difficult. I think it's definitely the part that we, or the cultural part is a part that we definitely under-appreciate, right? And it's the part that we have developed less muscle and discipline and, you know, sort of socializing around. And so that is definitely where the focus needs to go. There's a lot of headroom for improvement over there. And also the second thing I'll point out is that, and this is also hard for me to accept as an engineer, which is sometimes you have to compromise the technology to account for organizational, you know, weaknesses, right? So these things that you go to work through to try to optimize toward the organizational health and things like that, sometimes you take a lesser technology solution because it's more adoptable and it's more practical for the organization, right? And so it really is an interplay between the two where right now I think the technology is definitely the part that we probably understand better. And a lot of what Eric's going to build and share about organization and teams is things that we can really learn and develop a lot from. Do you also feel that sometimes technology or right tools can bring a lot of cultural changes? I mean, sorry, a lot of practices that evolve from Google itself and do have become kind of cultural norm. So what do you feel about right tools, right technology can actually bring the cultural changes because they empower the teams or they empower, you know, even decision makers to be able to do those things that were not possible without them. That's a great point. I know we're going off a little track here, but I think the interplay between technology and an organization, if I can kind of simplify it like that, for brevity is really an important part of what the DOOR report goes in and helps us understand better as well. But yeah, it goes in the other direction as well. Good technology can go in and help with organizational change as well. So, you know, I've spoken a lot about good technology contracts and good loosely coupled architecture, for example. I mean, loosely coupled architecture is a simple example. Microservices that go in and support project and team structures from a release cadence from a loose coupling from a contractual point of view. Those things can go in the top and provide opportunities for flexibility and visibility and things like that there as well, right? Previously, we were talking about organizational structures. Let's just narrow down and go and look at those organizations inside them. What are the teams, types are there once again through this survey where you're like, hey, these are different kind of teams that are there within organizations and they also once again influence that option of these technologies. Every year we try to do some additional clustering by taking certain groupings and seeing, you know, are there clusters that emerge in the data? And this year we identified four distinct clusters. One being user centric teams, so teams that are very heavily focused on, you know, user value and moving user value into the hands of customers as quickly as possible. We looked at feature-driven teams, so the opposite. You know, these are normally teams that take business requirements and develop features instead of user value. And then we also looked at developing teams. So these would be teams that are really, really heavily focused on like kind of getting the first release of their product out, you know, oftentimes they're associated with smaller companies in our data sets. And then we looked at balanced teams. So teams that do, you know, everything kind of in a more balanced fashion. And so those were the four clusters. And perhaps not surprisingly to this group, the user centric teams and the balanced teams seem to have the highest levels of performance, the lowest levels of burnout, higher levels of team satisfaction, things like this. And so I think, you know, that kind of coupled with the user centric research that we did really tells us a story about designing for the users and how important these things are. Yeah, that's interesting actually, Eric. I actually hadn't realized that these team clusters emerged from the data. Sort of, I thought that they were prescribed, you know, classifications that we would go to, that you had bucketed people. That's very, very interesting that that's what came out. Just a couple of comments on the team types. We strive in our engagements to be what you would call a user centric. We focus on outcomes that matter to the organization. Maybe not at the very top, you know, we're not a McKinsey and Co. We're not gonna advise our clients on business objectives and things like that. But at the top level, where we talk about product velocity and agility, where we talk about quality of service, we are outcomes-oriented in that sense. And that definitely makes sense, right? Because, you know, we're not the kind of organization that goes and says, hey, these 40 things that you have to go and do, we'll go and take that off your shoulders and get that done, a kind of a thing. The thing that I wanna go ahead is, besides that we found success like that, is the developing teams. So, you had mentioned, Eric, a lot of that might be smaller organizations, but also, that also probably represents smaller organizations inside larger organizations, right? So a lot of the times, the way we affect change, even at scale, in the larger organizations, is to start small. So, you know, you've heard them called like-house models or pilot models, where we go and take an idea, we take a small corner of the organization as proven grounds to production, and then we go and scale that out further upon success. And, you know, maybe we cover it here, or the audience members can go and read the report later, but it's pretty interesting. On the, across the four team types, the different characteristics of what, you know, how they tend to burn out, you know, versus how much they find job satisfaction, you know, and how productive they are. It's really, really interesting, and I found it consistent across our engagement as well, which obviously shouldn't be a surprise, on user centricity, and then, of course, the developing teams. And a takeaway for me, maybe that I hadn't thought about enough was, for example, on the developing teams of, while it's exciting and it's fun, that there might be, you know, whether it be burnout characteristics or whatnot, that we probably need to be a little more cognizant of, as we go to make pushes on a small tax office. I agree. And, you know, one of the things that we kind of hypothesized, based on the results that we received, and the clustering around developing teams was that, you know, perhaps the focus was on getting code out, and getting these proof of concepts out, and the focus on things like software delivery, automation, velocity, might be sort of deprioritized, and which might lead to the higher levels of burnout. So that's kind of one of the things that we recommend for teams that might fit into this cluster is, you know, maybe spend a little bit more time kind of focused on the software delivery and operations. Can you also talk about, you know, if you look at some of the lessons, or, you know, what advice do you have for organizations? If you look at those three, you know, set of organizations or these four teams, of course, in different use cases, it's a different approach. I mean, some are like not at all ideal for, you know, some cases, but what would be the ideal approach for organizations to become more productive, move faster, stay secure, and of course, you know, teams don't get burnout? So my recommendation is always going to be the same for all of the clusters, and it is just start doing the work and create a mindset of continuous improvement. And, you know, what we've seen from our research is that, you know, companies that adopt this mindset of continuous improvement are the most successful. I also wouldn't focus too much on, you know, the actual numbers from the metrics that you're collecting, rather think of the metrics as a gauge that you can use to understand where you're at, and then are the things that you're doing, you know, having a positive impact on what you're trying to achieve and the outcomes that you're looking for. I love that reminder, Eric, of using that as a conversation instigator of how should we look at this and all of the wonderful nuances that the DOA research team is putting out is really, really helpful. We're very grateful. It's not only a happy coincidence that the research coincides with what we're seeing out of the ground, out in the field as well, but that last thing that we talked about for me is a pretty good summary along the ways of advice, which is we find a lot of success in user-centric approach, which is user-centric approach, which is talk about end outcomes that we really care about, be flexible about how we go and change our course if necessary to go to meet those outcomes, keep everybody engaged and owning the outcomes is really, really ineffective for us and that breeds healthy teams. And then, of course, along the development route in cognizant of the things that the research want to share and also what Eric advises about don't just focus on getting to the goal and velocity only by any means, but also think about all the common things apply of sustainability and scalability, I think that you need to think about from the beginning as well. So that's a good validation for me today as well. Eric, Steven, thank you so much for taking time out today. Talk about this report and most importantly, those insights and advice. Thanks for all those insights and I would love to chat with you folks again. Thank you.