How Cloudflare Built This

Welcome to this week's episode of How Cloudflare Built This. I'm here joined today by James Allworth, our Head of Innovation.

I'm Rustam Lalkaka, Director of Product here at Cloudflare.

James and I were just talking about what outrageous things we were going to say on this show.

Boost the ratings. Outrage seems to be all the thing right now.

Yeah. And the other thing we were debating is whether or not we should allow my mom to dial in if and when that happens.

If your mom dials in, we are totally bringing her on air.

Fair. Okay. We're going to turn the tables, at least for now.

I think normally it's you pinging people about what they've built at Cloudflare.

But at least for the start, I feel like we should get this from you. You've been a PM here for like, gosh, how many years now?

A little more than four years.

Four years. And you've built some stuff pretty foundational to Cloudflare. But before we get into that, how did you end up here?

Okay. So first off, I appreciate the gambit.

I invite you onto the show to interview you, and then you flip it around immediately.

This is outrageous, and I think the ratings are really going to go.

That's a good question.

How did I end up here? It depends on how far we want to go back.

But I grew up in New York City, constantly playing with computers.

My parents sort of built that tinkering, nerdy thing in me from a very young age.

I would go dumpster diving at middle school and fish broken computers out of the garbage and- Oh, nice.

Frankenstein them and run esoteric Linux distributions on them, and then try and get antique networking systems working.

So anyway, I was mucking around with all that from a very young age. And for whatever reason, never really thought about pursuing that seriously academically or whatever.

What did you think about pursuing academically then? For the longest time, I thought I was going to be an ichthyologist.

So I spent several years in high school working at the American Museum of Natural History doing taxonomy and morphology on African catfish.

And I thought I was going to be a taxonomist and a phylogenist.

And it was actually a really interesting time to be in that space because it was early 2000s and people were just starting to transition from thinking about biodiversity in the same way that Linnaeus did in the 18th century.

It was a bunch of rich dudes tromping around in the wilderness, catching specimens and then measuring them carefully and taking pictures and making drawings and then saying, this is a new species and imposing all sorts of very artificial and arbitrary species concepts on the world.

And right around that time, this was right around the Human Genome Project and all this, when sequencing was starting to become a thing.

And this new class of taxonomists and geneticists were coming around who were saying, that's not the way to catalog biodiversity.

You do this with computers.

And it was clear that there was a lot of promise to that, but there was also just this crazy culture clash between people saying, I wrote this code and it says all these things are unrelated to each other, even though you think they are.

And all these interesting debates were happening. That was what I thought I was going to do when I grew up.

And how did things change?

I also became a big monetary policy nerd. I was super into that for a while.

It sounds like a crazy meandering story. It is. I studied that in college and then happened to be taking some CS classes on the side because I was interested and met a professor, Remzi Arpachi-Dusseau in Madison, where I went to school.

And he was basically like, dude, you're really good at this stuff. Why would you go be an economist?

You should take CS seriously. And I listened to him and one thing led to another and here I am.

So anyway, yeah, I went to Microsoft after school, worked on Exchange.

Also was there at a serious period of sort of shifting.

What time was that? I started there in 2011. And that was right when Bomber actually, Bomber doesn't get a lot of credit for much of anything, but sort of read the tea leaves properly and said, all this on-prem software that we sell is ancient history.

We're going to go all in on delivering things with services and the cloud.

And so watching that happen was super cool, super interesting.

Didn't really appreciate how disruptive that was at the time. But yeah, I worked there for a couple of years and then left to start a company, moved to San Francisco as part of that.

For various reasons that didn't work out, tried to start another one, sort of focused on consumer wearables.

It was like early, early, yeah, sort of took that from four or five employees to 20 or so and probably like 50,000 users.

And then left and joined Cloudflare. How did you find out? How did you hear about it?

About Cloudflare? Yeah. One of the investors, Inspire, the company I was at prior, was one of the founders of DreamHost and was close to Matthew.

And I was friendly with him and I said, hey, I'm thinking about leaving Inspire.

What company should I look at? And he was like, oh, you definitely need to talk to Matthew.

That's awesome. And I had heard of Cloudflare before that.

It wasn't like it was a total shot out of left field.

But yeah, no, like a really interesting company. And then I think one of the really interesting things about Cloudflare to me at the time was that I had worked, I had seen B2B software at Microsoft and I had seen B2C tech happen in a super small scale at this wearables company.

And there were parts of both that I really liked, right?

The B2C, even at the small scale that we were at, you just had so much more data and you could be so much more sort of like empirical about how you made product decisions.

But it turns out businesses are a lot better at telling you what they want.

And so I wanted some way to bridge that gap.

And there were a lot of companies that started in that sort of like 2008, 2010 period that sort of pioneered this like business to developer type business model that sort of splits the difference, right?

So the Twilio's and Stripes and Cloudflare as well.

And I was drawn to that classic company that had scale in terms of customer base, but was still sort of B2B at its core.

Yeah. It's interesting, like that framing of you're thinking about trying to change individuals' minds and how individuals react, which is more of a consumer nature aspect of a business.

But at the same time, it's definitely not selling things that you use so much in your everyday life, as opposed to enabling people to do their job.

I hadn't thought about it like that. It's cool. Yeah. Which I feel like is a pretty good segue into like, what do you actually do at Cloudflare?

Obviously, you're a product manager, but like talk a little bit about that, what your responsibilities are.

Yeah. So when I joined, there were a few product managers already, Pat and Angie, and some folks who are still around, and then a lot of folks who have left.

But I would say that as a discipline, product management was not super established or didn't have like a clear identity when I joined.

And that was super interesting to see, right?

If you read a textbook on software development, it's like the product manager figures out what to build.

And it turns out like Matthew and Michelle are like the best product managers ever, right?

They found some really horrendous pain that a ton of people were having and figured out a really elegant solution to it when the company launched.

And a lot of, or most of the energy over the years from when the company was founded to sort of around the time I joined was focused on just like keeping up with the just incredible explosive growth from that point to where we're at.

And then we were just starting to think about how do we build brand new products on this platform, both from a technical perspective and a user-based perspective to solve more problems, right?

And so that was sort of, and it turns out like product managers are the right people to help, that the skillset that we have is the right set to go solve that problem.

So that was kind of fascinating, right? Like coming in and we had millions and millions of users, a lot of happy paying ones and massive network.

And it was basically like, we got to figure out our second act, right?

And those were the marching orders.

So I actually, I became the product manager for our content delivery network off the bat.

And sort of, there's so much to do there.

There's still always so much to do in terms of building new features and making it more configurable and all that.

And then I was trying to figure out how to build things on top of that, and go beyond just sort of delivering bits as quickly as possible.

There were also a couple like really key feature requests that hadn't been sort of delivered on for years and years.

And so first order of business was like figuring out how to stop some of the bleeding there.

And so tier cash was one of the sort of like important things we did up front.

So up until that point, every Cloudflare data center was totally independent.

They didn't talk to each other. And so we built Argo tiered cash to help improve cash ratios generally and have all these different data centers talk to each other.

And so drive more network effects from a sort of like literal network perspective.

And then the other early project I worked on was actually related in product terms was Argo smart routing, which was basically how do we take the data we have on all this stuff moving across our network and use that to make better routing decisions.

Yeah. Ways for the Internet. Ways for the Internet. Yeah.

Yeah. That's pretty cool. It's awesome how many folks from the early days are still around here.

It's one of the things that makes the culture, I think, so wonderful.

One of the things that I really wanted to ask you about was whether you had any fun war stories from those early days.

Cause it's like, we're like what, 1500 people or so now it's like, I am sure it was a very different place four years ago.

Yeah. It was very different as an extreme understatement. Yeah.

I mean, it was really intense, honestly. And I think everyone still works really hard today and all that, but the pace felt even more relentless and sort of, we like to say when people are running marathons, right.

We're running a marathon here, not a sprint, but then it really felt like we were sprinting for a marathon.

What are some interesting war stories?

We really struggled, honestly, to get things out the door then, right.

In kind of like basic ways, right.

Like we weren't, there was not a lot of, we had all these ideas on things to do, to get new products out the door, like I was talking about.

And we just kept spinning our wheels for different reasons, right. Like we just didn't have a culture built yet of figuring out how to push new things out the door on a schedule and then iterating from there.

And there was no single thing.

I think the most interesting thing actually about all that was the pivotal turning point in going from, we can't ship on a schedule to save our lives, to we're really good at delivering on things we want to do on a date.

This sounds so simplistic, and I think it was actually a key learning of mine.

Alex Diner, who was sort of acting as Alex, I try to be nice to Alex, even though he's easy to make fun of.

He has terrible handwriting.

This is a key ingredient in the story. It was like, we just need a schedule that everyone can look at.

And it will be totally obvious when someone is late or not someone, but like a team is late or something is slipping.

And that's not to say like that team should be embarrassed, but like it needs to be totally clear that we are missing the boat here.

And so he took a whiteboard on the second floor of our San Francisco headquarters, and he took a Sharpie and he wrote Alex's shipboard.

And then he took a yardstick and drew this very rudimentary schedule on this whiteboard.

And actually, if you look carefully at that whiteboard, you can still see the Sharpie marks.

And he started writing down by hand all the different projects and when they were supposed to ship, and then would circle things in different colors when things were late and all this.

And that whiteboard took us from total chaos to we're delivering things on time.

And it was just remarkable, right?

Like it's the simplest little things that sort of got us on track from that perspective.

So yeah, I mean, that's not a war story so much as like, I don't know, I'm going to poke fun at HBS here.

But yeah, please go ahead. I mean, I don't know, would that show up in an HBS case study, like just write down a schedule on a whiteboard and then point at it and everyone's going to start shipping on time?

That's a really interesting question. I had a, it's funny because Dinah is from the finance world and I love Dinah, but I also love poking fun at him.

And one of the things is like the New York financier turns up in San Francisco.

That's something that I will often poke fun at.

But at HBS, one of the first year classes we take is leadership.

And I got Rob Kaplan, who is a leader inside of Goldman Sachs and is now head of the Dallas Federal Reserve, if I'm not mistaken.

And I remember sitting in class as he was talking and he would just talk about the simplest things, like, you know, like stuff like, you know, you think you've told people stuff, you have to tell them a hundred times before they actually get it.

Like just simple stuff. And I'm sitting there thinking, man, like I came from management consulting.

I don't need to hear this stuff. I tell you what, the wisdom of the messy, the messiness of the real world revealed the wisdom of that stuff.

So actually, that kind of stuff does show up at HBS. It's just, sometimes it's just the basics that end up making a big difference like that.

But that's pretty cool that it's Alex's shipboard that took us through, sounds like it got us through our teenage years.

Yeah. And then it got us through our teenage years. And then we were like, wow, this is really effective.

And, you know, we were already a pretty distributed team at that point.

And the one obvious problems with Alex's whiteboard was that it was only in one place.

So Uzman, who started right around then as our head of engineering, was like, wow, this whiteboard works really well.

We got to figure out how to like scale the whiteboard.

Yeah, scale the whiteboard. Yeah, exactly.

I think a critical thing there was not, okay, like this whiteboard was like an interesting little sideshow, but we're going to figure out like an adult way to do this, right?

It was, this is working. Let's grow this, right? And so Uzman wrote code, which he called the shipboard.

He found the most grotesque handwriting font he could to keep things uniform.

You want to stay true to the original.

Yeah, exactly. And built a little Python app or whatever that directly replicated this whiteboard.

And, you know, we've gone through four years of iteration on that thing now, but that shipboard software is still the underpinning of how we deliver software at Kleffler.

And we have all sorts of automation wired to it and sort of like virtual Uzman and ghost of Alex Steiner who follows product managers and engineers around and says, you know, this project was supposed to ship on this date and it's on time or it's late or whatever.

And it's interesting too, because like when you're inside this system, you're like, wow, this is like really rudimentary, but I guess it works, blah, blah, blah, blah.

You know, I talked to my peers at other companies.

I'm like, how do you guys solve these sort of visibility and accountability problems around software timelines?

And they're like, oh yeah, we like bought this third party tool and it doesn't work very well.

And like, blah, blah, blah.

I wish we had something better. And then I describe our systems that are all homebrew and like seem kind of janky and I guess they work and they're best in breed, right?

It's pretty cool. Yeah. That is a really cool story.

That's one process war story. I think the other thing that happened very, very, very soon after I started was CloudBleed, which was the war story of all war stories.

A lot we can talk about there.

Slightly amusing anecdote related to it was, we do this all hands meeting every week.

And actually the tiered captioning feature that I was talking about, we had just finished and I was up in front of the company, which was not 300 people at the time and said, announce this feature.

And it's the first major change to Nginx in a while and blah, blah, blah, blah.

And I was up there with Yuchen, one of our engineers. And all of a sudden, I see all this frantic activity and I was like, something.

And then Evan Johnson, who ran our product security team at the time, and actually still does, comes up and pulls Yuchen off the stage.

And I was like, I don't know what's going on.

And then this rumor started going around that there's this horrible bug in tiered cache.

And I was like, oh no. And obviously it was pretty bad. And we spent the next week plus hunkered down.

And it was actually pretty cool seeing how that scale of incident response sort of went down and how that brought everyone together.

And I still remember the conference when we were all in eating pizza and figuring out how to clean up.

And obviously not an experience I want to repeat, but it was interesting.

There's something that is revealing about people and organizations, teams, when they go through crises.

It does reveal people's true colors, right?

Yeah. And I think one of the things I really appreciate about being here is there's never, how do we cover this up or how do we spin this?

It's always, we are going to be as transparent as humanly possible about this.

And that is how we are going to A, emerge from this, but B, win long-term.

Like transparency always wins.

And that's my interpretation of things.

Maybe you can - I mean, well, there's a competing thesis happening on, I guess, on the other side of the Pacific ocean right now, I guess, maybe not at a company level, but at a national level.

And it's probably worth pointing that out, but I tend to agree with you.

And it's one of the things that drew me here is just, you meet everybody and there's just this culture of people being principled, being transparent and people being curious.

And those three things, it makes it somewhere where I want to work and it makes it something.

And I appreciate those qualities in people.

Yeah. Yeah. And it's interesting teaching that to new people, right?

When we still have incidents and things go wrong, always go wrong and we're always getting a little better at that stuff.

But just having people write their first incident report and then I'm like, include every detail you have.

And they're like, but that might make us look bad. I'm like, put it in the report.

That's okay. Yeah. Yeah. It's also the short run versus long run thing, right?

It'll make you look bad in the short run, but in the long run, willing to accept the fact that you made mistakes and owning up to them, acknowledging that's the first step in trying to fix something, whether it's a technical thing or a cultural thing or whatever it is, you can't fix something you don't want to acknowledge.

Beyond that, you don't give people around you confidence that you're going to fix it if you not even willing to accept that it happened.

Yeah, totally. I mean, I think the other thing is that, and this is one of the interesting things about working here.

And one of the things that drew me to it is that the sort of like distance between us internally as a product and engineering and operations team and our customers and like the people actually consuming our services from a subject matter expertise perspective and just like general skills perspective and all that is very, very short, right?

Like I am often talking to folks, my peers at our customer companies, and they are of similar backgrounds to me, similar skill sets, et cetera.

And so not that this makes transparency any more or less valuable, but like they read these reports and they're like, oh, I totally get how that happened, right?

Yeah. I mean, don't bullshit people.

It's actually pretty simple. I mean, really it is like, but let's keep going.

More recently, one of the products that, one of the things that a lot of folks are pretty excited about, Magic Transit, that's something that's been your baby.

Talk about how that came about, what it is, I guess, first of all, for those people listening who don't know what it is, how it came about, the story of that.

Yeah. So Cloudflare since its inception, kind of by accident, actually, if you ask Matthew and Michelle, it was really good at DDoS mitigation for HTTP applications, right?

So you set up Cloudflare as a reverse proxy in front of your HTTP endpoints.

And then we would terminate connections from clients that we call them eyeballs internally, and then re -establish connections outbound to the origin.

And just by breaking the connection in half, it turns out we protected our customers from most classes of DDoS attacks.

The funny thing about that though, is that our network was then subject to all these horrible attacks, right?

Like we were actually taking the body blows on our customer's behalf.

And it turns out we were not very good at dealing with that ourselves in the early days, right?

Like if you talk to Josh Dankbar and Jerome Flurry, and a lot of these folks on the op side who have been around for a long time, they were like, we used to just get paged.

And then some engineer would like log onto a box and like desperately be trying to figure out how to stop this thing.

And being a company of engineers, we were like, we got to figure out some more sustainable way to deal with this that isn't paging people.

There's actually a Harvard Business School case study on this.

And Josh is actually a character in that case study.

But anyway, being engineers, we're like, okay, there's got to be some technical solution to mitigating DDoS attacks on our own infrastructure, right?

We're already protecting our customers, but we are getting whacked and it's painful.

And so the options were go buy DDoS mitigation hardware, or there were already services available that you could go pay to work on your behalf.

We were like, we just don't have the cash for any of that, right?

And we don't think any of these are going to work very well. So we're going to build it ourselves.

And we put one engineer on this, because there were probably only Ken and the company.

And this guy had no background. This is Merrick Myakowski. He had no real background in DDoS mitigation, but he was just a really smart guy and approached the problem from first principles and built a really badass DDoS mitigation system.

And it got better and better over the course of years.

And fast forward from like 2011, when we're paging Josh every 20 minutes to 2018-ish.

Flawless, right?

The thing just works. And we had gone from terrified of getting attacked ourselves to no big deal.

And we were talking to customers and they were like, so we run a large IP network still because we're migrating the cloud, we're moving all our stuff to the...

We'd like to be able to use Cloudflare in front of everything, but right now we can only use it in front of our HTTP applications.

Can you do anything about DDoS mitigation for our corporate networks?

And we looked at them and we said, we had this problem ourselves a couple of years ago and we solved it.

We should productize what we built because it sounds better than anything else in the market.

And so that's what Magic Transit was. It was us taking the IP layer DDoS mitigation tools we had built ourselves and packaging them up in a way that our customers could consume for their own networks.

One of the interesting things about this was...

So I had looked at the space, the DDoS mitigation space, and I was like, this is kind of like an old and boring in some ways market.

I don't think this is actually worth doing, right?

We're a high growth company. Mm -hmm.

You know, this is like... This doesn't pass my rocket ship. Sniff test, yeah.

Sniff test. And then I looked at it more and I was like, wait a second, DDoS mitigation is not the end game here or could not be the end game.

Why don't we start with DDoS mitigation and then build all sorts of other stuff on top of that, like firewalls service or intrusion detection system or all these more sophisticated higher level security functions.

And then I was like, no, that doesn't make any sense.

There's all these other vendors already doing DDoS mitigation and none of them do that.

So I must be missing something, right? Right. And then I sort of like...

I'd worked on a dock with Pat Donahue and Malavika and some other folks internally and sort of put it aside and said, like, something doesn't add up here.

But the more I thought about it, I was like, wait a second, no, this really makes sense.

We're going to start with DDoS mitigation and then we're going to go right up the stack and we're going to help all these large enterprises who still have large on-prem data centers slowly replace the hardware they have on-prem that do these esoteric, not esoteric, but like very specific network functions.

And we're going to deliver them all as services, right, at the IP layer.

And once we have the traffic to do DDoS mitigation, that's a natural place to sort of build up from there.

And so we launched Magic Transit and that was always the plan, right?

Like to cover this sort of like expansive vision and suite of services.

And so we launched Magic Transit last year and people were like, oh, that's interesting.

Cloudflare's getting into this kind of sleepy DDoS mitigation space.

That in itself is interesting because like Cloudflare's approach to this problem is fresh and new and different from what's available.

But no one actually saw what was happening, which was really, really interesting to me.

And what was happening? We had this grand scheme that we were starting to execute on.

And it's interesting to me because like the way you described it, it sounds like you almost had the revelation from first principles.

Like you looked at it and it's like, no.

And then you looked at it again and it's like, hang on, what about if we do this and then we do this?

And it's one of these things about good ideas that like if you look through the sweep of history or even within companies, like good ideas seem to often pop up in more than one place at the same time.

And I can speak to a few folks, it's like they might have had a different way in on the idea, but the idea was almost like kind of a guiding principle that's been guiding a bunch of the things that we do.

And it kind of brings us pretty neatly to the idea behind Cloudflare 1, right?

Yeah, no. And so Cloudflare 1 is sort of us packaging up the whole vision into something discrete.

And it was super, so when we launched Magic Transit, I distinctly remember this one tweet, I should go find it.

Someone was like, Cloudflare's doing some really interesting things and they all kind of line up in this interesting way.

And I think in a year or two, people are going to be like, I forget what the Star Wars quote is, right?

That's no moon, that's the Death Star. And I was like, that guy gets it. And so yeah, Cloudflare 1, which we announced last week, or not last week, last month, was sort of the culmination of, or us sort of connecting all the dots.

And in a way that we had been talking about internally for a while, but sort of laying that all out for our customers and How do you describe it to folks, Cloudflare 1?

Like when someone's like, what is this thing?

It sounds cool. How do you describe it? Yeah, I think I describe it as a one-stop shop for corporate IT and security teams to protect and secure their corporate infrastructure and keep their employees productive, all from one.

The wonky way of describing is a control plane, right? But they're able to do that all from one place instead of having to balance between 16 different vendors.

Really? And the skeptics that I've heard would be like, that one thing, the one place, that's an advantage?

Or how is that an advantage to them?

Yeah. So there's three reasons, right? And I'm already smiling because these will sound familiar to you.

One is, I mean, ease of management is key, right? Like literally logging into one portal or one API to manage this stuff versus 10 of them is just wrong, right?

It's a math problem, right?

The second thing is back in the day when you were running a data center and all of your traffic was physically in the same place and you were moving traffic from one slot in a rack to another slot in a rack to another slot in a rack to perform your security and load balancing and other functions, it really didn't matter how many vendors were present in that rack, right?

From a performance perspective. The bits are, we're worried about the speed of light here and the bits are moving the same distance no matter whether it's going from a vendor A box to a vendor B box or a vendor A box to vendor A box.

When you're delivering or consuming things as a service and things are being delivered from a vendor's infrastructure, those vendors' infrastructures are in different places, right?

Physically distant places. And so every time bits have to move a mile down the street or 100 miles across a city or 1,000 miles across the country, latency is introduced, right?

And latency directly impacts your employee or user experience. And so by consuming all these services delivered from one place, one physical location, your bits don't have to bounce around and you've shaved multiple latency off of your security solution.

And that really matters, right? Especially in the context of COVID and working from home and a very distributed workforce, you don't want to be moving your traffic from Seattle to San Francisco to New York to Chicago and then back out to James and San Francisco or whatever.

So that's the second reason.

And then the third reason is consolidating on one vendor just saves you money, right?

Like there's no other way to slice that. So, yeah. I'm smiling and said that all might sound familiar because that sounds like the message some people delivered to Wall Street.

Are you about to rest the wheel away from me? No, no, no.

We can give it a second. I'm actually enjoying this. You can keep going.

Okay. I will keep going then. But it's been fun getting into the products. I imagine there are a few folks out here who have thought about either maybe working at Cloudflare or maybe working in product management, maybe even working in product management at Cloudflare.

Advice for them? I think all this talk about first principles should show how we operate, right?

We like hiring hardworking, smart, relentlessly curious people.

And if they have no expertise in the thing they are working on at the start, that's not just fine.

That's almost encouraged, right?

We've gotten to where we have gotten by, you know, I interviewed Matthew on this show a couple of months ago and he walked me through the sort of origin story of Cloudflare and same story, right?

Matthew, Michelle, and Lee, they knew a little bit about how the Internet worked.

They knew a little bit about security. They knew a little bit about websites.

They were not experts in any of those things.

They just kept talking to users and said, what sucks about running a website on the Internet?

Yep. And then they're like, okay, what if we did this thing?

And everyone's like, oh, yeah, that sounds good. And then they did that and then they learned from that.

And so just that attitude of curiosity and willingness to try things and then learn things and then go from there is really the most important skill, right?

Like, maybe I shouldn't be admitting this. I barely knew what BGP stood for a year ago, right?

Or two years or whenever, you know, when I started at Cloudflare, right?

And I had to learn very quickly. And, you know, I spent a lot of time with our network team and I was like, could we do this thing?

And they're like, no, you're crazy.

And I'm like, okay, can we do this thing? And they're like, oh, that's actually a really interesting idea.

We'd never thought about that before, right?

So like, yeah. Beginner's mind is a real thing. I mean, I like, it is definitely one of the things that I appreciate just how, okay, when you don't know something, there is a tendency for you to pretend like you or you start dealing with insecurities in all kinds of ways to try and cover up for that.

One of the things that I love about this place is people respect you more if you just say, I have no idea what the hell's going on here.

Like, help me understand. Yeah. Nobody has held that against me.

In fact, people prefer it. It's like, oh, he's interested.

He's curious. He wants to learn and he's not willing. He doesn't need to pretend that he knows something that he doesn't.

I guess that's PMing here.

What about PMing in general? I think those skills are valuable.

Having those skills will always make you a better PM. I don't think they're always totally necessary at every company.

Some companies do value subject matter expertise and very specific traits and skills more.

How do you know whether you're more likely to be good at one of those?

I mean, because that's the kind of advice that I feel is actionable.

It's like, OK, it seems like when you're PMing, some companies prefer the more first principle, come in and learn.

Other companies prefer subject matter experts. How do you figure out which one of those is going to be better for you?

I think how comfortable you are with uncertainty and chaos is a key differentiator.

There's no secret here.

People join Cloudflare and then they're like, oh, my God, this is crazy.

I got to get out of here. People do leave. The ones that do leave tend to be the ones that are like, I can't deal with the amount of uncertainty and ambiguity around me.

That's not a bad thing. I think I want to be very careful to point out, you don't have to be OK with ambiguity.

That's fine.

Different strokes for different folks. But I think that is the differentiator.

The way to cut through chaos is to ask first principles questions and root things in at the most basal level possible and then go from there.

I guess maybe we've already touched on this.

How do we recruit them? What do you look for in people?

What are the kinds of things that I can only imagine getting grilled by?

You must be fun. How do you go about doing it? Someone sits down in front of you and says, I want a job here.

What are you going to look for? How are you going to get there?

The first question I always ask is, why do you want to work at Cloudflare?

There's no right answer to that question, but there are definitely wrong answers.

Just an example of an answer I really don't like is, I saw you on the list of top 100 innovative companies and I want to work at an innovative company.

I'm like, why did you not talk to any of the 99 other companies then?

I think good answers are, I believe in Cloudflare's mission and I want to help further building a better Internet.

If you don't care about that, that's fine too. I was really fascinated by this one project you did.

I thought it was really interesting for X, Y, and Z reasons.

I want to be part of a company that is able to execute on that kind of stuff.

Great answer. There's so many different ways, but you should just care a little bit about something and be able to talk about that.

That's generally good advice.

It's crazy how many people don't pay attention to that stuff. I've interviewed people and I'm like, why do you want to work at Cloudflare?

They're like, can you tell me what Cloudflare does?

I'm like, what? I've heard that sort of interviewing advice 100 times and I'm like, does anyone need to actually hear that?

But it turns out that people do. Very good. One of the things that perhaps fascinates me most about this company and I find myself spending a lot of time thinking about is how we structure it.

Because we're always building new things.

I worked a lot with Clay Christensen and one of the things that he always said is the advantage that a startup has over an established incumbent is they literally get to do effectively at a nested level, what you were describing earlier, which is come at problems with a beginner's mind and organize themselves all around just what it is that they're trying to solve for customers.

You've been here for a while.

How is the company structured? Talk a little bit about it.

How did we end up here? Matthew and Michelle have spoken about this in various forums.

There was very early on a deliberate lack of emphasis on titles and classic organizational design.

It was like, hire smart people, throw them in the same room, find product market fit, and then do whatever it takes to keep going at.

I think even when I joined, which was five or six years into the company, that was still very much the ethos.

Super flat, no titles. There were different roles for sure. You knew who the salesperson was and you knew who the engineer was, but you didn't know if so -and-so was a level seven engineer or a level five engineer or whatever it is.

Deliberate lack of specialization.

It was like, your job is to do whatever it takes to make this successful.

I think we're still organized that way. We've made changes over the years.

We have levels now. I think there's more titles than there were and there's more managers and all the things you would expect, but you can still see that DNA.

Just approach every problem from first principles and don't worry about whose job this is.

Those feel a little bit like artifacts of the structure though.

I think you alluded to it.

It's still mostly a functional organization, but with a few interesting twists.

What do you mean by that? Well, we have engineering and sales and whatever, but we also have an emerging technology group because there's this recognition that disruptive stuff, it's like when you've built something that's become successful, it by definition has been built to be successful at that thing.

That doesn't necessarily mean, in fact, it's probably going to be a disadvantage in terms of what it takes to build the next thing.

There's this very direct tension between specialization drives efficiency.

It doesn't make sense for everyone to know how to do every job.

To scale, you need to have different people do specific things over and over again and get better.

Specialization inhibits innovation at some level.

That's related to communication overhead and all those things. Two people in a room are going to be able to get clarity on an idea faster than 10 people in a room.

That's just math. There's nothing you can do about that. If you have two generalists in a room, you're going to be able to get clarity faster than 10 specialists.

That ETI, emerging technology and incubation thing, is a way of playing on that.

How do we specialize as a company and continue driving efficiency and get greater and greater scale while still preserving that DNA around generalism?

It's super interesting to me that you're in the core part of the product group, but that culture of just do what it takes to get things done still prevails.

That was very apparent to me with Cloudflare 1.

You're a key part in bringing that vision to life, but you're working with folks inside of the ETI group in order to get it done.

It functions, but we all play nice together, which is kind of cool. Yeah, absolutely.

There's a bit of a drag race or something happening outside of my apartment.

Even with more specialization and more structure and all that stuff, there's still that attitude of getting things done.

You've successfully hijacked the past 50 minutes.

I know. I did a pretty good job, didn't I? I'm glad you managed to make it all about not me.

Yeah, either you did a good job or I'm bad at being succinct, or both.

Let's turn this around for a second. Speaking of titles. Head of Innovation.

What does that mean? It's kind of amorphous, isn't it? I think that was just like a lot of other things, kind of by design.

The pitch from Matthew was far from the only reason, but undoubtedly one of the key reasons why I decided to join, which was like, just come in here and you will figure it out what it is that you should be spending your time on.

It's kind of evolved into three main things.

In that ETI group that we were just talking about, all this cool stuff coming out, there are many folks from a product and engineering perspective that will have forgotten more than I will ever know.

I bring a slightly different perspective in terms of, how do we bring these things to market?

How do we position them?

A B2B kind of lens. I have that history behind me. Related to that, and it related also to the topic we were just talking about, is if these things are different, how should we structure them?

How do we set them up internally to make them successful?

Then I guess the third area that I end up working on are big strategic initiatives that either maybe don't have another natural owner or need a little bit of horsepower.

One of the really cool experiences that I had here and kind of just had no right to get this, but my timing was just good, ended up helping to lead the process of taking the company public, figure out the story.

That was just fascinating. It was so much fun.

That's an example of this category. I'm curious to hear more about that.

There are a lot of people like me at the company who have all these harebrained ideas.

I'm like, we're going to take over the world by doing A, B, and C in this order.

How did you go about collecting all those nuggets and different points of view and then turning them into what was really a very cohesive story and tell that to an audience that had really no exposure to the company before?

Telling stories is... Storytellers and thought leadership, you see that stuff on the Internet and my skin starts crawling, but truly figuring out a narrative, a line through something where you explain it in a way that people are able to internalize is just one of my favorite things to do.

I guess stepping back, I've had a couple of experiences that positioned me pretty well to do it.

One was working with a professor at HBS by the name of Clay Christensen, who I think is just one of the leading management thinkers of the modern era.

Unfortunately, he recently passed away at the start of this year, but I got to study under him and then work with him on a book and just getting indoctrinated in the way that he thinks about the world and then learning how to write.

One of the projects we ended up working on was a book targeting a general audience and taking complicated business ideas and making them accessible.

I ended up getting a very short, sharp course in how to do that.

That was just a heap of fun.

It was super stressful at the beginning. I hadn't really written anything long form since high school.

I'd been business and computer science stuff in undergrad and then management consulting.

They teach you to think in not word documents, so trying to figure out how to get this down at the start was super stressful, but by the end, I just developed this ability to communicate things in a way that could resonate with people.

The other experience that I'd had that was actually super, super helpful was when I applied to business school, I had someone who spent an ungodly amount of time helping me figure out what my story was.

The funny thing about this is you can never really pay those people back. All you can do is help someone else.

I was determined to help as many good people as I could get into whatever their dream school was.

That ended up I've probably done somewhere in the order of 25 business school applications now, also med school, other schools, whatever.

I became very good at telling stories in terms of finding ways of telling people, finding the narrative, finding the line through.

In the instance of an individual, it's like, okay, where have you come from?

Why did you do it?

Why do you want to do this? Where are you going? Seeing all the data points and then finding a way of drawing a line through that.

Cloudflare, like the S1 or whatever document, a company is just like a nested version of that.

It's more complicated because there are obviously many more opinions and whatever, but same basic idea.

There are a bunch of smart people here who were very patient in explaining to me what they thought.

I hadn't done anything like this before, but I had some incredibly smart friends that I made at Goldman Sachs and a couple of the other investment banks.

They gave me some perspectives and some thoughts on how to do this.

Then it was just like, get it down, get feedback, iterate, repeat, get it down, iterate, feedback, repeat.

Obviously, Matthew was very heavily involved.

A lot of the core ideas in terms of where it came from was with him. I remember one Saturday just being in the office, sitting there with a whiteboard.

We felt like we cracked it and we knew.

It was a really, really good feeling. There are some funny stories.

I remember early on in the process, we had a draft and I was still tapping away upstairs.

I get this message from Chad, one of our lawyers.

He's like, we're actually working on this downstairs. Maybe you should come down.

I'm tapping away. Literally, I walk into the room and there's all the lawyers and all the bankers.

They're doing this line edit to make sure that nothing is out of control.

They're just watching the thing on the screen as I'm just mad and typing away and cutting.

I'm like, I am so sorry. I had no idea you guys were all in here.

Maybe I should sit down here and stop for a second and let you do your thing.

Nothing to get your creative juices flowing like a bunch of investment. I actually discovered in the process of writing that context really matters.

Your environment really matters.

I tried writing in the little office that they gave me inside of HBS and I was terrible.

If I sat down in a coffee shop, got a pen and paper out and started writing, things would just come out.

Learn a bunch of those lessons.

Did what I needed to do in order to channel this stuff. I felt terrible at first and then I found the whole thing.

I was actually mortified. I was like, have I done something really wrong?

Then it just became funny when everybody else was just amused by it.

It's interesting you draw the grad school application parallel because when people ask me about my experience with the IPO and my perception of it, I think external folks always focus on the financial aspects of it.

Yes, the company raised a bunch of money and the people who held equity in the company can now sell it.

The more meaningful bits were, it really felt like graduation.

It felt like you were going from high school to college or whatever the transition is.

The game had changed in ways that were hard to put a finger on.

It was very clear that this was some threshold moment for the company in the same way that a graduation or whatever was.

Totally. There's a mistake I think some folks make in terms of thinking that it is the destination.

HBS is a cool thing to have done.

It's not a destination in life and it's the exact same thing with an IPO.

It's a super cool thing and it's a necessary. Well, not necessary. It's an important step for many companies, not every company, but it is not a destination.

It is a step along the journey. Speaking of interviews, some folks have asked me, how has life changed at the company post IPO?

The company keeps changing.

That's what keeps it interesting. Right. You can't say pre-IPO and post-IPO and everything changed at that point, right?

No. Yeah. Day-to-day looks very similar.

Yeah. One of the many things I appreciate about it. I took an extra day off in New York, but you're back in San Francisco in the office on Tuesday and so was everybody else.

Yeah. What are you excited about? Why are you still here? That's an amazing experience.

You're probably not going to top that anytime soon.

It's an amazing experience, but it's far from the reason I'm here.

The reason I came was just, we talked about it a little bit, Principal Curious Transparent.

I have a podcast and people can be pretty opinionated at times.

There are a lot of companies in this space that I couldn't work at, but one of the things I love about this place is that Principal Curious Transparent.

It's really important to me. The whole point of the company is giving people a voice.

There are places where I would work, where the fact that I'm spouting these opinions out would be considered a bad thing.

The purpose of the company is to give people this build a better Internet, helping to build a better Internet.

That's about if you had a website and you said something people didn't like, you'd get DDoSed, you'd get wiped off the face of the planet and you wouldn't have a voice.

The fact that we're making that readily accessible so anyone can have a voice on the web I think is really important to me.

That's super cool. We're at 10 seconds and I think that's a good thing to leave it on.

Thank you for interrupting. This was fun. Thank you, Rustam.

Thank you, James.