How Cloudflare Built This

Hi there. We're live on the five-weekly episode of How Cloudflare Built This. I'm your host, Rustam Lalkaka. I'm a Director of Product here at Cloudflare, and I'm joined today by Patrick Donahue. Pat, do you want to introduce yourself? Hey, Rustam. How's it going? Hi, everyone. Patrick Donahue from Cloudflare, Director of Product here as well. Rustam and I have worked together for quite some time, so this should be a fun segment here. Yeah, it's been a long time. We've done a lot of presentations together and things over the years, and we traditionally open with a joke that for some reason never lands. I was trying to think of a good joke. I was going to make a joke about UDP, but I wasn't sure you were going to get it. Moving on. In general, we don't bring these segments with this sort of discussion about what you did before Cloudflare, so how you ended up here. What's your story? Where did you go to college? What did you study? Did you go to college? What was the path that brought you to the product you used in Cloudflare? Sure. I started out, I kind of had an interest in computers when I was really young. My dad used to bring home computers. He worked at Apollo Computer and used to bring stuff home, and I would tinker with them, so I always kind of had an interest there. Then when I was in high school, I did some programming jobs for friends and family friends, and so kind of got hooked on it. Then I knew I wanted to go to college to study computer science. I also wanted to play baseball, so I tried to find the best academic school for CS that would also let me try out on the baseball field. I ended up at Bowdoin College in the Northeast, studied computer science and economics. I was looking for a campus job, and so I wanted to do something with technology. I ended up applying to the help desk. A couple days later, while waiting for that, I sent this really detailed troubleshooting report on some of the network connectivity problems that were happening. I was getting packet loss and super high latency. Then I got an email from the head of the Network Operations Center who asked if I wanted to come work there. Got a lot of really cool experience working on networks and systems, building them, securing them. It was a really interesting experience as a student that had full root access on all the campus systems. That was the fun side. The less fun side was getting paged while you were out at a party and going, having to reboot the digital UNIX 264 system that ran the campus mail server, for example. I've heard bits and pieces of this story before. It's funny, I'm smiling because I can tell basically the same story, except I didn't play baseball. When I was in college, I was playing around with the CS department. I was an admin for the CS department. That was my gear money job. You were on the climbing team. No, I actually didn't start rock climbing until relatively recently in my mid-20s. I did not much of anything in college besides homework. You sort of got your feet wet with True64. I think that dates you a little bit. Yeah, no, it was that and the networking I think we're most interested in. At the time, we had two T1s for the entire campus. Bowdoin is a really small school. It was 1,700 people or 1,600 something when I was there. There's more lobsters than people there, right? I'm sorry? More lobsters than people there? Yeah, exactly. We did have an annual lobster bake. I was more interested in the networking side of things. We actually were having problems with file sharing. I went to college in 2000 and file sharing was just starting to explode. If you can imagine at a campus, a very large percent of the traffic was going towards downloading not-so-legal MP3s and things like that. One of the first projects we had was installing this big box called a Packeteer, which would fail open if need be, but while it was running, it would try to shake traffic and clamp down. I remember when I wanted to download something big, I would go into the plug right in front of it so I wouldn't get a traffic shake. Then we eventually moved to Verizon Sonar Ring. We were only paying for not all whatever that is. I think it was OC3. We were only paying for 20 megabits or something. I got to go through the whole network administration experience managing, at the time, we were running Checkpoint NG firewall on the Nokia IPSO boxes, which I think they were BSD-based. I got a lot of fun experience. I knew that I wanted to do something within networking and also had some interesting security experience. We would get these. I think we were compromised at one point and we got a nice visit by the FBI. We also bought, I think at one point we got some counterfeit Cisco, that might have been later, some Cisco equipment. Got to experience a little bit on the security side. Coming out of school, I had been in the summers and the winters, I was writing software for a medical device company. Did that and got to also manage the networks. Coming out, I knew I wanted to do something more in the security side of things and joined a consulting firm in the Northeast. Got to split my time between building and securing networks and doing penetration testing. Why was it clear to you that you wanted to do security stuff and stay on the more network side of things versus taking the CS degree and doing the classic job and go work in some software company? That's a good question. I was fortunate enough to be paired in my labs with somebody that I ended up starting a company with after Bowdoin, who was just a brilliant mathematician. He had won the math Olympics in Thailand and came in second in all of Southeast Asia. He was just a brilliant guy. I knew algorithmically I could never do what he did and compete with him. I was always very practical. I taught myself how to code at a really young age and I could build stuff, but I just knew I wasn't going to be able to solve problems like that. At some point, you get by those early computer science classes and you get into the higher level mathematics. At my school, I know there are different styles. Do you know exactly the same story? Who's that? Jeff Bezos. I guess he studied physics at Princeton. He got an asterisk and was like, oh, you were studying physics. Why did you not continue with that? He goes, oh, I had this roommate who was just way better than me. I was like, I can't do that. Yeah, no, I enjoyed it. It's fun and I still do stuff here and there, but just that recognition that you're never going to be at the top in that room up there in a particular discipline. I wanted to do something I thought I could apply myself at better. I really enjoyed it. So you started as a network PE, obviously you got out of school and then where did that take you? Yeah, so I did that for a little bit and actually around that time, I got a call from that lab partner. We worked really well together. I was much more practical and I could get around and systems and that was really helpful for the projects we were doing. He said, hey, he was at a hedge fund and he was looking at starting a company doing basically writing software to help people do asset allocation and investment management. He said, come on down and let's chat and see if it's something you'd be interested in being a co-founder of. So I drove down to Connecticut. This would have been like 2005 or so. Flew out to San Francisco. I showed up to meet the founding CEO in a suit, which I later learned was not how you show up to meetings in San Francisco, but a kid coming from the Northeast, I thought that's what he did. So there's four of us at the start and the company, it was really fun. I started out doing, at the time, I was the only technical person there for, and so I was implementing Monte Carlo simulation for asset allocation and largely just porting what Sun Boon was his name, would write in MATLAB and into C. And this is, we needed a lot of, yeah, basically we needed a lot of computational power. And this was pre AWS, pre anything for the early cloud providers. And so what I ended up doing was we were writing it in C and I was using this thing, message patching interface and MPIC library and using like the Intel C++ compiler to do vector math and really trying to squeak as much computation as you could out of the application. And so I found these server, basically built like motherboard, RAM, network card, no hard drive, no video card, and built this like kind of budget cluster, if you will, in a co-location facility in San Francisco that I convinced to let me like put in this custom shelving. And usually you've got these nice 42U rack units. And so that was really fun. I had to build a bunch of computational power. In hindsight, it would have been nice to just give somebody a credit card and do it, but cool experience. I had an intern from Berkeley. Yeah, I had an intern from Berkeley who actually like stayed overnight. I gave him my Newegg account and he would buy like custom cooling and he would overclock. This was like when the Intel Core 2 Duo came out and he would like have this lab running and he would come in in the morning and see like what totally burned out, what didn't, and then we overclocked them. And so you have to be really scrappy, obviously, as a startup. And so I saved a lot of money and had some fun. Was the premise here basically like modern portfolio theory style stuff, basically like wealth front or better? Exactly, yeah. Think of wealth front for, the idea was it was most of our early clients were like these high net worth individuals. The idea was to build it, prove it out, and then kind of scale it down to the wealth front level. I learned a lot about product management actually in that job because once I realized that I really needed to hand over the engineering reins to someone else, I had kind of been starting to do this anyway, but I was doing product management and figuring out what the problems we had and how we might solve them for our customers without actually solving them myself. And so that was my first kind of transition. So it's not like you started doing that naturally and intuitively, but like when was the moment that you learned what a product manager was? This is always like a fascinating conversation, right? Yeah, no, I think it was after. So, you know, I was at the startup for about four years, you know, it was a tough time to start a financial services company in 06 when, you know, 08 was looming. And so after, you know, we kind of pivoted into doing cash management, which was not as exciting for me, but helped pay the bills. And I sort of, as we started to kind of wind down the number of employees we had, you know, we started out with four up to 40 and then down to 20. And I started to think about what was next. I kind of looked at my skill set and said, well, what am I good at? And what am I not so good at? And I thought that, you know, doing product management was something that I'd really kind of grown into. And as I thought about, you know, I started talking to just friends in the industry and they sort of pointed me to, you know, specific product management roles. And that's kind of when I really got into it. Okay, just fast forwarding a bit. How did you find Cloudflare? And like, was it obvious that this is where you wanted to work when you found it? Yeah, I mean, it's kind of a funny story. I was running, I had been, you know, somebody who preferred mostly to work for myself and take a lot of risk. And so I had gone eventually to started another company with a friend from, another friend from Bowdoin. And we were doing, 2013, we were doing Bitcoin poker. So it was online poker that only took Bitcoin. And our data center was in Costa Rica for, you know, for legal reasons and the Internet connectivity in Costa Rica is not so great. And we were getting, you know, given that you could kind of steal Bitcoin without any recourse, we were getting attached left and right. And I knew I needed, you know, the game run over WebSockets. And so I knew I needed WebSocket protection and proxying. And so I started doing some research and I'm like, okay, who's, who's going to help me with this? What is out there? And I stumbled across Cloudflare. And I was like, oh, this is really cool. At the time, you know, we couldn't afford the, now WebSocket proxying is available, you know, for, for I think every plan. But at the time, you know, it was only enterprise. And so didn't end up, I think we subscribed for a business account. And I was like, this, wow, this company is really cool. And we had sort of moderate success. And then when I kind of figured out I was, you know, ready to make a move, I emailed a friend of mine, Jim Payne, who had started MoPub. And I saw he was connected with Michelle and asked for an introduction and then, you know, showed up for an interview with, actually, I didn't, I saw Cloudflare uses Anycast. And so I was like, okay, I don't, you know, I've done networking a bit, but I haven't said anything about Anycast wise. And so I built this basically, like CDN using some of this old hardware I had. And so I had this massive, like network diagram I came in with, where I built, like, multiple different data centers using, you know, Biota at the time, which is like, didn't surprise me at all. But I was like, yeah, I understand how this stuff works. You know, I think I'd be a good, I could get hired. And yeah, the rest is history. So I was, you know, five, five and a half years ago, I came on board. Got it. The interesting thing to me about that story is like, if someone showed up for a PM interview, and we've done the same thing today, we would be as wowed as the folks interviewing you then. So it sounds like some things haven't changed. But what, what has changed in the five and a half years you've been here? Like, what was it like back then? Sure, yeah. And I agree, just to put a pin on that, like, I think I interview a lot of people as do you do that are there wanting to be product managers here. And I think the one thing that hasn't really changed is like, you still need that knowledge and technical, you know, curiosity to learn how things work. Well, it's actually your illustration is perfect, right? It's not actually knowledge base. You're like, I don't know what a test is, but then you figured it out. Exactly. Yeah. And I think nobody's expected coming in knowing like how we operate. But there's that base that you kind of want to build on and the ability to, I think you and I have, at our tenure here have gone into two projects, you know, you know, you work on magic transit, for example, that I knew there's a lot of stuff that you were learning early on, and you've, you know, really sucked it up. And I think you just need to have the ability to do that here. So like early on, I remember, I started and I was like, Okay, I don't have a monitor, how do I get a monitor? And it was, I had to go through a bunch of different people and finally convince someone that, you know, product managers need bigger monitors, too, even though we're not writing. Not a lot of processor. No, and I think like, I, you know, I think Matthew, our CEO, I was, I remember, we did this case study, one of his professors from HBS, and Michelle took a class from I can't remember who the professor was. But there's a case study that we talked about, about Cloudflare. And I think one of the things that I learned from that is, you know, we were very intentional early on of being a little bit behind process wise. And I think, you know, to sort of not slow things down, I think that over time, obviously, you need to add more process and level of approvals. And you know, if you want to get something, there's been all the way to CFO and whatnot. But that stuff, you know, you don't want to prematurely optimize for and I think it was really, it was really cool at the outset. There was a lot less, as you might imagine, there's a lot less kind of surface area that was, you know, spread really thin. And so if there was something that you want to work on, that nobody else is working on, you know, and that's still true today, right? You could just raise your hand and say, Hey, this is something I could help with. And I ended up I originally started as the product manager for the partnership team, because I just really want to work at Cloudflare. I didn't necessarily want to do partnerships. But I really liked the woman, Maria, who was running the team at the time. She really impressed me. And so I came in there. And then I started asking questions at one point, trying to help the partner team, you know, figure out something that was SSL related. And I started asking questions like, how does this work and didn't get great answers. And so I found a thread and just kind of pulled on and sort of figured it out. And then we, we moved an engineering manager over to that. And he asked if I would switch over and be the product manager for that role. So that's how I got in. And then, you know, what's changed over the years, I think, like, if you look at the teams, maybe around product management back then were relatively non existent. So like, you know, if you start a company, right, you typically want someone that's doing some of the engineering and the technical work and someone that's kind of doing the business and the sales. And then, as you grow the team, you know, maybe introduce product management early on. There's teams, though, that now do specialize in things I think we had to do ourselves back then. So if you're writing your product requirements stock, you know, which for those listening is obviously like the what you're building, why and sort of the runbook or the recipe for engineering, you would have to do a lot of this stuff yourself, such as the mock ups, the look and feel of the user interface. These days, you know, if you try to do that here, you probably get because, you know, we have such a great product design team. And that was a team that didn't exist back then. And similarly, with, you know, product marketing didn't exist. And so you were focused a lot more on telling that story as things, you know, kind of got built and came out. Product content experience, another team we have, it's really great in helping us with, you know, tell the message or get the message out rather in written form, whether it's documentation or blog posts or things like that. So that support structure wasn't there. Also, I think from a good and a bad perspective, you know, there was very little communication over that. And so the team was much smaller, and you would kind of have to just check in with one or two people and him doing this and doing that. Whereas today, you know, much larger when I joined, we're about, I think, around somewhere between 100 and 150. Now we're, you know, 1500 plus, so order of magnitude larger. And, you know, I think the communication overhead and keeping people in the loop, and there's more people involved in getting something out the door, and making something successful is higher. And there's benefits that come with that. But you know, there's also costs that come with that. So if you had to pick between Cloudflare, Circa 2015, and now, which would you rather want? That's a, that's a interesting question. I think there's, there's advantages to both. I think early on, you know, you could move very quickly, but you didn't have a lot to build up upon. I mean, you had a tremendous amount of like, product that was already there, but not in terms of like today, I feel like we're so lucky, because we can take, and I'm working on a project now where you can take this product that's built, and this product that's built, and kind of put them together and put a UI layer on top of it. And you've built this whole new product line, without having to do, you know, as much work as you had to do back then. I think definitely now, I mean, the, the, there's a lot of fun in that. And then I think there's fun in figuring out not just building things from scratch, but how do you scale something once it's been built? Yeah, it's much harder. So, okay, so, so, so that's sort of the backstory. Let's talk about some of the products we've actually managed and built over the years. So, as you mentioned, you know, a minute ago, you sort of accidentally found yourself working on, on SSL stuff. And I think a lot of people, especially those who've been around for a couple years know, think of Pat and then think of SSL, or, and vice versa. What, what is SSL? Do you have any exposure to it before? Like, what were the product problems associated? Like, talk to me about, about that. Sure. Yeah. So, SSL stands for Secure Sockets Layer. I think a lot of people are probably asking why we're not saying TLS, Transport Layer Security. I think it's cooler saying SSL. Yeah, yeah, no, I think there's, you know, if you want to be pedantic, you can, you can refer to the specific protocol that's used. But I think, you know, familiarity will try and simplicity and way of communicating trumps, you know, I think the exact correct terminology, the, what it is, is just a way like, if you're in a browser, and you type in HTTPS, right, that, that communication is secured by the TLS protocol. And so, and originally by the SSL protocol. And so, it deals with, you know, authenticating the server largely saying, hey, am I talking to, you know, example.com? Do they have a certificate that's been, you know, demonstrated some sort of certificate authority has proven that that is their identity? And does your browser trust that certificate authority? And then from that point, sort of once you've established that, that secure connection, that encrypted connection, making sure that all your requests, you know, are not susceptible to eavesdropping or any sort of tampering with those connections. And what were the sort of product challenges associated? Yeah, there were a lot early on, I think, Cloudflare was, before I started working on something called universal SSL, which was a way, you know, it was really remarkable at the time, because, you know, certificates were quite expensive. Actually, that job I mentioned in high school working for my friend's mom, I remember ordering an SSL certificate. And I remember like, getting a notarized seal from the Commonwealth of Massachusetts, like indicating that we had the authority to represent the business. And I had to put some like title down for myself as I mailed this in. And she told me just put down like CPO or something. I was a 16 year old kid. And I wrote that in and then sent this thing in the mail. And then like weeks later, finally got a certificate for for her domain. You finally got the certificate. And it was just this like super slow, complicated process that has so many steps. And if you think back, like to the late 90s, when this was there's, you know, the percent of connections that were encrypted was incredibly low, right. And I think what Cloudflare did shortly before I started with Universal SSL was make that free and easy, really, you don't have to do anything else other than sign up for Cloudflare. And that was groundbreaking, I think, as, as we tend to do when we're building products, especially on a stage where you know, you're just doing so many things and you're overwhelmed. It didn't have a lot of the features in it that I kind of quickly realized. And so the main one was, you know, when you order a certificate, it's typically valid for a certain number of years, right? You used to be able to get these like really long live five year certificates. And then the group that kind of oversees them brought that down to four and three. And, you know, I think just recently, like closer to one, I don't follow this much anymore. And so you'd have to go renew this periodically. And so, you know, it was sort of I was, I was in this seat, you know, close to one year after the, the original certificates were hired. And I said, Well, how does the renewal process? And, you know, I think the answer was, oh, yeah, we haven't implemented that yet. Which, you know, at the time was the right answer, right? There was the, and I think that's something that, you know, I was probably guilty of when I started, I see other people asking questions about that. But like, there was a right, there's a right decision at the right time. And so, you know, you're constantly as a product manager trying to decide, you know, you have scarce engineering resources. And do you do you take something all the way to the finish line, without even finding out if customers are going to use it, and it's going to be successful. And so I think I've learned here over the years that, you know, you want to give just enough for them to give you feedback on it. And I know you do the same as you build your products. But, you know, we eventually had to, to scramble and pull some late nights. I remember, Dave Costin was the engineering manager at the time he was, I came in in the morning, and he was like sleeping on his desk, and like he was trying to get the systems running. And he had these five screened windows going to, because there was rate limits that he was working around. And so anyway, there were a lot of like, scale challenges early on with that. And you know, in SSL world, you're relying on partners, right? So Cloudflare is not a certificate authority, ourselves, we, you know, we have trusted partners that we ask to sign these certificate requests. And so those companies obviously have their own, you know, scale and throughput challenges. And so we had to work around some of that stuff, but eventually, eventually got it going. And I think at the time, it was like, you could sign up for Cloudflare, and you'd get a free certificate for domain, and we took care of the whole process. And that was very innovative and groundbreaking time, nobody else was doing that. And we drove the number of sites using encryption way up, which I'm very proud of. And I think over time, we've continued to make that happen. So that was the just early stuff there. And then, you know, we kind of got into other use cases for different types of customers. So first off, that's like an amazing MVP anecdote, right? Like, sure. Yeah. How are we going to renew these certificates? We'll worry about that. Yeah. More pressing stuff to do in the next year. And you know, we got we got time. So that all makes sense. And it sounds like a lot of that was just sort of like rubberizing and making universal SSL real, how did things evolve from there? It sounds like universal SSL was this product that we gave away for free to everyone. And then how do you think about evolving that into something that was more than that? And like, what was the thought process around how you how you how you do that? Sure. So we started getting a lot of requests from people that wanted more control over the process. And so, you know, when you're doing something, and most of most of your customers are totally happy with just, you know, do it for me. I don't have a strong opinion on which particular, you know, key sizes you're using or cipher suites you're using to terminate it at the edge. They but but some of them were kind of very highly opinionated. Often, you know, larger companies that had their own PKI groups or, you know, security teams, security engineering teams that were being very prescriptive about this largely, you know, for regulatory reasons and oversight reasons. So some of these companies would have, you know, HIPAA that I have to follow or PCI, or just other financial regulations that they need to adhere to. And so we, I think, you know, with any product management function, you're spending a lot of time talking to customers and figuring out, you know, what are these pain points and you try to have, you know, I know you spend a lot of time with customers as well, like you, you start to spot patterns, right? And it's not exactly what the customer is telling you. But you hear enough of them where you sort of can can abstract those out into a particular use case. And so some of these early on were like, I want this specific validity period I want, we used to combine customers onto a single certificate largely for, you know, cost reasons and efficiency reasons. And some of them are saying, you know, I want I only I want to be the only name listed on that certificate. And so we heard these early use cases, and we built what we call dedicated certificates at the time, or dedicated certificates with custom host names, which was a much more custom, you know, way of ordering a certificate, and you can be more prescriptive. So we solved that use case. And that was, you know, a really successful product. People, it was very high attach rate, people used it quite a bit. And, and from there, we started kind of moving on, you know, okay, we solve like the use case that helps the most people, and then we solve sort of the next thing that came out. And then that I started having conversations with some of the early sales and solutions engineering people, Chris Merritt, for example, our head of sales, CRO, Trey, Gwynn, our head of solution engineering, and they had kind of started bringing up these, these challenges where we had these third parties, you know, these companies that were running SaaS platforms. So think of like, ecommerce platforms like Shopify, or help desk platforms like Zendesk, and, you know, marketing automation, like, like HubSpot, Marketo. And so these companies were managing certificates on behalf of their customers, right, which is, which is even further removed from the automation. And so these companies would say, you know, you could, in your case, you could have like, rustinstore.com, right, and you're not writing the code behind that, obviously, you're, you're, you know, paying Shopify to run the code for that. And, you know, you want to sell your stuff securely, you want your customers to be, you know, not afraid to put their credit card information in. So you want that, you know, that I'd say lock in the browser, but Google is removing that, and kind of flipping it, which, which makes sense, we won't get into that. But you want them to have a sense of comfort. But but what Shopify doesn't want to do, or any, you know, SaaS providers, they don't want to say, hey, Rustin, can you go get me a certificate and give it to me? And oh, by the way, can you do that every 90 days, or whatever it ultimately ends up on? Because it's, it's, it's cumbersome. It doesn't, it's not a great experience for you. It's also insecure, right? Like, how are you going to transmit that private key, which if somebody holds that private key, they can decrypt that traffic. And so getting, you know, it's hard enough to get somebody to send you something, you know, basic in a secure manner, but sending something that's really critical, like a private key is kind of problem, risk and error. So we, we had conversations with some of these, these customers that have these problems, as well as a lot of the sales and systems engineering folks that I kind of heard this request over time. By the way, that's, that's one thing I think is a lot better now is we do a much better job systematically at tracking all of these feature requests. You know, we, we, we get a nice email every week now aggregated by, you know, all the feature requests that came in makes it much more easy to prioritize. But back then we didn't have a lot of those systems. And so you were just, you know, I would, I would kind of just walk around the sales and SE area and ask people what they were hearing. So, you know, no matter how, how systematized everything is like, so. Yeah. I mean, this was, this is back in our SF office on, on third street. But then when we moved, I think you and I mostly overlapped in person in the Townsend street office. And I, I would just like a couple of times a day, I would take, you know, he was lazy. I'd take the elevator up to the third floor or sometimes walk and, and just walk around the sales floor. And you would just like, somebody would grab you and say, Hey, have you heard of this problem and this customer? And then you'd hear, you know, two weeks later, the same problem. And then, you know, not, not a super scientific way to quantify the demand, but definitely helpful in hearing some of those use cases to know what to follow. Yeah. So, so it sounds like you brought, you brought the tool to market for, for, for the best providers in the world. Yeah. Yeah. And that was actually to your point on the MVP. I think that there's a really interesting MVP story here too, which is for those familiar with building an API you know, you've got typically a few standard methods that the, you know, when you go to a webpage, it's, it's a get request, right? And you just click and type in a webpage and hit enter. It's going to load the contents for you when you type in some information and you say, submit, that's what's called a post, you know, as you're aware. And so we, when you're building an API, the, the get is like, give me information back. And the post is, is oftentimes a poster put is like, go create this thing. And the main problem that our customers had was how do I create this thing? And so we, you know, we, we flew to Boston myself and one of our sales, sales people or partnership people. And, you know, we spent time with the customer and said, this sounds, this sounds awesome. If, if you can build what's described here, you know, we're going to buy it. And I was like, perfect. So flew back to San Francisco out of the engineering team and said, Hey, great news. We have a first customer for our early product. Not so great news. You know, I committed us to delivering this and, you know, I think it was like two and a half months or something, which was a big undertaking at the time. But, you know, the, the, the confidence building, I think with the customer was really helpful there. And so all we really had time to do was implement that post method, right? So you could say, go get me a certificate, but you couldn't, you couldn't do a get and see like what I had, what I had ordered. And so it was kind of this weird feeling where it's like stuff is just in the ether, but it made for, you know, really powerful demo. And I think one of the things that I think that, that we both learned here is, you know, we're building a lot for developers, right? We're not building for oftentimes people kind of going, I mean, some people use the user interface, but anybody doing something at real large scale which are, I think the product managers, some of the more interesting problems we're building it for developers. And I think nailing that API experience of, okay, this is a well thought through API. They've maybe mocked or stubbed out what the other methods are, but this is going to fit with our workflow is really important problem. And so the, you know, the, the scale of this company originally sold it to you, I think is, is on the order of hundreds of thousands of certificates. You know, since then we've signed up customers that are doing many millions of it. And so obviously you want to build a great developer experience. And we did that initial use case. And then of course, you know, over time we built out the other, the other API calls. One, one thing that happened here from, from software sort of unified to people less familiar with how this stuff works. They asked me like, oh, you're working on this product. Like when is it going to be done? Yeah. How do you answer the question? When is that software SaaS product you're talking about? Is it ever done? Yeah, that is, that is a funny question. I think, you know, especially for companies that are continuing to reach, you know, different customers and, and there's always going to be something to do. Like I, I, I went, we'll probably talk about this, but I'm since switched to different areas of focus. So I'm not as close to this particular product anymore, but you know, I was just chatting with that product manager, catching up with him earlier today on a different call. And I know there's a whole bunch of other different use cases that are being worked on there. And so, yeah, it's, I think it's done for a certain customer at a certain point in time, but it's really never done. Because there's constantly things that you're trying to make easier. I mean, at some point you get to a level of maturity in a product where you're not having to invest in the same way that you're doing early on, but yeah, it's never done as you said. So as you mentioned, you, you, you sort of shifted focus a year or two ago from, from mostly a more sort of, I don't know, how would you, how would you describe your current area? Yeah. So I, I took on a new role in, so what I, you know, I think with, with a company like Cloudflare, especially even the people joining today, we're growing so fast and there's so many more things to do as we, you know, get more and more customers that I was able to transition. I lost you there, Rustam. Yeah, sorry. I was just making sure the camera wasn't turned off. Yeah, you, by the way, very impressive webcam. The crispness, you're kind of showing me up with the... Okay, that was the intent. That was actually the only reason I installed this thing was to dunk on you. So yeah, so, so I think like, you know, there's, we started to hire more and more product managers and you know, we've, as you're aware, you know, we started to kind of build a bit more structure into what the product team looks like. And so I had the opportunity to take on a role where I was managing product managers and helping them learn, you know, one, what it is to do product management well, but two, to do it at Cloudflare. I think it's, there's, you know, any organization, there's a lot of institutional knowledge and way to get, you know, ways to get things done. And so I took on a director role within the product management team. And so I'm now managing a team of product managers based in London. Got it. And mostly focused on security, firewalling, DDoS. Yeah. So the, the, the, exactly. So the, the subject matter is split between a few different security focuses. One, denial of service. And so, you know, keeping both Cloudflare's network online if it's under attack, as well as of course our customers keeping them online. Web application firewall. So what we call managed rules, which are patterns effectively that try to identify requests as good or bad. I was on with a general news model last week. So I won't go too deep in that. You can go, go watch that plug to this week in engineering. And then yeah. And then the, the other areas are kind of the firewall rules or custom rules. And so the ability to write, you know, really expressive rules to, to match traffic and say, you know, this, what, you know, matching traffic saying, okay, I want to take everything with maybe a certain bot score or user agent or whatever it may be and take this action with it. And so all of the custom tools and rate limits and things like that, that's on the firewall team. And then the, the other areas are more what we call frontline systems, which are basically when a request comes into Cloudflare, how do you figure out, you know, whose configuration should be applied? How do you route it through the system, which configuration to load as well as actually more recently as we've gotten all these like SAS providers that we sent, it's kind of funny, all these SAS providers will get signed up. Now there's customers that, you know, want to work with us directly as well. And so there's some challenges engineering wise to figure out how do you kind of apply multiple sets of settings. So I sort of set myself up for having to deal with this problem. Yeah, yeah. So, so that's my, that's my role today. Oh, so obviously, subject matter is pretty different now. Totally, totally. But it sounds like your day to day must be very different as a sort of the jargony terms individual contributor, right? So when he's actually like, yep, at the front lines versus versus a more people manager type team lead type role. Tell me about that. What's beyond the obvious, like now you manage people and before you didn't, like, what does that actually mean? How is that? Do you do you actually needed to do the job to manage that team? Yeah, absolutely. I think, you know, I think the primary responsibility that I have is helping my team be effective in doing their job. And so I think it's very difficult to, to coach someone and ask the right questions to kind of lead them to the right path. If you if you haven't done that job successfully yourself. And so I think, you know, you and I are interviewing, as we grow the team, our peers that are director roles. And so I think that's something that we both sort of evaluate for it. And then can this person do the job themselves? I think it was an interesting transition, because the team is pretty new in terms of hiring people. And so I was kind of playing the individual contributor role for several teams, while I was trying to recruit. And so that was that was a fun, you know, six month period or so good incentive to spend time recruiting. When you're, you know, trying to write requirements docs across. Yeah, it's interesting you say that, I mean, I think you and I both have gone through a very similar transition, right? We're both ICs at a different Cloudflare, right? Earlier Cloudflare, and then we're player coaches for a while as we built out teams and are now sort of Mr. Manager, for better or worse, I feel like I asked more than Jira is more than I actually do real work now. But what does that transition feel like? And was that a comfortable place to be? Or yeah, like, which of those three are sort of your preferred? I think anybody who really enjoys building products, like it's tough to give up that, you know, that, that camaraderie with your engineering team, and you know, going to, you know, to solve a problem together, and, you know, putting in those hours to make stuff successful. And it's, it's really fun, because it's very, like, it's, it's gratifying, you're getting that feedback really quickly. And so I definitely enjoyed that. I think it was hard to sort of give that up for a while. But then, you know, once you get to, I think it was especially harder when, when my team was just one product manager, two product managers. But when you have a lot more people, I think it actually becomes a little bit easier, because you're, you don't have the time to focus there. And, you know, you sort of, you're thinking, okay, I need to be more effective. But at the same time, like, I think you have less time to spend on any given decision. And so, you know, I was always coached early in my career, when you're sending an email, like up the organization to, you know, to your boss or CEO, whatever, keep it, keep it short, and give them the information that they need, like right away. And I always kind of wondered, I'm like, you know, I want to provide all this context and give all this detail, so they have a way to make a decision. And like, why can't they just read this, you know, this five page email that I sent them. And then, you know, once once you're kind of in a position like that, where you're getting asked from a number of different areas to weigh in on a number of different things, you sort of realize, okay, I don't have, you know, that much time. And that gets obviously, you have less and less time, the higher up in the organization you are. And so it's, it's been, I think, it's been helpful to, I think, one of the things of managing a team is you get, you get better at managing up as well, because you are, you are understanding, you know, what you want to see. And it helps you sort of craft messaging throughout the organization. One thing I've realized, like, I stare at some of the problems that come through my inbox, and just like, this is hard, like, why? And then and then I realized, like, the easy stuff has been taken care of. They're not easy, but the like, straightforward things have been addressed. And then the things that get followed up to me are are not there. And I don't have the answers all the time. But that's because someone else didn't have the answer, right? So that's an interesting time. Yeah. And, and, but I think it's been fun. Like I, somebody told me once that if you join a really fast growing company, you're in this constant state of like, learning how to do a different job. And I think that that's, you know, that's quite, it's quite true. I think you've experienced the same thing where you get really good at the job that you're doing. And you, you feel like, okay, I've got this, I, you know, I can, I, you know, I can, I can take take my frothy gas a little bit from a learning perspective, maybe just catch my breath. And then, you know, then you're in this different position, whether it's in a different phase of the company, or actually a different role that you're doing. And you're sort of back to square one, you're like, okay, I'm not not as good. You have a lot of the skills to make yourself good there, but you don't have as much of that experience. And so you're, you're doing quite a bit of learning and growing. But then it's, you know, then then you master that, and then you're moving on to something else. And I think that's kind of been the story for a lot of people like offering as we've grown so fast. Yeah. Do you think like, just be being good at product management doesn't make you good at managing? And as we just talked about, like, it's part of it for sure. Yeah. Have the management aspects of the job sort of come naturally to you? Or is that something you have to focus on? How do you level up there? And what support is available? Yeah, I think I learned I've learned a lot from from our boss, Jen, and sort of how to, you know, be an effective manager in terms of, you know, my natural tendency and inclination is to just say, you know, here's how we do it. And just tell somebody directly, you know, what the answer is. But I think I've, you know, learned a lot from her style of how do you ask questions that are, you know, probing or leading questions to, you know, to get somebody down the path that you kind of already know what the answer is, but you're, you're asking questions so that to make somebody think in a different way and grow. And, you know, when you ask those questions, you're, you're putting in more effort and learning and you're more likely to retain it than if you were just told, you know, how to do something or what to do. So yeah, it's, it's definitely it's, it's definitely been a good learning experience for me. And I've been fortunate to have somebody I think is really effective at doing it to us. I am laughing just because I know the conversation we're talking about again, and then the other traffic music on to occur and Travis to travel. But like, I will go into our one on one with Jen, and I'll start complaining about something. Broken when you do this. You want to do that? Yeah. Okay. Yeah. Here we go. No, and I think the, the the complaining versus like problem solving. I think that's another thing like, you're, you're constantly just solving problems are just different types of problems, right? So it's less like, well, this engineer stuck on this thing, and I need to bring in this other team lead from this other team and work in engineering manager, it's more sort of people and process problems that you're trying to solve. And, you know, kind of constantly reevaluating them. And so you have to just sort of adjust what it is that you're, you're thinking through. But in the day, it's just different types of problems. Yeah. What is switching gears a little bit? What's coming down the pipe? What are you really excited about? It sounds like your role is changing, and you're learning stuff and all that. And that's part of what's what's exciting. But like, if you were a user of Cloudflare, you know, what, what's coming down the pipe? Sure. Yeah, we've got, we've got all sorts of fun stuff in the works. I think, you know, on the DAS side, we've been partnering closely with, with, with you and your team on supporting transit. And so like taking in that traffic and protecting our customers at the network layer, as well as, you know, telling them when they're getting attacked and what that traffic looks like. And so we've been investing quite a bit on those network analytics and better protections and protections also at a cheaper scale, right? So the quicker we can drop something that's bad, the less CPU is consumed, and the more is available for other products like workers. And, you know, if we can keep those costs down, then we can keep our prices down and give a tremendous value to our customers. On the, on the firewall side of things, you know, broadly speaking, I'm really excited about a lot of the stuff we're doing for API production. If you think about what, what Cloudflare, you know, where Cloudflare started, a lot of the early sites that were on us were things like WordPress and Joomla and these content management systems. And we built up this really rich library of patterns to match against. And, you know, we stay quite a bit ahead of those protections. But where, you know, the traffic has gone on the Internet at large, I think I read a statistic saying like something like 83% of web traffic is API traffic. And so that could be things that are powering, you know, your mobile applications, anytime you open an app on your phone, anytime you, you know, have an IOT device, you know, your refrigerator these days, you know, phoning home and saying it needs, you know, service or something, all of that stuff is over APIs. And we've built some tremendous protections for those APIs. I think, you know, from a denial of service protective, rate limiting, you know, full body, regular expression based pattern matching, we have all these great ways to protect the traffic. I think what we haven't necessarily done is make that super easy to use and super obvious. And so, you know, going back to the point about why it's really fun to work on products here right now is you can take a couple of things that you've already built and put them together and really solve a lot of people's problems. And so one of the areas in particular we're going to be solving here is how do you actually secure the authentication from that in a similar way to what we do with universal SSL, where, you know, we can make it get a server cert, why not make it just as easy to get, you know, a client certificate and, you know, security folks like to say, like, you want to use something that you that you to authenticate yourself that you know, and that you have, right. And so something that you have is a client certificate. And so if we can, and we've been doing this as part of our access product for services, as well as individuals, but if you have an API, you know that only these users should connect to it, then can we give it in a way that is using strong encryption, the same way we're protecting servers with that. And then, you know, if you can also say this is this is what good traffic looks like something called a positive security model versus a negative one saying, well, this is bad. You can say what this is good, you can kind of quickly cut a lot of this stuff out that you don't really validation in addition to this sort of authentication piece, then, like, yeah, this is what a good request looks like. Yeah, that's what a good request looks like. And so, you know, if we go back to that example of sending that that post call to order a certificate, there are certain fields in there that they only make sense, you know, or certain fields that don't make sense. And you want to kind of if someone's trying to use those could be some sort of probe for an attack. And so kind of discarding those. The other thing is, there's a trend of API traffic that's switching from the protocols that we've known, you know, for many years, HTTP with JSON, you know, there's kind of a structure of the payload to more binary protocols that are more efficient and can do like remote procedure calls. And so there's something that is called gRPC that we are a lot of customers actually moving their entire mobile applications to. And so I spoke to one food delivery app not too long ago that said, you know, by next year, they want to have the vast, vast majority of their traffic using gRPC. And so how do you secure those sort of new protocols is something that we think a lot about. And we're partnering with your team on that, of course, to take that traffic through, but also to combine it with all those other security solutions that we have in the works as well. Yeah, I think that's a fascinating illustration of the like size and shape of a problem we can tackle now. And we couldn't have as a smaller company, right? Like we just have more teams working on more things. And you have like this cornucopia of solutions that you can put together in interesting new ways. Yeah, absolutely. And we're in more conversations with companies that, you know, it was not that we were that small five years ago, but like the company, we're much better known name today. And I think we've, we've earned the trust of some really, really large companies. And I think that that's due to a lot of, you know, hard work across, you know, all sorts of teams. But now that we've earned that trust, I think the things that we're being asked to do are much bigger and larger and more important than the things that we were being asked to do, you know, a while ago. And so we get to, from a product perspective, that means, you know, more, more fun things to build and put in customer's hands. Yeah. So, you know, we've gotten the trust of larger customers. We talked earlier about how we built a lot of things for really, really tiny customers as well. How do you think about the two sides of that spectrum? And how does that impact how you build, how we build products? Yeah, I mean, I think there's big customers, there's large, small customers, there's, you know, we have a lot of people not paying us anything using our free plan. And I think we deliver tremendous value on that plan. And that, you know, actually, I think it's great that we have that both from, you know, from our perspective, it helps us test our products. But also, I remember early into my tenure here, I was on site with a customer and nobody in the room had kind of purchased Cloudflare at a corporate level. But I asked, you know, anybody in the room if they had used Cloudflare, and you know, most of the hands of the engineering team shot up, they were using it on their own personal sites, and so had experience with it, familiarity with it. And that's really helpful. I think, you know, thinking about who we're building stuff for, I think, I think more about, you know, what is the persona of the person at that company? And so what are they tasked with doing? And if they're tasked with securing those, those API connections, the solutions they need, they might need more of, you know, more of them are at a greater scale. But at the end of the day, like there's good ways to solve problems, and there's not so good ways. And we want to build the good ways and give it, you know, to everyone. And maybe there's some more limitations or configurability or visibility, as you kind of scale up, but for the most part, you're still getting that same value. Yeah, yeah, that makes a lot of sense. We got a couple minutes left. You touched on this earlier in the conversation, but what advice do you have for folks trying to to grow up to be, be like Patrick Dunn? Like what, what folks who want to want to be product managers, whether it's a club or otherwise, you know, you talked to a lot of a lot of folks trying to do just that. What makes people successful versus not in that sort of journey? Sure. Yeah. Drink your milk, first and foremost. I was told that growing up. I have initials that spell E-R-D. Yeah, yeah, yeah. No, people always look at my initials and say, huh. I was, I was born to do product management. So the, I think the thing that I would suggest, first and foremost, is like, be technically curious. I think that's the most important, to me, foundational aspect of doing product management is wanting to understand, you know, what, how people do things, what problems they have, how could you potentially solve those problems? And, you know, a lot of what you and I do is, is sit there and ask questions, you know, all day long. We talk to customers many, many times per week. And your, your verbal communication skills are super important. I think, you know, it's not just, can you write a great document that, that engineering can take and iterate on? It's, can you get the information you need to decide what to do from those customers? And so communication, just working on verbal communication, as well as written, I mean, I think, you know, it's critically important to be able to express yourself and communicate your ideas, especially now that we're remote, right? You're having less in-person meetings and you're doing stuff more asynchronously. And so putting that stuff down. There's an interesting sort of implicit distinction you made just now. You said be technically curious, but that doesn't necessarily mean be technical, whatever that means, right? Like it's more about wanting to ask the questions and wanting to understand how things work rather than being a technical expert, right? Yeah, exactly. And I think you don't have the tights on. It's not the right place to become that technical expert. That's what you want to do. Maybe you should be in engineering, for example, but you need to get your hands dirty and know enough so that you can then step back and think about how you solve those problems. And then, yeah, I think just being super detail-oriented, like we need to be very precise in our language. And so, you know, put yourself, I think one of the nice things about having been a software developer before is, you know, if you were getting some documents and reading it, like what questions would you ask to understand that? And so you try to not leave those things out, I think being able to do that. And then I think just preparing and doing research and just to people interviewing, I think like coming in and understanding what a company does and why is really important. You'd be shocked at how many people don't. Where's Cloudflare here? No, no, no. Check out our website. Cool. Well, we're out of time. Thank you so much for joining and we'll see you.