How to Build a $100 Million DevOps Company – Damon Edwards, PagerDuty

This is Textron tv. I mean, I think first of all, like don't build a quote unquote technology company. Build a business.

A lot of people got into this, oh, we're gonna build a popular technology, right? And then we'll figure out the business model later, right? In 2020, Damon Edwards sold this DevOps company to PagerDuty for $100 million.

But Damon has been part of the DevOps movement from the very beginning. You've Worked, got together. It's like, yeah, Devon Ops, right?

Why? It's like, well, because we haven't figured out we're supposed to use Sheffer Puppet yet, right? It was all, get the deployment problem.

Join us as we take a look at Damon's involvement in DevOps and his advice for building a successful technology company. As someone who was at the forefront of DevOps when it was first happening, how is the, how is the progression? What, how have you seen the progress from when it started to how it has grown today?

Yeah, Right. I mean, I think, well the fir the first, the first thing was, you know, the first kind of driving principle while Patrick brought the DevOps started the DevOps days conference, right? Which is just a small meetup type style unconference where you have a couple people speak each morning and then in the afternoon as they call open spaces, which is almost like group therapy, right?

You just have this, you sit in circles, right? You have, you pick a bunch of topics beforehand and you have these kind of open free flowing conversations about, you know, a particular topic. And there's different rules.

Like, you know, you could, wherever it ha wherever whatever happens is what's supposed to happen. There's a law of two feet. Meaning if you're not learning, get up and move to a different circle.

It's a really cool way for practitioners to share what's going on. And you know, Patrick's first idea was like, well wait a minute. If you go to a conference and dev and ops are there together, like one of them is at the wrong conference, right?

Like, these people don't hang out together, right? And so that was sounds crazy now, but that was his first kind of impulse was let's bring people together to talk about our problems. How do we marry this sort of agile flow, you know, you know, development kind of world with this, you know, interrupt driven operational world because you know, it was quickly moving towards, you don't make your money right?

In the software, you make your money, right? Writing and running the software right before it's got together. It's like, yeah, DevOps spike.

Why? It's like, well, because we haven't figured out we're supposed to use chef or Puppet yet, right? It was all, it's a deployment problem.

We solve the deployment problems, it's all gonna go away. And then of course there was monitoring talking, 'cause everyone likes to talk about monitoring, but really it was, it was kind of, was it gonna be, chef is gonna be puppet, right? That was this.

And you know, how long this thing really gonna last? 'cause it's just that conversation. And then we sort of realized, well wait a minute, you know, deployment that acts, that's really just the flashpoint, right?

That's the where the moment of truth where all the sort of disconnects and dysfunction between these two, you know, sides of the house come together. And so it just kept expanding, right? And I think one of the brilliant things that, you know, the early community did was resist a hard definition.

There is no one canonical definition of DevOps. There is no DevOps manifesto because why? 'cause we were just learning.

In fact, I think I like Adam. Jacob had this great definition, I can't remember exactly what it was, was basically called the, like a movement, right? He says it's like a movement born of its practitioners, right?

Almost like an open source effect. Really saying how do we build high velocity, you know, organizations, right? Which is key.

It's not just, you know, the deployment, right? It's not just writing code or running code, it's the whole business, right? How do we build high velocity organizations?

And yet a better way of saying it, but effectively I thought that was a pretty good idea. It's like, it's a label for a movement, right? Of people who want to talk about this certain problems.

And that's kind of when, you know, John Willis and I came up with the, you know, the acronym of cams. It's just one of our podcast conversations we're like, how do you label a DevOps conversation? What's different about it?

Right? And we noticed it was, you know, obviously the Devon ops thing, but you know, it's, it was culture. There's a lot of talk, a lot of talk about culture, which is not something people, such technologists really talked a lot about, you know, operating behaviors and things like that.

Automation obviously, right. Metrics, right? Talking about how do we measure this stuff, right?

And then sharing, we thought it was a very interesting aspect, which was all about sharing. You, you go to these events you see people from who are vicious competitors in real life, their technologists sitting down over beers or lunch or whatever and announce some hard problems. Hey, we do this way.

How do you do it? Really, you know, the, the rising tide helping sort of all, all boats. When you were acting as sort of a lean consultant type of deal, what was that feedback like?

Yeah. When you were trying to implement these principles, DevOps into the actual workspace? Yeah, It was very interesting.

I mean, we'd focus a lot on really seeing the end-to-end system, right? And everybody kind of thought they knew what this system looked like, right? So we'd come in and do these workshops and we'd do these value stream mapping exercises.

And the value stream mapping is less about like kind of what you'll see in the textbooks of the each, you know, workstation in a, in a factory in the cycle time and process time. And we were more focused on like from a storytelling perspective. Like, okay, let's tell the story of this incident, the story of this, you know, deployment.

Like it was the Tuesday major release. Like, okay, let's go back, where'd this come from? Where were the planning cycle?

Like what was the, the decision making? What was the different, you know, requirements? What was the actual software, the whole life cycle?

Just massive long kind of storyboards. And people would go into with, well like, oh, we know this. Like why are we doing this?

This is a waste of time, you know, rum, right? And then half hour later, sometimes less, sometimes more people are like, whoa. Like I dunno.

And that's how it happens. Or that's why that happens. I had no idea.

Right? So, you know, we really realized that, you know, a big problem with this is that the, in the factory world, let's say we're making televisions and you know, a television fell off the assembly line, right? We can all run down to that part of the assembly line and just look at it and be like, Hey, is it the corner too sharp?

Is the belt too fast? Do we just put a net there? You know, have we changed the TV size and now it's not gonna, you know, like, like we would start coming with solutions pretty fast.

'cause we could all see it and be like, yep, there it goes. TV falling off assembly line, right? But in this kind of knowledge work world that we live in, there is no gemba or factory floor right?

To go to, like, it's all in our heads. Like, I can walk over to your desk. It doesn't mean I know what you're, you have in your heads we're having these conversations past each other or in collisions and because we just don't have the same mental models, right?

So we kind of realized that for most of these organizations is really about building those mental models, right? The shared mental models. So they kind of can visualize and think about the work in, in the same ways.

And then really teaching people sort of like the principles of, of flow. And often it's by understanding kind of well, what gets in the way? Like how do you identify, you know, the, the the, obviously the, you know, the defects like problems.

And once people get into that mode of we know how to get together and visualize the whole end-to-end system, we know how to spot the kind of, we have a good shared vocabulary for the waste and we have some good design patterns to start with in mind, and we can build more as we go. Once organizations get into that kind of way of working, the problems kind of fix themselves or it becomes clear who has to fix the problem. Sometimes it goes to the highest levels and it's like, wait a minute, how we're funding this thing, how we're organizing this thing, how we're incentivizing this thing is causing the problems.

But it becomes very clear and you'd be surprised, you know, how organizations can fix themselves, right? Or make it clear to leadership how they need to be, how, what they need to do to fix it. Just from kind of doing those three, those three things.

So that was really the kind of crux of what we were doing as consultants. And then we had the Rundeck thing on the side that was really started as a consulting project way back from our, from our, our, our tool Smith days. And yeah, that kinda became the vessel through which a lot of people were kind of applying these operational improvements and then that grew into its own business.

And you know, the rest was history. Eck was built on a open, open source, correct? Right?

Is that what it was? Or, Yeah, yeah, we had an open source project. So we just, you know, we built it back in our, you know, or some early versions back in our consulting days and then, you know, saying, Hey, you know, we know this is an issue.

There's this gap in tooling that's out there. And as tool chain builders, we kind of knew that. And so we had a previous open source project and we took that and sort of tried some other places, stripped it apart, and tried some of the pieces at other places, and they had solved the problem.

And, and then we, uh, you know, built what then became, became rundeck and just kind of put it out there as like, Hey, we use it, other people we know use it. And, you know, like good open source projects. It's almost like you're collecting a bunch of tinkerers who have an affinity for a problem.

Like they see the, whenever they're thinking, they see it in what you're doing. And so they get involved and they contribute things. And you know, it's kind of how these things, these things take off.

It's probably why it's so hard to kind of astro open source projects, right? Versus projects that are actually built to sort of genuine, you know, open source projects versus companies that come along and try to, you know, kind of build that community without, you know, just sort of, kind of after the fact doesn't nearly, or companies you see to just take something and say, we're gonna open source it, you know, thinking that magically posting the source code on the internet, you know, creates that community, creates that enthusiasm, creates that, that, that culture, right? It's a little mini culture.

Um, and so, you know, for us, there's kind of two sides to, one of 'em was building the Rundeck open source project, and then the other is figuring out, well, what's the business model that will support a company that could help drive that project, right? And all that zero to one. And, you know, kind of solving the problem and the customer that that's that building the company side of it, right?

Which is a different set of problems than building the, the an open source community. So it sounds like there's a lot of advantages. Are there, are there disadvantages to o doing open source projects then?

Yeah, I mean, it, the hardest thing is like you're giving away something for free. So you set the price, right? I mean, I don't say it's a disadvantage of the open source community.

I mean, it's a disadvantage of trying to build a business around the open source, open source community that, you know, a lot of folks, they try to re monetize the value proposition that, that they've already given away for free. So it's like, oh, we've got the pro version, right? It's like, well, what's the value prop?

The value prop is X, y, z Wasn't that the value prop of the free version? Well, yeah, but it's better. It's like, okay, but, you know, free, you're going from free to, to some amount of, you know, money usually quite a bit.

It's a big giant leap, right? For what's the difference? 10%, right?

Is it really that, that, you know, that noticeable, right? So you get this kind of business, business model collision, I'd say, right? Where they try, and so you have to monetize something else.

I think that's kind of my, my strategy of it, to say, Hey, look, you the user in the community for you, this is free forever, right? Like, there's a path for you to build this as an open and transferrable skill, and you can, and, and for what you care about, it's free, it's open, it's this community thing, right? But for the stuff your boss cares about, that's where the money comes in, right?

And so if you confuse those and they, and you feel like, hey, you're gonna, you know, you're, you're gonna have to go. And if you're a user and you feel like there's, like, you're gonna cut off somewhere, right? Then it's like the community's not gonna have the enthusiasm.

It's like, ah, this is a trap, right? I can't really build this as an open and transferable skill. But then if you go to the boss side and you don't give, and, and the boss value looks too close to the user value, it's like, well, we're already getting it for free.

Why would we bother paying for this thing? Right? And we've got smart engineers in this company, they'll figure out how to make this open source thing work.

They'll figure all the rough edges for you, right? So that's that from, so it's a real, you know, it becomes a business model discussion. And you have to make sure, at least in my formula, that you don't, you know, those things don't, don't collide.

And you, and you develop separate value propositions to where the user is super invested, and they'll, that'll often bring you in before there's even a commercial opportunity, or there's even a hint of one, right? You'll look it into a company, get entrenched because you've given that user something of value that they can, that they can build on and don't feel like they're gonna be, you know, chopped off the knees at some point if they use too much or do whatever. But you, You started a company.

So what was that process of like in the startup, like getting it up and running to eventually becoming what it is today? Right? So I mean, I'll just say, I, I, you know, I, I think kind of how, what was interesting is, you know, we, how we became product people, right?

I think we were always product people. You know, I think when you're in the consulting world, right? There's, it's kind of two ways to to scale, right?

A, a consulting business, one of them is your named consultants, right? It's like a named law firm, you know, everybody wants a certain partner. Like you just become sort of personalities and, you know, and known named people, and you just charge a lot more per hour, right?

And, but it doesn't really scale. And then the other kind of side of the business is more of like the conditional like kind of body, like, we'll bring you a bunch of bodies, right? We have a name and we have a system like a McKinsey, right?

Or a, or a Deloitte, or you know, even a Tata or something like that. We have this name, we have a process, we bring you a lot of bodies, but there, and you're kind of scaling the more of a labor arbitrage game. It's like, Hey, how do I, I, I know you, you need these kinds of people.

I get you these kinds of people. You're not really on the cutting edge as much there, right? And you're not really pine pioneering and in the product world, you're much more pioneering, right?

You're saying, Hey, there's a problem in the world and I can sort of see it and I'm gonna go, you know, fill that gap, right? And I have to figure out the product market fit. I gotta figure out the business market fit.

It's much more on the kind of leading edge, right? So we always wanted to be those folks. We, that's what we wanted to do.

And so we got lucky in some ways in, you know, rundeck, which was a holdover from kind of our previous, or the precursor to it kind of came out of our sort of previous consulting, our kind of tool pipeline building, consulting, and, you know, it just, we spun it out on its own early and it just kept growing, right? It kept growing and growing. And soon why people were calling us to be like, Hey, I know you do this DevOps thing, but we're Rundeck users, so can we get some help with Rundeck?

And then, you know, we'll do the DevOps stuff later, right? And it was all these kind of blue ship companies we're like, wow, this is something really, something really here, right? So we kept running experiments to say, Hey, is there business here?

Is there business here? And then finally we, you know, jumped in and with full, full boiler on the product and, you know, shut down the, the, the consulting. And then, you know, that eventually led to the sale to PagerDuty.

And you know, now we're doing similar things, but in, in the context of a bigger, a bigger set of capabilities solve the much bigger problems. Mm-hmm. So you had these people that were like, we want to use your software, we want to use the rundeck, we'll do the DevOps later.

Is, is Rundeck then not like a type of, I don't know, technology or DevOps company then, right? Yeah. That's an interesting, you know, idea, right?

Because I think, you know, it's like, oh, cloud computing or AI, or, you know, you know, G P U chips, right? I mean, these are all like things you can go, like, it's one of those things. And so make a company, it's gonna make those things, right?

And I think that, you know, that is, is a lot different than, you know, in the DevOps world, I said there wasn't really a clear, DevOps isn't a thing, right? DevOps is like a, I said it's, some people call it a, a movement or an umbrella, you know, it's a, it's, it's an overarching kind of conversation around a whole set of problems that are getting in the way of, you know, kind of speed and throughput for, for companies. And, you know, some people it's like, well, DevOps equals, you know, deployment, right?

They kind of kind of pigeonhole into this like kind of deployment pipeline, say, those are DevOps tools. But I think, you know, you know, a lot of people will disagree with that, with that assessment, right? Because it leaves out, you could still have terrible, siloed, broken, you know, processes and throughput your organization, yet use all those DevOps tools, right?

So it's obviously not a tool type thing, but I think we as a company, definitely, you know, I would suggest for anybody who's building a software company, try to find the big trends, right? DevOps is definitely a big trend. And, you know, that got rundeck into a lot of doors, right?

You know, we had a lot of open source street cred. So it's like, Hey, you know, we're using rundeck in these different places inside the company. We're using rundeck in these different places.

Let's get the Rundeck folks in here to come talk to us about their products and how they can help us. And, you know, you know, we could apply our, you know, our technology and our thinking to bigger and bigger problems for customers. So, you know, it's one of those things where you might have the greatest idea in the world, but if you don't have, you know, sort of a trend at your back, it's hard to get people to focus and spend time looking at your company or looking at your product.

We never call ourselves a DevOps company, but I guess we were a DevOps company. So zooming out then, like just in general then, when a, you know, the words startup and entrepreneur and things like that get thrown out a lot. And like, you know, people say, I want to make a startup.

I want to take make a technology company. What, what's that? What's, what do you recommend?

Like what, what are the, how do you build one, like to, to give just anyone who wants to do that? Some advice. I mean, I think first of all, like, don't build a quote unquote technology company.

Build a business, right? com, you know, boom, a lot of people got into this, oh, we're gonna build a popular technology sheet, right? And then we will figure out the business model later, right?

And I think, you know, in some cases you could figure it out. In other cases, look at, like, Docker is a great example. Like, you know, they probably squandered one of the hottest, greatest technology trends in history and, you know, basically imploded and had to recapitalize themselves to a much smaller, you know, constrained desktop, you know, entity, right?

Than the takeover the world position that they had, you know, raised hundreds of millions of dollars on. And I think, you know, it's, it's, it's, it's easy to look at the survivorship bias and say, oh, that company just luck. You know, they just, they just focused on community.

They just focused on, you know, on, on, on, on building the tool and then the, the business will come later, right? And that's actually not, you know, not how it, not how it happens. So, yeah, you know, another piece of advice I would say is, you know, make sure that you're focused on, you know, a trend, right?

And I think that's big to understand is you could have a great idea and they can have, and your customers potential buyers could say, oh, like, that's a great idea. You know, that's a great idea. I wish we could do that.

But if it's not in their top 10, think about how corporations work or buyers work. You know, there, there's only so much attention they could put on something, and if it's not in their top 10 list, it's probably gonna be put on the, well that's cool. We'll get back to it later list.

Right? So, you know, understanding kind of where people are thinking and what those top 10 or those top few things are is really important because you could have a great product, but you're not gonna make you need money to live, right? And you're not gonna make those, those sales if people are preoccupied with other things, right?

And we had a few de detours like that with rundeck, where we're like, ah, this is gonna be a great business model. But it's like, yeah, they're like, that's great, but if it's not on the things, they're already looking for the activation hurdle to get them so excited that they're gonna go and, and, you know, find budget and find people to work on the, on that thing, it's, you know, it's a lot lower percentage shot. Right?

That's what I was saying before about, you know, it's great if you could attach yourself to an AI trend or a, you know, for that it was kinda the cloud native transformation and there was the DevOps trend and the SS r e trend and different trends out there. And I think, you know, understanding that the industry kind works on these trends and businesses pick their priorities and set their budgets based on sort of those trends and you know, the things they want to do with their, with their business. So, you know, I think it's kind of like all things in life, you gotta have the empathy to see it from, you know, your customer's perspective.

And some people comment at as like, I got this tool, it's so cool. Like, don't you want to use this cool tool? And it's like, no one's calling you saying your tool not cool.

They're just saying like, it's not in the priorities of things that they have the time or the attention to, to spend to it. A lot of times just see open source projects that'll get really popular because it's that scratch the itch. Isn't that cool?

Tinkerer kind of kind of crowd, but then we go to turn into a business at Flounders because it's like, yeah, but that doesn't translate to, you know, somebody has to sign a check and it and assign people to do this. And if you're not in that top few, you know, list of priorities, you're gonna have a very hard time either breaking into that, you know, say no, add a number six onto your list, right? Or, you know, try to change their, what those top five kind of priorities might be, right?

So I think that, and I think that kind of gets back to the idea of, you know, that, that if you're gonna start a company, your your point is to make money. Your point is to make sales, right? Just saying, we built a community just saying we built technology.

That's all nice, that might be necessary to get where you want to get to, but it's not sufficient, right? So don't punt the business side down the road. I've seen way too many companies that fails because of that.

And you know, we almost failed several times, right? Because we had a hard time Exactly. Figuring, figuring that out before things really started to click.

And it, and it, and it, you know, finally took off. So now that you have figured it out, then what's the, what is the process for, like, how do you market it? How do you develop it in a way that gets over that Activision activation hurdle?

I mean, and I think, you know, part of it is just coming down to understanding, you know, kind of from the bottom up. Like what are people, what are their problems, right? Like your business exists.

Like one of the greatest advice I ever heard is you are not the hero, you're the guide, right? They're the customer is the hero. Too many people present themselves as like, we're the hero.

We're gonna solve X for you. Right? Versus saying like, you know, know, getting into their shoes and being like, no, they're the hero.

They're the ones that has to do their actual work here. You know, how do you make their life their life better? Right?

And then, you know, being very clear in what that before and after picture looks like, right? But to get in the door, it's gotta be attached to something that, you know, that they're, that they care about, right? You know, for example, like this whole digital transformation was a much kind of maligned term on the technologist side.

'cause they're like, what? Like, you mean make websites like whatcha talking about? Like, you know, it's a BSS term.

But the reality was, it was just a, a way for kind of a, a very, a board level conversation to say, look, you know, we need to digitize our business in that, you know, we need things to be, you know, always on, always available. We need to allow people to work, customers to come to us from any form factor. So that's a real desire, right?

And so if you know that's the pressure coming down from, from above, then you gotta figure out, well, okay, well what, how does that pressure then fall down to say the operations organization or development team or you know, marketing or sales or whatever it is, and then say, okay, well then now how can we solve whatever problems they're gonna have achieving those goals? They're gonna be able to go back to their board and say, Hey, we're building the flexibility. We're building these capabilities that you need, you know, to have these, this digital transformation for these new business models and new ideas.

So, you know, I I think it's, you know, no one ever sees it from day one because if they did, it would be obvious and everybody else would be doing it, right? All entrepreneurs have to have a bit of this kind of, you know, hey, I'm doing something that, you know, other people haven't, haven't done. But eventually I think where you find success is when you understand how to, how to weave that path, right?

From what I have all the way to sort of what the business desires are of a large enough set of companies to where when you get out there with your message, it cuts through the fog, it's very clear and it speaks to, you know, themselves, right? They see what they want to achieve in you. And then, you know, that's when you know the success starts to, starts to roll in.

It's that zero to one problem, right? It's like when there's nothing taking it into something, you know, it takes a tremendous amount of energy. It's like big bang or something, right?

But when you, when it starts to work, it's, I gotta admit it's pretty, it's pretty awesome. And it's, it's also unlike, you know, the zero to one problem. Like something to, you know, nothing, nothing to something is different than the next problem you gotta face, which is sort of like the one to 10, right?

And that's kind of like you got the product market fit with zero to one, then one to 10 is like the business market fit. Okay? You know, people would want this product, but how do you now deliver it in such a way that they will pay you more than it costs to deliver it?

And you can acquire customer, you can acquire customers, right? For less than it than you would receive from those customers and you know, so on and so forth. So it's like zero to one's a huge energy problem, which is actually quite different than like one to 10.

And then like 10 to a hundred is a whole nother, you know, a whole nother ball of wax. And then I'd say like, you know, 100 to, you know, whatever is another one. So it, there's all these stages where you keep finding yourself going back to, you know, nothing, right?

And, you know, having to figure it out kind of almost all over it, all over again.