On Cloudflare

Reflections

I joined a company in 2016 that I couldn’t explain to my parents or friends. “What does Cloudflare do?” they’d ask. I’d fumble through an answer about Internet infrastructure, watching their eyes glaze over. I’d abandoned law school for this. I had no technical background. I was betting my career on learning obscure (to me) Internet protocols I didn’t understand: DNS, DDoS, TCP/IP - and hoping it would matter.

It mattered more than I could have imagined.

I’ve been catching up with Grey-clouds lately - the name for people who’ve left Cloudflare - and every conversation follows the same pattern. We pause, smile, and admit: “I knew we had it good, but didn’t realize how rare it was until I left.” Some are even boomeranging back. Meanwhile, the company keeps accelerating, like a massive snowball rolling downhill - the more mass it accumulates, the faster it moves. This omnipresence and constant dominance made me reflect on what made, and continues to make, the Company special. Alas, some reflections.

(One of the original logos in which the “F” in Flare is capitalized”

Note: I am currently not involved with the Company, and these are merely reflections and observations from my time there several years ago.

[1] How and Why I Joined

I wish I had a clear understanding of how the Internet worked and some illuminating insight into what made Cloudflare unique. I didn’t. I was a political science major who, with two semesters left, decided to abandon law school. I was fortunate to land a three-month internship with a venture firm that had invested in Cloudflare early. During the internship, I couldn’t really grasp what Cloudflare did or what made it special. This was 2016/2017, when the company had around ~200 employees.

But that difficulty - not being able to understand the product immediately - was precisely what made Cloudflare unique. I came from a non-technical background. Within weeks of studying the firm’s portfolio, I could understand most of the other investments: vertical SaaS, traditional B2B, nothing exotic. The learning curve was gentle. Cloudflare was different. I looked up obscure terms: SSL, DNS, DDoS, WAF, TCP/IP, UDP. It felt theoretical at first. But the deeper I dove into understanding the core product, the more I realized I was learning how the Internet worked.

This knowledge had gravity. I use the Internet every day. Multiply that by everyone globally. Related to that, joining an infrastructure company was deeply non-consensus at the time - the consensus for any young, confused graduate wanting to get into tech would be to join a high-flying gig-economy startup like Uber, Lyft, or Airbnb.

I knew I had to apply, though I wasn’t sure the company would succeed. My personal underwriting for joining was predicated on the worst-case scenario: I’d get paid to earn a pseudo-computer-science degree, even in a non-engineering role. This turned out to be true. The interview process was long - ironically so for a junior role. I went through 10+ interviews, the last with Matthew, the co-founder and CEO. The structure covered several areas: technical (even for non-technical roles), behavioral, and others, as you’d expect. By the final round - typically with founders - the tables turn, and you get to ask questions directly. The process is deceptively simple in sussing out two critical attributes: competency and curiosity.

[2] Atypical Talent

Cloudflare hired mission-driven people from dizzying backgrounds. In my onboarding class, there were new hires from Yale and Cornell, as well as two engineers who’d dropped out of college entirely. Credentials were rarely discussed. I can’t recall a single conversation where people compared schools or backgrounds. The culture was less about “what we did” and more about “what we’ll do.” A fervor for ambition was the common denominator, and it was contagious.

The most surprising thing about Cloudflare employees was their level of passion - not just for the company’s mission, but for their specific domains. It reminds me of an old quote from Patrick Collison about having a good culture, “We try to hire people who are intrinsically happy... It’s much easier to hire happy people than it is to make people happy.” The same can be true of Cloudflare when it comes to hiring passionate people. As an example, one of the first outbound SDR managers joined early and was intrinsically obsessed with sourcing meetings. He studied every SaaS playbook, distilled the learnings, and practiced daily. He’d be the first person in the office, making cold calls to CISOs and VPs of Engineering at 6 am. This is one of the most daunting sales tasks imaginable - CISOs rarely answer and can detect a pitch in the dark. But he did it anyway, driven by passion for the craft and the company’s success. Another one of my favorite atypical background stories was centered on a philosophy professor turned Customer Success Manager (CSM). In retrospect, hiring a philosophy professor steeped in, well, philosophy would correlate well with relating to other humans who are also customers, but the hire was extremely atypical to begin with; he was given the role of ‘writer’ early on. He taught himself to code and became insanely passionate about helping customers use Cloudflare more effectively.

Now imagine the compounding effect: hiring passionate people across every domain, all making Cloudflare better. It’s cliché to say companies are collections of individuals, but Cloudflare mostly got this right. They hired people who cared deeply about the mission - Helping Build a Better Internet - and about becoming exceptional at their craft.

What made this unusual was the freedom to move cross-functionally. I knew a Sales Development Representative (“SDR”) who transitioned to engineering—a legal associate who moved to product. If you were genuinely curious and competent, you could succeed anywhere in the company.

Another unique aspect: Cloudflare surrounded itself with influential external figures who weren’t technically employed but were and are deeply connected to the company. Most generational companies have external prowess centered around the CEO/founders - Zuck, Karp, Jensen. Matthew and Michelle had similar presence, but the network extended far beyond them. Tim Berners-Lee, Larry Lessig, Julius Genachowski (former FCC Chairman), and hundreds of others orbited the company. These weren’t flashy advisory board appointments for PR purposes. These were influential figures on the Internet who genuinely believed in Cloudflare’s mission.

On competing for talent, it’s well known that many large incumbents tend to compete for candidates by throwing millions of dollars at them, having an ambitious mission - Helping Build a Better Internet - attracted atypical talent. The large surface area of complex problems was a gold mine for recruiting. For example, Cloudflare proxies roughly 20% of the Internet. Imagine pushing your code to 20% of the Internet and having it show up in undetected ways (e.g., your preferred fitness app, OS for your car, favorite delivery service). That level of impact, to be everywhere all at once, is a magnet for talent. I remember the day we went public. The next day, the company was back at work as if nothing had happened. It was almost culturally frowned upon to have an E*Trade terminal up or to discuss the stock price. Independent of what the share price said, employees believed it was grossly undervalued - so what was the point of looking? There was an intensity of focus on the problems at hand, which only got progressively more challenging.

The unwavering set of technical problems kept the team hyper-focused. These weren’t just hard technical problems - they had broader implications requiring second and third-order thinking. Optimizing global network throughput wasn’t just an engineering problem; it had policy implications at the micro and macro levels. This kind of work attracts people who want intellectual challenge paired with real-world impact. Most companies offer one or the other. Cloudflare offered both.

Tyler Cowen talks about how the best talent self-selects into environments where they can compound their advantages. Cloudflare created that environment: hard problems, passionate peers, freedom to move between domains, and a mission that actually mattered.

[3] Culture

It’s been said before, and it’s somewhat true, that the best start-ups are described as cults: Cloudflare’s culture was cult-like. It was a byproduct of being convinced that what we were building mattered, that people using Cloudflare were genuinely better off, and that we were, to some degree, on the right side of history—making the Internet faster, freer, more open, more secure.

What constituted the belief system? There was a pseudo-intellectual undercurrent at the company that ran deeper than typical Silicon Valley posturing. Aristotle was invoked more often than Peter Thiel or YC. At several company off-sites, the management team brought in Harvard professors and gave the entire company a case study to debate. Software engineers, entry-level employees, customer success reps - everyone - debated with Harvard faculty. This sounds performative, but it signaled something real: deep respect for individual thinking, systems thinking, and intellectual agency. You didn’t need credentials to have a voice, but you needed to think clearly.

One of the most striking things about Cloudflare was its diversity - not just in the numerical sense, but in how people thought. In the Valley, the default is “most people went to Stanford.” Cloudflare hired on competence over credentialism, which meant you’d have underrepresented voices and perspectives in the room. Products would be announced in the internal chat, and dissenting opinions would surface immediately. This wasn’t always comfortable, but it kept the company honest. Bad ideas died faster. The willingness to hire for raw ability rather than pedigree created a culture where your argument mattered more than where you went to school.

Technical competence was currency at Cloudflare. If you couldn’t speak “technical”, you were ineffective. Period. There was a high bar: the more technical you were - regardless of org - the more influence you had. The company’s internal language was programming languages, Internet protocols, and computer science principles.

Insane Transparency. Every quarter, the executive team walked the company through the board slides - revenue numbers, difficult strategic decisions, the whole thing. Bill Gates once said, “Power comes not from knowledge kept but knowledge shared.” Cloudflare lived this. It created alignment and accountability. Everyone knew the numbers. Everyone knew what was working and what wasn’t.

The company had low tolerance for incompetence, but only a specific kind. Not “you’re an asshole if you don’t know how TCP/IP works,” but “you’re lazy if you’re not willing to learn.” An internal slogan that was floated around to best illustrate this, if you join Cloudflare “you’re going to be drinking from a fire hose.” The most effective people at Cloudflare shared traits: insane curiosity, refusal to know the same thing twice, and willingness to go deep. On average, Cloudflare had more of these people than most Valley companies.

At Cloudflare, the culture rewarded autodidacts, systems thinkers, and people who could operate in ambiguity. If you needed clear direction or explicit encouragement, you’d struggle. If you thrived on autonomy and were willing to figure things out yourself, you’d thrive. The cult worked because the mission was real, the standards were high, and the company actually lived its values. That’s rare. Most companies say they value transparency, intellectual rigor, or technical excellence. Cloudflare actually did.

[4] Christensen’s Playbook

The company also had a near-religious reverence for business strategy, particularly Clay Christensen’s The Innovator’s Dilemma. This wasn’t accidental - Christensen taught both Matthew and Michelle at HBS. The book’s frameworks - disruption, Jobs to Be Done, RPV - were embedded in how the company thought about competition, product, and organizational design.

For those who haven’t read Clay’s work, the core premise of Christensen’s The Innovator’s Dilemma makes a counterintuitive claim: successful companies fail precisely because they do everything right. They listen to their best customers, invest in sustaining innovations to improve their products, and pursue higher margins. This is rational behavior - until it kills you.

The mechanism works like this: incumbents gradually move upmarket, making products that are increasingly sophisticated and expensive. They optimize along the dimensions their most profitable customers care about - performance, features, customization, and white-glove service. Eventually, they overshoot. The product becomes too good - more capability than most potential customers need, at a price they can’t justify.

This creates an opening at the low end. A new entrant builds something simpler, cheaper, and “worse” by the incumbent’s standards. The incumbent’s best customers don’t want it. The margins are terrible. The natural response is to ignore it - why compete for low-margin business when you have great customers willing to pay premium prices? So they cede the low end and keep moving up.

Meanwhile, the disruptor improves. The “good enough” product gets better. It moves upmarket. Suddenly, it’s not just serving small customers - it’s competitive for mid-market deals—the enterprise. By the time the incumbent realizes what’s happening, the disruptor has volume, brand recognition, and a genuinely competitive product. The incumbent’s choices are now: compete on price (destroying margins) or lose the business entirely.

Cloudflare’s Version

When Cloudflare launched in 2010, the content delivery and DDoS protection - core elements of a website’s infrastructure - market looked like this: Akamai, the dominant player, sold enterprise CDN services with custom contracts, dedicated account teams, and professional services. Minimum deals were hundreds of thousands of dollars, often millions. The sales cycle was 6-12 months. You needed a sales engineer to do a site assessment. Everything was bespoke.

This worked great for Akamai - they had Fortune 500 customers paying premium prices. Their margins were excellent. Their customers were happy. Why would they want to serve some developer’s personal blog, or a small e-commerce site doing $50K in revenue? The unit economics made no sense. You can’t afford a sales team when your customer is paying $20/month.

Cloudflare saw the opening. They built a self-serve product with a generous free tier. Any developer can sign up, point their DNS to Cloudflare, and get CDN and basic DDoS protection in 5 minutes. No sales call. No contract negotiation. No minimum spend.

From Akamai’s perspective, this wasn’t even a real competitor. The free-tier customers were worthless. The paid customers at $20-200/month were barely worth the server costs. The product was more straightforward, less customizable, and without the white-glove service that enterprise customers expected. It was obviously not a threat to the serious, honest business of enterprise CDN contracts.

But Cloudflare wasn’t trying to compete with Akamai for enterprise customers in 2010. They were building something else: a massive installed base of users who loved the product, talked about it, and brought it with them as they grew. A developer using Cloudflare for their side project becomes a CTO who brings Cloudflare to their startup. That startup becomes a scale-up that upgrades to Cloudflare’s enterprise tier. The blog becomes a media company. The hobbyist becomes a decision-maker.

Meanwhile, Cloudflare kept improving the product - but “improving” undersells what was actually happening. The company was expanding into entirely new service lines, moving beyond website infrastructure into adjacent markets.

• Workers turned the edge network into a compute platform. Instead of just caching content, you could run arbitrary code at 300+ locations globally. This opened serverless computing, APIs at the edge, and entire applications running in a distributed manner. New business line: edge computing platform.

• Stream tackled video delivery and encoding. New business line: media infrastructure.

• Access replaced corporate VPNs with zero-trust security. New business line: enterprise security.

• R2 provided object storage competing directly with AWS S3, but with zero egress fees. New business line: cloud storage.

Each of these wasn’t just a feature add - they were category expansions that opened new revenue streams and customer segments. The self-serve base became the testing ground. Launch to developers first, iterate based on real usage, then sell upmarket to enterprise once it’s proven.

The company also made a critical strategic bet that most observers missed: commodity hardware. While competitors like Akamai relied on expensive, brand-name hardware from vendors, Cloudflare built its network on commodity components. In the short term, this was cheap - better unit economics from day one. In the long term, it was a strategic advantage: no vendor lock-in, faster iteration cycles, and cost structures competitors couldn’t match even if they wanted to.

This might sound like standard “be scrappy” startup advice, but it’s deeper than that. Decoupling from hardware vendors meant Cloudflare could innovate at the software layer without waiting for vendors to release new products. They could optimize for their specific workloads. They could scale economics in ways that companies dependent on Dell or Cisco couldn’t replicate. This combination - thrifty in execution, long-term oriented in strategy - is rare. Most companies optimize for one or the other.

The RPV Framework and the Austin, Texas Advantage

Resources are what you have: people, technology, capital, brand. Processes are how you do things: the way you make decisions, develop products, and go to market. Values are what you prioritize: the margin structure you need, the customer size that’s worth pursuing, and the definition of success.

The problem for incumbents is that their RPV framework - the very thing that made them successful - becomes a cage. Akamai’s processes were built for 12-month enterprise sales cycles. Their values dictated that deals below $500K weren’t worth pursuing. Their decision-making required executive approvals and business cases showing clear ROI. You can’t pivot that organizational machinery to ship a self-serve product for $20/month customers, even if you wanted to. The antibodies are too strong.

Cloudflare understood this instinctively and cleverly built around it. The massive self-serve base wasn’t just a go-to-market strategy - it was a product development laboratory. Millions of users meant millions of test cases, edge cases, attack vectors, and use cases. You could dogfood everything at scale before selling it to enterprise customers. If a feature worked for 100,000 self-serve customers, you knew it would work for the enterprise.

But here’s the brilliant part: Cloudflare recognized they’d eventually face the same RPV trap. As the company grew, as enterprise revenue became more critical, as processes ossified, there would be pressure to optimize for existing customers, to avoid risky bets, and to focus on sustaining innovations rather than disruptive ones.

So they did something unusual. They created a separate product organization, initially called Product Strategy, based in Austin, Texas, physically separated from the main SF headquarters. This team later became Emerging Technology Innovations and Incubations (ETI). Their mandate: ship innovative products unencumbered by the Resources, Processes, and Values of core Cloudflare.

This wasn’t a skunkworks or an R&D lab in the traditional sense. This was a team with shipping responsibility, tasked with launching products that might not make sense under the core company’s RPV framework. Products that might cannibalize existing revenue. Products that might not have obvious business models. Products that served different customer segments or opened new markets entirely.

The Austin team operated with different processes - faster shipping cycles, willingness to launch products in beta, and tolerance for products without clear monetization paths. They had different values - growth and innovation over immediate margin optimization. And critically, they had permission to ignore what core customers wanted and build for the future instead.

This is Christensen’s other key insight, the one most companies miss: you can’t fight disruption with your existing organizational structure. The processes and values that made you successful will kill any disruptive initiative. You need a separate team with its own processes and values. Not a “tiger team” that reports to the leading organization, but an actually autonomous unit that can make decisions the central organization would reject.

The dogfooding dynamic made this even more powerful. The Austin team could build wild new products, launch them to the self-serve base first, iterate rapidly based on real usage, and only then think about enterprise adoption. By the time a product like Workers got to enterprise customers, it had already been battle-tested by thousands of developers. The core Cloudflare team got products that had proven themselves in the market, without taking the risk of approving them initially.

This is the complete Christensen playbook:

1. Enter at the low end where incumbents can’t follow (self-serve model)

2. Build a massive user base that becomes a product laboratory (dogfooding at scale)

3. Create separate organizations to avoid your own RPV trap (Austin team)

4. Move upmarket with products that have been validated by real usage

5. Use brand equity from serving millions to win enterprise deals

Most companies only do steps 1 and 2. Very few have the discipline to do step-3 - to institutionalize the disruption of themselves before someone else does it to them. Cloudflare did all five. The broader lesson: if you’re building something in a market with entrenched players, look for the customers they’re running away from. Build for them first. Make it self-serve, simple, and cheap. But also: prepare for the day when you become the incumbent. Build the organizational structures now that let you disrupt yourself later. Create teams that operate outside your RPV framework, before your RPV framework calcifies completely.

Most companies can’t do this. Their antibodies are too strong. They optimize for today’s business and starve tomorrow’s. Cloudflare figured out how to do both at once: serve enterprise customers with proven, scaled products while simultaneously launching weird experimental things that might become the next platform.

[5] Go Direct

The power of storytelling at Cloudflare can’t be overstated. Much of the management team was steeped in Aristotle, known for systematic thinking and logic, as well as in Plato, who told masterful stories about Socrates. This wasn’t abstract intellectual posturing. It showed up in how the company operated: an unusually talented in-house PR team, one of tech’s best blogs, Matthew’s ability to paint a compelling vision, and a willingness to go direct to customers before that became fashionable.

• The PR drumbeat. The PR team remained small relative to its impact, but punched way above its weight. They weren’t just managing press releases - they had taste. They cared about where Cloudflare was covered (not just that it was covered), which global events mattered, and how product launches should feel. The result: it felt like Cloudflare was everywhere. This wasn’t just shipping velocity - though that helped - it was deliberately owning the narrative. To external observers, there was rarely a day when Cloudflare wasn’t top of mind.

• The blog as institution. The Cloudflare blog started as a place to discuss technical problems. Over time, it became something more: a rite of passage. Writing a blog post felt like committing ideas to the permanent record. For many employees, authoring or co-authoring a blog post was a source of genuine pride. The review process was rigorous - final approval often went through JGC (then CTO), Matthew, Michelle, or other executives. The bar was high. This mattered: the blog became a recruiting tool, a technical showcase, and a way to shape industry conversations.

• Picking your competitors. From the earliest days, external observers positioned Cloudflare as a competitor to legacy CDNs. Internally, the competition was AWS, Microsoft, and Google. The hyperscalers. This wasn’t delusional - it was aspirational in a way that created reality. Matthew’s constant belief that Cloudflare would one day be as big as the mega-clouds ran through the company like a contagion. Picking your competitors wisely matters. Aim small, stay small. Aim at giants, and maybe you become one.

• Going direct. To invoke the lyrical genius DMX: “X Gon’ Give It To Ya.” Twitter (now X) was a powerful tool for going direct to customers, hearing from them, and recruiting. It wasn’t unusual for executives to DM employees on weekends with a customer complaint they’d seen on Twitter, with the expectation that the issue would be fixed immediately - and the fix communicated back on Twitter. This sounds exhausting (it was), but it created tight feedback loops.

[6] Pace and Innovation

There’s a phrase that captures Cloudflare’s culture better than any mission statement: “due yesterday.”

This wasn’t just startup hustle or performative intensity. It was baked into the company’s product development approach. The default assumption was that whatever you’re working on should have shipped already, and you’re now playing catch-up with the market. This created a palpable bias toward action. You didn’t wait for perfect - you shipped, measured, and iterated.

The most visible manifestation of this was Birthday Week. Every September, Cloudflare would launch a dozen or more new products in a single week to celebrate the company’s founding. This sounds insane if you’ve worked at a typical enterprise software company, where launching a single product might take 18 months of planning, beta testing, and go-to-market coordination. But Cloudflare would ship Workers KV, Argo Tunnel, Cloudflare Access, and five other products in seven days.

The genius of Birthday Week wasn’t just the PR - though it was great for that. It was the creation of an artificial deadline that forced product teams actually to finish things. Without Birthday Week, that half-baked feature or experimental product might languish in “almost done” purgatory for months. With Birthday Week approaching, the question became: can we get this to “good enough to ship” by September 27th? Usually, the answer was yes. The products shipped during Birthday Week were often things that had been in development for months, sometimes years. But the forcing function of a hard deadline - and the cultural expectation that you would ship something interesting - meant that teams cut scope aggressively, focused on the core value proposition, and figured out the polish later. It was the opposite of the “wait until it’s perfect” trap that kills most enterprise software. This dedicated week of shipping features and products later morphed into its own; it was followed by multiple innovation weeks, spanning from Security Week and Developer Week, as an example.

Tyler Cowen talks about “lowering the threshold for action“ as a key trait of high performers. Birthday Week was an institutionalized low threshold for action. The bar for “should we ship this?” was deliberately set at “is it interesting and does it basically work?” rather than “is it fully baked and ready for every edge case?” This meant more stuff shipped. Some of it failed. Most of it succeeded. All of it created learning.

The cultural artifact of “due yesterday” worked because it was paired with genuine forgiveness for failure. You could ship something that didn’t quite land, and as long as you learned from it, nobody held it against you. The sin wasn’t shipping something imperfect - it was not shipping at all. This is rare. Most companies say they tolerate failure, but actually punish it. Cloudflare actually tolerated it, which meant people took bets.

The result was a compounding innovation that’s hard to replicate. Each Birthday Week, you’d see products that built on infrastructure from previous years. Workers enabled Workers KV. Workers KV enabled Durable Objects. Durable Objects enabled D1. Each layer created new possibilities, and the rapid shipping cadence meant you could iterate on the stack multiple times per year, rather than once every 3 years like a traditional enterprise company.

[7] Ethical and Weighted Decisions

The most challenging conversations at Cloudflare weren’t about technology. They were about who we provided service to, and why.

The 8chan case was canonical. For years, Cloudflare provided DDoS protection to 8chan, a site hosting extremely offensive content, linked to harassment campaigns, and eventually to mass shooter manifestos. Activists and journalists demanded we terminate service. We didn’t, until we did. After the El Paso shooting in 2019, where the shooter posted to 8chan minutes before the attack - the third such shooting in six months - The Company terminated 8chan’s service.

The core tension: Cloudflare is infrastructure. The Company provides DDoS protection, CDN, and DNS, which sit beneath the content layer. The company’s analogy was simple: They were the phone company, the power company. Infrastructure providers shouldn’t make editorial decisions about who deserves basic services. Today it’s 8chan. Tomorrow it’s WikiLeaks, a dissident newspaper in Turkey, a protest organizing site. Privatized censorship by infrastructure companies is dangerous.

What impressed me: the company took this seriously. The Company detailed blog posts explaining decisions. I’m firmly of the belief that the most meaningful work exists in morally grey areas. You can work on ethically neutral things: corporate software, consumer apps, standard enterprise tools. You can work on unambiguously good things: pandemic response, anti-child exploitation work, and disaster relief. Or you can work on grey areas: things that involve morally thorny, difficult decisions where reasonable people disagree.

Internet Infrastructure neutrality is a grey area. Health insurance is a grey area. Immigration enforcement is a grey area. Military and intelligence work are grey areas. Content moderation at scale is a grey area. These institutions need to exist: we need infrastructure providers, we need defense, we need someone making decisions about scarce medical resources - but every decision involves tradeoffs that make people uncomfortable.

The tempting response is to disengage entirely. “I won’t work on anything morally ambiguous. I’ll stick to clear-cut good things.” This is emotionally satisfying but also an abdication of responsibility. Someone has to build the core components of the Internet’s infrastructure. Someone has to decide who gets DDoS protection. If everyone with good judgment and strong ethical intuitions refuses to engage with these questions, the decisions get made by people who don’t think as carefully.

Ignoring these grey areas entirely, just disengaging from them, means letting these institutions sort themselves out without your input. The alternative is to engage with the messy reality that these institutions exist, serve essential functions, and that being in the room when decisions get made is better than not being there at all.

This is uncomfortable precisely because you’re not guaranteed to be doing 100% good at all times. You’re at the mercy of history. You’re betting that (a) more good is being done than bad, and (b) being in the room, with the ability to influence outcomes, is better than standing outside and criticizing.

In the case of Cloudflare, this meant a few things: First, defaulting to infrastructure neutrality - providing service broadly, even to customers that the Company found morally objectionable - because the alternative (infrastructure providers as content arbiters) seemed worse. The slippery slope is real: once you start making editorial decisions, where do you stop? Who decides what’s “too controversial” to deserve infrastructure protection?

Second, drawing lines in extreme cases. The 8chan termination violated the general principle because the specific facts demanded it. Three mass shootings. Apparent inability or unwillingness to moderate. Active coordination of violence. At some point, sticking to principle becomes complicity.

Third, being transparent about the difficulty. Most companies make these decisions quietly or dress them up in confident rhetoric. Cloudflare’s approach was: show your work, acknowledge reasonable people can disagree, and explain why this case felt different. This won’t satisfy everyone: critics wanted either “always terminate hate speech” or “never terminate anyone,” but it was intellectually honest.

The danger of this stance is that it becomes a fully general argument for doing whatever the power structure wants. You’re just amplifying existing processes. This is where specificity matters. You can’t have a blanket rule. You have to be specific about which grey areas you’re willing to engage with, and why.

Here’s the thing about grey areas: engaging with them means accepting that you’ll sometimes be wrong, sometimes be uncomfortable, and always be criticized by someone. The people who terminated 8chan think the Company should have done it sooner. The people who opposed termination think the Company shouldn’t have terminated the employee. No stance satisfies everyone because the problem itself has no clean solution. Cloudflare wasn’t perfect. No company is. But they engaged seriously with the grey areas, they tried to get it right, and they were honest about the difficulty. That’s defensible. And frankly, admirable.

Long $NET

I joined Cloudflare thinking I’d learn technical skills and maybe get a decent job. I learned something far more important: passion compounds faster than talent, and the problems that seem hardest are the ones worth solving.

I used to think success came from hiring the smartest people from the best schools and giving them clear problems to solve. I was wrong on both counts. Success comes from hiring people who give a shit regardless of their pedigree, then giving them something genuinely worth caring about: problems so complex they require second and third-order thinking and missions ambitious enough to seem impossible. The smartest people without passion build incrementally better things. Passionate people working on hard problems reshape industries.

This is why Cloudflare picked the hyperscalers as competitors instead of legacy CDNs. This is why they hired philosophy professors and college dropouts instead of optimizing for Stanford CS degrees. This is why they engaged with impossible questions about infrastructure neutrality instead of avoiding them. Aim small, you stay small. Aim at giants, aim at problems that matter, and maybe - just maybe - you become one.

Every Grey-cloud I talk to learned some version of this. We didn’t just learn technical skills or business frameworks - though we learned both. We learned what it feels like to care deeply about something that genuinely matters. We learned that the morally complex work - the grey areas everyone else avoids - is often the most important work to do. You can’t unlearn that.

The lesson: Find something you can care about deeply. Not “this seems like a good opportunity” care. Real, visceral, wake-up-thinking-about-it care. Then find a problem that’s genuinely hard - complex enough that most people won’t touch it, significant enough that it matters if you succeed.

As for me, I’ve started something new with former “Grey-clouds.” We’ve already incorporated many of the lessons from our time at Cloudflare into the new Company, and we’re tackling a critical mission to defend reality in the era of AI. The team is excellent, we’re actively hiring, and we often debate Clay Christensen’s theories over warm coffee.

Thanks to Remy, Alonso, Andrew, Shannon, and Irtefa for the edits.