Nick Peacock: This is the second in a three-part webinar series titled DevOps Disruptors. Across the series, we will be looking at a report by the analyst on exploring platform engineering as an emerging organizational approach and how it may be disrupting DevOps. I'm Nick Peacock.

Nick Peacock: I'm Senior Director of Customer Success here at Cloudsmith, And momentarily, I'm going to be joined by two experts who, between them, have at least a couple of decades of experience implementing and managing DevOps across several organizations. We're going to be discussing, and you'll be hearing about their own journeys and experiences in DevOps and platform engineering.

Nick Peacock: The how they are reacting to changes in environments and changes of business objectives using the maturity model that the d report uses. We're gonna discuss how to assess your organization's maturity in DevOps and platform engineering and how you make necessary changes. With that, we're gonna try to keep it all within the next 45 minutes or so.

Nick Peacock: We're gonna be calling for some audience participation, so please feel free, to join in and answer any questions. A couple of quick plugs. If you missed the first session, please go back and now listen. It was hosted by Glenn Weinstein, the Cloudsmith, CEO who hosted Alan Carson, the co-founder and chief strategy officer at Cloudsmith.

Nick Peacock: And Humanetec's VP of Product and Growth, Luca Galante, where they dug into and debated the points that were raised by the authors of the report. And if you're not already registered for the next in the series and the last rounds you can see the banner at the bottom. It takes place on the 21st of August at 12 p.m. E. T. Either scan the QR code or go to Cloudsmith.com. com. Our VP of Product, Alison Sickelka, and Rob Godfrey, Senior Technical Architect at the Financial Times. Discussing that with the evolution of DevOps and there's going to be a focus to shift to creating internal development platforms and how you offer self-service capabilities developers but on that note, I want to welcome our panellists Richard Vodden who is the VP of technology at Humanising autonomy and Dave Bresci who is senior manager at PagerDuty.

Nick Peacock: Welcome to you both. for taking part. So, Dave, I'm going to start with you. As a leader in SRE and DevOps at PagerDuty, what can you tell us about what DevOps means to you and how did you come about platform engineering as an approach or methodology?

Dave Bresci: Well, I think one of the interesting things when I started at PagerDuty, it was an environment here, it was a lot different from other places that I've been to where it fully embraced, this was years ago, the full source ownership model.

Dave Bresci: So there was, you know, Code it, ship it, own it. Teams were running fully operational autonomous services. And to be honest, that was part, that was gotten to be a bit of a problem. I think maybe when you're in a growth mode. And you're under a hundred developers as we were at the time. It's okay. If you have multiple data stores running around, or if you have teams running their own container schedulers and certain circumstances, but as we were growing, we found that that was not going to be scalable and I think one of the things I did, and that was encouraged to do was to go around and talk to stakeholders and go to, and talk to other folks in engineering managers, senior individual contributors and say like, Hey, what's, what can we do to help, right?

Dave Bresci: Like what can infrastructure do to help you? And so getting that feedback from the folks who are your customers, your internal customers was critical because one of the things that they kept saying was, we want more standardization. We want more paved roads. And that's kind of what we've been building towards.

Dave Bresci: Cause I think sometimes a DevOps model can be, I've heard of some organizations some folks that came to PagerDuty where they have, you know, the self-sufficient teams with embedded SREs. So that could be one direction you can go right as you grow. Whereas you make the teams fully autonomous. But I think what we wanted to do was different.

Dave Bresci: This was to have provided centralized capabilities that could be shared by the rest of the organization. And so that's what we started building towards. And we, you know, progressively we would do customer interviews every year. Last year we started doing developer surveys too. And so getting that feedback internally to make sure that we were on the right track, but also trying to stay current with the trends that were going around in terms of what's capable, what's out there for infrastructure, but also being guided by our vision of what we wanted to provide to the org.

Dave Bresci: It's a combination of all those things. And so I think we stumbled into platform engineering because I think I mentioned to you and Richard before that you went to KubeCon last year and I was like, Whoa, this is, this is what we've been trying to do, you know, and you're kind of seeing it play out and it's an actual thing and there's a discipline and CNCF has written documents about it.

Dave Bresci: So. I think we've been trying to do platform engineering without knowing that it's what the title is, but also, you know, I think the thing I want to say is I think it's important, it's what our organization needs and wants. So I think that maybe to answer your original questions, part of what you need to figure out about your DevOps journey is what is the need that you need to satisfy for your organization.

Dave Bresci: And that could be different. Based on the organization. It could be different at different times for the same organization. That's my two cents.

Dave Bresci: Yeah, it's interesting. You spoke a lot about the kind of internal team collaboration and an aspiration for standardizing and creating centralized capabilities.

Dave Bresci: It sounds like there was an inflection point there. Was that kind of a natural inflection point? Or was that like a formal process and someone stood up at 9 a.m. on a Tuesday? So on a Monday morning say, Hey, we need to do platform engineering or we need to do better. What would that kind of inflection point look like for you?

Dave Bresci: I wouldn't say it was an epiphany of any sort on anybody's part. It was very gradual and it was very gradual depending on the teams too. We had some teams that at first really embraced this, but like take our data stores. We don't want to run a container schedule, right? Like at the extremes, right?

Dave Bresci: [00:06:00] Like they, they, they wanted, they were willing to give up some of their in order to get, to have less operational burden. And to have sort of distributed expertise or have us be able to have capabilities that could be shared across the org. Other teams are a bit more reluctant, right? They didn't want to give up their own ability to control the technologies that they were using.

Dave Bresci: But over time, I just think, You know, you use metrics and you use surveys to show that there's a productivity advantage and there's also a morale advantage to, to make this shift, especially as you're growing, it's just, you can't have, you know, as you're scaling from at the time we, when I started, we were about 400 people now we're like 1400, right?

Dave Bresci: And so from 100 developers to 400 developers. At that scale, you're, you know, at those scales, it just wouldn't make sense to keep going the same way that we were going. And I think now it's, it's not, there's not even a question really. It's like, taking more of our abstract, more things away from us. Give us more centralized capabilities.

Dave Bresci: I mean, we don't, we don't want to worry about this stuff. So I think it's gradual. I don't think, I don't think there was something. That was a top-down or that was sort of everyone woke up and said, like, yes, we're going to do it this way tomorrow. It took time.

Nick Peacock: Yeah. So, I mean, I know I asked the question around the inflection point, but it doesn't seem to be any single point.

Nick Peacock: It was a kind of a gradual thing as you scaled. And, Richard, I know like you and the guys that help humanize on top of your scaling, did you implement engineering from the start based on growth from other businesses? How did that not, I keep wanting to call it an inflection point, but how did that, that journey kind of work for you?

Richard Vodden: We definitely didn't do it from the start. I joined about just over two years ago, which was, I think, three years into the company's journey. So we're now about five years old. If I've got the numbers, right? We're 22 people. So kind of order of magnitude down, from my UR Dave. And traditionally, you might think that actually platform engineering has no relevance at that kind of size.

Richard Vodden: And I'd certainly take that as an argument, even if I strongly disagree with it. I think Dave hit the nail on the head around what DevOps is, the code it, ship it, own it, but it's absolutely what that is about. You know, we're no longer having a dev team and an ops team. That's what it is. It's that portmanteau of dev and ops.

Richard Vodden: An innate kind of. The conclusion of that is you end up having teams that need to have all of the capabilities that that team needs to be able to deliver up to a point. And it's that up to a point where platform engineering becomes really interesting. So one extreme example might be, do you have an air conditioning engineer in your dev team for when the data centre is, I can tell you, no, of course, you don't.

Richard Vodden: And in that particular instance, you've kind of taken the ultimate platform engineering. The approach of, buying a SAS, presumably, I mean, I guess we're probably all using cloud and at that stage, you know, a cloud provider is basically, or even SAS product. Absolutely. That is a platform. And what we're talking about here is building internal platforms.

Richard Vodden: And I think to build on what Dave was saying, a few, there are two parts that kind of, to me, say you are doing platform engineering and you're not just doing engineering, if you saw what I mean, the first one is. That platform team must be absolutely focused on the self-service So what we don't want to do is go back to the days of having you know One team raise a ticket on another team and get them to do some work Like let's say we've got a database team You don't want you don't want your dev team raising a ticket on the database team saying please can you can you?

Richard Vodden: Raise me a database, please. That's that's just an ops team, right? That's not a platform team so what they should be doing, in my opinion, and what I found very, very effective, even at the tiny scale, I'll get onto exactly how it works in a second by empowering the dev team to create a database without needing the knowledge to know how to create a database, you get that standardization that Dave was talking about, because it's the database team that control the bit that creates the database.

Richard Vodden: They're all created in exactly the same way, but you don't get that handoff. So the dev teams get to decide when the database is created and when it is destroyed and when it's powered up and when it's You know, you can add features to it and the other thing which I've found particularly effective and a mark of platform engineering and we see it in saas providers as well Is this idea of inner sourcing?

Richard Vodden: Dave you talked about autonomy and control and I think you know dev teams not wanting to let go of that autonomy and control one thing we've done You are really well at humanizing and also in a couple of other organizations I've worked in are basically open source the product internally You say here is the platform There is the source code if you want autonomy and control you want a feature the platform team can't deliver it in time raise a pr And so if you have that sense of openness and collaboration Combined with that sense of self-service first then kind of an almost complexity firewall Then you're doing platform engineering Even if you're doing it as one guy writing a terraform module that's driven by yaml files, which is very much the stage we're at at Humanizing. That's still a platform It doesn't have to have a fancy gooey and a load of pretty metrics behind it does that answer the question? I think it kind of does.

Nick Peacock: I think it does. Yeah, I, think the kind of takeaway I have is that the principles of platform engineering are not different really to the fundamentals of DevOps.

Nick Peacock: It is still code build and ship it, but it is, it is a shift in the paradigm with the problem you were solving I guess probably back in 2009, probably when DevOps started to rear its, its head, it was to try to provide centralized services. For a whole organization as it scaled in complexity or size platform engineering Is the I guess the older more experienced brother or sibling of that of that function where, okay, well, we've, we've proved that we can build these things, but now the developer teams want greater ownership.

Nick Peacock: They want great collaboration. You, can't have an air conditioning

Nick Peacock: for every single team. So you, you obfuscate those out. And I, I think it was microphones, so to speak. I think a big piece here is how do you, how do you know where to start? How do you say, okay, why I haven't yet sold my Nirvana of DevOps? How do I evolve myself into a platform engineering function?

Nick Peacock: I, I guess the not-so-simple question I'm going to pose to you both is when you start or where did you start?

Richard Vodden: We started, and maybe let me give

Nick Peacock: you some guides for us. I say, maybe give us a guide. Is it, is it, is it tooling first? Is it processed first? Is it culture first?

Richard Vodden: I've never done it tooling first.

Richard Vodden: I'm not saying that doesn't work. It's not an approach I've ever tried. The way I tend to look at it is if, if we are in a situation where we're going, right, we're going to do platform engineering, which is Dave alluded to is not something that's ever really happened. I think platform engineering is more of a natural evolution of what.

Richard Vodden: DevOps is what I look at is the proportion of time, the team, let's assume you're running a team. You look at that team, think, look and measure the proportion of time they're spending on the roadmap versus spending on things aside from the roadmap. John Cutler calls it LODO or lights on doors open.

Richard Vodden: Also heard it called TOIL. And that it's going to happen, but if it's more than the kind of 10 percent of what you're doing, then there's. Kind of an alarm bell there in my mind and you'll start thinking actually maybe we've got too much to do here. Maybe we've got a body of work here that somebody should be giving ownership of and it might be within the team.

Richard Vodden: Even you kind of have a little platform team within your platform team, within your, within your dev team. And, and then it's ticket analysis. What, what is that toil? When I was at EMAD, the huge thing was database snapshot restores. I think we had something stupid like six and a half thousand tickets in the DevOps backlog, whatever a DevOps backlog is and about a third of them were, can you please restore this database snapshot?

Richard Vodden: And so there's, there's a very, very obvious place to start. And that is often the case in my experience there are real pain points that are exactly that handoff that DevOps is trying to move away from. And you can tackle those in an API first kind of way to the extent that we've even, I've even written APIs, which just raised your tickets so that you get the API sorted for the dev team to be able to interact with it.

Richard Vodden: And then it's done manually while you sort the automation out in parallel. Dave, where did you start from?

Dave Bresci: I think one of the things I really like about working in infrastructure, but it also makes it really hard is that you are not only engineers, you're also product managers a lot of times and salespeople and marketers internally because your customers are inside. And you don't have those functions as part of your infrastructure or typically.

Dave Bresci: So a lot of it falls into you as managers, but also onto your engineers, right? Like the program management, project management, and product management functions are all within your org. So my roundabout way of answering this question is, you have to figure out that you asked, which one would you start with first?

Dave Bresci: And I think part of my answer would be, it could be more than one. So one of the first things I mentioned was. I started talking to folks around the leaders around the org, trying to figure out where the pain points are, right? So that's key. You want information from your customer base to understand what it is, like what the high-leverage things you can address can fix.

Dave Bresci: But you know, also you listen to your own team and the expertise you have for folks who, from folks who are, know infrastructure. So one of the things folks on my team were telling me is that this was years ago and we need to implement infrastructure as code. Cause at the time, all we were doing was.

Dave Bresci: EC2 instances provisioned via chat ops and Slack, that kind of thing. And they're like, and I said, okay, well let's do it. So we brought in Terraform via Atlantis and as far as CD tooling. And, you know, when we did that, that enabled us to allow developers to self-service infrastructure within AWS directly, rather than using the CLI or rather than using the console and by doing that, our adoption of AWS managed services and the The, the, the efficiencies that were gained by the developers increased a lot.

Dave Bresci: So that, in that aspect, we started with tooling first. We were like, we have to onboard Terraform in order to unlock these capabilities for our developers. But we also had other initiatives where you're like, okay, where are they, they're like, Oh, our builds are too slow. Our deploys are too slow. That's what we were getting from you know, we want to be able to create services, you know, not take a month.

Dave Bresci: We want it to take a week. Right. So those are the, we can address those as well. So. You can, you can do a mix of both. Obviously, you don't have unlimited folks on your team because there's so much you can do. Sometimes you want unlimited folks, but I mean, I think it can be a mix of approaches depending on what the needs are of your business.

Dave Bresci: And that's up to you to figure out. And I think, I think that's probably one of the tough parts, but also one of the parts I like about the job is that you know, we have that level of autonomy or the level of, you know, we can do the level of responsibility, but also the impact. It's really great. That's what I like about working in infrastructure your impact isn't just one feature you're shipping.

Dave Bresci: Everything, almost everything you do has an impact across the organization.

Richard Vodden: I worked in a place that had a career ladder, and it talked about the impact of individual engineers at different ranks being part of these ranks. And at a principal level, it regularly makes changes, which have a significant impact across the organization.

Richard Vodden: And I'm like, my juniors are doing that every day. It's like, it's a fantastic place to work, isn't it?

Dave Bresci: I feel the same way.

Nick Peacock: Yeah, I, I, you know, I, I, I think that again, that kind of resonates. It sounds like a pair of you where you're trying to solve a [00:18:00] problem. Maybe a transactional problem at scale with the process of building and delivering software, whether that's a kind of distribution to other companies or just internal software internal processes.

Nick Peacock: I guess the I don't want to take the I want to change tact a little bit and say, how has this

Nick Peacock: change that you've been delivering and how has that impacted your need to change to a platform engineering team or whatever kind of name or methodology you put against it? I think in the modern world, I'm not going to use AI as a buzzword here, but with more generative software development.

Nick Peacock: People are using and deploying containers more frequently. You're deploying to community environments pulling and using more open source software than ever before. I think the breadth and scope of software kind of in control and software under use by organizations is just a kind of skyrocket, right?

Nick Peacock: It's, it's exponentially more. Sophisticated, complicated, and much larger. How has that scaled? Not necessarily with the organization in terms of the number of developers or the number of problems. How do you think the the evolution of software has impacted what DevOps is and what platform engineering becomes, from DevOps?

Dave Bresci: I think, if you don't mind, I'll, I can answer first., I'm trying to have, I think one way I can answer your question is you have to have standards. So you have to restrict Richard talked a lot about self-service, but you have to restrict. What that's, what the capabilities are of that self-service in order to provide, you know, you can't provide a platform.

Dave Bresci: That's a platform for everything that anyone can get any software they want at any time because that's not supportable. That's not sustainable. You need to be able to, you need to say, we're going to focus on these things. This is. This is the menu that you get and we're going to, and we're going to optimize that menu.

Dave Bresci: So you get all these things out of the box when you get when you self-service this thing, whether it's software or platform or capability in some way, shape or form. So I think that one of the key things, and again, that's, that was a tough thing to do transitionally, where it was, everybody was used to just saying, I need this technology.

Dave Bresci: So therefore I'm going to use this technology to, okay, now I have a limited menu of things I'm going to do, but they're going to be well supported. So I think that's the key. Is there a cultural transition that can occur where people realize that having this self-supported or this well-supported technology is better than me being able to self-service even though it may not fit 100 percent of my use case it fits 90 percent and I get all these extra things for free, right?

Dave Bresci: It's like it's the same thing as is us get it by buying a managed service from the cloud, right? Maybe it's not 100 percent of everything that. We wanted, but there's a reason why we're not running something, on-prem. There are advantages to it. Most of the time. But in this case, I think that has a lot to do with it.

Dave Bresci: You have to restrict, you have to restrict. And I think the thing I want to add to the self-service bit that's tricky, and I think is part of what's hard about platform engineering is you have to figure out how far to abstract, and that's a tricky thing too, right? So it's not just soft. You can't, you're not self-servicing a hundred percent of everything.

Dave Bresci: There are certain things that you want the developers to not. Care about is inefficient for them. And also the expertise you have is in the house. Like you, the infrastructure team will have more expertise on certain things. So, you know, how far do you want to get? Do you want to get to it, I saw this talk at KubeCon last year from Tim Hanson at Spotify, where it was like, they just have four YAML files.

Dave Bresci: And it's like, one's a build YAML, one's a deploy YAML. And that sounds awesome. Like I want to, but so what it, you know, you know, we're a ways away from that. Right. We're, we're sort of in Terraform module land right now. This is tricky because then developers need to know Terraform, but we want to abstract Terraform away from the developers.

Dave Bresci: We kind of do it's a long journey and then how much bang for the buck are you going to get that? So you have to figure that part out of it, too And I'm not sure I may have taken your question in a different direction Nick so I apologize, but hopefully, I kind of answered it.

Richard Vodden: I think I think so.

Nick Peacock: Yeah

Richard Vodden: Oh cool, I think you nailed it in I guess opinionated self service is what I'd describe it as where you're like, okay You're not just able to buy anything you want. You can only buy the things that we sell. I guess which approach I found to kind of keep it under control is. You have some non-negotiables and you, you, you, it's one of the tenets of platform engineering kind of as a product, right?

Richard Vodden: So we, we don't want to tell people they have to do things. We, we want to compel them, to use it. The platform should be so amazing that everybody wants to use it. But again, you have to do that within certain constraints. So what I've found is actually if you constrain the code repository and you say, right, [00:23:00] you must put your code In whatever code repository provider You must put your artifacts obviously in Cloudsmith because you wouldn't ever consider any other cloud any other artifacts product you must use our cloud account If you're building a sales product and then your alerts must end up in let's say pager duty and those are your four Non-negotiables, right?

Richard Vodden: And then the platform team provide almost approved ways of working off-the-shelf products that get you from Your code repository into Cloudsmith and like you might have right we've got a Python one. We've got a c one. We've got a javascript one and then if somebody wants to do something else, they're free to And that's a great way of giving you a metric that says how what proportion of the organization actually are making use of the products that we've provided, you know, how effective is it?

Richard Vodden: And also, it means that you're not stuck on the rails. You're not kind of [00:24:00] going, Oh, we're only going to use, I don't know, poetry for Python, because that's what we've done. Someone can come along and say, Oh, actually, I think this other Python build tool is amazing. I'm going to give it a try. They try it.

Richard Vodden: It works and there's a clear route to upstream because you've got it kind of you're not building something that's so Tightly coupled that it's got no flexibility at all And then you can elevate that but it will get enthusiasm and encourage it and you're no longer saying don't do that You're saying no crack on Give it a go, see if it works.

Richard Vodden: By the way, we require from an interface between code and artifact there to be a tag on the commit and that tag to match the version number in Cloudsmith, you know, you go, this is what your contract is that you must adhere to and then let them innovate, let them crack on. And then if it's good enough, upstream it, go, this is fantastic.

Richard Vodden: And let them then effectively become the product owner for that product. As it grows they're still like, this was my idea and it's grown up. And that's very, very, very, very powerful. And helps kind of almost present an illusion of freedom if you like, because, by the time you spent sort of 18 months, two years working on these off-the-shelf components, they are so amazing and so whizzy and so clean that actually it's, it's a pretty tough hurdle to build something that's better.

Richard Vodden: It does definitely happen though. And it's, it's, it's an amazing feeling when it does happen. You get a contribution from a team that is sort of two levels of indirection away from infrastructure. But I built this thing that deploys RDSs and only takes four minutes, not eight. You're like, Oh, that's cool.

Richard Vodden: I remember when I emailed, when we got the first PR to our, to our platform, that was such an exciting moment. And that you were talking about sort of cultural things to look for. That's, that's really one where. It's no longer the case that the platform team own the platform the platform team are like the museum curators they're there to sort of help people get around the platform and to make their [00:26:00] experience as easy as possible But it's not their museum.

Richard Vodden: The museum is not the museum of the people. It's not really the platform team's platform. It is the platform of the company if that makes sense.

Nick Peacock: Yeah, it does. It's interesting. What keep coming back to me is that there's an element of maturity here, whether this is kind of a maturity of tooling of the process of organization

Nick Peacock: coming back. Is that kind of culture and process, does one lead the other or does the other lead the other? Like does the culture lead the processes? Does the process lead the culture? And I think that's different for different companies. I'm sure Richard, how you operate is, is different from Dave, but no, no less or no more.

Nick Peacock: I, guess the next question that I'll pose to you both and pose to everyone in a poll as well as how mature do you feel like your organization's processes are. I won't necessarily get you to speak about the good and the bad and the ugly. Or let any external kind of secrets out into the world.

Nick Peacock: But maybe just speak in general in terms of kind of the, the, the mature, the maturity of a process versus the maturity of a culture that is willing to. Hand over the reins to a platform engineering team to solve those problems that traditionally potentially developed teams have tried to solve themselves or wanted to own.

Nick Peacock: I think maybe Richard, this is the maybe first, first punt for you.

Richard Vodden: I think if you have the right culture, you don't need process at all, which is a controversial thing to say. And that's probably an extreme end. And I'm not sure anyone ever quite gets to that extreme. I think. For example, you talk about ownership there, and you talk about the platform team owning problems and solving them.

Richard Vodden: I think if the culture is right, there should be a sense of collaborative ownership between the dev team and the, and the platform team. And they, they, they, it shouldn't be a sense of, oh, this is the platform team's problem. They need to go and solve that 'cause that's not ours anymore. But that's obviously, you know, a, a pretty.

Richard Vodden: Impressive place to have got to and certainly not something I've ever fully achieved and I think process Is a helpful way to provide guidelines and guardrails around Areas where you perhaps can't rely on your culture for all kinds of reasons There might be regulatory reasons why you can't just go.

Richard Vodden: Oh, no, the culture is fine We can do this because you you know, certainly if I said to an accounting system, you know Oh, we're just going to rely on culture. We're not going to do any process that that would not wash. And however, I think if you imagine taking it to an extreme where you have I mean, you've got here fully matured and optimized processes.

Richard Vodden: What are those processes? Are they really, are we now coding my numbers? Have we taken all of the decision-making away from the developers? And I feel like there's a sweet spot or sweet zone, I guess, cause it's definitely not a single point where you've got some situations, for example, our production system has gone down.

Richard Vodden: None of our customers can get to any of their information. That's a situation where you really need a process. It could be as light touch or as complex as you like, but something needs to be there to say, okay, what you do is you do this, this gets you an incident manager assigned. This is what happens after that.

Richard Vodden: And that's about, that's about expediency more than anything else. And then there might be other situations like. We want to experiment with a new way of building Python, to pick my analogy up before and that's something where you can let the culture rely on the, on the process, on the sorry, let the, the sort of naturally evolving process come out of the culture, if you see what I mean.

Richard Vodden: So I think in an ideal world process is culturally led. However, that's an idyllic utopia that probably doesn't exist anymore. And in reality, you know, regulation. Exists for good reason and process kind of has to cover that off also there are situations where sometimes you just don't have time to let the culture work out what to do And so yeah, you kind of do need to do that.

Richard Vodden: Dave Sure with an organization a couple of orders of magnitude bigger than mine. You've got a slightly different view

Dave Bresci: can't say I strongly disagree with you though I mean, I think the challenge for us like if I say culturally speaking we have embraced whatever platform engineering means today or DevOps, et cetera, but what I could tell you pragmatically is like, we just don't have enough folks to implement all the things in the platform that we would like to have, like, I would, is that a process question that I would like more headcount because there are all sorts of cool things that we can unlock for the organization to say like, Hey, we could do all this stuff for you.

Dave Bresci: It just, but there's only so many things we can do with the people that we've got. So I think culturally speaking, people are bought into like, Yes. Provide us with more things out of the box, abstract, more things away from us. Give us mobility to self-service more things, but there's only so much we can provide in any given year.

Dave Bresci: And to Richard's point about regulation, I mean, going through the FedRAMP authorization process has really, you know, like if you say, if you want your platform, your self-determined platform standards to seem less onerous, then go through compliance to regulation process. Cause then you'll look less bad, right?

Dave Bresci: Like you'll say like, Hey, look, at least you don't have to go through all this other stuff. I mean, I think for all the things that FedRAMP kind of unlocked for us, it has added a lot of compliance work that we have to do in our software development lifecycle process, and that does impact. That does, that is, that does impact the process.

Dave Bresci: And maybe to a certain extent, the culture, because we can't, our experience is that we can't. We still encourage experimentation. It's just, the question is when you want to get that experiment into something like a production environment, now it's a little bit more challenging, right? Like there's a lot more things you have to go through.

Dave Bresci: So that does slow things down, can slow things down a bit. So that does, have a cultural impact, right? So as you grow and you make these business decisions, but that's the decision the business has decided, you know, to open up the federal market for ourselves. Not just the federal market, but there's a lot of other customers who are like, Hey, if you're FedRAMP certified, then you don't have to worry about, you know, other compliance or security certifications, et cetera.

Dave Bresci: It's sort of like the gold standard, especially for a lot of companies here in the U S so there's a lot of things that it unlocks for the business. And it makes a lot of sense, but there is an impact on your software development life cycle that needs that you need to acknowledge and somewhat embrace, right?

Dave Bresci: Like there are certain things that FedRAMP has forced us to do. Like. We have a great vulnerability management program. Now all of our, you know, things get patched regularly. People keep their software up, up to date a lot more than we did before. I mean, people would be, you know, three, four years old libraries that they, you know, they hadn't worked on a service in a while.

Dave Bresci: They bring it in and all of a sudden they're spending two weeks just trying to resolve dependencies. It happens less frequently now. So there are some. Some benefits that are provided by going through this, but it's, it's all intertwined, I guess, is what I'm saying, Nick. It's not, it's hard to tease one out, from the others.

Richard Vodden: That is a great plan, isn't it? Well, you're saying, you know, we've got all this regulatory nonsense that we have to go through so that we've got this compliance. If you use our platform, you only have to worry about this bit of it. If you do your own thing. You're welcome to come to the audit with us. See how

Dave Bresci: exactly, right.

Dave Bresci: Cause I think now the problem is folks have to go jump through a lot of hoops to get these exceptions. So they just end up using me. Now, does that make you lazy as a platform provider? It shouldn't, it shouldn't. Right. I mean,, your goal ultimately should be to serve your customers in the business.

Dave Bresci: And so, you know, you just have different constraints to work under. But as you said, it does. It doesn't make, I think it puts the onus on you though, to say, can we abstract more so that, that, that maybe the pain is lessened for those folks that need to, need to use the platform that we're providing because now everybody has to use it, right?

Dave Bresci: So what can we do that's going to have the most impact? Throughout the organization. So you, you know, you kind of shift the way you look at things, but I don't think it's just our mission.

Richard Vodden: Do you find it tricky? I'm sorry, Nick if I can ask you a question, is it given the regulatory position and you kind of do have that organizational mandate where people have to use your platform, how do you stay honest and keep it product-led and keep it compelling and not kind of go, Oh, well, everyone has to use it.

Richard Vodden: We don't, we don't need to. We don't need to make it awesome.

Dave Bresci: I mean, we have great people working in the org. I want to start with that, right? Like we don't have folks who just want to punch the clock and there's people who are really legitimately interested in advancing our platform and advancing the technology.

Dave Bresci: And the other part, I can't stress there's two, it's not just. There's, there's multiple aspects to figuring out how effective you're being. And one of them is, I think, talking to your customers. So developer surveys, interviews with folks, speaking to folks around the org, seeing where their pain points are, that never should change.

Dave Bresci: Like you should always be getting feedback from the users and subjective feedback. So if you look at all the Dora and space metrics stuff, they all say you need that subjective feedback to round out the metrics, but you also need the metrics. Right's. So I, I hadn't mentioned before, so it's like, where are, are we, you know, our deployment times going up or is our cycle time going up?

Dave Bresci: Is like, what can we do to, to, to help fix that? I don't know. I guess it's hard to answer your question theoretically. I suppose you could just kind of mail it in. I, luckily, I, I, I don't [00:36:00] think that's the type of folks that we have here. In fact, like I was, it's hard because I feel like folks wanna do more.

Dave Bresci: And I think that's the challenge sometimes of the like I said before, I wish we had more people because we could provide more to the org because people want to give more, provide more to capabilities as part of the platform. And you know, I think that's the challenge with the, when you're in infrastructure and platform engineering, you have a certain level of keep the lights on work that you have to do.

Dave Bresci: And so if your organization is smaller, the percentage of keep the lights on work that you have to do is maybe higher than you'd like, and you can't invest in the platform capabilities as much as you'd like, and I think that's, there's a bit more, keep the lights on work that comes with a higher regulatory environment, unfortunately.

Dave Bresci: And so I think that's where the impact comes in. And I think that's sometimes where it can be hard to find a good balance.

Nick Peacock: Yeah, Joe, I, I, I appreciate that, Dave and Rich. There's, there's a lot to ask. There seems to be this synonymous piece with regulation breeds the need for platform engineering or whatever you may call it, right?

Nick Peacock: This kind of cultural process and tooling alignment where you're all driven by one North Star-like objective and goal, which is compliance against some regulation. And that, for better or worse, kind of drives the very single-minded view of like, we need to prioritize this piece of our work this quarter or this month.

Nick Peacock: And that's the lead, I think David, you've been talking about this for a number of months with us, around FedRAMP compliance is really important. And so if we could all leverage that kind of single focus to do this organization a lot of these a lot of the requirements kind of look and feel like platform engineering and Maybe just in the last 90 seconds or so

Nick Peacock: Leave people with a bit of kind of practical advice And if I maybe Richard to start with you, kind of in 30 seconds or 45 seconds or less what advice would you give to people or to others or friends in an organization to things better to focus themselves on making something better or by or by making a shift at platform engineering

Richard Vodden: I think the single most important thing is to Have a metric, be it ENPS, be it satisfaction, something like that, which just measures how much your users like your product, your platform.

Richard Vodden: And if that's going up, you're doing something right. If that's plateauing or going down, you're doing something wrong. Dave, I hope I haven't stolen your answer. That

Dave Bresci: was, that was a really good answer. I would say, listen to your customers and don't get hung up on terminology. Because if you start saying like, Oh, I have to do platform engineering, or I have to do DevOps, just make sure it's serving the needs of the business and not the other way around.

Nick Peacock: I love that. I think kind of identifying and using the metric, using developer survey, NPS, build times, whatever it may be, find your Northstar metrics. Excellent. Well guys, thank you so much for your time. Thank you for joining with us. One last thing before we go if you haven't registered for the last in the series you can use the banner below that's just appeared or go to cloudsmith.com. Again, Dave, and Richard, thank you so much. I'm sure we'll be speaking again over the next couple of weeks but I appreciate your time. Thanks, everyone.