Jenkins founder Kohsuke Kawaguchi (KK) and respected DevOps veteran Harpreet Singh have launched a new company called Launchable.
Launchable aims to help you improve your delivery velocity by prioritizing and applying some ML and intelligence to testing. There is still much work to be done but with these two industry luminaries behind it, the expectations are high for something impactful.
The VC community and a blue chip list of investors are already on board.
Yes, this means KK is no longer at CloudBees (several CloudBees execs are investors in Launchable) and Jenkins, while he is still an advisory. But, with Jenkins now in the capable hands of the CDF and Linux Foundation, and CloudBees well established, he felt this was a good time to pursue an issue he thinks needs to be solved.
Hear from KK and Harpreet themselves in this great podcast.
Alan Shimel: Hey, everyone, this is Alan Shimel for DevOps.com, and I am here, you’re listening to another DevOps Chat. We have some really great breaking news on this DevOps Chat. I’m really happy to have, snagged a dynamic duo of industry veterans in the DevOps space who have just started what promises to be perhaps a game changer in the DevOps industry. But they’re gonna tell us more about that, I don’t know.
Let me introduce you to Harpreet Singh.
Harpreet Singh: Hello.
Shimel: Hi, Harpreet, how are you?
Singh: Very well, thank you.
Shimel: Thank you. And Harpreet is co-CEO of the new company, and his co-CEO is none other than my friend, Kohsuke, K.K., founder of Jenkins, CloudBees and all of that good stuff. K.K., welcome.
Kohsuke Kawaguchi: Hello. Thanks.
Shimel: Okay, so, let’s talk about the big news. We have a new company in the DevOps space called Launchable.
Shimel: Is that—and the both of you are co-CEOs?
Singh: That’s right.
Shimel: And, of course, with your track record, I’m sure, you know, it wasn’t as hard as it is for a first time entrepreneur, but Launchable’s already raised some venture capital to help it get off the ground, including some high profile angels.
Kawaguchi: Yeah. We’ve been very lucky.
Shimel: Talk a little bit about it—who’s involved, who’s put some money in?
Kawaguchi: So, there are two big institutional investors. One is Barclays Ventures, and that comes from Harpreet’s long relationship with their partner, Gomesh. I think, in fact, your wives know each other. Like, it almost feels like an insider. [Laughter]
And then another VC is the unusual ventures, and that’s started by Unusual Ventures, and that’s started by John Vrionis. And John actually has been also an investor at CloudBees, so his people have seen us in action and know us well enough so, you know, you get their validation and then you endeavor it. It’s been—I’ve been truly grateful.
Shimel: Sure. Well, I’m familiar with Battery back in my day, it was a guy named Gerry Conlon out of Battery Ventures. I don’t know if either of you know Gerry, but he was instrumental early on in Battery. But yeah, they’re a great company. It sounds like two, you know, kind of blue blood venture capital firms in there.
There’s also some high profile angels including Sacha—Sacha Labourey, CEO of CloudBees, right?
Singh: Yeah, yeah. So, I think what was exciting for us as we were talking with people was just, you know, the phenomenal backing that we got from investors as well as—you know, these marquee investors as well as individual angels, right? So, we both have been at CloudBees.
So, I don’t like to think of ourselves as first time entrepreneurs, because we built CloudBees from less than 10 people to whatever it is today.
Singh: I had a sojourn to Atlassian, where I spent about a year and a half really learning from that phenomenal company. So, we were very lucky when people from CloudBees like Sacha, Michel—Michel Goossens, who was the VP of sales there at some point came in and invested. Bob Bickel, who’s been an industry veteran invested in us. And on the Atlassian side where the CTO is Sri Viswanath and Noah, who’s the head of tech teams, which is Jira, Bitbucket, Opshimi and all these comfortable investing in our capabilities and our mission.
Shimel: Absolutely. And make no mistake, you’re not first time entrepreneurs, because first time entrepreneurs don’t raise money that easily, guys.
Shimel: I mean, I think there’ll be a lot of people who listen to this podcast who are first time entrepreneurs and say, “Man, if we only had their background and their resume and their experience, it wouldn’t be as hard as it is.” I think a lot of first time entrepreneurs struggle—struggle with doing that.
But that’s great. It’s always good to have money in the bank when you start a venture, because it’s needed, but as we were talking about off camera a little bit, I’ve never met a successful startup entrepreneur who did not think what they were doing was in some way changing the world, making it better.
And so, I wanted to ask each of you individually—what really got your juices flowing? What really got you excited about what you guys are doing at Launchable?
Kawaguchi: Sure. Alright, so I’ll start. So, you know, one of the things I started—I created this sort of thinking and I felt like I put the state of the automation and the software development power to the next level in the world. And this automation, they produce a lot of data. And what I realized after a while was that, you know, in the rest of the world, in the rest of the business world, data is increasingly being used effectively to drive decisions and make people more efficient and so on.
But whereas in the software development, I feel like that actually hasn’t really happened. And I felt like this was a great shame, one as somebody who, you know, helps people produce a lot of data with these automation systems, but also, you know, we are the number people, we are the data people, right? We are the pride of ____, at least I think of it that way.
Kawaguchi: Yet, everywhere I look, I feel like we are making decisions, engineering decisions based on gut and instincts, and this can’t continue. And so, that’s what I kind of started thinking about after a while, and then this idea kind of grew and grew on me. So, yeah—so, that’s probably where my, how my juices got flowing.
Singh: Yeah, very similar. I think Kohsuke and me used to sit next to each other in the same office room at CloudBees and we used to talk about this all the time. We got the opportunity to see sales and marketing really be completely numbers driven, and we would come back and say, “Oh, if we could only do this on our engineering product side of the house, it would be so much better.” And the answer always was, “Well, it’s a craft.” And we think bringing data in there is important.
Singh: And so, that’s sort of what got us both going. My personal anecdote was, after I left and moved to Atlassian, I was talking to somebody out in my customer base there who had this challenge where their delivery velocity was slow and, you know, their aim was to put a few engineers to go in and look at it and how to improve it. And having the DevOps background and you understand CI/CD, I felt like—there has to be a better way to do this than just, “let’s allocate a few engineers and see what comes out of it.”
Singh: So, that’s sort of the problem space, and that’s what excited us.
Shimel: Excellent. And it is, it’s almost ironic or oxymoronic, even, when you think about it, right?
Shimel: Because—so, my background’s in information security, right? And one of the things we have seen in security is information overload, like data overload.
Shimel: The noise to signal ratio. But there have been—there have been a lot of security startups over the last, let’s say five years, seven years, who have really tried to fine tune that dial to get more signal to noise, to be able to automate going through the mounds and mounds of log data, for instance, right?
Shimel: So, you get a company like a Splunk that can just suck a lot of data in from everywhere. And then try to figure out, in an automated way—because there’s just too much to go through by hand—
Shimel: What’s important from a security point of view or maybe even from a network operations point of view. But as you guys said it, I’m thinking—we don’t really do that with our software development, do we?
Kawaguchi: Yeah. And I mean, when you describe it like, it might sound a little abstract program, but idealized, it’s actually connected in so many ways to frustrations that I have every day as a developer, right?
Let me give you an example. You know, I was working on this Jenkins project, and it’s a sizable project with lots of test cases, which is great, but what that means is that every time when anybody wants to make, like, a ____ change, the first thing that happens is, the CI system comes in and they run the whole one hour test cycle before the code review happens, and then somebody makes some observations or a suggestion that, “Oh, you should change this part to something else.” And then you follow that and then another whole hour of testing. And then that’s basically, like—two hours is a long time to wait if you get some change in, actually. And that happens all day in that area.
Shimel: No, no—I mean, so, let me be a half glass full kind of guy. It’s better than—the one hour is better than the one day it used to be before we automated some of this stuff, right?
Kawaguchi: That’s true.
Shimel: I remember back in my StillSecure days and we would—we didn’t even have a big enough infrastructure to do the testing, we would have to outsource, like, unit testing and all this stuff.
Kawaguchi: Yeah, so, let’s talk about that one big thing, right? Because that’s actually probably an even bigger program. And you said that that’s before automation, but I’ve seen teams every single day that actually have tests that run for more than a day, you know, [Cross talk].
Shimel: With automation?
Kawaguchi: Yeah, like an auto maker company putting a car together, a lot of big software. If you test them all, it’s in that cycle for weeks. So, there are a lot of pieces of software getting assembled together into something big, and that test gets even bigger.
So, what I started doing is, like—okay, so, every time you do this, it’s not like everything is changing all at the same time, right? There’s only small parts of the system it’s changing, and then when we re-run the whole test cycle. So, what if we could ____ the right subset for that test to run? They’re most likely detached programs, so they’ll not only finish quickly, but they also run cheap, and then you still get, like, a pretty sizable, meaningful feedback. You know, you’re not gonna get 100% coverage, but you might get 95%, and that’s plenty good, and that cuts the execution down in, let’s say, half.
And so, these are the kind of things I thought the data would actually enable, and I’ve seen some prior work, I’ve talked with teams who seem to be on the cusp of doing these things, and I felt like—yeah, this clearly makes sense. More and more people need it, and I need it. And so, that sort of became the founding idea behind Launchable.
Shimel: So, that was the itch you were looking to scratch here, as I say, right?
Kawaguchi: Yeah, right.
Singh: And you asked, like [Cross talk]—
Shimel: I’m sorry, go ahead.
Singh: Yeah, and as we were sort of thinking about this, right, we identified this problem and we’re thinking about, like—so, what’s the company’s mission, right? And we realized that every sort of software teams in the future or even today will drive every significant human achievement there. It’s really hard to think about anything that’s not being software delivered.
And our mission now is to take this artisan teams and actually make them data driven scientists to drive their velocity, you know, and deliver software confidently. So, that’s sort of our big itch and our big mission.
Shimel: Absolutely, got it. So, let me play devil’s advocate a little bit. You know, one of the things we always used to hear—I heard it in security, I heard it in QA—was, “Look, we don’t have enough time to do a full test, full testing. Let’s just test 80%, 70%, 90%”—take your pick, I don’t care what number you pick.
You know, Murphy’s Law says whatever you don’t test, that’ll be the thing, somehow, that breaks, right, or that causes a problem. And when we say, “Oh, my God, because we didn’t test that”—why didn’t we test that?
Kawaguchi: Right. So—
Shimel: “Why shouldn’t it get done?” Right.
Kawaguchi: Yeah. So, if you think of testing in isolation, then yes, that’s naturally a concern, because, you know, we need every help and every confidence we can get out of the test. So, like, why would you skip that? That doesn’t make sense.
But I think where it does make sense is actually, if you think about it, the software development life cycle is composed of a lot of different tests at a lot of different points. So, collectively, they should be seen as a whole system, right? I mean, this is things like—so, the code review, right? If that’s the only point in which you are getting tests run, then you want to run them all. But what happened is, after the cold gets reviewed and merged, then another set of the same tests will come in. So, it is really important that you run all the tests before the code review and spend one hour, or are you okay with 80% of the confidence that happens in, like, five minutes, right? Then knowing that the rest of the 20% get code immediately after.
I think there is an argument to be made that, overall, you’d be better off, even if some program slips down into the ____, so long as it gets eventually caught before the customer sees everything, so.
Shimel: So, I guess then that that begs the question is—can that be accomplished? And, to accomplish that, what’s it going to take?
Kawaguchi: Mm-hmm, yeah, and that’s what we are working on. I think, you know, the—so, I have some preliminary numbers, and they look good. Because if you think about it, the baseline that we are competing against is basically people running all the tests in a random order, and so, literally, you cannot do any worse than that. So, and instinctively as a developer, I know that certain tests are designed to catch certain programs in some specific things.
So, really, the only question is how well a machine learning model can learn these things over what amount of data. And that, over time, I think I’m sure is gonna get better and whatnot. And I don’t know exactly what kind of impact we can create or what product, but overall, I’m feeling pretty confident. You know, it just needs to be good enough to start making an impact, and it’s only gonna go up from there.
Shimel: Harpreet, what does success look like for you?
Singh: Well, this has been a question that’s been asked to us while we were raising funds. I like to think in terms of—so, we’ve done this before. We’ve helped companies get successful. What’s in it for me is actually solving a problem for customers.
So, if you are able to get and solve a software team’s problems everywhere, to get their products in the hands of customers first—that’s success for me. I know it’s not sort of putting the typical Silicon Valley 100 million to 200 million ARRs. That’s not where we are. That’s not where my head is at. It’s really helping people who are struggling with delivering software.
Shimel: Got it. K.K.?
Kawaguchi: So, you know—
Shimel: What about you?
Kawaguchi: One time I was working in San Francisco Airport, and then somebody was, you know, working behind me and she said, “Oh, you got a Jenkins thing. That’s nice. Where can I get it?” Right? And that, to me, is like a success. So, it’s gonna be a difficult one to beat once more, but you know, I feel like it’s worth giving it a shot.
I mean, that’s the kind of—I guess I sort of think that the sign that you made a big enough impact in the world, and some people, and touched some people in pretty deep ways. And that, to me, is success. That’s what I’m itching for, yeah.
Shimel: Okay. Let’s—let me hold both of your feet to the fire a little bit. So, you’re now launched, this is—you know, it’s out there, the website’s out at Launchable Inc, that’s L-A-U-N-C-H-A-B-L-E-I-N-C dot com, right? When can people hope, maybe, to see a beta? When do you think you’ll be out with something people can actually start using?
Singh: You’re really holding our feet to the fire, right?
Singh: You have a product manager and an engineer, here. I would like my engineering head to give me the dates on deliverables. [Laughter]
Shimel: You know what? Classic. You’ll make a [Cross talk].
Singh: Boy, you and me on the same side, here.
Shimel: That was a great CEO move right there.
Shimel: Alright, Mr. co-CEO, he threw you under the bus. What do you think?
Singh: Jokes apart, I think one of the things that we are actually doing at the moment are, we are actively talking to prospects and customers. A lesson that we’ve learned over the years is not build a product in a vacuum and then hope that we’ve solved the problem.
So, we are actually—there is actually a beta invite list button on our website. What we are looking for is actually partners who can come with us and tell us if we are solving the right problem and work with us to solve the right problem, right? So, that’s sort of where we are today. I’ll leave it at that and I’ll put the dates to you.
Kawaguchi: Yeah, so, you know, we have preliminary numbers, like I mentioned. We made some models that made some impact, and now what I’m really hoping to find is event partners where we can apply the same technique on their system, their projects, and their source code to see what kind of impact does it produce. And then, so that’s—you know, that may be fundamental in these teams who are willing to work closely with us, and—
Singh: Is that some number that you can share on preliminary numbers?
Kawaguchi: Yeah. So, I mean, there is no guarantee that it’s gonna apply to your system. But, for example, while I was able to do this, select 10% of the subset for the best case use and it’s gonna catch like 40% of ____ right off the bat. So, I guess, you know, that’s—yeah, that, to me, is a pretty promising number, and you can only go up from here, so.
Shimel: Excellent. So, look, both of you have garnered a ton of good will, not only among your peers as evidenced by the angel, you know, the investors’ list here, but also in the community at large, and K.K.—I mean, it goes without saying within the Jenkins community how well respected and, I don’t wanna use the term worshiped, that’ll go to your head, [Laughter] but you know, how honored you are in the community.
What, people maybe from the community listening, what can they do to help, here?
Kawaguchi: Yeah, I think giving us their feedback probably is the most. You know, we are working on something that we think is pretty exciting, and then we wanna hear that, or if that’s not the case, then that’s also great to hear. So, so far, the conversations we’ve had with people who are interested in this space who are thinking about this space have been incredibly valuable.
So, if—you know, if you feel like some of what we discussed here is you and your challenges, we’d love to hear from you. And also, we are hiring—wink, wink. So, you know. [Laughter]
Shimel: Everyone’s hiring.
Kawaguchi: Yeah, so if you—
Shimel: Alright. Is it on the website?
Kawaguchi: It is. You know, one thing I got a lot more passionate at, you know, CloudBees and Jenkins is sort of passing back onto the next people, right? I felt like I got a lot more joy out of talking to the junior engineers and folks, we steer and mentor them. So, I feel like what we can offer—and I know it’s true with Harpreet, too, so I feel like what we have right here is an incredible opportunity to work, you know, sit side by side with these people, you know, people like us who, I think ____ creativity. We’re also passionate about mentoring other people. So, you know, I think if it sounds like your cup of tea, then…
Singh: I’ll jump on that. So, I think, CloudBees was a fantastic company. You know Sacha, Alan—he’s just a great leader. He built a fantastic company. So, we learned a lot of good lessons on what it means to be a good company.
Then I ended up at Atlassian where, you know, I learned the same things from Scott Farquhar and the other folks, and we’ve tried to bring in all the great points from these two companies into this company, right? We are sort of values driven. We’ve really thought hard about the kind of company we want to build, the kind of impact we want to have in the world, and we are looking for people who share that sense of mission, right, to come on our team, right? And if you find some of those guys on our team, that’s fantastic.
On the former side of the house, again, we are looking to solve problems for customers. We are not looking to do this in a vacuum. So, there’s a general profile of people who are like, “Yeah, I hear this. I wish I could partner with someone and help you define what—go solve this problem for me.” If you’re that person, we would love to talk to you and we’d love to partner with you through those things.
Shimel: Fantastic. Guys, we’re way over time. I promised you 15 minutes. We might be coming up on a half hour; I apologize.
But let me close off by saying—you know what? Congratulations. Someone once told me new companies are like boats—the best days are the first day you get ‘em and the day you sell ‘em. [Laughter] But that being said, it’s also a lot of fun sailing ‘em. So, enjoy the sail, guys—change the world. If there’s anything, of course, we can do here at MediaOps, you know you can count on it. I couldn’t think of two nicer people for this new adventure and to take on this challenge.
Harpreet Singh, K.K.—co-founders, co-CEO of Launchable, you can find out more at Launchable Inc. This is Alan Shimel for DevOps.com. You’ve just listened to another DevOps Chat.