Founder Stories

Hi, everyone. I'm Mia Wang. I'm a member of Cloudflare's Corporate Strategy and M&A team. And today I have with me Darren Remmington, who is our Director of Product Strategy Innovation. And the segment is called Founder Stories, Why We Joined Cloudflare. And it's meant to highlight the experiences of some folks who've joined Cloudflare through somewhat non -traditional channels. And in this case, Darren joined us by way of ST Systems, a company he co-founded and was then acquired by Cloudflare back in January of this year. So thanks for joining us, Darren. Thank you. Thank you. I'd love to dig in a little bit on, you know, what your experiences were like leading up to coming to Cloudflare and what your first few months here have been like. But before you get there, do you mind just telling us a little bit about your background? And I know you've had a pretty interesting career. I would love to hear more about that. Well, the short version is I think that I started messing with computers in high school, like sophomore year, which is way back before the Apple and before the IBM PC. It was a long time. By the time I left high school, I was doing, I had a job of writing programs for different people, contract programming. And I did that in college as well. But that wasn't my track. I wasn't planning on going into technology or computers. I was actually on a medical track, which is most of what my family does and continues to do. But partway through that process, I realized that I really did like computers a lot better than sick people, unfortunately, for my mother, at least. So I switched. I started a computer company with just me. And that was the first of many, I think. And I sold that one for a ridiculously low amount of money, $27,000, I think it was, which I thought was a lot of money at the time. And then started another one, eventually got absorbed by a large bank and spent some time there in IT and technology for them. And then got hired by Microsoft in the late 80s and spent 17 years there in two stints, actually. 11 years and then was away for eight years and then back for, actually for eight years, I think it was, and then back for another six. And then left in 2014 and started another project, another company, and eventually recruited some additional people out of Microsoft, which turned into S2 after a few machinations. So a wide range of companies, lots of different sizes, lots of different experiences. Well, even at some of the big brand that a lot of us would know, even at Microsoft, your experience there, between the two times you joined, it's probably a very different company, right? It was. I mean, I started when there was just a few thousand, very small company. Many of those were in sales offices around the world. So the actual Microsoft campus was relatively small. And I left, when I left in 2000, there was, we went from a few thousand to 35,000. And then when I came back eight years later, it was 110,000. So you get to see different stages of the company and different challenges in the company, depending on what stage the company is in. So that was very interesting, unexpected and very interesting. And I know even at Microsoft, you had a range of roles there. Can you tell us a little bit, a little bit more about that? Yeah, I did. It was, it was my first job at Microsoft was on Microsoft Word. It was kind of midway through the process of the very first version of Word through Windows. And so that was an interesting, an interesting experience. And then from there, I, you know, I think at some point the company at that point was, the email system for the company was actually Xenix with dumb terminals. It's hard to believe now, but, and at some point Bill said, we need to build our own email system that we can sell to our customers. That's land-based and server-based. And so me and another guy embarked on that. And that was sort of the first of several sort of almost startup-like things in Microsoft that we were tasked with doing. And it was a lot of work and that was followed by others. And then when I finally left Microsoft after doing a startup for online payment systems at Microsoft, I left, I retired. And when I went back, it was being a group that sat between the Microsoft Research Division and the commercial group to help productize some of the technologies that were being developed in Microsoft Research and move them into the commercial division. So that was an interesting experience and got to exercise some muscles in evaluating technologies and determining whether they were good technologies to move or whether they were full products. It was, we did, we did a lot of that for, that was about six years of that. So that was very interesting, but touched a lot of groups inside the company, including, you know, Office and Windows and the online stuff. It was, it was, it was good. Yeah. One of the interesting things that you mentioned just now is sort of what the innovation lifecycle looks like at different stages of the company, right? You know, earlier in the earlier days, it's someone might've decided we should build an email product or, you know, build our own email product and people just went ahead and did it, right? And later on, there are folks like you who are sort of a bridge between a more kind of classic R&D organization and a more kind of productization commercial org. How do you think Microsoft was able to preserve the pace of R&D, being able to put out good products despite, you know, growing extremely quickly? I think it's a challenge that every company has. Clearly in the early days, it was really just the company deciding at a senior level, hey, we're going to do this or we're going to do that. Let's go figure it out. And I think one of the things that made Microsoft successful in those days was that they weren't afraid to fail. There were a lot of things we tried that didn't work and that was okay because we were, it's hard now to think about it because things have evolved. There's lots of examples, there's lots of companies that you can point to and say, well, they did this right or that wrong. In those days, it was really very much uncharted waters. At least it felt that way. And so we didn't know necessarily what was going to work and what didn't. So there was a lot more experimentation early on with ideas and approaches and challenges. And that gave people a lot of leeway. You know, I can remember working on electronic payments thinking, why am I doing electronic payments? I thought that with email, but I was probably one of the few people in the company that had experience with mainframe email systems. So I got designated. That's how it worked. But as the company got bigger, of course, that doesn't work. And you have to be more thoughtful and mindful about how you do it. It's hard to do that. And so more processes came into the system. And that makes it harder to innovate and do new things. I've yet to see a company who's escaped those challenges as they've gotten bigger. And so the trick is not to try to avoid them, but to understand what they are and the realities and try to manage the process that mitigates some of the challenges that come with size. And decision-making, there's more distributed decision-making. More people looking at numbers ahead of time and trying to pre -guess whether this is a good idea or not. You have to be willing to take risks and fail. And to a large degree, that stayed true. But it became harder, no question. Yeah. I think as someone, for me personally, who joined about a month before Cloudflare's IPO, a lot of my role is thinking about how to put a little bit of kind of the process we need and a little bit of the structure we need without kind of ruining any of the things that have made Cloudflare so great so far. So that definitely resonates with me. I'm sure a lot of the experiences you described were extremely helpful when you were starting S2 Systems or when you were thinking about it and building the product and growing it. First, I guess it would be great to hear just a little bit about what S2 Systems does, what led you to focus on the browser security space or security in general, and kind of how you envision the company's growth. Yeah, that's a good question. I think we started – we had a project before S2 that at least three of the co-founders were involved in that didn't work out well. So like many things, it wasn't the first attempt. But in the process of what we were doing before, it became really clear that cybersecurity was a massive and growing issue for organizations of all kinds. And at that point in time, we were focused largely on the government. And it became obvious as I dug into it that the industry had really moved to a place where they were focused on ex post facto, which means you get breached, and then they have stuff to detect. Software is there to detect and remediate what happens. And the genesis behind the idea of S2 was zero-day solutions. Let's go find ways to not focus on detecting breaches and fixing them. Let's focus on preventing the issues, which is all around zero-day. And so the vision was that we would have a series of products in that space, the first of which was the remote browser isolation product because it's a definitive zero-day solution. It works really well. Every enterprise needs it. And the plan was to grow the company. We had no really plan to – no idea that we'd really sell the company, at least not in the first six to ten years that this wasn't on the radar. And we certainly didn't imagine selling it to another – a larger company. But the paths change, and one of the things about startups is you need to be mindful of how things can change and how quickly they can change. But that's where we started was zero-day solutions really definitively solving security problems. And the challenge of solving zero-days, depending on the type of surface, is difficult, and it's sort of the holy grail in a lot of ways, right, with security. If we can be immune to any sort of threats, whether or not we know about it, that's the state everyone wants to be in. How did you decide to specifically focus on browsers and the web experience? Yeah, I think – and I spent probably six or eight months just researching the cybersecurity space broadly on my evenings and weekends. And it became clear that the vast majority of breaches come through people's interaction with the Internet, through endpoints. And the browser is a big point for that. That's the on-ramp for the Internet for most people. So, we realized that focusing on the browser – I think one of the analyst companies reported that if people were able to prevent breaches through browsers, be it exploits or other mechanisms that are used, that that's 72 percent of all the breaches in the enterprise. That seemed like a good place to start, and we came across the concept of browser isolation and recognized that that was a very definitive way to address zero-day solutions. We looked at the existing solutions that were out there and really was surprised, frankly. It kind of – the state of the technology at that point in time and started looking for a better way to do it, and we found it. There's definitely some luck involved in that, but we found it as we were looking, I suppose. And that's where S2 came from. That's the genesis of it. And that's how we ended up doing exactly what we were doing is because we had looked at a bunch of different things and seen that there was an opportunity in the remote browser space because of where things were at in that industry. And when you say that you saw that there's an opportunity for things to be better, what does that mean? Is it finding a balance of performance and security, or is it sort of about – if I think about kind of the other solutions out there or just security in general, it's difficult to make that balance, right? So, was that sort of the focus? It was. The solutions that were out there at the time were – you know, you had tradeoffs, and that's not unusual that there's tradeoffs in things. That's part of life generally. But they were pretty severe. You either had to choose between a really slow system that was secure or a much faster system that wasn't as secure and broke things. There were some compatibility issues with the systems that weren't pixel-based. And that choice for customers that we talked to because we talked to a bunch of people about those tradeoffs were very difficult. They were between a rock and a hard place. And we said, well, if we could solve the solution that didn't require you to trade between performance or security or user experience or compatibility, if you didn't have to make those tradeoffs, that would be a very valuable solution. So, that's where we focused, and we were able to achieve that, both, as I said, a combination of hard work and some luck. Yeah. Well, we'll get to this in a bit. But when I hear you say that, I think we had talked about this in the very first meeting between Cloudflare and S2. One of the things we believe with our product is that we try to extract that tradeoff away, right? We try to deliver products in a performant and reliable way while still delivering in the most secure way possible. But before we get more into kind of what you're working on at Cloudflare, I know your team likes to credit you with kind of pulling everyone together and really assembling the team. And so, when you thought about building out the team, how did you think about who to bring on, what types of capabilities, kind of how big the team should be? That's a good question. Lots of people approach it different ways. My view on it was looking for people with non-overlapping skills. So, you know, the other co -founders that came on board were deliberately chosen. You know, when you work in the industry for many, many years, you always – most people accumulate a list of people that they think are really, really good. And you think in the back of your head sometime, oh, man, if I ever did a startup, that would be a good person. And that was the list I worked from. And I looked specifically for people who had skill sets that I didn't have. Because there's no point in everybody having the same skill set or largely overlapping skill set. We need a broad range of experience and perspectives. And so, it was a pretty deliberate process to go out and find those people with those specific skills, especially because we had the advantage, which isn't always the case, of really knowing exactly what we were building and having a sense of what skills were going to be required. So, that was helpful. That doesn't always work out that way, but that was helpful. The other thing that I think was a factor is that the people – you know, certainly for this first several – actually most of the employees that we hired were people that we knew. And that isn't – people can take that the wrong way, but when you're a startup and small, everybody has to be firing. Every cylinder needs to fire. And when you hire somebody you don't know, you don't understand their history, don't know how their work ethic is, don't know the quality of what they produce, it's a risk. And it's a risk for the company that you've got one or more people who aren't firing on all cylinders. And so, it was deliberate to find people we knew that were known people, known entities, known quantities. And that we understood what we would get from them. That doesn't scale over the long term, but when you're very, very small and you're only six, eight, nine people, everybody needs to be moving the ball forward. And it's a risk to take. You can do it, and we have done it in the past. I've done it in the past, but for this one, the people that came on the team were known to somebody in the team. Not necessarily to me, but to somebody in the team. And that worked out really well. They were all fantastic. Really, really good. Really good people. Yeah. Having worked with your team for a while now, I can definitely attest to that. It's interesting because I had sort of a past life in early stage investing in venture capital. And a lot of times we look at companies and founders and their teams and, you know, whether it's product market fit or building sort of their founding team. A lot of times you sort of just see this one puzzle piece that's slightly off. And it sounds like in your case, you were really deliberate about trying to optimize where you could. Knowing fully well that. You know, you didn't have perfect information. You didn't know exactly what the products would look like. We tried to find the pieces that. Sort of wouldn't fail no matter what the product ended up looking like. Right. Great engineers. They could build. Anything. But more importantly, you have people that. You could trust that could work together really well. Yeah. there's a lot of people that could fire on all cylinders from, from day one. Yep. That's absolutely. And on the, on the topic of, of team. So I think Cloudflare first met the S2 team back in. I want to say late August of 2019. Right. And so. MNA is something that can be really distracting for, for startups. You know, or it could be a great thing, but in, in your experience, How did you sort of think about, about the process? You know, understanding that was completely sort of unexpected, maybe. How did you think about communicating with your team about it or thinking through the decisions and path forward with your team? Yeah. Good questions. I think. For us. As I mentioned earlier, we really weren't on a path where we thought we were going to sell anytime soon, at least. And the reason that came up is we actually were out talking to a company that we were looking to partner with. And in the very first meeting they learned about what we're doing and said, Hey, you know, we want to buy you. And we didn't, it was, which was a surprise. And we didn't really honestly take that too seriously because. This individual, I think was, was, was very excited by what we're doing, but there's a big difference between individual interest and institutional interest. And so we tended to discount a little bit that that, that that was a serious thing. It was, it was David and I in that meeting. And, but in, in subsequent conversations. With that company, we realized, no, they are serious. And there is institutional interest. And that was a shock. We just felt like we were way too early. But we recognize that if we were going to get an offer from one company, we were. Not in a great position because we needed to have other options. Because we're young. And we haven't had enough runway to develop the value where we think it needed to be. So we took it pretty seriously that we were going to go. Fine and see if there were other companies that might be interested. And so very. The team question in that is at the very first, I think we. We didn't say much to the team or anything to the team, because we just weren't sure that it was real, but when it became clear that it was real, then, then all of the co -founders went and met with that company. And that really kind of got us focused as a group saying, okay, so if we're going to entertain this, you know, what's, what's the best way to approach this. And we. You know, tactically map that out. And that's what we did. And. So it was, it was a danger, as you mentioned, because we weren't sure that we would get an offer that made any sense to us. So we didn't want the team to be distracted. We told them what was going on, but we really. Bifurcated. The focus on what needed to be done and the company to move forward with our existing plans. And this side process, it was, it was a debate. As to how much energy we spent on one versus the other. We were actually in the middle of, of. Raising our second round, which we eventually fully had funded. And was ready to go. So we had the choice of, you know, We don't have to do anything because we have our money in place for the next. Next year or two. So it was an interesting process. But as we work through the process, we. When were there other, there were other companies who were seriously interested. We realized that a lot of companies, and this was a revelation to the team. Certainly to me was that there were a lot of companies who've been looking at this space for a long time. And we're actively out seeking solutions. And, and then we realized at some point we realized, okay, this is the right time to sell, even though it's. Way earlier than we thought. And it wouldn't be our first choice. That's that's how we ended up. And I remember our conversation, our first conversation with. And how somebody made the point very early on. Yeah. there's a lot of companies that have been looking at this space for a You know, security without, without, without compromise. No compromise to performance. No compromise to experience. That resonated because we hadn't heard that from any other companies. That was a, that was a. A big deal for us. Yeah. I I've seen a lot of companies. Who think of sort of browser security or. Or. Security in general, a sort of this. Enterprise thing, right? Like, you know, if you work at a large enterprise, you, you have the best in class solutions, but. I remember one of the other things that sort of resonated between among all of us on that first meeting was that there's, there's an opportunity to sort of democratize it. Right. And they. To deliver a secure. Web experience, not just to fortune fifties. But to anyone that's using Cloudflare and that's such a broad range of people. And so that was, that was, that was, that was, that was, Did, did the, did that, our platform, our reach, kind of our. Our. Mission and working with different types of users and customers. Was that a factor in what led you to join Cloudflare? It definitely was. We, we had, we had choices, as you said, and we really were able then to. When you have, when you have choices, you can make trade-offs. When you don't have choices, you don't get to make trade-offs. And, and we looked at the fit with Cloudflare. We, we felt very clearly very early on that Cloudflare was. The best possible technology fit with what we did. Cloudflare is incredible network and the ability to run code of the edge is a perfect fit for remote browsing. There's, there's no better way to do it than that. That is the, if you were starting from scratch. And could ignore the realities of having to build your own network. That's the way you would do it. And here Cloudflare came along and had, and had the network. So that was, that was part of it. I think the other thing is that we were very impressed with the people. You know, you're in the end, when you join a company, you join a group of people and, and the people were, were great. They were focused on moving things forward. They cared about finding the right solutions. People were. Would listen to each other. They, you know, there was nobody in the rooms that we talked to who felt like they had the right solutions. And they, they, they, they came up with all the answers and, and that was important to us. And then, you know, from a company perspective, Respect it was a, it was a young company. I mean, Clout first a young company where many of us came from. These large, you know, Seattle. Megalith technology companies and, and Cloudflare was. a young company and it felt fun and invigorating and similar like the old days again. And that was exciting, I think, to everybody. And then lastly, I think that the thing that drew us to Cloudflare was we really believed and felt like we had the ability to move the needle for the company, both as a project and as individuals. And that's, for a lot of people, highly motivating. And so there are a number of reasons why we picked Cloudflare. Those are a few, but in retrospect, it was the right choice and we're very happy to be in the company and working away. Got it, so six months in and no regrets so far, right? No regrets so far. The reasons that we identified up front that make Cloudflare attractive turned out to be true. That doesn't always happen, so that's good. I think some of the things that surprised me in a good way is how mission-focused the company is. The mission and mantra of making the Internet better. People are very aligned and unified around that. And that's very refreshing and it's clarifying because it makes things easier to do. There are obviously trade-offs on joining a larger company and not being able to run the show and make your own decisions, but Cloudflare isn't that big at this point in time and it still feels like a very nimble company. And corporate overhead, such as it is, is appropriate for its size. So none of us, we all know what it means to work for larger companies, and so I don't think there's been any surprises for any of us in that sense. So if I were a founder watching this segment, it sounds like some of the maybe indirect pieces of advice are to sort of understand as much as possible about the organization you might potentially join to really focus on the people and the team and ensure that everyone's incentives and goals and visions really are in alignment. And those are probably some of the more important things to figure out upfront. Absolutely. I think every situation is different. And any advice I could give that would be too specific is probably less useful. But from a principles-based perspective, I think you're exactly right. Shared vision is important because everybody that starts a company has a vision about what they're trying to achieve and what they're trying to accomplish. And most people aren't interested in abandoning that vision. They want to hold that vision. So having a shared vision is really important, I think. The compatible culture, which I think I mentioned before, is also important. When you join a company, you join a group of people. And so it's a little bit like getting married. You better like the people and the culture that's reflected in that organization. Otherwise, it's going to be a difficult process for you. And lastly, I think for individuals, it's important to understand what, from a personal point of view, drives career satisfaction for people and be able to map that into the company to say, yes, will this company be able to, will I be able to drive career satisfaction for my role and purpose in this company as part of their overall mission? I think that's important when it gets down to the individual more so than even the larger startup or the larger company. So I think those are some of the principles. There's several others, but it's a big decision for people. It's a big decision. Yeah. And I found having worked on M&A from both sides of the equation is that people often forget it's a deeply personal decision at the end of the day, right? And the dollar number, sure, definitely affects the personal piece of it. But at the end of the day, it's where will you personally feel satisfied? Where will you feel satisfied from a career perspective? And those are things that we can't tell founders how to feel, right? They have to just feel that for themselves. Yes. That makes a ton of sense. And then lastly, on the point of sort of individual and team contribution, when S2 joined the team, we also announced something called Cloudflare for Teams. So can you share a little bit more about what that is and how browser isolation fits into it? So Cloudflare for Teams is about protecting the enterprise, turning around what Cloudflare has done traditionally, which is protecting infrastructure for people with websites on the web. And it's taking the same infrastructure, that same network, and some of the same technology and turning it around and helping protect the enterprise. And Cloudflare for Teams is focused specifically on that. And it's two core products at the moment, but will eventually be at a range of products and technologies that work together and leverage Cloudflare's asset, which is that network and control of the stack from layer seven down through most of the stack and protecting enterprises. Got it. It's an exciting product suite, product family, and I'm sure people will hear plenty more about it going forward. But thank you for joining us for this. It was great chatting with you and appreciate you being super candid about your experience leading up to Poplar. Thank you. Appreciate it. Enjoyed it. Thanks, Aaron. Bye.