How to Build With Confidence with LaunchDarkly

John Kodumal:

A lot of times, the reason why organizations move slowly with respect to delivering change in software is fear. A lot of times what's holding you back is not the quality of your development team, but technical debt and the fear of changing code or the fear of making changes to software that's poorly understood. And that's holding you back, you know. I think the connection that folks are making now is if your engineering teams are moving slow, if you're developing software slowly, you can't deliver change at a rapid pace, you're falling behind. And the connection there is, you're sort of giving your teams fewer at bats, right? If your engineering teams can't move quickly, then you're unable to try out new ideas. You're unable to experiment. You’re unable to move quickly enough to deliver great customer experiences. And I think once you accept that—the connection between moving quickly and moving with confidence and delivering business outcomes becomes much more clear.

Liesse Jones:

Today we're joined by CTO and Co-founder of LaunchDarkly, John Kodumal. LaunchDarkly is a feature management platform that gives developers total control of their code so that they can ship quicker, reduce risk, and reclaim their nights and weekends. We're going to talk about why having tools that help devs build with confidence is essential to a successful DevOps culture and John's top tips for enterprises who are early in their DevOps adoption.

Welcome to DevOps State of Mind. A podcast where we dive deep into the DevOps culture and chat with friends from small startups and large enterprises about what DevOps looks like in their organizations. I'm Liesse from LogDNA. Join us as we get into a DevOps state of mind. Hey John, thank you for joining us.

John Kodumal:

Thanks for having me.

Liesse Jones:

Yeah, this is super fun! Before we dive in, tell our listeners a little bit about LaunchDarkly and the problems that you guys are solving.

John Kodumal:

Yeah. I'm the Co-founder and CTO of LaunchDarkly. We were founded about seven years ago. We're based out of Oakland, but obviously, like a lot of other companies post-COVID we've become increasingly a remote company. We are pioneers in the space of feature management, which I know we're going to spend a chunk of time talking about. We’re about 350 folks these days. We've raised several rounds of VC funding—we just closed a $200 million series D round. We have about 25% of the Fortune 100 using the LaunchDarkly platform and over 2,500 enterprise customers taking advantage of the platform.

Liesse Jones:

That’s so cool. LaunchDarkly has been on my radar for quite a while. Before LogDNA I worked at Bitnami—we were very familiar and friendly with you guys as well. And I've had the chance, on the partner marketing side, to work with some folks at LaunchDarkly. And I have to say everybody is awesome. Super friendly. Just a really smart, cool group of people. So, great job.

John Kodumal:

Thank you. We've been really intentional about our culture and so I'm glad to see that reflected in the interactions you've had with the folks on our team.

Liesse Jones:

Yeah, absolutely. Everybody is amazing. I was just at KubeCon in LA last week—first in-person event for a long time—and it was nice to see some of the folks and meet some new people from the LaunchDarkly side. That was great. For people listening, who don't know, can you just tell us what feature management is?

John Kodumal:

Absolutely. There's a lot of ways to describe feature management. And one of the ways that I like to describe it is it's an identification of a broken process and the way that we release software. So the way I'll describe that is, traditionally when people were deploying software, they kind of conflated two steps together—deploying software and releasing software. Deploying software meant also releasing it to everybody. So, you know, you'd package up an artifact, you'd put it out on a server, and then you’d point all your traffic to it. And everybody would be experiencing that new version of the software. And the flaw that we recognized—the flaw that feature management tries to address is—you should be able to deploy your software to a server and be able to point, or route, traffic to it, but you should be able to release that change in a much more granular way. And you can use that more granular release process to mitigate risk, to expose the change to a smaller set of users to reduce the blast radius and the impact if something is going wrong and also to more rapidly roll that change back. And so when you decouple deploying software from releasing software, it just unlocks a massive amount of additional superpowers for your team to capitalize on. Especially in a world that's more and more continuous, more and more software-driven, where organizations are working really, really hard to become software-driven and to become elite in the way that they build and deploy their software.

Liesse Jones:

Yeah, absolutely. I think there's a slight nuance that people might be curious about—the change in language from feature flagging to feature management. Can you talk a little bit about that?

John Kodumal:

Yeah, that's a really good point. I guess the way that I think about it is that a feature flag is a tool, it’s a means to an end. It's a mechanism. It's the means by which you can achieve that change. And feature management is really the change that you want, the change that drives your business forward. So when we think about feature management, we're not really selling you feature flags, we're selling you the ability to reduce risk as you deploy software, to give you more ability to control how your customers or end users are experiencing your software, and more ability to measure the impact of the software that you're building. That's the story we're trying to tell. It's not like you can use feature flags in your software development here like, “here's some feature flags.” Feature flags are incredibly powerful but what's a lot more interesting is the capabilities that those feature flags unlock within an organization.

Liesse Jones:

Yeah, absolutely. It's the shift in a style of working rather than just the tool that enables that. Much like DevOps. I think that's a common confusion for people who are talking about DevOps, and it's such an ambiguous term anyways. We see people use it in a way that's synonymous with CI/CD which is—it just misses so much more.

John Kodumal:

Yeah, absolutely.

Liesse Jones:

Okay, cool. That's really interesting. You guys have been doing this for a little while. When was LaunchDarkly founded?

John Kodumal:

2014.

Liesse Jones:

ame age as we are. We were in: 2015

John Kodumal:

Yeah, we were one of the earliest customers of LogDNA.

Liesse Jones:

Yes! That’s amazing. The product has changed a lot in that time, on our side, but the industry has changed a lot in a short amount of time. I'm sure you've seen that on your side as well. How have you seen specifically the market's reaction to the concept of feature management change over those last five years—or six, seven, however long it’s been.

John Kodumal:

It's been a remarkable change. People talk about startups as, you know, folks that are able to see a way before it comes in and capitalize on it—ride that wave. And I think we have been able to do that. When we first started LaunchDarkly it was hard explaining the value proposition. It was hard to get people to understand what we were, what we were trying to do. And there was this whole other space of experimentation and A/B testing, that when people heard our pitch people naturally gravitated towards that and thought that we should be in the same category as that and were confused as to why this was a different thing. So, you know, it was pretty difficult to raise funds when we started, we worked really hard to get our seed round closed and to get our series A closed after that. And, if you look at our sales for like the first year or so, it took a long while before we had some initial traction and before that really took off. If you looked at the first two years of our existence across all of our metrics, you wouldn't see anything that even comes close to approximating a hockey stick or anything close to that. It took a long while. One of the other lenses that I use to think about how the space has matured is, you know, we were very fortunate to have some folks at Microsoft invite us to Microsoft Build, even as a really early stage startup. So we had a keynote talk in Microsoft Build, I think in our second year of existence, and we've been fortunate to partner with Microsoft and continue to attend Microsoft Build over the years. I remember attending Microsoft Build the first year we were there and people would walk up to our booth and go, “what is this? I don't understand this at all.” A few years later, I came back to Build and joined in and sat at our booth and we had customers (prospects) coming up to us from some pretty notable companies—and the message went from like, “what is this? I've never seen this before. What are you talking about?” to, “we have a feature management initiative and we have budget set up for the next year. Tell us why you're the right solution for us” or, “we look at you as the leaders in the space, tell us how to get there.” And that maturation is just an amazing sign of how we've progressed.

Liesse Jones:

What do you attribute that to? The shift in mindset. I mean, you can attribute it to yourselves if that's appropriate, too. Like it might be just being out there, educating people about what feature management is and why they should care about it.

John Kodumal:

Yeah. I mean, it's an incredible amount of work by everyone on the team, from the marketing folks to the product folks. It's also a convergence of ideas on the DevOps side of the world, that I think really aligns with our message. Things like the value of delivering software faster, things like the DORA Metrics and other movements to sort of become more quantitative and modern about our approaches to DevOps, and an understanding that DevOps is not just agile and it's not just an issue tracking tool and a CI/CD tool. It's a lot of stuff that happens in operation as well. I'm sure you know, from logging, you sort of see the same story of, we need more tools to give us an understanding of what's happening at runtime. And we fit into that bucket of things as well. So it's a lot of things coming together.

Liesse Jones:

It's interesting that you mention that because I think sometimes when talking about DevOps there's such a strong focus on the developer side of it and pushing more things onto the developer. The developers should be thinking about operations and about security and about how their application runs in production, which is true, but we kind of miss this concept of operations should also be thinking about the development process and tying things to moving quickly and getting new products out there that actually deliver value for the business. And we think about that because of logs, obviously, like you just mentioned, and you guys do too, but it's funny to see how often people forget about the operators in DevOps.

John Kodumal:

Yeah. No, I think that's a really good point. One of the ways I think about it is like, there's really only so much you can lump onto a developer developing software and if you throw operations on them, that makes them busier. And then now there's the DevSecOps movement and it's sort of like, there's something behind all of those words, all of those motions that is important, and I think it's not just lumping it onto the developer persona. It's more about having those teams work together. It's more about having operations that are operating as an integrated team with the developers and security folks operating as a team with developers. It's not about throwing more words on the developer or throwing more requirements on the developer to get a piece of code out into production and just throwing that on their plate. It's not like DevOps means everybody has to be a developer and an operator [or that] DevSecOps means everybody has to be a security specialist and a developer and an operations expert. That's just too much. It's just more about teams operating in a more integrated manner, I think.

Liesse Jones:

Absolutely. So we've just started kind of recording these sessions for this podcast, but I've had a chance to talk to a few folks already and some of the concepts that have come up again and again are talking about empathy and trust. Trust is just so foundational to the DevOps style of work and I think it's cool that in every conversation basically that's come up and people are like, yeah, start there. Think about how we can lean on each other as experts in their respective roles. That's where it has to start.

John Kodumal:

Yeah, I agree with that completely.

I'm really proud of our security team at LaunchDarkly—our application security engineers and security team as a whole. I think one of the things that we've done differently is we've had them work really tightly and really closely with our software developers. And we kind of built that into the culture of what we do. For example, at a lot of organizations governance, risk, compliance, that whole side of the world is very antagonistic with the software development team. But that's not the case here at LaunchDarkly. We're all kind of going in the same direction. Everybody understands the importance of those kinds of initiatives within what we do. And I see that in our engineers. I see that in them having an enormous amount of trust in the requests that are being made to them from like the GRC side and from the security side.

Liesse Jones:

That's awesome. Talking about DevSecOps, I know it's kind of a buzz word, we think about it a lot at LogDNA and it sounds like you guys work in that style internally, but what about externally? How important is the concept of DevSecOps to your customers? Is it something that they're thinking about right now?

John Kodumal:

It is. I think what our customers want to see is just that we have a mature practice. Our customers are enterprise software companies and what they're interested in is—I think the way that I think about it is it's sort of like when you bring on a SaaS vendor, when you're trusting a third-party SaaS vendor, there's a model where you're sort of delegating part of the security aspect of your business to them. And you're only willing to do that if you trust them to be as secure and as mature about security, compliance [and] risk, as you are as an organization. So if you are counting some of the Fortune 100 as your customers, they're only as secure as you are. And that's really what they're looking for, is some assurance that you can operate with the same standards and the same maturity models as them.

Liesse Jones:

Absolutely. And I think if there was any hiding from that in the past, there is no hiding from that now. It's just in everybody's faces. You have to protect yourself.

John Kodumal:

Well you can't sell software to the enterprise without maturity in those dimensions.

Liesse Jones:

No. And even if you do have maturity in those dimensions, as you said, we've seen that can sometimes not be enough. Which, I get the pleasure of working with the PR teams as well so we get to see a lot of that stuff. It's pretty insane at the top this year. Talking about enterprise software companies, what advice would you give leaders of organizations that are early in their adoption of DevOps practices, or just trying to figure out how to implement some aspects, if they're not ready to take the full leap, or if they're making incremental change?

John Kodumal:

I think my advice would be to try to detangle all of the things that seem incredibly tangled as they're trying to get going in this DevOps story. And try to find something that you can latch on to that you can pull out of that incredibly tangled ball of yarn that will give you some forward progress.

You know, I'm from LaunchDarkly, I'm going to sell feature flags to some degree, but feature flags are one of those things that, you know, we're lucky as a company in that you don't need to have a ton of prerequisites to take advantage of feature flags. You don't have to have a really sophisticated deployment system. You don't necessarily even need a very sophisticated microservices architecture. There's a lot of prerequisites that you don't need to have and you can begin taking advantage of feature flags kind of immediately. And so, one of my pieces of advice is [to] find those types of opportunities and latch onto them because otherwise it's incredibly difficult to tease all the technical debt apart, to tease all the interdependent projects that are needed to take you down the path towards modernization. I think that the most terrifying way to go about a modernization or a digital transformation, is to go, “okay, well, the first thing we have to do is this multi-year monolith to microservices migration.” That would not be the way I would go about it.

Liesse Jones:

I don't even know if people have that luxury now. I mean, I know that they do obviously, but I think what we saw with a lot of our customers over the last 18 months is that they had plans for multi-year migrations that were forced to accelerate. And so they just went with it. There was nothing else that they could possibly do. Which, in a way, is cool. It may have made it messier, but also I think that it has helped advance the industry as a whole, a lot more than it may have in such a short amount of time.

John Kodumal:

Yeah. I definitely think the pandemic in particular forced companies to accelerate across the board. Many companies that have made this transformation suddenly realized that it wasn't the thing that they could afford to do two or three years from now. It was dropped in their lap as like an immediate now—we need this now. One of the things we saw was the uncertainty and the rapidly changing conditions required businesses to really rapidly adapt to that change, whether that be regulatory change, laws or, we have customers in the restaurant sector—in the food industry—and they were going from this world where they were having people dining in restaurants to a world where, based on the locale, based on the state, based on the county even at times, the regulations were different. And those regulations were requiring them to deliver different software experiences to different customers. Right? Like if you're a pizza chain, for example, in some localities you could have in-store pickup and in others, you couldn't. And you had to have your software that adapted to that. And if you had to deploy that software every time you needed to change in response to regulatory change, you would have been dead in the water.

Liesse Jones:

Absolutely. We also have had the opportunity to work with some industries where it was like, you can use this time to do a lot of the things that you wanted to but didn't have the time or resources to. Like the airline industry, for example, that was definitely a moment to grab it by the horns and be like, okay, we're completely moving to cloud now. Or, we're shifting all of this stuff to a microservices architecture. There were some blessings in disguise there, you know, it's really hard to do that when you are operating at full speed.

John Kodumal:

Yeah, we saw them kind of go two different ways, right? Some organizations embraced it as an opportunity and others, because of the fear on how long this would take or how it would impact their budgets, there were some teams that just paused on a lot of innovation, like just stopped bringing in new initiatives or new technologies into the fold during that time.

Liesse Jones:

Absolutely. As a leader yourself, how do you think about embracing those moments, you know, over the last 18 months, I'm sure you've faced the same things as many other leaders of organizations. What's your approach?

John Kodumal:

global financial crisis [in]: 2008

Liesse Jones:

Cool, awesome approach.

To shift gears a little bit, I do want to drill into one thing that I think is central to LaunchDarkly, which is this concept of building with confidence. And I would love to just have you kind of walk us through that and why you think that's so important and specifically important to the style of work that we're talking about.

John Kodumal:

Yeah. I think building with confidence, the importance of that connects to the following idea. Which is that the reason, a lot of times, the reason why organizations move slowly with respect to delivering change in software is fear. A lot of times what's holding you back is not the quality of your development team, but technical debt and the fear of changing code or the fear of making changes to software that's poorly understood. And that's holding you back, you know. I think the connection that folks are making now is if your engineering teams are moving slow, if you're developing software slowly, you can't deliver change at a rapid pace, you're falling behind. And the connection there is, you're sort of giving your teams fewer at bats, right? Like if your engineering teams can't move quickly, then you're unable to try out new ideas. You're unable to experiment. You’re unable to move quickly enough to deliver great customer experiences. And I think once you accept that—like the connection between moving quickly and moving with confidence and delivering business outcomes becomes much more clear, right? Especially as your business transforms from software being a secondary part of the experience to software being the primary interaction point between your company and your customer—which is the reality that so many companies faced, especially during the pandemic, we're now all doing all of our banking over a mobile application, so that banking experience had better be exceptional. I think the thing holding back a lot of these organizations has been fear. And the thing that LaunchDarkly can provide, the thing that feature management can provide, is that risk mitigation. And that helps you move faster. That helps you deliver better software experiences over time.

Liesse Jones:

Yeah, I love that. I was talking to our CEO recently and I asked him this question, how do you feel about the statement, “move fast and break things?” and he was like, “I like it. But, move fast, break things and then fix them before it's customer impacting.”

John Kodumal:

at's the old Facebook—circa: 2006

Liesse Jones:

Yeah. That's amazing. “Move fast and measure things.” Did you come up with that one? Love it. No, it's okay. It's from your mouth and we're recording. You get the trademark on that, for sure. I'll let your marketing people know, they'll be thrilled with you.

John Kodumal:

I’m sure a number of people have thought of that long before me, so I will not take credit.

Liesse Jones: It's a good one though. Thank you for sharing.

Okay, last question. What do you think the future of DevOps looks like?

John Kodumal:

I'll touch on a point that we made earlier, which is that we have more and more teams operating in an integrated fashion. When I think about what the future of DevOps looks like, I think it's more of that. And I think it's more of that extending beyond engineering roles. So beyond just DevOps and DevSecOps. How do we take product managers and how do we integrate them more into the delivery practice? How do we take designers and integrate them more tightly into the delivery practice? It sounds abstract, but a really concrete example of this is, we're starting to roll out ephemeral environments in our workflow. So that means that anytime there's a pull request there’s a LaunchDarkly environment spun up that is posting that code or is deploying that branch of the code. And that means that designers can go in and interact with the things that their engineers have built, the designs that their engineers have built, and that's a way of bringing designers into this continuous process—the software development life cycle. And when I think about DevOps, I think about more and more things moving into that kind of mode where it's like collaborative software teams continuously operating together. And I think of it as a broader thing than just DevOps. I think of it as the way that software will be built in the future as a multi-disciplinary kind of activity, that's all operating continuously.

Liesse Jones:

That’s awesome and I don't think it sounds abstract at all. I mean, truly in my mind in the future, sales and marketing and product and engineering all can collaborate. Thinking back to even The Phoenix project, right, this is the entire premise that it's built on—that sales asks for something that engineering can't deliver. They're forcing them to create something. If everybody has true insight into how their partners across the company are working and operating you can build something that's so much stronger, and that has input from the market, and where sales is continually providing feedback to the product team about what customers are needing and that can influence the future direction of the product. So I love that. I think it's awesome.

John Kodumal:

Yeah. I think if we can unlock that as an industry, if we could figure that out, the sky's the limit. What we can accomplish is going to be incredible.

Liesse Jones: Absolutely. Looking forward to talking to you again in five years and being like, “remember when we talked about this thing and now it's real?” Can’t wait.

John Kodumal:

Yeah, I'll take my flying car to your office.

Liesse Jones:

Awesome. I love it. Well, thank you so much for joining us, John. It's been awesome to chat with you! For people who would like to learn more about LaunchDarkly and feature management, where can they find out more?

John Kodumal:

They can go to launchdarkly.com. That's a great way to find out about us. You can learn all about what we do, what our mission is, and how we can impact you and your software development team.

Liesse Jones:

Awesome. Thank you so much.

John Kodumal:

Thank you.

Share Episode

Shownotes

Transcripts

Follow

Links

Chapters

Video

More from YouTube