In this episode, Paul and Edith are joined by Martin Casado, General Partner at Andreessen Horowitz. The group discusses the deeply complicated and difficult process of category creation, with a special focus on technology infrastructure products.  This is episode #24 in the To Be Continuous podcast series all about continuous delivery and software development.

This episode of To Be Continuous, brought to you by Heavybit. To learn more about Heavybit, visit While you’re there, check out their library, home to great educational talks from other developer company founders and industry leaders.


Martin Casado is currently a General Partner at Andreessen Horowitz. He was previously the cofounder and chief technology officer at Nicira, which was acquired by VMware in 2012. While at VMware, Martin served as senior vice president and general manager of the Networking and Security Business Unit.


Edith Harbaugh: What do you like about continuous delivery?

Martin Casado: I think that there’s a broader movement around continuous delivery that is really interesting, which is, traditionally, infrastructure and operations came from an independent group. My first job out of undergraduate was working on simulations code in a national lab.

I couldn’t control anything about infrastructure. I really didn’t have budget to buy a pencil. You get infrastructure, and you’d have some application to code, and you’d work on that application. We’d fiddle around with our MIG files or whatever, and that was pretty much it.

The cool thing about the broad movement now, and I think CI/CD is just part of this, is more and more applications, application developers, are actually getting responsibility for operations.

This is provisioning, this is delivery, this is deployment. That’s a big huge change in not only what technologies get created but who’s consuming it and why they’re consuming it. I think it’s actually one of the more interesting trends right now.

Edith: This would be a great time for you to introduce yourself.

Martin: My name is Martin Casado, and I’m a general partner at Andreessen Horowitz.

Edith: But you did stuff before you were at Andreessen.

Martin: That’s right. The quick arc, as I mentioned, I used to be a research scientist at Lawrence Livermore National Labs. I spun out of that, did my PhD at Stanford. My research was in networking, so I was part of the team that started software-defined networking.

I was there for four years, spun out of that, started a company called Nicira where we did software-defined networking. I did that for five years. That was acquired by VMware. I ran the networking security business unit at VMware for almost four years, and four months ago I decided to change and become a VC.

Edith: So you basically created a category. What drove you to do that? What made you decide to start something knowing that it was so hard?

Paul Biggar: You’re talking about software-defined networking? For the viewers at home, Martin roughly invented software-defined networking.

Martin: There’s a whole bunch of people contributing, but I think a lot of the original momentum came from my thesis. You know, I’m going to be totally honest. If I had any idea how hard it was, I never would’ve done it.

Edith: Really?

Martin: I think so.

Edith: I think you would’ve.

Martin: Well, maybe. But it would’ve been a lot more daunting. I came out of Stanford pretty darn naive, like, “This is going to be easy!” Now, nine years and tons of gray hair later, I just realized that, man, it was a battle. I don’t think I had one quarter that was easy. Everything was a battle.

This is the way that I think about it. If you’re an entrepreneur, and you’re going to do category creation, you basically just have two jobs, in addition to product development. And job number one is, there’s going to be some constituency out there you’re selling to, and that constituency, they wake up every morning and they think about all sorts of stuff, but they’re not thinking about your thing, because it hasn’t been created yet.

That object in the mind space, that object doesn’t even exist in their brains yet. The first thing you have to do is create that object. It’s like Leonardo DiCaprio at Inception. You go in, you’re planting an idea in somebody’s head. It has to become a thing,something people think about, something people know and integrate.

This is from nothing, and that’s hard. For us, it took 5+ years, and it touches every aspect of thought leadership such as analyst relations and technical conferences and broad marketing.

Paul: So the activities that you’re doing in that category creation are largely marketing and getting people to hear about the activity and learn about it?

Martin: I think so.I think maybe technologists will view marketing as this pretty shallow thing, but I think you’re exactly right. It’s marketing. But it is often very technical marketing, for example, in the guise of open source.

In releasing open source projects, you’re getting people to use it, you’re going to standards bodies, you’re going to conferences. It’s an incredibly technical thing, but in the end, it’s marketing in the sense that you’re actually creating awareness and a market.

The first thing that you’ve got to do as an entrepreneur is, if you’re doing category creation, nobody’s thinking about your thing. You’ve got to get them to think about your thing, which is a lot of work. In my experience, five to seven years.

Then the second thing that you have to do, which is just as much work, is then you have to attach a value to that thing. And I think we as technologists, there’s this kind of fallacy that we have where, “I’m going to create this new widget.” Let’s say I create the iPhone.

Paul: Everyone will know how amazing it’s going to be.

Martin: Exactly.

Paul: Just build it and they will come.

Martin: Yeah, there’s intrinsic value in my widgets. I take my widget, I put it on a sidewalk and someone picks it up. They’re like, “This is amazing. It’s worth millions of dollars!” And that’s totally not the reality.

The reality is people only see value if they exchange money and they’ve used it.

And if you’re doing category creation, how do people know what that value is? It’s a very difficult thing.

Paul: And when you say attaching value, do you mean monetizing? Or is there more to it than that?

Martin: I meant more the idea. Ultimately, this materializes monetization. Let’s say that you’re my constituency, and I’ve created this new widget. First I need to get you to think that this is actually a real thing. I’m going to call it a new phone. So, you need this new phone. First I need to convince you that you need the new phone.

Then the second thing I need to convince you is it’s worth tens of thousands of dollars to you because you need to mentally actually attach that value to it. And it turns out introducing new concepts don’t necessarily have value if they’re new concepts.

Normally, the value comes from, for example, an actual transaction. There’s a psychology around this. Or at least some experience with it, knowing that it’s going to, I don’t think you can just sit back to a couch experiment and be like, “Oh, I think this is going to save me money, therefore it’s worth something.” It really requires a lot of effort to make value.

Paul: So the category that I see being created, or the one that’s closest to me at least, is this idea of containers and Docker, and more specifically Kubernetes, the idea that there’s this cloud infrastructure over there. The way that I became aware of it is exactly the way you’re talking about it. There’s open source coming out there that you can use and you can hack on yourself. There’s talks up there where people blow your mind.

Martin: I think that actually this point, and certainly for all the listeners, I think this is one of the most salient points of this decade, actually, which is going to be a weird thing to say. At least an infrastructure’s the following.

In the past, how did we create mindshare and customer bases? Well, there’s this whole pmm function and this whole sales function. And if you look at the big enterprise companies, if you look at Cisco and IBM and Oracle, really their power is this function. They own the sales channel.

They have great relationships with the analysts, they’ve got great relationships with the customers, they’ve got certifications and the classes. So anytime they have a new concept, they take that concept and they cram it down the machine.

As a startup, it doesn’t matter how cool your technology is, the hardest thing is to actually penetrate that channel.

But when it comes to this new era of open source, now you actually have this hack that’s never existed before, where the buyer is shifting from an operator to a developer. Developers like open source, and you can actually create these concepts by getting open source out there and getting them to use it.

Paul: We’ve been talking about this sort of thing, just the idea that it’s bottom-up now versus top-down.

Martin: Not only that, it’s a totally different buyer that’s a totally different aesthetic. I don’t think developers care as much about analysts. I don’t think developers care as much about the 42-long sales dude with white teeth and the boat. I don’t think developers care as much.

Paul: They won’t even answer his call.

Martin: Exactly. About the channel, I think they don’t care about complex procurement processes.

Edith: Having sold software for a little bit myself, if you get into a bigger corporation, you still don’t start to run into that.

Paul: You get there, because the developers were first asking for it to exist.

Edith: The longest part of our sale cycle is you get bounced to procurement and legal.

Martin: Absolutely. I think this is the most important nuance of this argument, is exactly what you said. I’ve always maintained that open source and the developer is replacing marketing and pre-sales, not sales.

You get credibility to the account, you can get things to technical close and technical validation, you can get account pull. So it’s almost like filling the pipeline, getting the transaction done, I still believe. For a long time, you need to have a professional, direct sales force that will be in there pushing things for procurement.

Edith: It’s just a lot of work, because you pass the technical evaluation. They’re like, “Okay, go talk to procurement.” And to procurement, you’re a widget.

Martin: Right, but the good news is, now it’s possible. Where in the past, to get that much legitimacy, to get things to technical close, was very difficult. You didn’t have the certification, you didn’t have access to the buyer, you didn’t have the account rep to make the introduction. You didn’t have any of that.

Edith: That’s true.

Martin: And now you do, and now it’s just about actually going through the logistics. And you’re absolutely right, it’s hard, it’s baroque. I’ve called it tribal bloodletting. It’s all of that, but you can do it as a startup.

Paul: The thing that I think is really interesting is the converse of that. It’s that people who work in open source now are becoming actually incredible marketers. They don’t refer to themselves as such, but they have amazing social media presence.They build up tons of channels, whether it’s mailing lists or just Twitter followers.

Edith: It’s like everybody recreates marketing. Everybody’s like, “Oh, we don’t need marketing.” Then you’re like, “Well, what is this thing over here where you have an email list?” Oh, that’s not marketing.

Paul: It’s not marketing because I’m a developer.

Martin: I really think that those that know how to do this are some of the most valuable people in the entire industry because this is the new entree for products into customer bases. I mean, there’s another kind of potential pitfall here, which is, let’s say you’re using open source for marketing.

Now, there’s probably seven billion dollars have been invested in open source companies and only about a billion dollars worth of returns. I’m not sure if those numbers are true, but I hear them quoted all of the time. But the reality is, a lot of money’s gone into it and not a lot of money has come back.

The reason is because now, if you’re using open source to do marketing, you’re almost cannibalizing your sales motion. And so for a long time, the only open source model we knew how to work was the Red Hat model, which is a services company. Only Red Hat’s ever pulled it off. It’s been very difficult.

But another shift has happened in the last few years is people have figured out that actually you can use open source for marketing, but you don’t have to confuse that with your actual product offering.

And with the rise of services, you can actually use open source for customer traction. You can monetize the service, and when it comes to services, no discussion of open source or closed source. So I think that we’re actually starting to unlock viable business models where you use open source for marketing.

Edith: Who do you think does a good job of that?

Martin:I think GitHub is a great example, right? Git isn’t even built by GitHub. It’s the standard in Linux. But if you look at GitHub, it’s a very fast-growing company that’s based on open source, and so everybody knows about it because of Git.So Git is doing the marketing. And this is just one example, I think there are many.

Paul: It’s funny that you cite that as based in open source, because almost none of their stack is actually open source.

Martin: Exactly, it’s a service offering. That’s what I’m saying.

Paul: When you say service, you’re referring to software as a service, not service as in consulting?

Martin: Absolutely. I should’ve been more clear. The long-standing question for us, certainly since 1995, is how do you build an open source company that has the margins of a closed source software company? Because you’re open source, basically you become a service and support company.

What has happened in the last decade is exactly what you’re saying: people will realize that you can get account credibility and account traction, account knowledge, through open source.But then you can offer a back-end service offering as a service offering, and monetize that, and it’s often a closed-source stack on the back end of what you’re doing.

But you don’t talk about open source/close source as much with service offerings. It’s normally if you’re consuming something on-prem that you think about those things.

Paul: How do you feel about this? People who are building, let’s say CircleCI as a good model, but there’s a ton of them. Building something that’s a SaaS product, a hosted SaaS product, but that then sells to people who use it in their own VPC and pseudo on-prem sort of thing.

Edith: Oh gosh.

Martin: I come from this somewhat traditional world of selling enterprise software. In there, there’s this whole discussion, and I was part of this discussion, of is it on prem or is it off prem in general? And I think that you framed this question perfectly. I’ve realized that that’s a false dichotomy. It’s actually not the right question to ask. I think as a service, it isactually an operational model and a delivery model? It doesn’t really matter if it’s on prem or if it’s off prem.

I think that the days of selling closed-source software to companies is done.

But you can sell them services and you actually can sell them appliances. But if you look at appliances, appliances almost look like services. They’re boxes that have services, and often the upgrade is happening remotely, management is happening remotely.

I do think that the right model for these companies, I think CircleCI’s a great example of this, you have open source that customers use, you have a SaaS offering, but you also have an on-prem delivery offering as long as you don’t change the operating model, as long as it still looks like a SaaS model somehow, whether it’s a managed service or something like that.

I think as soon as it becomes shippable software, where you have to manage a heterogeneous set of environments, you have to manage all the day-two ops. It becomes unwieldy.

Edith: I had a really interesting discussion the other day with the VP of Sales from CircleCI and somebody from Microsoft. CircleCI was basically like, “We love that it’s selling on prem. It’s helping you.” Microsoft is like, “We’re trying to get off prem desperately.” So it was not the argument you thought was going to happen.

Paul: I think it’s probably because of how sensitive the IP is. If you’re talking about something like, well, documents are pretty sensitive, but the source code is very sensitive. And so people are not as happy to ship that off prem as we once thought was going to be the case.

Edith: Microsoft’s reasoning was, and this might be the way Microsoft had done it, is they have 10-year maintenance agreements.

Martin: We have, “If you have a problem, upgrade to the latest version and then we’ll deal with you.” I think that’s kind of what everyone has. There used to be this idea that you’d create a fork and then you’d backport things to that fork or the old version, or something like that.

I don’t know anyone who’s doing this sort of services, the SaaS with a managed to on-prem version that does anything but “the latest version is the version.”

Martin: If you think about it, having come from this world, anybody that’s shipping closed-source software, or even software in general, has so many hurdles to overcome that some of this that’s doing a sales offering or manage offering doesn’t have.

For example, heterogeneous environments. Everybody’s got a different hardware setup. Sometimes you have skilled administrators, sometimes you don’t. Now, when you’re dealing with distributed systems, a skilled administrator is really critical. These things, clusters, are hard to manage. Remote debugging is really hard. A lot of the debugging is happening on the site in these day-two operations where we’ve got existing tools, we’ve got to support all of those interfaces.

And then you’ve got the mother of all cash consistency problems. You’ve got 10,000 customers and everyone is running a different version. You have to maintain all those versions on the back end. It’s just a massive, massive disadvantage just from an operations standpoint for a company. So, if you can do it as a managed offering, just like you said, or a managed version, or a SaaS offering, you automatically have all of the velocity of that, and you’re not being weighted down.

Paul: It’s interesting that you’re talking about heterogeneous environments, because what we see is it doesn’t feel like there’s heterogeneous environments anymore. I mean, we’re selling. VMware is one environment, or there’s Amazon VPC is another environment. But it’s not like there’s 12 Unixes anymore.

Martin: That’s a super good point. I’m used to talking to hardware. And so in that case, and especially on the networking side, It’s just this eclectic collection of computer science past. Seriously, we go to these data centers, and then you’ll still have mainframes and you’ll have all the old Xboxes, you just have all this random stuff on the hardware.

I think one of the most exciting trends is exactly what you said, is actually we’re seeing unification on the software side. And I think that you can actually parallel what happened to consumer devices in about 2006. Do you guys remember GPSes? Actual hardware GPSes? In the 2000s, you’d rent a car, you’d get a hardware GPS. Most consumer goods were fixed-function, whether it was to play a game on your PlayStation Portable or it was a GPS or it was for learning or it was for health or whatever.

The iPhone came out as an ubiquitous software platform, and Android, you had two ubiquitous software platforms. And then small teams of software developers got to go after huge markets that displaced them. Waze is a great example. I think this exact same thing is happening in infrastructure, where in the past, the only standard interface was IP.

You had to put something in a box, or maybe x86, where you had to install it on bare metal. But now, if you look at software stacks on the end point, you’re absolutely right. This seems like they started to unify, whether it’s Linux, whether it’s AWS, whether it’s VMware, whether it’s Openstack, whatever it is. So it allows you to deliver functionality just entirely in software.

Edith: Yeah, I think the value’s just moving further and further up.

Martin: Yeah, exactly.

Paul: Especially with containers, because it’s a homogeneous environment. You get a certain kernel version, maybe, but I don’t know anyone who’s really cared about a kernel version in quite some time. So you build whatever software, and it runs on whatever operating system that you want, not whatever operating system the customer happens to have.

Martin: I just think it’s a really big deal for those that are doing startups. Everything that we’ve talked about basically is in support of small technical startups. For example, all of PMM is replaced by a technical function, which is open source. I think a small startup is going to be better at doing that, that’s technically focused.

Number two, instead of having to worry about a hardware supply chain, like wrapping things in sheet metal, which requires a supply chain management and putting things in shipping containers, putting things on boats, etc. You can just deliver stuff entirely in software. So it’s a great time to be delivering core functionality, especially infrastructure functionality in software.

Edith: They published an article recently on the stuff you had to do 15 years ago. My friend Andy was at Opsware. The stuff you had to do back then, you don’t do now. You don’t have to have an ops person on staff, you don’t have to buy hardware.

Martin: This is another really interesting trend, and I actually don’t understand the implications of this one. You’ve always had an operations layer. I’m a networking dude, so let me talk about networking. We used to put a bunch of stuff in networks. We’d do fault isolation networks, we’d do service discovery networks, we would do security in networks. And it seems like things are moving up to the application layer.

Things that are traditionally part of ops, things that were traditionally part of the infrastructure, compute networking and storage, are now application libraries,things like discovery, things like failover, things like load balancing, things like security.

And that’s a massive shift, because now it’s in the domain of developers. Now you’ve got more semantics. Now it’s part of the development process. And so I think that there’s implications on market fragmentation; it’s no longer a unified insertion layer. I think that we have to rework a lot of technologies. I think this is blurring a lot of traditional lines.

Edith: When you’re talking about the changing of technologies, what do you mean exactly?

Martin: I think a good way is just to talk about context. Let’s just talk about, say, security. In the past, you would have a box on a wire that would do security. And, say, a firewall. What does a firewall actually know? Very little, right? It knows IP pairs, it knows port numbers, maybe if you’re a fancy pants, you can look at the first 1,500 bytes of data and you can try and do some application analysis. But just seeing bits on the wire.

Now compare that to these new companies that are doing application-level security, where you’re actually part of the application. You’re running a Node.js. Your running is part of the Python runtime. You know everything. You know users, you know data, you know high-level abstractions. You can absolutely transform the level and type of security you can do, because you’ve got way more context.

It just feels like this is part of this broader movement where core networking is being done at the application layer, like routing and discovery and microservices architecture.

Security like I mentioned has been doing this. Storage has been moving up, certainly, to the object level. And I think that because you now have more visibility and more semantics, you can build deeper and richer things.

But I also think you get way more fragmentation, like per-language fragmentation. So as opposed to setting a box on a wire, where that sees everything, you’re now going to have one for node.js and one for Python, or whatever. I think we’re still grappling with the implications of this, but it’s really exciting to see this happen.

Paul: It’s interesting that when you see thata new software product comes out, and they’re an API, so they’re a HTTP API or a REST API. And they still say, “We support these three languages.” because they wrote client libraries for those languages. And people in the software industry still think, “We’re a Python shop,” or a Ruby shop or a Node shop, whatever it is. Even though there’s not necessarily a requirement for there to be that fragmentation, it’s still built into who we are.

Martin: That’s such a good point. And maybe this is just symptomatic of my past. It definitely think things are going micro services, and it’s more of a protocol. So it’s almost like we’re recreating IP. But we’re doing it like the JSON level, or something like that. And you’re right, this is actually totally language agnostic.

That said, and maybe it’s a good point, maybe we’re going to see some innovation of this space. That’s hit a lot of the movement that I’ve seen, too, of core infrastructure. Things like security to the application layer, aren’t language specific. A lot of the application security guys are basically having mechanisms that hook into the run times of these different languages.

And maybe you’re right, maybe what’s going to happen is basically the microservice’s framework becomes the next internet, and discovery and routing and naming and everything happens there, and you’re going to have these protocol-specific boxes that mediate these things. They speak JSON or whatever, and they can be firewalls at that high level.

Edith: I have a total jump shift of a question. You said, at the beginning, if you’d known what you know now, you perhaps would not have started the company. My saying is you can’t A/B test life. Do you wish you were still a PhD, and do you think a PhD has helped you with starting your company? I guess can ask the same question to Paul.

Paul: You go first.

Martin: If I roughly segment my life between 20 and 30, I was basically a core researcher. I was an academic and I was an engineer, and then 30 and 40, I did the company. And then now I’m doing investing, and I just turned 40. So between 20 and 30, I felt like that was leading up to doing this academic work.

The PhD was nice because I haven’t found any other times in my life where someone’s like, when I joined, my advisor went to go do a startup immediately after, and I still remember I sent him an email. I’m like, “What should I work on?” And his response was like, “Whatever you’d like.” And I didn’t know that that was a metaphor for PhD, which is that basically it’s the deep end, at least in my program.

It’s like, basically, do whatever you want. Being thrown into a vacuum and having to make some sort of form from the chaos means a lot. That said, it’s a massive investment of time that I don’t think there’s any commensurate payout afterwards. I think, at least in my experience, you have to view it as a self-enclosed system where I got the value out of doing it, but I don’t think having done it, it’s worth justifying the time. You can be just as successful as an entrepreneur and as a technologist and as a coder and as anything else without having the PhD.

Paul: I’m not sure I necessarily agree with that. I think that there’s a lot of value that you get coming out the end of doing the PhD. I agree that most of the value is from the time that you spend there, but even just looking at the social proof value, when I was trying to raise money, when I was getting my Green Card.

Edith: But I thought it was all about the podcast.

Paul: The podcast. Being Dr. Biggar is a lot easier than not, I find.

Martin: I think that these things largely depend on your personal arc, for sure. And I think I’m just sensitive to mine. When I did graduate with my PhD, I got a faculty offer at Cornell. Now, clearly this is something you don’t get without a PhD, so in that sense it was very helpful. But what I immediately did is turn around and I started a startup. If I look at other founders like Sanjit Biswas of Meraki who’s now doing Samsara. The guy didn’t do his PhD, I think he’s a way better entrepreneur than I ever was, and I think he’s hugely successful.

Paul: I had a funny experience where I was meeting this guy who worked at Google, on compilers. I did my PhD on compilers. And I had done my PhD because I had looked at this site called,and it was all, “You need a PhD from a name-brand compiler school.” I remember this stuff.

So, all right, I’m going to do my PhD. I work in compilers. And then I was talking to this guy, I was like, “Oh, where did you get your PhD?” And he’s like, “I don’t have a PhD.” And it just blew my mind at that point, that maybe there was a thing, some other path. His path was working on open source since he was 18, and then at 22 he got hired to be a compiler editor. It’s like, oh, I could’ve done that instead. That would’ve been a much better idea.

Martin: Yeah, I think there’s just a selection bias here, too, which is interesting. In my experience, often the best developers didn’t finish college. But I think that the reason is is just because the job market really is a Darwinistic system, and I think that if you have this adverse selection of, “You don’t have a degree,” I think that is much more difficult.

The people that managed, one of my core engineers that I worked with for seven, eight years who’s super instrumental to the product, never had a college degree. Actually multiple of them didn’t. These guys often become principal engineers or whatever, but they do it just through sheer skill rather than, you know.

I think for some people, a PhD is super valuable as an experience to do. I think how you use it depends on your personal arc and what you need to get out of it. But I definitely don’t think it’s necessary to be a great entrepreneur, to be widely successful.

Paul: I noticed that you can split PhDs into people who are roughly the most brilliant people I’ve ever seen and people who are complete idiots. And there’s these two camps, that some people do it because they love it and they’re amazing, and some people do it because they’ve nothing else to do with their lives, and they can’t do a job, and actually anyone can really get through a PhD. It’s hard work more than anything.

Martin: That’s so true.

Edith: I was giving advice to a dude from my college. He was a programmer and he really loved machine learning. And so he was like, “Should I go back and get a PhD?” And my advice was, “I don’t think you’ll make anymore money. You might make less, even, because you might get pigeonholed. But if you really love machine learning, go get your PhD in that. But I don’t think you’ll make much more money.”

Martin:I wouldn’t, unless you want to be a professor or even want to join core research, I wouldn’t do it for future prospects. I’d do it because it’s actually one of the few times in your life where it’s just like, “Think really big and probably impractical, and do something amazing.”

Paul: You have four to six years to do what you like, just make sure it’s good at the end.

Martin: That’s right. And it does. And listen, it feels good to crawl out of that cave. When you finally see the light and you’re pale and you’re malnourished and whatever, but you’ve crawled out.

Paul: I regard it as being very similar to raising a seed round. You have some funding to do something, and you kind of thought you knew what it was going to be, and you might be totally wrong.You might need to pivot six times before you hit something good.

Edith: That’s funny. I went back the other day and looked at our angel funding deck, and it’s basically kind of the same.

Paul: Yeah, but you kind of knew what you were doing. There’s a lot of people who start off doing something and then end up doing something wildly different. If I had built a pitch deck for CircleCI on day one, it would’ve been vastly different to what we actually shipped six months later.

Edith: I mean, CircleCI seems pretty comprehensive.

Paul: The first thing that anyone saw about Circle was that it was for web apps, and then we added iOS after it, so now you can run a large amount of stuff on it. But when we started, we were building this CI for everything, so it was going to be CI that ran your on-prem machines, and it did performance testing.

I was working at Mozilla beforehand, so I was looking at replacing what Mozilla has. There was going to be all sorts of, “You could add your 3,000 machines to our something.” And we might’ve ended up in the same space or in the same place as where we are five years later, but the thing that made us successful was that it was really, really good at web apps.

It was like, and this is how we pitch it, if Heroku had built CI, this is what CicleCI would be. And that is why we took off. And when I look at people who did similar things, there’s that Jenkins company, CloudBees, that no one loves, because it’s just Jenkins. It’s Jenkins plus we added some cloud to it. Everyone loves the, “Oh my god, you click one button and it just works,” or you can spend two days setting the whole thing up.

Edith: Did your company end up where you thought it was, where it had started?

Martin: Certainly not from the seed. It’s funny, I actually pointed that the Series A deck recently, and for the bulk of the deck, we actually executed pretty m