Why Are You Still Spinning Up Your Own Environments? with Tommy McClung, Co-Founder & CEO at Release

(Intro Narrator at 00:00:02) Hello, my friends. Today, Joel is talking to Tommy, cofounder and CEO of Release. And they discuss how Tommy founded Release to solve the huge problem of quickly spinning up environments, why the best entrepreneurs are always extremely persistent, and why being vulnerable goes a long way as a leader. All of this right here, right now, on the Modern CTO podcast.

(Joel Beasley at 00:00:32) Here we go. This is the Modern CTO podcast.

(Tommy at 00:00:44) I also have kids. I've got five kids, and so trying to weave kids in life and work together is fun. So, yeah, I mean, I know how it is. Been an entrepreneur my whole career myself, so I know the journey you've been through a bit.

(Joel Beasley at 00:00:58) Yes. That's what I like. When I read your prep and I saw you, I was like, yes, he's an entrepreneur. Because, you know, all guests are great, but there's that—Elon Musk says staring into the abyss and eating glass. There's, you go through that. That's just a different level of experience.

(Tommy at 00:01:14) I guess we have some glutton for punishment or something. I don't know what it is. I just think about going to work for someone else, and I just can't make myself—I mean, I did. I've done it. I was the CTO at TrueCar before this, after a company I started got acquired. And, you know, the whole time I was there, I could just not get it out of my head that I wanted to do it again. So there's something about it that's exciting and freeing and scary, but I don't know, man. That's what makes me tick is just going out there and trying to do something crazy.

(Joel Beasley at 00:01:45) Absolutely. And I love what you guys are doing with Release because, you know, my background—I said, software developer, seventeen years. I understand environments and all of that. And when I saw what you guys were doing, I think it was a month or two ago, with one of—I think your marketing director—they were showing me, I was legitimately, this is one of the coolest things I've seen in a long time. So I was hoping you could just explain what Release is, what it does.

(Tommy at 00:02:11) Yeah. So Release is environments as a service. You know, environments are needed for developers for everything from developing their code, testing it, QAing it, running it for their customers. Obviously, your production environment is where the customer sees the end result of your work. And then environments play—in modern software delivery, there's all sorts of new delivery mechanisms where you might have a customer who comes to you and says, I don't want to have my data commingled with all of your other customers in a multi-tenant kind of environment. So I would rather have a version of what you're selling me isolated to myself, a single-tenant version of that. Sometimes our customers host those for their customers directly, single-tenant environments. Sometimes they deliver those into their cloud accounts, so they're an enterprise version of their applications. And so environments are just this absolutely necessary fundamental part of the software ecosystem across development all the way through to getting your ideas in front of your customers, and they're just really hard. They've always been really hard. So Release makes it really easy to spin up and down environments on demand.

(Joel Beasley at 00:03:26) Is this one of the companies that you founded?

(Tommy at 00:03:29) Oh, Release is. Yeah. Yeah. So me and two of my cofounders who have worked together since the early 2000s—we actually started working on blade servers back in 2001, 2002. That was the cloud before the cloud. Stick as many servers into a rack as you could and see how much compute you could get in one tiny little place because you used to physically rack and stack these things. And so we started working on systems management stuff early on in our careers at that startup called RLX Technologies. Hewlett Packard bought that company a few years after I started there. And then I got the itch to start another company. So I started two more along the way. And the last one was this company CarWoo that got acquired by TrueCar. I was trying to solve car buying because I bought a car and it really irritated me, and I was like, this should be way easier. It still needs to be way easier. My grand vision of solving the world's car buying problems did not come to fruition. It still needs to be done. Someone at some point will figure it out, probably Tesla. And I ended up becoming the CTO at TrueCar. So, you know, as the CTO of a public company for a handful of years, I got to see what does it take to run a large engineering organization and make them effective and efficient. Environments were a really difficult problem to solve, especially when you get to a larger scale company where the applications get really complicated. It's not just an ORM, a Rails app and that's all you're running, or a Node.js app. It's got data pipelines. It's got ETL that needs to happen. It's got lots of different applications, internal and external. And then you have big teams of engineers trying to collaborate, and they all tend to bottleneck around, well, I've got to use the staging environment, or QA is being used by this team, and so I've got to wait. So I really, really felt the pain in trying to get an engineering organization efficient. Environments were kind of the headache there. So me and my cofounders decided we were going to go start a company to solve that problem because nothing really existed in the market. You kind of had to cobble together a bunch of tools—Terraform and your containers and, you know, your AWS account. Build some pipelines, figure out how to make environments work. And it's tricky. We spent a good two years internally there trying to solve environments. And we had to build it in-house because nothing existed, and so we felt the pain and then started Release back in 2020, early 2020. Did Y Combinator, which is a big startup accelerator up in Silicon Valley. And then we've been working on the problem for about two and a half years now.

(Joel Beasley at 00:06:13) Nice. Yeah. You kind of reminded me of LaunchDarkly. I got to talk to this guy, John, from there. And they do feature flags. Right? And a lot of people roll their own feature flags, and they'll build it themselves because, you know, it's a relatively—I think, to me, it's a relatively new concept in the past ten years. But there might be some older software people that are like, you're way too young.

(Tommy at 00:06:35) Yeah. Yeah. But, um—it's an if-else statement if you take feature flags to its purest form. Right?

(Joel Beasley at 00:06:42) Right. Well, if you talk to, you know, my friends, everything's an if-else statement, and that's just what we do all day.

(Tommy at 00:06:48) It's a one and a zero, one way or the other. Right? Yep. Yeah.

(Joel Beasley at 00:06:51) So when I was talking with John, he was saying, you know, a lot of people roll their own. That's one of the sales objections that they'll have, things like that. And then I got to use his platform because I had, you know, a very crude feature flag system that I would ship from Rails project to Rails project. I just, you know, very basic that I did myself. And then I saw theirs, and I was like, dude, this is unbelievable. It's next level. It's got all—it's almost as if you spend all of your time thinking about feature flags. So do you guys do the same thing? You just spend all your time thinking about environments?

(Tommy at 00:07:23) That's it. We're obsessed over them. It's actually a really good parallel, and I actually use them as an example. I also use Datadog as an example here too. In the early days of monitoring and alerting, you used to roll your own monitoring and alerting. You'd use RRD. You'd use Nagios, you'd create your own dashboards, Grafana, whatever it is, and then you had a team of people trying to make your monitoring system work for you. Now you've got Datadog, New Relic, you know, a bunch of tools that you can use. And what it really comes down to is where do you want to spend your time in these undifferentiated areas of your technology ecosystem. They really can suck up a huge amount of time and money. The problem—I think the challenge is the problems there for engineers are fun to solve though. Right? So when you're talking to a company who's saying, oh, I want to build my own environment, you know, spin up, spin down platform. For an engineer, it's kind of a fun problem. You're building tools for developers on your team. You're making other software engineers more effective. It's really attractive to want to work on that problem and solve it for your organization. But as a CTO—this is the seat that I was in. You know, I was the CTO. I'm managing these 300 people. Our problem at TrueCar was to solve car buying. Right? It wasn't to figure out how fast can we spin up and down environments. You know, it was a really needed thing for us, but it wasn't our core competency, and we spent a lot of time and money trying to solve it. So, you know, in my opinion, you're going to see this in lots of areas. Right? Environments as a service is kind of like LaunchDarkly and Datadog in that way, where today, what we find is DevOps teams, they're spending a lot of cycles trying to make their development teams productive. And at the core of that really is, do my developers have the environments, the resources in the cloud that they need to get their job done? And if they don't, how do you solve it? Well, let's put the DevOps team in front of that problem and either manually, which we see a lot—DevOps teams are like, well, we've got to create another environment. Let's go run our scripts manually or whatever we do to make that happen. Or they're investing pretty heavily in trying to build an internal pass platform. But, again, that kind of goes back to, hey, do I really want to spend these engineering cycles and resources on something that isn't differentiated? It really isn't. It's just a means to an end to get my product in front of customers. And, you know, I think the pattern in the space is a company's going to come figure it out, and they're going to do it to the level that you would never be able to accomplish it internally. And that's actually feedback that we get all the time. You know, people that have tried to build it internally. And that's actually feedback that we get all the time. You know, people that have tried to build it are like, oh, this is what it would look like if I spend all my time doing this. Yeah. This is way better. I should not spend my time worrying about this.

(Joel Beasley at 00:10:22) Yeah. And we do that. It's this repetitive cycle because it happens almost with every problem. It happened with CMSs back in the day when everybody's just rolling their own, and then they finally figured, you know, there's a couple main players in the market. Let's just use theirs. Why do you think that happens? Is it just that the problem catches us off guard? Or it's they're very new problems, and when we search for solutions, we don't necessarily know how to search for them? Or—

(Tommy at 00:10:49) Yeah. I think it's a bit of a combination of both. Right? You know, when I faced the issue at TrueCar, we looked—hey. Let's go see if there's an out-of-the-box solution to solve this problem. And, you know, it was kind of like, well, there's a bunch of parts that you could find that would help you accomplish it, not a full-fledged solution. Right? So you could potentially use CircleCI to do your pipelines, and then you could, you know, write some scripts that would, you know, at the end of your pipeline, orchestrate an environment and kind of get your way there. But there was nothing purpose-built for that specific issue. So I think part of the issue is that when these categories kind of emerge, whether it's monitoring, alerting, whether it's feature flagging or environments as a service, initially, the only answer is you can do it yourself. So I think that kind of tends to—well, I guess we've got to go build it in-house. And then what we'll find over time is these patterns that emerge. Okay. Having an environment with every pull request becomes something that the engineer can see is possible. Right? It's possible to do this. You can do it. It's technically—you know, all the parts are there to pull it off. And so somebody's going to go build a company like Release or LaunchDarkly or Datadog. And I think as those companies start to emerge, I think the resistance to it—you have the pre, there's a solution to it. Then there is a solution to the problem that is early, kind of like where we are. And then there's a solution to the problem that is later, like LaunchDarkly or Datadog. And when the companies, like Release, show up that are early, the resistance and the reason why companies continue to do it is it's a control or a lack of trust problem mostly. Right? It's like, hey, I'm going to trust you with my feature flags. That's important. I need to sort it. I'm going to trust you with my data and alerting and monitoring. I don't know, man. That's a tall task for anybody to do. I'm going to do it myself. But as those companies kind of evolve and grow a bigger base, that trust starts to be like, okay. Well, this is an established company. They know what they're doing. Let's not waste our time on it. So I think it's kind of a natural evolution where it takes a couple of years, maybe three, four, or five years of a company really doing that work that you spoke about before of building and just maniacally focusing on that problem, building trust with their early customers. And then at some point, the market says, you know what? This isn't something that we should be building in-house. We should just buy this off the shelf. And then there's a tipping point where all of a sudden, you just would never think about doing it internally anymore. So you'll see that in other areas too. It's not just environments as a service. It's kind of a common—I think it's a normal cycle, and I think, you know, we're right in the middle of it right now.

(Joel Beasley at 00:13:50) Yes. I think there's a component of humans interacting and communicating with each other. So people will ask me, you know, how do you create a podcast or a popular podcast? You know? And I'll explain, you know, here's our method or whatnot of how we did it. And then they'll say, oh, well, can we spend $500,000 and accelerate the timeline so it doesn't have to be three or four years? And I said, well, a little bit, maybe. But there's this thing that happens. You definitely need two years for it to become a thing because people go to conferences or they meet with each other or they see it a couple times here and there till they finally try it or experience it. So I've started to value recently the time lag of humans sharing their experiences with each other.

(Tommy at 00:14:36) Yeah. It's a big part of it. There's that social proof element of this. That's why every B2B SaaS company you ever go to on their website has "trusted by these companies." Right? What they're trying to do is get you to shortcut to the point where, well, if those guys are using it, it must be good. And everybody does that. It's normal. But, you know, I think in an area that's really critical and important like the environments that your developers use—and I think this is completely true, and I know it from customers we have today—there's a bar that you have to be able to cross before, you know, the DevOps team that we talked to is saying, you know what? It is better than what we could do internally. And there's a cycle time of building that that, you know, doesn't happen overnight. This is a really complex problem. Everybody's applications are different and unique in their own way. And to believe that a company could come in and say, well, I can run your app and I can run yours and I can run yours out of the box—that's a tall order.

(Tommy at 00:15:39) And so that's why as a startup, what you do is you start small. You say, okay, there's probably 20 different companies that have this specific footprint, whether that's a small Rails app or a Node app or, you know, we're going to stick with just AWS apps that look like this. Make it work really, really well for them. And then what you end up doing is you just start expanding and expanding and expanding. And before you know it, that ability to handle an environment that any company is trying to rebuild becomes a possibility.

(Tommy at 00:16:11) And so I think that's another reason why it takes a while for that trust cycle to happen is technology maturity, product maturity has to be there. And I remember looking at Datadog and New Relic in the early days, and we were just like, yeah, it's not ready yet. And then as you wait two or three more years and a couple technology cycles, all of a sudden you're like, yeah, this will work.

(Tommy at 00:16:32) And as the CTO of a public company, especially when you get to the larger enterprises, they really don't want to be the guinea pig. Right? They want to jump in when they're confident that it's a good decision because you're spending a lot of money on this stuff. It's not cheap and there's a lot of dependency in the organization on it. So, you know, it's a natural cycle.

(Tommy at 00:16:53) We started with small startups. We've worked our way up the chain of larger and larger companies. Still have room to go there until we can satisfy the needs of Amazon or somebody really, really big. You know, you've got to stick to it. It's like that persistence that you talked about that you learned when you were 12.

(Tommy at 00:17:13) I think that's the crazy entrepreneur trait that people don't value or don't understand is that the best entrepreneurs are just persistent. They just keep beating their head against the wall. And at some point, all of a sudden it opens up and everyone's like, man, that guy got successful overnight. And the reality is it was 20 years in the making of beating your head against the wall of persistence that really got you to where you want to be.

(Joel Beasley at 00:17:39) Oh, for sure. 100%. I started trying to make my first company around '10, '12-ish and, you know, failed miserably and then just kept trying to do things. And I had a little success. I'd say I had success with projects. Right?

(Joel Beasley at 00:17:56) I'd build something, sell it off, and, you know, it wasn't until I decided to, you know, like 20 years later when I was doing this podcast, I just decided, okay, I'm going to do this podcast. If I'm going to go do it, I'm going to do it until the day I die. I'm just going to go in comfortable knowing that whether nobody listens to it or whatnot, I will keep doing this until I die, and that's it. And I'll just have this ridiculous persistence applied to it.

(Joel Beasley at 00:18:23) So, yeah, I love that. I think when earlier, when you were talking about why entrepreneurs do it, I think one of the big draws to it is the fact that it seems like everything's stacked against you, but you still just dig your heels in and you stay persistent. And then just somehow, it just works. It just comes together right when it needs to come together, and those moments feel magical. Right?

(Tommy at 00:18:50) Yeah. And you kind of have this view of the world that doesn't exist yet either. Right? For us, the view of the world is ideas, and this is something I learned when I was in a larger organization. There's so many good ideas inside of every company.

(Tommy at 00:19:07) Every individual that exists in your development team or your product team or your DevOps team, there's really amazing ideas embedded in those people. But to get those ideas from just somebody's head out into a software product that users can use, there's a lot of friction in that. There's friction in organizational politics. There's friction in the technology that's needed to enable that. There's all of these kind of friction points that keep ideas trapped behind whatever barriers that are there.

(Tommy at 00:19:43) And the world that we kind of envision, you know, when I started this company, I wasn't like, man, I really want to go build DevOps tooling. I had a bigger idea, you know, and got really excited when I thought about the fact that every company we work with, they're trying to accomplish something big in the world. And if we can make it easier to get their ideas out in front of their users, then we are doing something really impactful. And a mission-driven DevOps company, I think, is a little bit kind of, probably doesn't exist. Maybe it does. I haven't run across one who's really mission-oriented.

(Tommy at 00:20:14) But we look at this as ideas are trapped. They need to be easier to get to the world. And when we went and experienced this for ourselves at TrueCar, it was hard to get stuff out. And then when we talked to other engineering leaders, they would say, yeah, it's really difficult to do continuous integration and deployment at the pace that we want. And then when you rolled that back further, you would ask them why. You keep asking why. And environments tend to keep coming up over and over again.

(Tommy at 00:20:45) It just was like, well, it's just kind of hard to make them. It's hard for our developers to trust whether the underlying infrastructure that they're using looks like production. And there's all of these problems in and around environments. And so the entry point into our mission is solving environments. Right? I think that's a huge impediment in the software development process that everybody deals with. But in the long run, you know, if we are crazy and we see this out 15, 20 years, you know, making ideas get to the world easier, environments will be a part of that. But there'll be all sorts of other things that we could do to help solve that problem.

(Tommy at 00:21:21) So this is just where we saw the biggest pain point, and I think that's, you know, for an entrepreneur, you probably have, I always talk about Elon Musk wants to go to Mars. But when he went to Mars, he didn't just say we're going to build a rocket to go to Mars. He said, let's build a reusable rocket first. That was step one on that journey. But he always had that vision, Mars is the endpoint.

(Tommy at 00:21:42) So I think it's important. And that's what keeps me motivated is, hey, if I can help a company accomplish their mission and in turn that does something really impactful and positive for the world, you know, we're making it this much closer to that end state of getting these ideas out. So, you know, I kind of am a little philosophical about that stuff and mission-oriented and driven, but, you know, I think you kind of have to be when you're an entrepreneur. Right?

(Joel Beasley at 00:22:08) Absolutely. And I enjoy your perspective on that. I like it. So you have five kids. Right?

(Tommy at 00:22:15) Five kids. Yep.

(Joel Beasley at 00:22:16) I have two. There's one on the way, so I'm excited. And I always like to think, I heard once somebody said, explain it to me like I'm a three-year-old. Right? And so how do you explain environments if you explain it to a three-year-old?

(Tommy at 00:22:31) If I explain it to my kids, well, I usually just tell them, I don't actually go all the way into environments. I always tell them, who do you think made all the money in the gold rush? And it's the people selling pickaxes. So I always tell my kids that I make pickaxes for software developers.

(Tommy at 00:22:49) And they're like, oh, that's cool. And then they run off. They don't care. But if I was to explain it, it's, you know, hey, when you have an app on your phone, right, that's the environment that that app runs in. We do that for big, complicated, server-based applications. That's how I explain it usually.

(Joel Beasley at 00:23:07) Very cool. And then when you started this, did you just self-fund? Or how did you get it going?

(Tommy at 00:23:14) You know, the first six months, me and the three founders met at David Giffin's house and hacked on this in his living room for six months. So self-funded it. And then we got our first customer, which, you know, until you get your first customer, you don't really have anything. You just have a crazy idea that you're hacking on. And that made it a little more real.

(Tommy at 00:23:36) And we're like, all right, if we're really going to do this, this is a technically complex problem. We're going to need to raise money. And so we had done Y Combinator 10 years ago. Well, it's not 10 anymore, it's 13. I keep saying 10 because that's what I said at the beginning of this journey at Release. It was 13 years ago in 2009. We did Y Combinator for our last startup, and we loved the way that it forced us to spend, and if you don't know about Y Combinator, it's a startup accelerator, probably the biggest, it is the biggest one in the world. Airbnb, Stripe, you know, all these companies started there.

(Tommy at 00:24:13) And for the first, when you go into the program, the first 90 days, you essentially obsess isolated in an apartment somewhere in Silicon Valley. So me and Eric and David, even though we have kids, all of us, we decided to move up to Mountain View, get this tiny, crappy little apartment, and we basically did nothing but work on this problem from seven in the morning until midnight every day. And the other nice part about Y Combinator is you get, you know, now there's 250, well, there was 250 companies that were peers of ours in that program at the time. I think now they do like 400 or 500 and this is just a couple years later. So you have all these other entrepreneurs who are building things and a lot of it's, you know, technology-based.

(Tommy at 00:24:56) So we had a cohort of people that we could sell to sitting right next to us. So, you know, they fund you a little bit, you know, it's like a tiny little seed round, like 150K. And then you get to go into this demo day where a bunch of investors kind of show up. The challenge for us was, this is winter of 2020, and three weeks before demo day at Y Combinator, COVID shut the world down. And so we were all excited. We had some customers that were coming on. We were getting really good feedback from investors, and then the world shut down.

(Tommy at 00:25:26) And we were like, man, this probably isn't going to be good. And the world really thought, for two to three weeks there, everything was going to tip over. And actually, it was funny, two to three weeks later, everybody kind of took a step back and said, you know what? Things might not just completely implode. People started working from home. Investors started coming back. And in the middle of that, Sequoia Capital led our seed round, which is crazy to think that, you know, we raised $2.5 million right in the middle of that all happening. But that's kind of how we got things off the ground.

(Tommy at 00:26:02) And since then, we've raised our Series A, another $20 million. And, you know, it's kind of, we have enough capital to get closer and closer to that mission. And this is technically hard. We need good engineers to help solve the problem. You know, it's a difficult problem, so it's not cheap to do.

(Joel Beasley at 00:26:19) How do you go to market, or how do you sell it? Can people go on and try it, or do they book a meeting? How does that work?

(Tommy at 00:26:27) Yeah. There's, you know, typically we like to do a demo of the product, you know, hear really what somebody's trying to solve. Because as we listen to companies that are kind of thinking about how do they make their software development process more efficient, there's always a nuance along the way that, you know, they've got an application that works some way or a process that works another way. And I really like to tailor, here's how the product will solve that specific problem. So we generally do a product demo, but there are ways to get into the product, you know, kind of bottoms-up, free version. Just tinker with it on your own.

(Tommy at 00:27:01) So you can go to the site, click on the login button at the top, and you can get into the app and start playing around with it. But generally, what happens is we'll meet with usually a VP of engineering or a CTO because they're the ones in the organization that are really trying to solve for this organizational efficiency. Right? They have product managers, QA people, designers, engineers, all of these different stakeholders that are working on building products.

(Tommy at 00:27:33) And their job is, how do I make all these people efficient? They're expensive. How do I make all of these folks collaborate in a better way? And they're usually on the hook. And this was the case for me when I was at TrueCar.

(Tommy at 00:27:44) I was on the hook to make all of these organizations more efficient. So we'll usually have a conversation with the head of engineering or the CTO and, you know, talk about the collaborative nature of how environments can solve that problem. And they'll put us in front of the DevOps team and then we chat with those folks and talk about their applications. And then, you know, usually at that point, they either jump right in and say, okay, we want to use you guys, or we do a proof of concept and off we go and we give it a try. But, you know, we try to make that short.

(Tommy at 00:28:15) You know, if you try to build an environment management platform internally, it could take you 12, 18, 24 months just to get it going. And so we're trying to shrink that, getting it up and making it useful to your engineering team down to weeks. So a two-year project or a 12-month project, shrinking that down to three or four weeks, which is just the get it up and running phase of our product, you know, there's a huge time to value thing that we help solve. And so, you know, it's a conversation with the company to try to figure out how to get their apps and their environments up and running. Most of it's automated.

(Tommy at 00:28:57) You know, you come in, you tell us what repository you want in your application. We build an environment blueprint out of it. And then from that blueprint, we can just reproduce the environment over and over and over again. But, you know, I really pride ourselves in that personal touch too. Right?

(Tommy at 00:29:12) One of the things that I've always loved about AWS is, you know, the customer obsession stuff that they do. And I think that bottoms-up products where you can just go in, log in, and use it are great. But there is something to be said about really understanding your customer and helping them solve these problems. So we like to have those conversations, but if you're an engineer and you don't want to, just hit the login button on the site and you'll get into it.

(Joel Beasley at 00:29:38) I love it. I love it when people do that because so often, you know, when I was engineering, I just would be like, I just need to see it real quick just to see if this is going to solve my problem. And then if there was a degree of trust there and I'm like, oh, I think this might, then I'd go book a meeting, but I just need that. There's so much. Little taste.

(Joel Beasley at 00:29:58) Yeah. Yeah. What did they call it? I think it used to be vaporware or there was some word for things that, you know, people would put out there, but and they advertise it one way and then it does another way. So being able to just see it or put your hands on it for a second is super valuable.

(Tommy at 00:30:13) Yeah. Yeah. It really is.

(Joel Beasley at 00:30:15) Yeah. You mentioned you guys raised some money, but as far as people go, revenue goes, how has your company been growing?

(Tommy at 00:30:23) I mean, we're growing like crazy. We can't hire engineers fast enough. The team has grown, I don't know, let's see, like 4x over the last 12 months. You know, customer growth is really good. We're getting good customers that are paying us a good amount coming into the product.

(Tommy at 00:30:41) So, you know, I think we usually don't talk about what the public, you know, what the numbers are. But I think the most encouraging thing for us is not really, obviously our investors and everybody wants to make a ton of money. But I think the most encouraging thing for me is, you know, we can pull this off. I think it's really important. You know, when you go look at a lot of these tools that exist out there and, you know, they claim, like you said, the vaporware side of it, it's a real problem.

(Tommy at 00:31:08) You try something, it doesn't quite work. And I think we did a lot of things that didn't scale in the early days too. We would hand hold a customer getting onboarded onto the product, literally doing it ourselves. And even to this day, we'll do that for companies if they really need us to. And I think that's allowed us to build a better product because we see it firsthand from their point of view.

(Tommy at 00:31:34) And so that's one of the other trade-offs of having a bottoms-up freemium product. You kind of can't see it directly. When you do a more controlled, "we'll help you get your application set up and running in Release," we really get a good inside view of what does it take to make this stuff work. In the first ten, fifteen customers we had, we had to do that. There was no way to have a bottoms-up product that could consume anybody's environments and just reproduce them over and over again.

(Tommy at 00:32:04) If anybody claims that they can do that, they're lying to you. It cannot happen. So I think even to this day, every customer that comes on, we learn something unique and new. And that goes back to that earlier conversation that we talked about where in the early days of Datadog or LaunchDarkly, it was very narrow. And then over time, the surface area of what they could solve just kind of grows and grows and grows.

(Tommy at 00:32:29) That's where we are right now. A new customer comes on, they've got some requirement that we didn't really think about initially. We now have the building blocks to solve, I would say, 99% of the issues that people have when they're trying to reproduce environments or get their application up and running in Release. So I think we're at that point now.

(Joel Beasley at 00:32:49) Nice. I'm excited. I want to make sure I'm watching time here. I did want to get a couple leadership questions in. Is that cool?

(Tommy at 00:32:56) Sure. Yeah.

(Joel Beasley at 00:32:57) All right. So if you were to design the perfect leadership training program for your direct reports specifically, what would be the most important concept taught in that program?

(Tommy at 00:33:10) You know, I actually went through a big leadership program at my last company and really enjoyed it. We had these two executive coaches that came and worked with us. Awesome guys. Still friends with them to this day. One of the things that I really took away from that was this concept of your number one team. And it's tough when you're a leader because you tend to think that your job as a leader is to manage your reports.

(Tommy at 00:33:39) That's your number one priority. I have all these people that work for me. I need to nurture and cater to them, which is 100% true. You have to. But your number one team is actually your group of peers.

(Tommy at 00:33:51) Right? So if you are, let's say, a software engineering leader. Right? You might be a director of engineering and there's four or five other software engineering leaders that report to the same boss. Your number one team is that group of other software engineering leaders that you are working together with to make that entire organization effective.

(Tommy at 00:34:13) And so I think the most important trait that I tend to want to see for people that work for me, either as the CEO today or the CTO then, was how well do my direct reports collaborate with each other? And fostering an environment where they do collaborate with each other. Because nothing in today's modern enterprises is solvable without massive amounts of collaboration. And so if your direct reports can't work with their peers, collaboration falls apart and therefore it slows everything down. And so honestly, environments kind of foster collaboration, so it kind of fits into the mold of that thought.

(Tommy at 00:34:59) But the thing that I would see when we had really, really effective teams, and I've always had really effective teams, is when my direct reports can collaborate well. And it's the responsibility of the leader to create an environment where that collaboration can happen. You know, off-sites, people kind of joke about those, but they're really important because you build those personal connections. Doing things together that are fun. You take your group, your team that works for you out and you have a good time together. You learn about each other.

(Tommy at 00:35:31) You actually know them. Those things foster free communication amongst that collaborative peer group, and it's really, really important. That then helps them be better managers to the people that report to them. And if everybody all the way down the chain does that, you get a highly collaborative organization. And I think it's probably the single most important leadership skill. Can you foster collaboration amongst people that work for you?

(Joel Beasley at 00:35:56) I like that. You said 20 things that I thought were amazing there.

(Tommy at 00:36:01) Yes. It's all Tony and Kendall Lyman. If you ever want a recommendation for really good executive coaches, those two guys are really good.

(Joel Beasley at 00:36:08) Absolutely. Yeah. The production team, make a note to follow up on that. I always look for great people to refer because people will ask me all the time for different things. And we have a chat area on the website, so we get people asking us for recommendations, but we also get people asking us questions.

(Joel Beasley at 00:36:26) I do have a question here from that chat bubble. Yeah. So often these are ambiguous, right? They lack context. You get it. When a leader doesn't know something or gets something wrong, what is the best way to communicate that to the team?

(Tommy at 00:36:43) Yeah. Just admit it. Just say I screwed up, or I don't know. You'd be surprised how powerful that is to just say, you know what? I don't know the answer to that, but I'll get it for you, and I'll get back to you.

(Tommy at 00:36:55) And you know, everybody's human here, right? We all make mistakes. So it'd be impossible for any leader to do everything perfectly. And when you screw up, just own up to it. You'll be surprised how far that goes.

(Tommy at 00:37:05) It really is powerful to hear somebody that you work for or in an organization that you belong to just say, you know what? I made a mistake here. I was wrong. Here's why I was wrong.

(Tommy at 00:37:22) I should have this conversation with my wife. She would tell me I probably don't do this with her. But in work, you've got to be able to say, hey, this isn't my strongest suit or I made a mistake. And being vulnerable as a leader allows people to relate to you better. And if you kind of put on the persona that you're infallible and that you never make mistakes, I think there's some merit to some leaders who have taken that a long way and figured out how to ride that train for a long way, but I don't think it's lasting.

(Tommy at 00:37:59) Those aren't the leaders that we'll remember or that we respect. I think the ones who can be vulnerable and have that kind of high EQ side of their personality, those are the ones that you remember.

(Joel Beasley at 00:38:16) Because people don't remember what you say. They remember how you make them feel.

(Tommy at 00:38:22) Exactly. Exactly. You know, especially when you have kids and I have kids, I think these are skills that I now know when I'm in my forties that I probably didn't know when I was in my twenties and how important fostering that emotional security, emotional safety is. If you don't feel like you can go to your manager, your boss, or whatever, then you can't get that collaboration that I was talking about before.

(Tommy at 00:38:45) And so I think it all kind of stems from just admit when you're wrong and be vulnerable and who cares? So what? Everybody makes mistakes. You don't want to make mistakes constantly. You've got to be right.

(Tommy at 00:38:57) You know, I think Amazon has a leadership principle that says you're right most of the time. That's one of Amazon's leadership principles. I like that one. But when you're not, you should be able to say, you know what? I screwed up.

(Joel Beasley at 00:39:09) Yes. I found that became a lot easier for me as I became more experienced as an entrepreneur because when my focus is just developing the most efficient system to get to the end result, then all sorts of ego, everything drops off. And then it's just you pull things out of the shadows into the light. You address them, you move forward. And so I like doing that.

(Joel Beasley at 00:39:31) Multiple time mistake questions. So I've made mistakes. I'm a big fan of saying, you know, I try not to make the same mistake twice, right? First time it can catch you off guard, but you try to put a system in place so it doesn't happen again.

(Joel Beasley at 00:39:45) However, throughout our progression and growth in life, there are mistakes that we'll make multiple times before we finally solve them. Do you have one of those off the top of your head that you can share? A mistake that you were making several times until you finally solved it?

(Tommy at 00:39:58) Yeah. I mean, I think it kind of happens in the normal course of business. One that we've recently been dealing with internally, and this is, again, me being vulnerable. Customer success. When you're dealing with a bunch of customers on and you have to ensure that they're all happy, things are complicated.

(Tommy at 00:40:18) These things, you know, it's not simple to know all the variables of everything that's going on. And I think in this role and then even in previous companies I've had, seeing things not communicated well back to a customer has happened more than twice. You know, it's repeated mistakes of, man, we forgot to communicate the status of a project or a status of something that we're doing, which caused the customer to kind of tip over or not work the way we expected it to. I think that is something that we're currently spending a lot of time on at Release trying to figure out. How do we be better about letting our customers know what products we have, how they can solve things, or if they're onboarding into the product, how do we make sure they understand what the status of that is?

(Tommy at 00:41:03) And I think we've made repeated mistakes in all of that stuff over the years. And you know, it's always a work in progress. So we do retrospectives where we go back and we say, okay, what was the timeline? And then you identify, oh, that's where it fell down, right?

(Tommy at 00:41:20) And that's how we tend to improve our process. When we have something like that that's happened once or multiple times, we do a blameless post-mortem where we look at it over the timeline. Who cares whose fault it was. And you'll see it pop out like, oh, we didn't give a status update on this date or we didn't communicate this properly. How are we going to ensure that doesn't happen again? And then you put, for better or worse, you put a process in place to kind of ensure that those things don't happen anymore. Um, whether that's automating something, which I tend to want to do, is automate it with technology, or just like, hey, when we get to this step of the process, just make sure the customer's aware of it.

(Tommy at 00:42:01) Right? And you can see that stuff. Those post-mortems are invaluable for that. And you know, I think those mistakes as an entrepreneur, you bump across them all the time, but I'm telling you, man, they're one of the best learning things that you'll go through. When you bump across a mistake multiple times, you actually resolve it, and now you're better for it. So I actually, you know, the failures, they hurt in the moment, but in the long run, they're incredibly powerful to ensure that you kind of evolve as an organization.

(Joel Beasley at 00:42:33) Yes. Absolutely. People want to learn more about Release. If they want to try it, where do they go? What do they do?

(Tommy at 00:42:39) Yeah. If you want to try Release, go to releasehub.com. You can fill out the request a demo or request access form on the homepage. I see all of them. So we'll make sure that you get the best product demo.

(Tommy at 00:42:56) If you don't want to do it that way, just click on the login button in the top right. You can get right in with a GitHub, Bitbucket, or GitLab account. And yep, that's how you try it. Give it a shot.

(Joel Beasley at 00:43:08) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.