 All right, I think we can go ahead and get started. Okay, so I'd like to thank everyone who's joining us today. Welcome to today's CNCF webinar on Lean DevOps, Building a Culture of Delivery. My name is Terry Lee. I'm the Lead DevOps Consultants at Media Consulting and CNCF Ambassador, based in Johannesburg, South Africa. So I'll be moderating today's webinar and we would like to welcome our presenter today, Carl Campbell, CEO and founder at CTO.ai. So before we get started, just a few housekeeping items. During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your screen. So please feel free to drop your questions in there and we'll get to as many as we can at the end. And please note that this is an official webinar of the CNCF and as such, it is subjected to CNCF's code of conduct. So please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinar page. With that, I'll hand it over to Carl to kick off today's presentation. All right, thanks, Harry. Thanks for everybody who's joined the call, the webinar here. So just as we get started, I wanna make sure that I set some expectations about what you can get out of this talk. This is not necessarily a technical talk. So if you were looking for more technical details, we're not gonna be diving into any command line today, but I do have a follow-up talk that I'm working on to try to communicate some of these concepts in a more technical way. The focus of this talk is obviously building a culture of delivery using Lean DevOps. And I'm gonna walk you through a lot of my experiences and my thoughts as I try to advocate for accessibility of intuitive DevOps tools that help us all to build better software. So just getting started here, a little bit about me before we get started. So as Harry mentioned, I'm the CEO and founder of CTO.AI. What's good to know about my background and my experience which shapes my worldview is I have a very, I'd say, non-linear path where I have gotten in my career. I'm self-taught as a software engineer and an entrepreneur. I dropped out of high school to pursue tech. I started my career in the very early shared hosting days working for companies like Hostopia, which is white-label shared hosting back in 2002, 2003 for telcos. And so I've watched DevOps evolve from this early days of sort of FTP into where we are now. I've also spent an equal amount of time in my career on the front end and the back end. I spent a lot of times in the early days of Mootools and Node.js, but I also was very involved in early Linux open source work as well. And over sort of like the last five years, I've helped maybe 25 different startups implement some form of DevOps. And that's a big part of what is shaping the presentation that I'm gonna offer today. I've also worked at larger organizations. So for example, a company like Zillow who acquired my last startup. And so I've had a pretty decent amount of experience across different sizes of businesses. But what I focus on a lot in my work and in my practice, obviously as an entrepreneur is advocating for the interests of much smaller organizations. And with that comes a level of efficiency that's required, shall we say. And DevOps is a great platform for that. So a little bit about CTO today, just so that you understand what we do and why this is such an important thing to us. We provide a platform that enables developers to create and share workflow automations leading the command line. The idea is you build this workflow and it's using a container. The container then works in anybody's CLI, but also in Slack sort of an isomorphic workflow is how we think about it. You can publish it to our platform. It's instantly available to your whole team, which means that senior engineers can now help junior engineers who are joining the team be more effective. This helps the business because you're able to get access to a broader base of talent and aren't competing for talent as much. And at the end of the day, what we advocate a lot is for DevOps engineers and senior engineers to be a bit of a, what we call a 10X multiplier or 10X engineer. It's not one person who's 10 times better than anyone else. It's an engineer who helps five people be two times more productive using technology. So what is DevOps? I'm going to just frame this out of the gate so that my views are understood. I subscribe quite directly to some of the things that AWS says, DevOps is philosophy's best practices and tools. I like to think of it in that order. My belief is that the tools exist to immortalize the philosophies and best practices of your team. And I think often a lot of times we read that book backwards. We start with the tools and then we try to work towards the philosophies and best practices. But I like to clarify that out of the gate because it really informs why I start with the idea of building a culture of delivery and then work towards tools in how I think about this. And obviously we all know the impact, 200 times more frequent software deployments, 255 faster lead times or 2,555 faster lead times. One of the reports that I often will point to also at the same time when quoting these things that I think we mostly all know is a report called The Developer Coefficient by Stripe which goes on to touch on maybe the less glamorous side of DevOps. It says things about like, there's $300 billion lost every year in developer productivity in large part due to legacy software but also complex tools. But more importantly, it really highlights the interests and the needs of DevOps in organizations. And I think this quote's really great. It's not just how many Devs a company has. It's also how they're being leveraged. And so that goes back to that multiplier that we can see when we use DevOps. So setting the frame as I advocate for early stage and early stage with DevOps, the early stage of a business, the early stage of a team has lots of challenges and let's just go through them real quick. I've been through all of these many times. I mean, hiring is always a challenge. It's a challenge everywhere but it's certainly a challenging organization and an early stage organization. But in early stage organization almost everything is a first. You're learning everything for the first time together and success is often implemented bottom up but it's measured top down. And this requires a lot of accountability but also initiative from the engineers to go out and explore tools, best practices. And it can be really hard if you start with tools and then work towards best practices, especially when everything is a first because there's an a shared set of philosophies and best practices that emerge in an early stage business. Most of the innovative tech that these early stage businesses are implementing is quite time consuming and complex for them to wrap their head around. And ultimately in early stage business you just never have enough money especially if you're on the venture track because you're always working against some runway. And so it's hard to just spend more money to get more efficiency because you really and so when you think about DevOps it really can act as a differentiator in how companies implement their success. So the current state of DevOps is that it is fragmented across many different tools and technologies developers have been tasked with workflow automation and it burns valuable time that can be used for shipping features that customers love. And I've got my little guy with me here guys so we're just gonna try and work through this right now. You just jumped into my office. And this is kind of what it looks like. I mean, this doesn't even dig into the huge amount of open source tools that are now coming out of the CNCF and the Kubernetes ecosystem. But when you think about this it can be quite overwhelming for a developer to think about how to be efficient across this many tools, right? So what are the DevOps challenges that we're really tackling? Yeah, it's a dinosaur. Many companies struggle to adopt DevOps best practices and DevOps tools are more complex than ever before. And as a result, what I think is that most startups it can feel like a snake swallowing an elephant. So how do we tackle this? How do we make it easier for these very powerful tools to be available in earlier stage businesses and actually realize their full potential? DevOps evolves over time. And what's really clear to me from being at different stages of businesses is there's sort of this adoption curve that's really important to understand when you're thinking about implementing a DevOps culture. In the early days, you start off with a smaller team and the number of developers is quite low but the DevOps efficiency or the inefficiency is also low. So your efficiency is high. You have things like source control, server management, cloud management and as you adopt more tools, ultimately you add more complexity to the process. And that can create inefficiency. So what do we need to do in the beginning as we're considering the process by which we implement DevOps over time? Early on, you're flat, you got a Kanban based organization. You evolve into more of a matrix or agile driven organization. And what I think a lot about when I'm adopting DevOps in organization is how do I realize that this is the journey that I'm going on and how do I adopt things in time based on the organization's needs? When I frame it like this for people, I think one of the things that I've seen with engineers is it really puts the whole journey in context and it helps people to not, to obviously like be mindful of things like security and compliance or governance and policy but obviously like front loading that in your journey to adopting an end to end DevOps tool set can be quite challenging because in a flat and Kanban organization information flows very differently than in a matrix or agile oriented organization. So if I were to state the problem that I see out there within DevOps, especially for the early stages, 300 billion loss in developer productivity every year and access to developers is now classified as a bigger threat than access to capital by most businesses according to the strike coefficient. The technical leaders who are building tools and supporting engineering teams know that it's critical to invest into the workflow that their team requires for work and by workflow I also just mean generally tools but it can often be too time consuming especially in the early stage to ad-licate critical resources to doing it right. So how do you survive in that situation? For us the way we've tried to do it is make it really easy to automate automation and intelligence into a workflow. We do this with something that we call ops which are essentially an end to end operation that allows anybody to automate a thing very quickly and that sort of creates an experience across the developer lifecycle that's quite consistent. We've also tried to make it very accessible across the command line Slack but also CI CD. So these things that we offer on our platform called ops are essentially these developer workflows, developer experiences that can bridge the interfaces that developers use and someone who's more technical can adopt tools at the CLI level. Someone who's less technical might adopt it at the Slack level. But ultimately what we try to do and the key thing here that's a win is we try to abstract a lot of that complexity behind the scenes so that the developer can just stay focused on the task at hand and they don't end up going down a deeper rabbit hole trying to work with the tools than they do with solving the actual key feature that they're trying to deliver. So the idea here is trying to expand that idea beyond CI CD Slack and CLI to really embrace the model of what are the best practices and the philosophies that we want to immortalize into our tooling layer and how do we make it as cheap as possible for our teams to do so. I think when you approach your tooling in that perspective, when you start philosophies you start with best practice and then you immortalize them into your tools and you deliver them in a very accessible format to your team whether it's CI CD, whether it's GitOps or ChatOps whether it's your CLI ultimately you now have that leverage point that we were talking about earlier and that's what enables you to sort of 10x your team and that one developer can make three or five developers two times more efficient because they've solved the harder problem and then delivered those philosophies and best practices into the tools. So this brings us to this idea of like building this culture of delivery and there's a number of things that I've tried to really embrace as I've learned these lessons over time. I think as an organization grows it's really easy to add more process add more tools, add more complexity but in doing that you ultimately are taking what I think is the easier road what's harder is to try to stick with simplicity longer try to stay leaner longer try to add less complexity longer I think that really takes a level of intention and really thoughtfulness to do that and I think that's often the harder path and I really try to encourage people to do that there's been thought leadership on this for a long time people like Dan McKinley who've talked about choosing boring technology the idea being that you have three innovation tokens spend them wisely. If you spend it on your database or on how you deploy an application you don't have that innovation token to spend in other places like a customer facing or a business facing item. So in my mind a lot of things in DevOps should be relatively boring that doesn't mean they should not be enjoyable to use but they should be easy enough to use that they feel like a commodity. The other thing that I think a lot about is how do you set expectations for people who are joining your team whether it's at the early stage the later stage. The more complexity you add the longer it takes for somebody to deploy code the experience that they have setting up your tools really dictates to them what are the philosophies and best practices or therefore the expectations in this company. So in most startups that I've worked in or started we try to have this rule early on where everybody deploys on day one and the reason that we would prioritize that even over things like some of the administrative work is that I want you to know that when you join this development team you're gonna be very successful at contributing to value that customers are gonna see and if I can set that expectation on your first day it really does a huge amount of good for the holistic culture as the company grows. It's often obviously a very hard thing to maintain in the long run but it is sort of like the intention or the goal of every good DevOps practice. I think it creates a platform for the success of people who joined your team and that's ultimately how I think about DevOps. And one of the things that I think is often missed in organizations which is maybe not so much DevOps but falls a little bit more in a product management is that as engineers we often don't have a great ability to estimate things accurately and this is because most of the systems we work with are complicated. We also have a hard time sometimes clearly articulating what the impact of a contribution might be. So like what would the impact be if I go and automate this GitOps pipeline? So what I really try to encourage engineering teams to do is not just estimate things but actually communicate a more complex model for how they communicate priority. And I think of this as prioritizing your best work. What I like to try to get people to do is communicate impact plus confidence divided by effort. It's because if you can communicate the impact that something has and the confidence that you have that it will reach that point of impact and you divide it by your effort, you get something that's much more valuable than a story point. What you get is the ability to prioritize the things that are gonna have the highest yield in your team. And the other thing that I talk a lot about with early stage businesses is when they move into this idea of DevOps, there's a lot of knowledge out there already around the traditional DevOps lifecycle. And at the end of the day, it also includes quite a bit of information about how product management works in this graphic that I think we're probably all familiar with. For early engineering teams, even though I try to get them to talk in the form of like ice impact confidence divided by effort, I do try to get them to focus a little bit more on just the technical things that they need to adopt and adopt those in time based on where they are at in their go to market cycles. So pre-product market fit, you have a very different level of needing to operate and monitor obviously post-market fit or in a mature organization, that maybe is a higher priority. But I think when I visualize DevOps and lean DevOps in this format on the right, it sort of helps you to create the cyclical journey where you're first trying to get a full loop and then you're reinvesting. So you start with committing, then you're reviewing code provisioning servers, delivering servers, you need to build managed incidents once you have them in users and then you need to build a measure things, whether it's in the product or it's in the system. Now you need to reinvest in that curve. How do we make commit and then review and then provision delivery? And I think one of the fallacies about DevOps is people kind of think like you set it up, it's done, but it's a continuous investment. And the more that we can communicate that, I think the easier it is for businesses to justify the cost and improving the efficiency of their engineering teams by further investing into DevOps. So I think part of what we need to work on as a dev community is just how we communicate our priorities, whether it's ICE, or how do we communicate the investments that we're making and the impact that it has in the business. Another thing that factors into this is how an organization structure is set up. And sometimes we may or may not have control over how this is organized. Maybe something that we can organize within an engineering team or a DevOps organization, but it also may be something that's set more broadly in the business. But it's just important to understand that evolution as I talked about earlier, so you have your eyes wide open. Early on you have a flat organization. Communication is very easy to have cross-functionally. People work very independently. Then you move to a more matrix or agile organization. And obviously you start to have domain expertise, even some information silos, if we will, where I maybe don't know what that team's doing over there or that team specializes in security or they specialize in DevOps. This team over here is focusing more on this part of the system. And I think figuring out how to maintain a level of cross-functional consistency across these different groups is a really hard challenge when it comes to building a culture of delivery. Because as an organization grows, it's usually not the tools that break down. To be honest with you, it is the philosophy and the best practices. It's how we communicate about our expectations and how we understand that this organization, this team over here is doing this, this team over here is doing this, those two things are different. Well, now we have a massive context switch between those two things and a fragmentation of how we think about doing software development. That doesn't mean to me that we need everything to run in exactly the same way and we need to control the highest common denominator. But I do think it's about making sure that if there are new ideas emerging in the organization, those things can flow, especially if they're a net order improvement on investing into these workflows that we use to deliver software. A good example of this that's rooted in data is ultimately security. And so the 2019 State of DevOps report, we pulled some data from that and we looked through this to try to really find data that suggests that there's big changes happening. And still 50% of organizations have a centralized security function. That makes sense to me, like security, especially in large organization is a deep specialization. I think what we do see as, and we see this with other specializations is there is a movement to more generalized and distributed models for this specialization, which means that we're lowering the barrier to entry to for other developers to think about security. And this is sort of the rise of DevSecOps. 31% of organizations said that they centralized security function but had delivery designated delivery expert on each team. And then 14% literally were distributing and decentralized as security function. And I think that this is sort of more of a, like everybody is involved in security. And when you think about that extreme, there's definitely a need to like pollinate information, like what are your security best practices? How do this get implemented? In a centralized model, if you just go, hey, all of our security function happens within the pipeline and the pipeline is what analyzes our security. And you basically create kind of a black box for the rest of the organization. But if you have a more distributed model that where information can flow, it helps people to understand like what's happening and why we're implementing these security procedures. And this brings us to sort of the lattice organization structure. So a way to think about this in the public domain would be some of the things that Spotify has put out there about how they organize their company and their engineering teams. More recently there's been feedback on this that talks about its compromises and drawbacks as well. I think that's really good because there's obviously no one size fits all way to build a successful company. But I think the benefit of this approach that especially in the early and mid stage is you can ultimately have sort of this verticalization as we highlight in green, which is aligned with sort of business units that might have strategic goals that are relevant to let's say product or relevant to a section of the business. Horizontally you can layer in these specializations, things like security, DevOps or generally it depends on how you wanna break it down. But if you can have a designated point person on each of these areas, whether it's the business unit or the cross-functional disciplines that are more specialized, you can start to build this model for permeating knowledge and cross-functional training, which helps people move across different business units and have similar expectations. And this is really easy to do in the earlier stage because usually just have one DevOps engineer, but as you grow, this is a harder thing to implement. But I really encourage people to think this through because it's really important how we communicate philosophy and best practices. I think tools are a big part of how we immortalize them and translate our expectations, but there's a lot that can't be translated in a tool obviously. And this is why we have so many Zoom meetings. So the technology and process tactics really matter. And there's a lot of different ways to approach it. I went through a few that I see out there, but I think there's some like really core things that you need to just focus on. So there is no silver bullet that'll offer you on this, but there are some things that I really value when I'm building a team and scaling a team. For me, tooling enables less technical team members, maybe junior team members, to be given more responsibility, which creates less burden on senior members. So the more you can like start there and figure out how do you translate the philosophy and best practices, so it's accessible by others, I think you're really hitting an important point if that's your primary goal. Secondarily, I think you have to be mindful of what the long-term looks like. And I think you need to start with strategies and focus that focus on high velocity because high velocity is much harder to get as if you start with low velocity, it's much easier to get to, much easier to start with a higher velocity and then slowly lose some velocity over time. But that's a really hard thing to focus on early because you have to adopt certain tools along the way. You're inevitably gonna slow down as you add people in process. So just recognize that there's a negative correlation between the work we do sometimes and the productivity of an organization. Our goal is trying to maintain a focus on this velocity as we leverage more DevOps tools. And this is why I advocate for Lean DevOps because I think it's one of the most important correlating factors in the end result of the work that we do in DevOps because it kind of looks like this if I were to just summarize. So what we have is velocity on the left and the amount of process complexity on the right. As you adopt more process and ultimately people, you have velocity in green, which is diminishing over time. The point of, we say CTO today, but just DevOps and Lean DevOps in general is to try to sustain that velocity longer. And I think if you factor in that model into how you think through your DevOps strategies, you really have a robust framework that can scale, it's what worked well early and scale into a growth model. It's very adaptable. And I guess that's the whole point I'm trying to communicate is it should be adaptable, but it also should be very accessible because the number one thing is how do I get access to the tool I need to achieve the thing I need? And the tool is just the means to the end. So this is where I don't offer like a concrete conclusion, unfortunately, because there is no perfect process. I'm not going to tell you exactly how to do DevOps and that's why I didn't start with a technical talk here because what I'm trying to communicate and what I'm trying to advocate for are a lot of things that actually don't start with tools, but I do think tools are important part of the process, the important part of the tactics. So when you think about tools, they enable bottom-up adoption and they can create top-down transparency. I mean, that is a big important thing, but they also have to immortalize, as I've said, the philosophy and the best practices. As you start breaking out your organization into different specializations, it can be an advantage to maintain a flat organization longer. So think through really hard when you start breaking up teams. Is this what we need? And or is that going to create an amount of overhead or a level of fragmentation and communication, philosophy, best practices and tools that adds an exponential overhead to that business? When's the right time to do this? Most times I've seen organizations start to do this as sort of 25 engineers, and then again at maybe 40 or 50. And then from there, it's kind of really different based on how people work. But the most important thing is, because every organization is different, is you have to be adaptable and so should your tools. You're gonna have to evolve best practices along the way. You gotta be kind to your future self, being think through one of the things that you're gonna have to tackle later, but try not to front load all of the solutions. And what I think is really important is to be able to throw away code. And as engineers, we often don't wanna do that because it might communicate that that code failed. But if we can normalize that idea with an organization that right is building for right now and sometimes right now is not the thing we need in a year or two years from now, what it does is it gives us permission to evolve as we go and not carry forward our assumptions. So I try to communicate, always retest those assumptions about what's working and what's not, and give yourself as much permission as you can to throw away code. And then as you're growing, like one of the key things here that's really, really hard to do is to manage and be mindful of the dichotomy between velocity and stability. Stability is very important as a business gets to scale as it's robust and it's predictable because you need to have that predictability to evolve from the premise. But early on, adaptability and velocity to get to that level of stability is also very important. And I can't count how many teams I've seen fail in the early stage because they think the goal is to build for stability before they actually really understand what they're building for stability. And they don't leverage the leaner side of DevOps as an advantage early on. So the more you can do that, I think the better you're able to grow with your DevOps strategy. So my takeaway, the thing that I'm advocating a call to action for all DevOps engineers in the CNCF is this idea of accessibility and intuitive developer tools. I like to frame this around the idea of like who are you 10xing? What I'm trying to really bring to the table with this talk is almost an obligation that I think we all have to consider who are the constituents who are using our tools? What philosophies and best practices do those encompass? How are those adaptable and how do those actually remove friction from the process? And I think we have some really powerful tools in the DevOps world, but we need to spend more time on making them intuitive and easier to use for the next 40 million developers. And that is the presentation. So I'm happy to open it up for Q&A, but I will just note that if anybody's interested in what we're doing, please, we have a free Slack community where we talk about these things a lot. Please come check us out. And we'd love to continue the discussion there, but I'm also happy to answer any questions now that may be out there. Cool, awesome. Thanks, Carl, for the fantastic presentation. So we do have some time now for questions. You have a question that you would like to ask, please drop it in the Q&A section at the bottom of your screen and then we'll get to them. So I see that there are two questions currently. So the first one's from David. And David is very interested in hearing more about your experiences and tips with regards to maintaining a cross-functional consistency across teams and avoid information silos. So we'll come into that. Great question. Probably the hardest thing. I think it's the hardest challenge. I don't think there's any challenge harder than this in what we do. I don't have a clear answer for how to solve this in a situation where there exists a lot of what I think of as communication debt or expectation debt or process debt. I mean, there's all these other forms of debt that we carry forward. It's why I think we need to retest our assumptions. And so this is why I try to advocate for the idea of starting this conversation in the early stage because earlier you can start thinking about that as inevitably the outcome. And there's a bit of a physics mindset here, right? And I think Elon Musk talks about this little bit like you should start assuming you're gonna be wrong and work towards being right. So I always start with just assuming that that's gonna exist and like it's unavoidable. I think if you start with that assumption and you try to make different changes like on your journey there or take different approaches on your journey there, that is the number one thing that I've seen reduce the friction that you can feel at a later stage. I think when you get to that point and you suddenly see the forest through the trees and you're like, oh man, we have all of these information silos. There's a lot of approaches you can take that I think are helpful but don't necessarily like are hard to implement, hard to influence change. And this is why we have things like digital transformation that happen. I think some of the things that are really important is like try to have a single source of truth with obviously your code base, right? So try not to have multiple source control systems but also documentation. Certainly I think CICD is good. I think the thing that's the most important there is just generally accessibility and observability and transparency. So this is one of the things that we think things like chat ops is just really good for under the gate and obviously chat is not a silver bullet like it does certain things better and get ops does certain things better but the more you can make your workflows observable by default the more you can make them inclusive by default. The more that on that first day that engineer can look and see here's how somebody did that the less they have to then go dig and find the information. It's just a more organic way to surface this context. And I think these are strategies that tend to work really well but they're hard to implement and I think we need to make them easier to implement. I think by default what we tend to do is lean towards security and control and mitigation of potential human error. And I think we lock things down sometimes so that they're less accessible and I think what we could be thinking about is okay if that's we're putting all this effort into governance and compliance and security and like these things at the end of the cycle that give you that stability. Well, could we approach those things earlier by just making them more intuitive? So there's less room for human error but you still get the benefits of like transparency and accessibility where that junior engineer can deploy a thing and the system is good enough at falling back because you have this really clear and easy way to roll back that you're mitigating certain risks just out of the box. And so I think a lot about that and unfortunately I don't know that I have like one strategy but I'd say definitely like centralize your documentation. I think engineering office hours are really important just a place for people to get and like share ideas especially like team leads coming and be like hey, my team tried this, my team tried that. You know, it's always a balance because the time invested in is a big factor to how much ROI you get in the later stage. So try to start it earlier as early as possible and that doesn't mean give up if you're at the later stage and you're already at this point it just means you need to be probably more thoughtful and ready to achieve more buy-in to make change. And so executive stakeholders are super key in that kind of piece. And that's why I talk about trying to surface how we communicate about our KPIs and our goals in a slightly different format because I think they translate a little bit better to the business world and then they're easy to get stakeholder buy-in on. Cool, thanks Kyle for that. So the second question is from Barton who asks what role does ops play in this process? And I guess is the question about ops is in an ops team or ops is in our platform. Maybe I'll address both. I don't want to be too presumptive there. So I think the ops side of DevOps is this idea that we used to have sys admins and people who are sort of more on the IT and operation side. And what we were trying to do is like make systems more accessible so devs could access ops and be in there for DevOps. And I think what role that the ops team plays in this is really that call to action and that obligation that I was describing about how do we make the system as intuitive as possible whether it's a CI CD system or it's some other method for like getting access to logs. How do we make it as easy to access that as possible? I think that's the obligation of the ops team as they think about the devs as their customers their internal customers. And I think prioritizing the needs of the developer and understanding like what is their end game? What do they want to get to? And how do I get them there as quickly as possible without them having to take on all of the knowledge that I spent the last 10 years doing. I think that's the role ultimately of dev ops especially if you think about it implemented from the ops side of the equation. What we've tried to do with our platform the workflows which we call ops is try to start from that constraint and say look if the goal is to make this accessible to people what are the ways that we can really leverage the simple enough ways for these developers to get access to that while not assuming we know what the ops team knows. And so we think of as the ops platform is generally just a set of tools that you can use to build a developer experience that's easily distributed to your team and has 12 factor principles. The idea is you build this command line and you write it with our SDK the command line is just a Docker file so you can kind of think Haroku for developer workflows. Once you build it and you publish it it doesn't just run in everyone's command line without them having to think about environment variables and all these other things, it also runs in Slack. So you get chat ops for pretty much for free when you're building your command lines. And what we think this does is it both drives down the cost of automating things and taking the knowledge out of your brain as the ops person. And it makes it very easy to make it accessible and intuitive because now it doesn't just run through Slack or through the CLI it also runs through Slack which means you can automate away a lot of those things that were your dependencies on you. It doesn't replace your traditional CI-CD system necessarily it's a container though so you can run anything you want in it. You can put your Terraform scripts in there your Bash scripts, like whatever tools you use you're the expert, I'm not here to tell you how to implement your technology. What we're trying to do is like bring down the cost of distributing this knowledge out of the specialist brain into the form that the generalist can access them and reduce the burden on the DevOps heroes that we are helping us all ship software, right? Awesome, thanks, Carl. So the third question is, do you see your company competing with established players such as Jenkins X and GitLab as well as SaaS products, CI-CD vendors like Codefresh and harness.io or are you focused on spreading a message of efficient CI-CD only? Great question. I think we often get confused with CI-CD maybe because like an op is a container and you can like execute it in many different ways. We don't really see ourselves as a CI-CD solution. We see ourselves as a framework for building a developer experience that's accessible and measurable. So one of the things I didn't talk about is when you write these workflows we also have not just a set of frameworks in SDKs for the 12 factor principles, secrets, configurations. You can also store events and metrics. So we try to layer on top of existing tools in a lightweight way so that you can automate across your tool chain with some level of consistency. As a result, I guess there's overlap with some of the things that the CI-CD companies are doing, there's overlap with some of this what I think of as like the rise of the workflow and I think the intention behind that is here's a set of tools that you can use to implement your ideas bottom up and drive transparency top down. But I think we're unique in how we think about it because we're really focused on the idea that you can build the CLI which is typically how we automate all the other things and CLI and then from there the CLI also works in Slack. I suppose when you start triggering these workflows based on commits or other types of system events, I mean, it's really hard to figure out how it's different from CI-CD. It has a lot of the same kind of like fundamental principles in that way but we very much start from the idea of a more distributed and loosely coupled workflow for developers and as a result, we're not as much of what I would think of as like a centralized CI-CD system. It's accessible through Slack but each Slack channel can have its own set of workflows and to be honest with you people automate things that have nothing to do with CI-CD quite often and I think there's a lot of things that developers do which doesn't just fall into the existing CI-CD paradigm things like getting access to logs, running that report for a product manager against like who logged in and some of the migration stuff that we do is not great inside of CI-CD to be honest with you. I think CI-CD tends to be in some cases, it is a single point of commanding control which is great but I think in this remote world more and more of that control plane and how we think about where we jump off to start our day, where we jump off to do our work and where we communicate and collaborate more and more I think it's moving to Slack. So we're really trying to take this like Slack first mindset of how developers do work and we don't think of ourselves as like a chat bot but we're more chat first or chat free I guess in how we think about enabling you to build out your developer workflow. So I know that isn't like a direct answer but I hope that gives some context. Yeah, so DevOps isn't just like automation in CI-CD there's more to it than that. Yeah, and I see Barton clarify that he's talking about the ops team so hopefully Barton like that answered that question as well it's an obligation on the ops team to make tooling accessible and we're just trying to make that available to lower burden on the ops team. Yeah, awesome, thank you. Next question, while we take cognizance of the velocity versus stability graph can we not look at DevOps security which is DevOps sec to improve the stability? So such as including security tools to get more stability? Yeah, I think that's great. And that's actually why I sort of like point to security in that other slide about where like we're trying to measure the shift in this mindset of like centralized versus decentralized approaches in how we permeate knowledge but also practices and philosophy through tools. So I do think that like the rise of that sec ops is like great because it reduces the burden on the generalists to have to observe all of the deep knowledge of the security specialists and we're using tools to distribute that knowledge in a process-driven way to embrace best practices. So I think it's one of the new trends certainly that is finding that balance between stability and velocity because it's unintrusive and it's typically quite intuitive. You check your code in it runs some sort of security scan and then you get a note put and then if like you're blocked you need to now go contact switch and figure out why to block that. But I think there's still more that can be emerging from this field to make it even more intuitive because I don't think it's quite enough just yet to say, all right, well, you failed the security policy, right? And like now you have to go figure that out. I think there's now like that's the beginning of the feedback loop. And so the question is how do you continue to guide that developer down the set of things that they need to make complying with those policies more intuitive? And that's where I think we have a lot to still explore as practitioners because I think we do a really great job now of distributing the policy and the best practices and the tools in a lot of ways. DevSecOps is a perfect example, but how we do that and then how we leave the developer still back to the proper outcome is something that I often see that still needs a lot of work from a usability perspective. Cool, thanks Kyle. Another question, what have you observed are some great catalysts in large organizations that help the transition to a DevOps mindset, which in your experience, brought quick wins that clearly demonstrated the benefits of adopting a DevOps culture and practices to improve delivery. I need to think about this one for a minute. A long question. Yeah, well, digital transformation is definitely not it. I saw a great slide about what prompted and catalyzed digital transformation in my organization. The CTO, the CIO, or COVID and COVID had a checkbox in it. I think while I don't wanna make light of any of the suffering that's happened here with as a result of this, I do think unfortunately the catalyst, and maybe I'll just, is it okay if I just stop my screen share here, Harry? Yeah, Susan Lee? Yeah, cool. One of the things that I think is like, unfortunately, one of the things that is that catalyst is often, it's often some unfortunate situation. And more often than not, it's like there was a security incident, there was some downtime, a third party vendor didn't meet SLA or something like this. And there's a lot of other things that sort of like permeate up to this sort of like challenge where then like management leadership is now in this mindset of like, okay, this bad thing happened, we need to mitigate that. And I think that's often, it's just too late, right? And so this is where I try to like tell the story from the earlier stage because I recognize as we get to the later stage those catalysts are actually really hard to create. It's not clear to me what is a consistent set of catalyzms. I think that the mainstream adoption of DevOps is definitely one of those things that's helping organizations that move to cloud but these things are really slow. So they happen over a long period of time. I think the things that we have more control over is how we tell the story, how we advocate for the interests of our teams, how we create that like shared set of conversations across an engineering group to advocate that, how we start speaking the language of business and how we advocate it. So like if you go to a Chief Revenue Officer they don't understand what it means to say like I need to like scale the Kubernetes cluster or something like that. They're just like, okay, you're gonna add more servers like that should be just done, right? But if you frame it like, hey, here's our what's a door metrics and here's the result of how things are getting slowed down. And if you want things delivered on time we need to move this number. I think that's you're getting closer to speaking that language because I mean a sales team is very data driven a marketing team very data driven and we don't often try to create that same kind of data and use that data to justify some of our investments the same way that other teams do as engineers. And I think like it's expensive to do that. And I think it's something that gets thought about way too late in the cycle and this is why door metrics are usually something that like large organizations are thinking about. But if we can find ways to make these tools easier to adopt then it's less of a conversation of time and energy investment where you need someone to sign off you can kind of just do it it's a commodity at that point. But if it isn't that easy then you need to have some form of like information that you can really tell the story and meet people with where they're at and just recognizing that like other parts of the organization maybe don't understand what's going on in the engineering team it's a bit of a black box and that you need to translate that to them and say here is a set of metrics that you can understand which kind of like thin slices the situation and here's why and here's how it'll be good for you. I think we tend to lean with like if you don't do this, it'll go down and that's like a fear-based approach but if you talk about it as a profit center here's how we can make more money like now the sales teams are your price up like oh, we like to make more money, right? So I think it's both storytelling a bit and I use analogies a lot which sometimes miss the point but that's what I've tried to get across sometimes when I say like a snake's clawing an elephant or these kinds of things. Okay, cool, thanks Kyle. I don't see there's any questions. So lost chance guys, you guys have any questions? Please put them in the Q&A panel. So I have a question actually. So one of the questions mentioned DevSecOps or DevOpsSec, right? So this is like a term that has been recently coined and in your slides you mentioned a lot about DevOps and security and compliance, right? What is your sort of feeling about this term DevSecOps? Would you consider your practices DevSecOps? I mean, I think any term like this anytime we're branding something like this in our community it's often like us trying to translate something we've been doing into something that we're trying to more commoditize and lower the cost of so it's more accessible and like more mainstream, right? And I think that generally is what I'm preaching on from my soapbox, right? Like that's the thing I'm trying to get across. So I align with that very well. I'm certainly not as deep into the security space or the DevSecOps space myself, but I do look at when I zoom out and look at the macro effect that is a great example of a more a slightly more niche area within DevSecOps. I think now you have things like we were talking earlier before the call about AIOps area and like that's kind of the same idea. It's like we're trying to make this segment of technology more accessible. And that's where I really love the whole like DevSecOps AIOps like whatever ops you wanna come up with. I think to the extent that that DevSecOps movement continues and it continues down that path. And you see AIOps follow and you see other emerging, I would expect there's gonna be something related to front end at some point that kind of gets coined. I think that's generally good because overall what it's doing is it's lowering the barrier to entry for the developers who don't wanna struggle with the technology and need to meet their deliverables. And then they can say, hey, look, I can do DevSecOps. They can even put that on their resume. Like I've been working in a company that does DevSecOps, right? That's good for everybody. I think what we have to recognize is like what is the pathway there? What are we trying to achieve? And how do we then like look for other areas where we can bring down that? And if the way we do that is by like coining a term so that people can like organize around it and bring their knowledge and expertise. I think that is incredibly aligned with what I believe we need to do to build cultures of delivery, that especially in security. Because security is often something that gets adopted way late in the curve. And by adopting DevSecOps, you bring it earlier in the curve because the cost implemented is much lower. The cost to use it is much lower. And the more we can bring things down the curve so they're easier to adopt, right? The better we do at maintaining that velocity versus stability paradigm as the group grows and the best practices and such evolve. Oh, thanks Carl. So I see there's no more questions. I think we can end of the session. So again, thank you Carl for this fantastic presentation. And thanks everyone for joining us today. The webinar recording and slides will be online later today. And we're looking forward to seeing you at a future CNCF webinar. Have a great day everyone. Thanks everybody.