For the exclusive use of G. ALLON, 2018.

9-813-145
REV: MARCH 7, 2017

THOMAS R. EISENMANN

ALEX GODDEN

CloudFlare, Inc.: Running Hot?

On a Sunday evening in July 2012, CloudFlare, Inc. co-founders Matthew Prince (CEO), Michelle
Zatlyn (head of user experience), and Lee Holloway (lead engineer) met to discuss important personnel
matters. Another employee had just told Prince that he planned to leave the company. The resignation
would be CloudFlare’s fifth in three months. The cofounders had to determine whether this was natural
attrition for their rapidly growing startup or symptomatic of bigger issues.

CloudFlare protected websites and accelerated their traffic. The company, founded in 2009, had
experienced phenomenal growth, despite having no sales team and spending almost nothing on
marketing. CloudFlare’s network served over 2 billion page views daily—about 1% of total Internet
page views—for nearly 500,000 websites that cumulatively had 550 million unique monthly visitors
(see Exhibit 1 for traffic growth). However, only 35 employees—26 of whom were engineers—worked
for the San Francisco–based company. They had been attracted by a culture that emphasized self-
direction, minimal hierarchy, and few bureaucratic processes.

CloudFlare offered two related types of service. The first was an evolving combination of caching,
optimization, and delivery of content that loaded websites faster, reduced their bandwidth costs, and
absorbed big traffic spikes. The second offered greater security to websites by identifying potentially
harmful visitors who might engage in comment spam, excessive bot crawling, or distributed denial-of-
service (DDoS) attacks. CloudFlare principally targeted small and medium-sized websites that could
not afford the security software and content delivery network (CDN) services sold to large enterprise
customers by vendors such as Akamai, Limelight, and Barracuda.

Prince described CloudFlare as “an operating system for the Internet,” capable—by virtue of
inserting a globally distributed network of servers and software between customers’ websites and their
sites’ visitors—of much more than just security and traffic optimization. Indeed, CloudFlare was
already offering analytics and, through its recently launched platform, access to third-party web
applications that customers could add to their sites. The cofounders also believed that CloudFlare could
use its extensive knowledge of web-browsing patterns to help online publishers serve targeted ads—a
potentially huge opportunity.

Given its growth potential as well as the complexity and mission-critical nature of CloudFlare’s
technology, it was essential to continue to attract and retain outstanding engineers. Would the culture,
organizational structure, and hiring practices that had served CloudFlare well in assembling a
remarkable team continue to meet the scaling startup’s needs?

________________________________________________________________________________________________________________

Professor Thomas R. Eisenmann and Research Associate Alex Godden prepared this case. HBS cases are developed solely as the basis for class
discussion. Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management.

Copyright © 2013, 2014, 2017 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-800-
545-7685, write Harvard Business School Publishing, Boston, MA 02163, or go to www.hbsp.harvard.edu/educators. This publication may not be
digitized, photocopied, or otherwise reproduced, posted, or transmitted, without the permission of Harvard Business School.

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

CloudFlare’s History
In 2001, Prince planted the seeds from which CloudFlare would grow when, along with former law
school classmates, he launched Unspam Technologies, Inc., which provided state governments and
corporations with solutions to the problem of unsolicited e-mail. Prince and his cofounders acquired
some patents from a team of University of California, Santa Cruz, students who had been working on
a similar solution and, in the process, hired one of the team members, Lee Holloway.

Soon after joining Unspam, Holloway built a tool that tracked spammers who harvested e-mail
addresses. The tool evolved into Project Honey Pot, a not-for-profit, open-source effort that allowed
webmasters to place e-mail addresses with hidden tags on their sites. When e-mail spammers scraped
the addresses, the tags allowed Project Honey Pot to identify and catalog the spammers’ IP addresses.
Participating websites could then shut off access to offending IP addresses.

While Project Honey Pot was very popular with webmasters, Unspam’s main business was growing
slowly. Prince decided to stop taking a salary and to run Unspam remotely while completing an MBA
at Harvard Business School. There, he met Michelle Zatlyn, who previously had been a founding team
member at a startup that created employee rewards programs and later worked as a product manager
at Toshiba (see Exhibit 2 for founder bios). Prince felt that their abilities and personalities were
complementary, saying: “Michelle is one of those people who gets stuff done—she’s incredibly well
organized. If my strength is saying, ‘The opportunity is over there,’ hers is getting all the stuff done to
get us over there.”

During their second year at HBS, Prince and Zatlyn developed a plan for CloudFlare. They surveyed
webmasters, who expressed deep frustration with their inability to protect their sites from unwanted
access. Prince thought that CloudFlare’s concept might appeal to Holloway, who was still at Unspam.
Prince explained, “Lee had said, ‘You’ve always treated me fairly, but I’m getting offers.’ This wasn’t
about money; he wanted a big, new technical challenge. He didn’t see that at Unspam anymore. Lee
joined our team and helped us build CloudFlare’s first prototype.”

The team won the HBS Business Plan Contest in the spring of 2009, along with its $25,000 prize that
helped cover expenses after graduation, when Prince and Zatlyn joined Holloway in California.
Holloway spent the summer coding, while Zatlyn refined CloudFlare’s business model and Prince
sorted out CloudFlare’s relationship with Unspam. Prince wished to license Project Honey Pot’s data
from Unspam and to extract Holloway from his job there. Otherwise, Prince wanted to keep the
companies separate, since the businesses were very different.

The team commenced fund-raising and met Ray Rothrock of Venrock, a venture capitalist who had
deep experience with Internet infrastructure businesses. In November 2009, Venrock led a $2.05 million
Series A round in which Pelion Venture Partners also participated. Although Pelion was usually a late-
stage investor, it had a good relationship with Venrock, and Prince’s cofounder from Unspam now
worked at Pelion.

CloudFlare’s cofounders then began hiring engineers. By October 2010, after some alpha testing,
they were ready to launch publicly at TechCrunch Disrupt San Francisco, a high-profile competition
for technology startups. CloudFlare placed second and won Disrupt’s “Most Innovative” award. A
wave of publicity followed, along with a surge of customer sign-ups and many unsolicited queries
from investors, even though CloudFlare had no pressing need for cash. Zatlyn explained: “Up to that
point, we’d spent only half of the capital that we’d raised. Our biggest expense had been for salaries,
and we’d been fairly frugal.”

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

After meeting with several top-tier venture capital firms, the CloudFlare team connected especially
well with New Enterprise Associate’s Scott Sandell. In November 2010, CloudFlare raised a $20 million
Series B round from NEA, Venrock, and Pelion.

Business Model
Customer Value Proposition
Without CloudFlare, a visitor’s request for information from a website was sent to the site’s web
server. With CloudFlare, the request was sent instead through CloudFlare’s global network. There, the
visitor’s IP address was checked against a constantly updated list of malicious addresses, which was
prioritized by threat level. Algorithms also determined whether suspicious patterns warranted adding
the visitor to the list. Customers pre-specified their desired level of security, ranging from “I’m under
attack!” to blocking only the most serious threats.

If a request was trouble free, the visitor’s browser was directed to one of hundreds of CloudFlare
servers in 17 data centers around the world, where CloudFlare’s software cached less frequently
updated page elements (e.g., site logos). In parallel, requests for any page content not cached by
CloudFlare were directed to the customer’s servers. For content that it cached, CloudFlare could speed
delivery because the distance between the visitor and one of CloudFlare’s many data centers was
almost always less than the distance between the visitor and the customer’s servers (see Exhibit 3 for
network diagram). By relying on CloudFlare to deliver certain content, the customer also spent less on
bandwidth. On average, a website loaded twice as fast as it did before adopting CloudFlare and
reduced bandwidth use by 60%.

CloudFlare’s service could be enabled through a simple sign-up procedure that took less than five
minutes and required no new hardware, coding, or change in hosting service. Unlike incumbent CDNs,
CloudFlare did not ask customers to specify, file by file, which content should be cached. Basic service
was free; premium options offered faster performance, more advanced security, and other benefits for
subscription fees starting at $20 per month (see Exhibit 4 for subscription plans). From the outset,
CloudFlare’s founders believed that they were opening a new market, providing small and midsized
websites an affordable way to protect themselves and speed content delivery. Zatlyn explained: “We’re
not shrinking or seeking to steal share of the pie; we are expanding it. Most of our customers are online
publishers using such services for the first time. They spread the word about us, saying, ‘Wow, this
makes my site much better—it really works, and it’s free!’”

CloudFlare aimed to deliver more than just improved website performance: it sought to create a
sense of community among its customers and provide assurance that someone was available to help
them manage their sites. Giants like Google could afford big network operations teams to address
obscure technical issues like differential packet loss rates by time of day. By aggregating a huge volume
of traffic, CloudFlare could offer similar benefits to webmasters who otherwise could not afford expert
network operations staff. Zatlyn noted:

We knew that the webmaster’s sense of isolation was an emotive issue from our original
survey. We stress that we’re a community and we’re stronger together. That’s true technically:
as our traffic expands, we see more patterns, so the system actually learns and gets better. That’s
one reason why getting big fast matters. But it’s also true that a webmaster feels very much alone
as she struggles to cope with the bad actors and the bad luck that can slow down or even shut
down her site. One customer tracks online fraud, and the guys he exposes are constantly trying
to knock his site offline. He told us, “You’ve given me back three hours of sleep a night.”

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

CloudFlare offered service to everyone without judgment, which won admiration from some of the
Internet’s anti-corporate elements. For example, CloudFlare had protected LulzSec, a hacker group that
had protested anti-piracy campaigns and overregulation of the Internet by compromising corporate
and government sites. LulzSec became the target of massive hacker counterattacks, but CloudFlare
helped keep its site operational. CloudFlare’s management initially struggled over what to do about
LulzSec, but decided to avoid the “slippery slope” of playing censor. This policy had paid dividends.
For instance, many escort agencies in Turkey relied upon CloudFlare to protect against attacks by
fundamentalist groups. After word got around that CloudFlare’s protection worked, CloudFlare
signed up several mainstream Turkish corporations and government agencies.

CloudFlare had few competitors offering similar services to its target customers. Traditional CDN
offerings from firms like Akamai and Limelight were typically aimed at large enterprise customers, as
were security products and services from vendors like Barracuda and Juniper. Google offered
PageSpeed to help smaller sites deliver content faster, but did not match CloudFlare’s full range of
caching and security services. Companies targeting the “long tail” of small to midsized websites (e.g.,
Incapsula, Sitelock, Cotendo) usually focused on only a subset of CloudFlare’s services.

CloudFlare’s highly efficient infrastructure, described below, allowed the startup to compete on
cost. Zatlyn recounted one recent example: “We had a customer paying a big incumbent $1.5 million
per year, which was supposedly a deep discount. We said we could profitably serve them for $40,000
a year. They asked, ‘Did you leave a zero off?’ We can offer big savings, because to date, we’ve only
spent $2 million on network equipment.”

Technology and Operations

Three technological trends had allowed CloudFlare to offer its innovative service for free or at much
lower rates than rivals. First, bandwidth costs had been declining sharply for many years. Second, a
shift from spinning disc drives to flash memory–based, solid-state drives (SSDs) had greatly boosted
speeds at which drives could write and access data—a key requirement for CDNs. Since 100% of its
servers had SSDs, CloudFlare gained cost and performance advantages over incumbent CDNs, which
had lots of legacy spinning disc drives. Third, as a new entrant, CloudFlare was able to build its entire
network around high-capacity servers with multicore processors that executed programming
commands in parallel. Again, this gave CloudFlare an edge over incumbent CDNs, which would have
to rewrite their software code in order to leverage multicore processors.

CloudFlare’s state-of-the-art technology had recently made possible a new premium feature,
Railgun, that allowed CloudFlare to serve much of the 34% of web content that previously was
uncacheable because it was generated dynamically (e.g., personalized pages). Railgun’s innovative
approach identified content on a page that had changed by comparing a dynamically generated page
with versions previously served. This required a large number of rapid, concurrent server requests,
which were readily handled by CloudFlare’s servers by virtue of their multicore processors and SSD
drives.

CloudFlare outsourced the physical installation, operation, and maintenance of its servers to data
center operators around the world, to whom it paid fees based largely on space required. CloudFlare
employees did no work inside the data centers; rather, they provided the data center operators with
detailed instructions on physical installation requirements, then managed software installation and
monitored server performance remotely. Such outsourcing arrangements had long been employed by
incumbent CDNs.

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

CloudFlare purchased bandwidth in bulk on wholesale markets. Consistent with long-standing

Internet practice, whenever possible, CloudFlare “peered” with other large network providers, that is,
it allowed them to send data, free of charge, over CloudFlare’s network, in exchange for reciprocal
rights on the peers’ networks.

CloudFlare’s team was obsessive about maximizing performance per dollar of infrastructure
investment. Its engineering team was constantly developing and refining algorithms that optimized
content delivery speed, often by leveraging CloudFlare’s deep and ever-expanding knowledge of
Internet traffic patterns—in particular, where and when bottlenecks were likely to occur.

In its relentless quest to improve network efficiency, CloudFlare management also pushed its
engineering team for innovative software solutions to network capacity crises (e.g., traffic spikes due
to novel DDoS attacks), rather than overcoming capacity constraints by investing in more servers.
Prince explained his aversion to relying too much on buffer capacity, which he viewed as “throwing
money at problems”:

If we constantly stay near our capacity limits, then we’ll always be learning. Whenever we
encounter a new type of attack, we are forced to ask if we can handle it by creating a new,
proprietary software response. If we can develop an automated response, then we won’t need
to scramble to manually reconfigure our capacity the next time we see that type of attack. We
should spend money on new hardware only when we absolutely have to.

These approaches yielded a great deal of proprietary intellectual property for CloudFlare in the
form of software solutions for identifying threats and optimizing site performance; on average, the
company was filing a patent every three weeks. CloudFlare management believed that this IP provided
a significant barrier to entry.

Customer Acquisition
CloudFlare had no sales or marketing team. The startup had achieved its phenomenal growth
mostly through carefully nurtured word-of-mouth. Resale agreements with hosting services (described
below) accounted for a smaller share of new customers. Zatlyn clarified: “We’re not opposed to sales
and marketing on religious grounds. To date, our challenge hasn’t been getting new customers; it’s
been serving our rapidly growing base.”

About 4% of CloudFlare’s customers subscribed to a premium plan. Many premium customers had
first been exposed to CloudFlare when they had signed up for free service for their personal blog or
hobby site. After experiencing the service, they advised their employer to get a Business or Enterprise
subscription.

About one-quarter of CloudFlare’s customers were acquired through resale agreements with
hundreds of web hosting companies such as GoDaddy and HostMonster—firms that provided, for
subscription fees, server space, bandwidth, domain names, and other services necessary to operate a
website. Hosting companies derived several benefits from signing up their customers for CloudFlare’s
service. Those customers: (1) were less likely to be hacked, and thus less likely to churn and/or generate
expensive requests for support from their hosting company; (2) were less likely to be victims of DDoS
attacks, which could reduce network response times for a hosting company’s entire customer base; and
(3) consumed less bandwidth by caching content on CloudFlare servers, reducing costs otherwise
incurred by the hosting company.

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

Zatlyn believed that partnering with established hosting companies further improved the
trustworthiness of CloudFlare’s brand. In turn, offering CloudFlare provided hosting companies with
some differentiation in a commodity industry, although this advantage would fade if reselling
CloudFlare became—as Zatlyn hoped—industry standard practice. Given the mutual benefits
available from resale agreements, CloudFlare did not initially share revenue when hosting company’s
customers signed up for a CloudFlare premium account. More recently, however, CloudFlare had
made available, at a $5 wholesale rate, a premium offer with fewer features than its $20 “Pro” plan that
hosting partners could resell to their customers at whatever price they chose.

Profit Formula
CloudFlare’s management did not disclose the company’s financial statements, but its business
model was fairly simple. To date, 95% of revenue came from paid subscriptions; advertising on
“challenge” pages accounted for most of the rest.1 If 4% of 500,000 customers paid a $20 monthly
subscription fee, then CloudFlare’s annual revenue run rate would be in the range of $4.8 million.
Server depreciation costs, hosting fees, and bandwidth expenses increased in close proportion to traffic
volume. Prince estimated these costs to be about $3.5 per million page views, or $2.6 million on an
annual run rate basis, assuming 2 billion daily page views. Most of CloudFlare’s remaining costs
related to salaries and benefits, plus rent and overhead expenses (e.g., legal and accounting fees). A
rough rule of thumb was that Silicon Valley startups whose staffs consisted mostly of engineers and
managers (rather than large numbers of warehouse or customer support workers) might pay about
$150,000 per head in salary, benefits, rent, and overhead. If this rule held for CloudFlare, which had 35
employees, then such expenses would equal $5.25 million. Total expenses would be $7.85 million,
implying a $3.05 million annual loss at current scale.

Growth Opportunities
CloudFlare’s cofounders believed that their company benefited from significant scale economies.
The more traffic they handled, the more patterns they could discern, allowing their team to improve
network performance. Also, many of CloudFlare’s unit costs—including server and bandwidth
expenses—would continue to decline due to the bargaining clout that came with greater scale. For these
reasons, CloudFlare’s management was eager to rapidly expand the company’s customer base.

At the same time, the cofounders saw value in exploring monetization opportunities and had
identified two main options. The first was to grow the “mium” aspect of their “freemium” offer. To do
so, they might advertise online, hire sales staff, and/or create an affiliate program. They also could e-
mail users of their free service, suggesting they upgrade to premium plans. Zatlyn noted, “We’ve never
done that before; e-mailing everyone just once might really boost our premium sales.”

A second, more ambitious option was to monetize the traffic that flowed through their network.
Because CloudFlare served content from so many different types of websites to a sizable fraction of all
Internet users, the company could use its data on visitors’ browsing patterns to help marketers and
online publishers target advertising. For example, a consumer who had recently visited automotive
blogs powered by CloudFlare could subsequently be targeted on those and other sites with ads for new

1 Web surfers whose computers had been compromised with a virus or malware often unknowingly spread viruses online. At a
CloudFlare-protected site, such visitors were presented with a challenge page that displayed visually distorted text, i.e., a
CAPTCHA. The visitor was asked to retype the text, to prove they were human and not an automated “bot.” The challenge page
also informed the visitor that their computer might be infected. CloudFlare ran ads (e.g., for anti-virus software) on some
challenge pages.

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

cars. As Prince explained, “We’re constantly reassessing the reputation of every visitor to our
customers’ sites. We could augment that record of trustworthiness with data on content consumption
patterns and potential purchase intent.”

CloudFlare could conceivably launch its own ad network to leverage this data; more likely, it would
license the data to online publishers, marketers, and incumbent ad networks. While this opportunity
was potentially enormous, the cofounders were aware that they had to carefully consider its brand
implications. Internet service providers serving consumers were in a similar position to use data on
subscribers’ browsing behavior to target ads, but had moved slowly due to privacy concerns. The
cofounders believed that, first and foremost, any plans for monetization had to be seen as beneficial by
CloudFlare’s primary customers—websites that relied upon CloudFlare for protection and accelerated
content delivery.

These opportunities were likely behind rumors of a $1 billion valuation for the company during the
spring of 2012.2 CloudFlare did not have a near-term need for additional capital, but the team expected
to raise a new round within a year. A more fully developed plan for monetization could help ensure
advantageous financing terms.

People and Organization

Culture
CloudFlare’s cofounders had decided from the outset that they wanted a nonhierarchical culture
without inflated titles or rigid reporting structures. This provided more flexibility for people to grow
into roles and to move around the organization. Zatlyn said:

We’ve hired employees with an expectation that they’d supervise someone, and it turned out
exactly the other way. A classic problem in a scaling startup is Fred—who was wonderful in his
function early on—struggling now because the function is four times bigger. If Fred is, say, VP
of engineering and we now need to hire a new VP of engineering over him, it’ll cause problems.
With no titles, those problems are mitigated. If somebody is stretched beyond their limits, we’ve
found that they’re usually happy to pull back and focus—as long as it doesn’t look like a
demotion.

The cofounders also felt it was important to give employees a lot of independence and to harness
their intrinsic motivation. However, Prince saw a need to keep this motivation in balance. He said:

This is a demanding place to work, and team members work hard because they believe that
we are building a better Internet. But we can’t allow people to burn out. For example, the board
told Michelle, “Make sure that Matthew and Lee take vacations.” I said, “I don’t want to take a
vacation. For me, that’s a total waste of time.” Michelle told me I had to do this, if only to set an
example. I used to jokingly say, “Not having time for friends and loved ones is no big deal for
me, because I don’t have any.” Michelle told me, “Stop saying things like that: it sends the wrong
signal to employees who aspire to be like you. And, recognize that what time you leave the office
influences when others leave.”

2 “CloudFlare Is In Talks to Raise Funding At Near A $1 Billion Valuation,” TechCrunch, April 17, 2012.

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

Organizational Structure, Decision Making, and Planning

CloudFlare had a flat, fluid organizational structure. Prince and Zatlyn had always shared decision-
making responsibilities for strategy and business issues. After working together for several years, they
understood who would take the lead on a given issue, without any formal delineation of roles.

Of 35 full-time employees, 26 were engineers. The other nonfounder employees included a team
working on what could loosely be called business development. They structured partnerships with
hosting providers, evaluated monetization opportunities, and managed CloudFlare’s application
platform. Zatlyn directed this team, although Prince was also involved in setting their priorities.

Sixteen engineers were programmers who worked in a variety of languages on front- and back-end
systems—improving existing software and building new features. Five engineers worked on the
technical support team, which responded to customers’ requests for technical help and fixed software
bugs; they also reached out proactively to resolve service problems mentioned on Twitter and
Facebook. Three engineers worked on the technical operations team, which constantly monitored
network performance, rotating on-call duty to provide 24-hour coverage, and relying on automated
processes to alert them when they needed to intervene to deal with unusual threats or malfunctions.
Two engineers worked on the network operations team. They were essentially bandwidth traders,
matching capacity to CloudFlare’s ever-evolving needs. Although Holloway took the lead on most
engineering-related matters, many team members also sought advice from Prince or Zatlyn.

Zatlyn explained how product development priorities were established:

In terms of what to do, Matthew is the storyteller; he has the vision and big ideas. Then I do
more of the planning on how to get us there. But our engineers also come up with ideas. We
don’t really have what you’d call a product road map—a detailed plan for which features we’ll
build over the next few quarters. We’re constantly adjusting our priorities.

The entire staff met every three weeks to set priorities within the context of three-month goals.
Priorities for each team member were recorded on Post-it Notes and placed on a white board that was
prominently displayed in CloudFlare’s open plan office. Each person was expected to complete his or
her priority tasks before tackling any other projects that popped up. The entire company met every
Friday at 5 p.m. to remove Post-it Notes for tasks that had been completed, and to revise priorities for
the coming week.

The company had recently hired a product engineer, Dane Knecht, to help organize the engineering
team’s work. Prince reflected:

In any other company, Dane would be called a product manager, but I don’t like the term
“manager.” I don’t want our engineers to be managed, I want them to be assisted. Lee had
reservations about this hire, and one of our most senior engineers was strongly opposed. But
other members of the engineering team had said they needed someone to settle fights, to help
prioritize and assign work. A big part of Dane’s job is figuring out how to put in some process
without putting in too much of it.

The cofounders knew that scaling would eventually bring more management roles and layers to
the company, and more processes with them. Prince explained:

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

We are under no illusion that these management practices will work forever; you can already
see some gaps. People want feedback; they want direction. When we double our current staff,
we will need more hierarchy and managers and processes. We’ve tried not to impose that from
the top down, but rather, to let it evolve from the bottom up.

It’s not easy for me to strike the right balance, in part because there are things that no one
tells me. I’m often the last person to know when something’s gone wrong. Michelle is more
approachable. And people now come to Dane to say that they are frustrated about something.
Dane can channel that to me; he’s a safe go-between.

Human Resource Policies and Hiring

CloudFlare had no human resources function and no official HR policies or processes, preferring
instead to rely on simple guidelines. Zatlyn commented on performance reviews and pay raises:

Everyone has to kill it here; otherwise, you can’t stay on our team. But we recognize when
someone’s clearly gone above and beyond, and we increase their salary—but always in an ad
hoc way. After one year or so, everyone’s supervisor takes them to lunch, where they get some
feedback and maybe a salary increase. We know this leads to frustration about how, when, and
why people get raises, but we don’t want the process to become mechanistic.

CloudFlare did not have a team member with lead responsibility for recruiting, nor did it rely on
external recruiters or post positions on job sites. Most hires came through employees’ personal
networks, referrals, or candidates e-mailing unsolicited résumés. Prince said, “It has an impact when
someone says in their e-mail, ‘What you guys do is really important; I want to be a part of it.’”

The interview process was relatively unstructured. Zatlyn said, “We empower our team to make
judgment calls. That means we have to live with their mistakes.” She acknowledged some problems
with the process: “We’re terrible at follow-up. Best practice for hiring engineers gets the deal done
within 10 days, so you should be calling a candidate all the time. We’re not like that, so we probably
lose people.” Prince added, “We have more success with very, very talented people with whom we
already have connections.”

CloudFlare had no formal procedure for bringing new hires on-board, relying instead on
shadowing colleagues and giving them early ownership of a project—consistent with a preference for
hiring self-starters.

The cofounders distinguished between need-based hires required to fill an open operational role, and
opportunity-based hires who had distinctive qualities that were not immediately essential. It could be
difficult to fill operational roles, because few individuals had experience with networks as large and
complex as CloudFlare’s. Those who did tended to work for large companies, and issues often arose
about their fit with CloudFlare’s unique culture.

Opportunity hires brought new perspectives and ideas to the company. Prince noted:

When we meet incredibly talented self-starters and inventors who are motivated by our
vision, we try to find a role for them. Our brilliant engineer Chris is an example. He invented
what we call “lazy loading images” to speed up mobile sites. On your phone, the display initially
shows only the top part of a web page. Chris said, “What if we only load images that are visible
in the initial display, and we don’t load anything else until you start scrolling?” That’s the type
of innovation we get from our opportunity hires.

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

Five Resignations
Five employees had resigned from CloudFlare over the past three months. They came from different
parts of the company and gave a variety of reasons for leaving.

Dale Kiefling
Dale Kiefling had worked with Sri Rao on the technical operations team. They alternated weeks on
call, which required a response within 20 minutes to technical issues ranging from DDoS attacks to
hardware failures to serious software bugs. Kiefling recounted his frustrations with the role:

When I was on call, it was 24/7. We had automated systems with alerts and dashboards, and
at the beginning, the work was manageable; we learned to adjust the thresholds and we designed
automated responses for different issues. But eventually, we were growing too fast to do that.
My pager was going off every 8 minutes on average, for the entire 24 hours, which is far beyond
any normal Ops job and certainly not what I signed up for. With our volume of traffic, most
companies would have a network operations center with a big team, and probably another NOC
in Asia to cover all time zones.

Sri had been trying to hire someone, but he set a very high bar; he wanted an absolute
superstar. They are really hard to find, especially for a job that requires these hours. So the
position was open for months, and all that time it was just the two of us.

I raised my concerns with Sri, Matthew, Lee, and Michelle and backed them up with metrics.
They wanted to fix things, but they just kept saying that we needed to automate more, and the
time we had to automate kept shrinking as traffic ramped. Then my wife and I had our first baby
and I realized that working at this level of intensity was just not sustainable. I could see that
plans were in place to fix things, but I couldn’t wait for that.

Prince agreed that this was a difficult role:

Dale was right; we run the team hot. He is a great, hard-working guy, but his pager was
going off way too much. We’ve been growing like crazy, and we have plans to automate, but
Dale resigned before we got the automation done.

Dale was our first employee to resign, and he did so just short of one year’s tenure. If he had
stayed a few more weeks, he would have vested some valuable stock options, which shows just
how much workload pressure he was under.

David Conrad
The second departure was David Conrad, one of CloudFlare’s opportunity hires. Like Dale, Conrad
had quit just before his one-year anniversary, forfeiting stock options that otherwise would soon vest.
He previously had been cofounder and CTO of Nominum, which built advanced network technology,
and had held senior roles at four nonprofits that coordinated Internet policy and technology standards:
Asia Pacific Network Information Centre, American Registry for Internet Numbers, the Internet
Systems Consortium, and ICANN. Conrad recalled:

Before I joined, Matthew and I were really excited about what I could offer CloudFlare. But I
realize now that it wasn’t clear what role I’d be filling. In my previous jobs, I’d worked on
standardizing development processes and stabilizing infrastructure. I assumed that was what
CloudFlare wanted me to do, but every time I brought up a suggestion, they said “No, we don’t

10

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

want any structure.” For example, they program in several different languages with hardly any
documentation. They choose to live with a growing problem, rather than slowing down to
rationalize things.

Conrad also had concerns about CloudFlare’s lack of organizational structure and HR processes.
He continued:

The company has no org chart, no reporting lines. It’s just engineering, support, and
“everyone else.” But at a certain size, you need a middle level. Hiring Dane was a step in the
right direction, but the company needs the same layer in other functions. For example, the
support team hates the software they are using, but they have no one senior to fight for a change.

Also, the company lacks an office IT function to take care of stuff like setting up printers. For
now, most everyone on staff is technically sophisticated and they can do those things themselves,
but as we bring onboard more nontechnical people, we are going to need more support. New
hires expect certain things from a company this size, like a staff handbook that explains vacation
and sick-day policies, or how expenses get handled. When you are tiny, you can sort these things
out ad hoc, but as you grow you need some structure.

I could have helped with these issues, but the cofounders weren’t ready to address them. I
ended up coding, but that’s not really what I’m best at and not how I thought I should contribute.

Prince felt that Conrad had a valuable role to play but acknowledged the integration challenges that
had troubled Conrad. Prince elaborated:

David added huge value because he knows everyone who matters in the world of Internet
policy and technology, and he made introductions to those people. Over time, his role would
have become even more important. If we ever wanted to send someone to Washington to lobby,
he’d be the perfect guy.

David was also adult supervision to some extent. He would fight with our engineering guys,
saying we needed more redundancy and process. He won some of those battles, but he lost most
of them.

We gave him a technical project to get started, because this is a place that values engineering,
but his progress was slow. It’s hard to go to the Friday meeting every week and see none of your
stickies come down. He didn’t feel like he was being well utilized, and there’s nothing more
demotivating than that.

David turned in his resignation just before vesting his first tranche of options. He’s a Silicon
Valley veteran, so unlike some of our younger employees, he knew that he was leaving a lot of
value on the table. But he felt like he wasn’t contributing, and that he didn’t earn his options.
This speaks volumes about how strongly great engineers feel about doing important work. We
definitely want to keep David as a consultant.

David Zakur
The next resignation, in July, was David Zakur’s. Zakur had previously worked at a company that
sold domain names and provided web advertising services. He was persuaded by Prince to join
CloudFlare in spring of 2011 to evaluate monetization opportunities in targeted advertising. Age 36,
married with two young children, and with both his and his wife’s families living on the East Coast,

11

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

Zakur had some personal issues that contributed to his decision to resign. However, he also found
aspects of his role at CloudFlare frustrating. He said:

As a fast-paced startup which is literally defining a new market, CloudFlare has a very
dynamic strategy. It’s been hard to get the buy-in to focus on monetization at this stage of the
company. I’m perfectly comfortable ramping up and building a business line, but the
opportunity I was hired to pursue never really took off. In all fairness, Matthew had warned me
that my role might be premature. During the interview process, he said, “We want to hire you,
so we’ll figure out how to make it work. But you have to be comfortable not launching anything
for a year.”

I don’t think we’ll make a big shift into monetization until our burn rate gets higher or the
market demands these services. Right now, we haven’t got a pressing need for revenue, given
the fact that the subscriptions business is so strong and growing consistently. I wouldn’t say that
I’m impatient, but I think we could be more aggressive on monetization. When I joined, Matthew
said, “The stuff you’re going to build will disrupt huge markets. If you’re going to poke the giant
in the eye, make sure that you’re as big as possible.” I understand that if you move too soon, it
could be a company killer. But that doesn’t make it ideal for me from a job satisfaction
standpoint.

Ultimately, in what proved to be an extremely difficult decision, Zakur found that he wasn’t getting
enough satisfaction from his work to make up for the challenges that long hours posed to his family
life. He said:

Matthew lives across the street from the office. Michelle does, too. They each literally cross a
street or two, and they’re at work. Matthew is at the office morning, noon, and night. Lots of
others are, too: people here are really engaged by their work. But the hours can take a toll. We
have a status meeting every Friday at five o’clock, which lasts for 1 to 1.5 hours on average. The
intention is fantastic, but the timing is brutal. I have a long commute, and this means I can’t get
home to even see my kids before bed. Changing the timing has been raised by multiple people,
but it has been emphatically rejected every time. Most of the rest of the staff is single, and they
live nearby in San Francisco, so this is less of an issue for them.

Two More Resignations

Two other employees had resigned over the past two months. One had been an early hire who had
been deeply involved in developing all of the company’s key systems. Prince elaborated:

This employee is a brilliant jack-of-all-trades engineer, so work just kept piling up on him.
He wasn’t really passionate about a lot of that work. It took a while for us to clear his backlog,
and he finally said, “I’m burned out, I’m going to quit.” I said, “You don’t want to quit—you’d
really be walking away from a lot.” I wasn’t talking about unvested options; this guy doesn’t
care much about money—he cares about working on hard problems. So I told him, “If you want
to work on massively scalable data infrastructure, this is the place to be.”

Prince suggested a two-month travel sabbatical to think things over, and the engineer was surprised
and happy to be given this opportunity. He was currently traveling in Europe but in constant contact
via e-mail and still working on CloudFlare projects. The cofounders were confident that he would
eventually rejoin the full-time staff.

12

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

The last resignation was by an engineer who disagreed with Prince about strategy and staffing
plans. When he realized that he wouldn’t get the larger team and management responsibility he
wanted, he resigned.

What Now?
Prince called his cofounders to discuss the implications of these resignations. With 35 employees,
did the recent loss of five team members simply represent natural attrition? Were employees’ reasons
for leaving idiosyncratic, or were there patterns in their departures that signaled a need for corrective
actions? Specifically, were changes required in the CloudFlare’s culture, organizational structure, and
management processes? Could CloudFlare make such changes without undermining its commitment
to innovation by brilliant, self-directed, mission-driven staff? Was CloudFlare hiring the wrong types
of people? And how did Prince’s own management style fit with any changes that might be required?

Prince said, “We’re not taking these resignations lightly. We need to think about how and whom
we hire. I have a sense that a couple of other people are at risk; they just feel worn out. The question is:
What, if anything, should we do to address burnout? And, as CEO, how should I make these decisions,
and how should I communicate them to our team?”

13

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

813-145 CloudFlare, Inc.: Running Hot?

Exhibit 1 Traffic Growth, October 2010 through July 2012

Monthly Page Views (millions)

70,000

60,000

50,000

40,000

30,000

20,000

10,000

Unique Monthly IPs (millions)

600

500

400

300

200

100

Source: Company.

14

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

Exhibit 2 Founder Bios

Matthew Prince received his BA in English and Computer Science from Trinity College, Hartford.
While earning his law degree from University of Chicago he interned at Latham and Watkins,
specializing in technology securities. Prince worked at an internet startup in the employee benefits and
insurance space, and founded Unspam Technologies Inc., a consulting firm helping businesses and
government agencies regulate unsolicited email. He served as an adjunct professor at John Marshall
Law School, co-created Project Honey Pot, an open source spam harvester tracking network, and
received an MBA from Harvard Business School.

Michelle Zatlyn studied chemistry and business as an undergrad at McGill University, spent three
years as an investment research analyst and then was a founding team member at I Love Rewards, a
rewards and marketing software and services company. She spent two years as a product manager at
Toshiba and interned at Google while earning her MBA from Harvard Business School.

Lee Holloway has a degree in Computer Science from University of California, Santa Cruz. He
subsequently worked on the post-acquisition software integration of homewarehouse.com onto
Walmart.com’s platform; developed the customer service application AVOCADO; and developed and
maintained a software platform for Book Online Vacation Rentals. Holloway was lead engineer for
both Unspam Technologies Inc. and Project Honey Pot (see above).

Source: Company.

15

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.
-16-
813-145

How CloudFlare Works

Source: Company.
Exhibit 3

This document is authorized for use only by GAD ALLON in 2018.

 For the exclusive use of G. ALLON, 2018.

CloudFlare, Inc.: Running Hot? 813-145

Exhibit 4 Tiers of Service Offered

• Free: improved performance; security protection; visitor stats updated every 24 hours; and email
support

• Pro ($20/month for first site, $5/month for additional sites; no bandwidth charges): faster
performance including image polishing and mobile optimization; more advanced security
including SSL encryption and web app firewall; visitor stats updated every 15 minutes; and email
support

• Business ($200 per month per site; no bandwidth charges): advanced optimization with Railgun;
advanced DDoS protection; 100.0% uptime guarantee (rather than 99.999% industry standard,
which can yield 5 minutes per year of downtime); visitor stats updated every 15 minutes; and
prioritized email support

• Enterprise (starting at $3,000 per month; no bandwidth charges): customized solutions including
advanced optimization with Railgun; advanced DDoS protection; visitor stats updated every 15
minutes with access to raw log file data; 2,500% uptime guarantee (which applies a 25x multiplier
to any credits owed due to lapses from 100.0% service); 24/7 email support; phone support; and a
dedicated account manager

Source: Company.

17

This document is authorized for use only by GAD ALLON in 2018.