4

HYPERGROWTH

On Goals, Doubling, Ancestors, and Pain

A company is most vulnerable when it has completed one major goal and not yet signed up for another: this was our position after going public. Dan said that an IPO is like graduating from college. For years you focus on getting that diploma, but then you leave school and it’s time to go out and show the world what you can do. Dan was warning us not to be too pleased with ourselves. By some measures, NetApp was remarkably successful, but in the computer industry, we were something else: small and weak, with much larger competitors hell-bent on killing us, and customers who weren’t big enough to sustain us. Going public is the beginning of a tough fight, not the end of one.

To survive, we needed new goals that were bold, profitable, and achievable. Dan held a three-day offsite for his staff, a meeting away from our offices where we could focus on planning the future without the interruptions of the present. The outcome was three goals that guided our growth for the next five years:

• Create a new market called Network-Attached Storage (NAS), and convince analysts to track it.

• Dominate that new market, with No. 1 market share.

• Double revenue every year for five years to a billion dollars.

 

The first goal was about being recognized. We believed that NAS was an important new market category, but it’s one thing to claim that you’ve invented a new market and quite another to convince industry analysts that it is worth their time to study it and report on it the same way they do for computers, routers, and printers.

The second goal was about beating the competition. At that point, Auspex was our closest competitor, but we were growing so fast that we expected to pass them up before the analysts started paying attention.

The third goal was about our own execution, and it was bold to the point of controversy. When Tom Mendoza heard that his goal was to sell a billion dollars worth of equipment, his eyes rolled back in his head, and he practically fell out of his seat.

Tom believed in the company and the product, but a billion dollars seemed unrealistic to him. It was an absolutely enormous goal given that our revenue that year was only about $40 million. This company-wide goal would require fantastic products, successful marketing, and strong customer service, but Tom felt the burden most heavily because revenue goals traditionally belong to sales. I mistakenly assumed that Tom just didn’t understand the math of doubling, but it didn’t calm him at all when I scribbled down some figures and said, “Look, if we double every year for five years, that’s well past a billion, more like $1.3 billion.”

“Great,” Tom said sarcastically, “the $300 million can be my safety margin.”

Tom could have turned it back on me by saying, “Okay, Dave, we need the product to be thirty times faster.” Then it would have been my eyeballs rolling back.

A few years before, we were concerned with hundreds of thousands of dollars and then with millions. Now Dan was saying we should talk about billions. “Can we do it?” he asked.

“Well, sure we can,” said Tom, “we just need people we haven’t hired yet to sell products we haven’t built yet to customers we haven’t met yet.”

We had many reasons to believe that NetApp had a big opportunity. We had a track record of high revenue growth. Over three years, sales went from $2 million to $14 million to $43 million. Our initial market, storage for low-end UNIX computers, was growing quickly, and we found new markets as well. We added support for Windows computers, which roughly doubled our potential, and our Ferrari-fast speed let us sell to still more customers.

The biggest growth driver of all was the Internet. Many dot-com companies became great customers because they had so much data. They stored e-mail for millions of people, photos and movies to download, or pictures of products for people to buy. One analyst explained it like this: venture capitalists gave money to Web start-ups, and the start-ups gave it to NetApp. Early Internet customers included Amazon, Yahoo, AOL, EarthLink, MindSpring, and even Hustler.com—the list goes on and on. In the Gold Rush, it wasn’t the miners who made the most money; it was the people who sold them shovels and blue jeans. We weren’t a Web company, but we supplied them.

As the dot-com boom progressed, this style of thinking drove NetApp’s stock sky-high. Our price-to-earnings ratio hit 800 at one point, which was absolutely crazy. (I became, for a while, a billionaire.) Jeff Allen was our chief financial officer (CFO), and the stock market analysts wanted him to justify our stock price. “That’s your job,” he said. “I can tell you about our business and our growth, but as to what the market’s doing, I really can’t help you there.”

The Internet helped us in a second, more subtle way: it legitimized networking for mission-critical applications—apps that absolutely must be available 100 percent of the time. In the early nineties, Ethernet, the technology that networks are built from, wasn’t very reliable: good enough for e-mail or sharing files, but only a crazy company would trust it for applications that provide services to customers or collect money from them. Internet companies, however, had to depend on their networks. If the net was down, Amazon couldn’t sell books. Yahoo couldn’t provide e-mail.

This situation drove Cisco and other networking companies to make Ethernet faster and more reliable, and that helped NetApp. Remember, the “N” in NAS stands for network: Network-Attached Storage. Our products provided storage over the network, so improving the network improved our solution. At first, only Internet companies used NAS for mission-critical applications, but when the trend spread to traditional companies, it created a truly enormous opportunity for us.

Even with so much opportunity, it was fair to ask: How fast can a company grow? Despite Tom’s skepticism, I felt that doubling to a billion was possible. The rules are probably different for different industries, so before the offsite meeting, I researched tech companies that sold computing equipment into data centers, as we did, and I derived some rules of revenue growth:

• You can reach $100 million within a year of shipping product.

• Beyond $100 million, doubling annually is the best you can do.

• Beyond $1 billion, 50 percent annual growth is the maximum.

 

You must also consider growth in terms of people. A rough rule of thumb for tech companies is $500,000 in revenue per employee, so a $100 million company needs two hundred people. At that size, the largest groups are engineering and sales, each with fifty to seventy people.

In Guns, Germs, and Steel, Jared Diamond describes different types of societies. The band is the smallest, with only a few dozen members, and Diamond argues that “the band is the political, economic, and social organization that we inherited from our millions of years of evolutionary history. Our developments beyond it all took place within the last few tens of thousands of years.”

I believe it is no coincidence that the group size of our evolutionary history matches the maximum group size that can form easily and spontaneously in a company. A few dozen people can all fit in a lunchroom to talk and plan and form a team. Beyond that, growth becomes more painful. That’s not to say it’s impossible, but it is unnatural and takes hard work. If you double annually, then half of your employees have been on board less than a year. The big challenge is quickly absorbing them into your culture.

I was lucky to still have a job at NetApp. The title “jack-of-all-trades” is greatly valued in start-ups, but unfortunately, the entire phrase is “jack of all trades, master of none.” Start-ups remind me of my time on a remote desert ranch: you need people who can do pretty much anything. As a company grows, job requirements get more specialized. Bigger companies have more masters and fewer jacks. Founders often leave after the IPO or after a new CEO, but James and I survived both.

Lots of people asked, “What’s next for the two of you?” and VCs and headhunters called to lure us into another start-up. They assumed that we would be looking for something new. But when James and I thought back to our initial vision, we realized that we had much more to do at NetApp, and we wanted to see it through. We wanted to change the industry. We wanted NetApp to become a Fortune 500 company, like Sun and Cisco. We had built a foundation, but in terms of these big goals, we’d come less than halfway. Fortunately, we found places to contribute—James became CTO and I became “VP of doubling.” Having two founders stay so long was unusual enough to make people curious. VCs sent the technical founders of younger companies to ask: Why hadn’t Dan fired James and me? The secret was simple: We valued our customers and our company more than we valued the technology we had developed.

In the beginning, a start-up is all about new technology, but as it grows, other things become at least as important: customers, sales, marketing, and so on. In the end, a start-up is a business, and businesses must return profits to their owners. In a conflict between profit and cool new technology, profit likely wins. This isn’t always palatable to a technically minded founder.

For me, developing our technology was a wonderful experience, but I also got a thrill watching customer adoption. It is one thing to develop technology that should work in theory. It is another thing to see hundreds and then thousands of customers actually use it. Some people love solving a problem, whether or not anyone else knows about it. Isaac Newton was that way. He invented calculus and then put it on a shelf for decades until friends begged him to publish it. His satisfaction came from the discovery itself. Newton was a genius, and there’s nothing wrong with being wired like him, but if you are, then maybe you belong in academia or in a large corporate lab. In business, satisfying customers matters more than your favorite research project.

As VP of doubling, I would walk into a manager’s office and say, “Right now you have ten employees. Next year it’ll be twenty, in two years forty, and in three years eighty. Have you thought about how to hire seventy more people? Have you thought about how to organize a group of eighty people? Can any of your people manage a group of ten? In three years you’ll need eight who can.” My goal was to get people thinking big. If they couldn’t, then we’d have to hire a boss over them who could.

The good news is that people don’t worry as much about being demoted during hypergrowth. If your group of forty people is split four ways, then you become manager of ten. But two years of doubling will take you back to forty, and you can try again. If you weren’t ready the first time around, it’s a short wait until the next opportunity. Once people understand this, fast growth can help foster a healthy culture. Everyone has so much on their plate that they are willing to hand some off. (In game theory terms, hypergrowth creates a non-zero-sum situation in which everybody can win. I recommend the book Nonzero by Robert Wright.)

The Grass Is Always Greener

In hypergrowth you must always be on the lookout for people to hire.

I once took a friend’s daughter to a piercing studio to get her tongue pierced. The piercing technician had a shaved head and tattoos that ran down his arms and up his neck. His ears and eyebrows were riddled with holes, all filled with stainless steel hardware. He noticed my company T-shirt and said, “NetApp? You work at NetApp?” I nodded and he said, “Can I give you my résumé? NetApp is so cool!”

Surprised, I asked, “What have you heard about NetApp that you think we need a full-time body piercer?”

“I’m tired of this piercing thing. I mean, all of these idiot young girls come in and they want me to pierce their tongues, pierce their nipples, pierce their clits. I am so tired of teen nipples and tongues and—what I love is IT.”

“IT? You mean information technology?”

“Yeah. I’m the guy that put up the Web site for this shop and I can do Linux and Apache. My favorite operating system is Linux 2.4. I would love to work for NetApp.”

Perhaps he interpreted my shocked expression as skepticism that his Linux experience was sufficiently broad, because he immediately said, “Oh oh oh, not a problem. I can do Windows too.”

I gave him my card.

The act of doubling is not an annual milestone; it is an incremental process. Doubling happens every single day. The key is to stay focused. A trick that helps people think about annual doubling is to break it into quarterly goals. To double in a year, you must grow by 20 percent each quarter—actually it’s 18.9 percent, but close enough. Instead of focusing on the distant, giant numbers, I would focus on the next two quarters. “You’ve got twenty people today. That’s twenty-four in three months and twenty-nine in six. Do you have nine people in your hiring pipeline?” I practiced doing the math for 20 percent growth in my head. Managers who weren’t on track for the next two quarters would never succeed at doubling in a year.

The first lesson of hypergrowth is Everything is always broken. Relax, because it’s a good thing. Of course, there are good problems and bad problems. We need more office space. Our demand exceeds our production capacity. We have too many orders to process. I love to hear problems like this. On the other hand: Everyone is quitting. Sales are down. Our investors are dissatisfied. Not good.

Problems during doubling tend to be the good kind, and pointing that out to people can help morale. Our VP of engineering at the time, Helen Bradley, did this. When people complained about sharing small cubes that were designed for just one person, Helen said, “Be careful what you wish for. My last company had plenty of space—because people were being laid off.”

Systems and processes that work well for a small company often fail for a larger one. Accounting software designed for $10 million in revenue didn’t scale to $100 million. We bought the small-company version anyway, knowing it would break soon, because the one for big companies was too expensive. Even with a giant discount, we couldn’t have afforded the customization required to install it or the people to operate it. Companies in hypergrowth are rare, so application vendors don’t optimize for their needs. The result is lots of problems.

It is tempting to fix every problem, but that is a mistake. The old saying “a stitch in time saves nine” is fine if you only have one problem. But what if you have a thousand problems? It would take a thousand stitches to prevent them all. Better to fix the few that are deadly and ignore the rest. Don’t fix a problem because it’s painful; fix it because it impedes growth.

We accumulated lots of painful problems, and people naturally complained. “What moron designed this inadequate system?” It does not inspire confidence if new people believe they were brought into a company to clean up someone else’s mess. I tried to help them understand that even good systems break under the strain of doubling. Whoever put the system in place probably did the best they could with the resources they had.

Brian Ehrmantraut was our seventeenth employee, and he focused on making NetApp more mature. He wrote a process manual documenting the steps required to accomplish various tasks. Years later, Brian was working on a problem and came up with an innovative solution. A much more recent employee told him, “We can’t do that. It’s not how NetApp does business.”

“What are you talking about?” Brian asked. The employee went to the shelf, grabbed a book, and flipped it open: “See, it says right here that we have to do it this way.”

Brian looked at him and said, “Don’t give me this bullshit. We were a thirty-person company when that was written. Now we have three hundred. Besides, I wrote that procedure myself.”

When new people were fixing the problems of the past, I cautioned them not to complain too loudly about the “moron who designed this system.” I said, “You’ll design a replacement system, and after two more years of growth, the moron will turn out to be you.” Respect your ancestors, and perhaps your descendants will respect you.

With so many new employees coming in, we invested heavily in training. Once a month we invited all new employees to spend a day with the executive staff. Most of the executives described the goals for their particular part of the company, but I wanted to give people a sense of how hypergrowth feels. I tried to inoculate them against the pain by warning them about it. Growth is exciting, and it creates opportunity—not only for the company but also for people’s careers. They can withstand the pain more easily if they see it as a natural side effect of something healthy.

One thing I fought during those talks was simple disbelief. When NetApp was 250 people, I put up a spreadsheet showing that in three years we would have 2,000 people. It was natural for people to doubt, but if they don’t believe, they won’t even try, so I told stories about other companies that had done it, like Oracle, Cisco, and Sun. Many ingredients are required to sustain such fast growth—good products, good sales, a large enough market opportunity—but one critical factor is deciding to grow.

Given the pain of doubling, many wondered why NetApp should grow so fast. Couldn’t we serve our customers better if we grew at a more reasonable rate? I replied that growth for growth’s sake is not a worthy goal, but we could never lead the industry we helped create by remaining small. We might not even survive.

In Inside the Tornado, Geoffrey Moore describes the difference between Oracle, which you’ve probably heard of, and their early competitor Ingres, which you probably haven’t. “What set Oracle apart from Ingres,” says Moore, “was that Larry Ellison [the CEO] drove for 100 percent growth while Ingres ‘accepted’ 50 percent growth. To garner that 100 percent growth he simply doubled the size of his sales force every year.” Ingres had a different theory: “We simply cannot grow any faster than 50 percent and still adequately serve our customers.” With such different growth rates, Oracle killed Ingres in no time. Oracle got so much bigger, so much faster, that they out-invested Ingres on every front. Trying to double may seem risky, but not trying can be even more dangerous. You can’t serve customers at all if you are dead.

Having decided to double, we optimized the whole company for growth, and we succeeded. By 2001, we had 2,400 employees and $1 billion in revenue. Our motto during this era was Double or Die.

There is a deep link between hypergrowth and culture. In hypergrowth, new employees (and new problems) arrive so fast that detailed planning can’t possibly succeed. You set high-level goals and trust people to do the right thing. All my personal experience was in start-ups, and the dot-com customers I spent time with were also growing very fast, so I assumed that this model was best for everyone. I couldn’t understand why big old companies couldn’t see the light and adopt our (obviously superior) culture.

My first experience with “stodgy old companies” occurred when we started selling to them in the late 1990s. I went to visit companies like Ford and General Electric, and their culture baffled me. We would talk to information technology (IT) people managing millions of dollars of budget, but they had no autonomy whatsoever. As near as I could tell, their companies had teams of accountants with green eyeshades and sharpened pencils who dominated every decision. Crazy!

The more I learned about these companies, the more I understood the logic of their structure, and that helped me understand our own culture. In a hypergrowth company, you optimize everything for growth. Trimming IT spending from 5 percent of revenue to 4 percent might seem like a good plan, but if it slows your growth, you’ve made a terrible mistake. Better to waste a little money and keep on doubling. To achieve this, you design a decentralized culture. You help people understand the big picture, warn them of the challenges, and then turn them loose. Sometimes they screw up, but more often they find and fix problems that never would have occurred to you. Things are changing so fast that centralized planning is impossible. Instead of focusing on process and control, you focus on trust and enablement.

It is completely different for a mature company that dominates its market and doesn’t expect much growth. If you can’t increase revenue, then to improve profitability you must reduce costs. In this case, trimming IT spending will increase earnings by the same amount, which should drive up your share price. The same strategy that was a terrible mistake in hypergrowth makes great sense here. When things aren’t changing very fast, centralized control can work. If you identify a cost savings, standardize it and push it through the whole organization. In other words, put the people with pencils and eyeshades in charge.

When the stock market crashed in 2000, NetApp’s stock fell from $150 a share to $6 in less than a year. Fortune published an article called “The Forty Biggest Losers,” which listed the individuals who lost the most money in the crash. I lost over a billion dollars and was number thirty-two on the list. When my assistant Kathy Bittner saw that, she marched into my office, held up the article, and said, “This makes me ashamed to work for you. Here are all the biggest losers, and you can’t even make the top twenty.” One of Kathy’s jobs is to keep my ego in check. Another friend helped out too. He came up to me and said, “Hey Dave, did I ever tell you that I used to know a billionaire?”

The dot-com boom of the 1990s was a classic market bubble. Everyone sensed that the Internet was going to change everything, and in some ways it has, but there was no justification for the crazy stock prices. The crash hit Internet companies first, but then spread quickly to anyone that sold to them. Seventy percent of our revenue came from Internet and technology companies, so their pain became ours.

Now the analysts wanted our CFO, Jeff Allen, to tell them how quickly the stock market would bounce back. Would it be a V-shaped graph or a U-shaped graph? Jeff said, “I know what you want to hear, but I’m not going to blow sunshine up your ass. I think the market looks flattish. L-shaped.” Nobody wanted that news, but I was proud of Jeff. He wouldn’t make stuff up back when the stock was so high, and he still wouldn’t now that it was so low.

We had designed NetApp for growth, and when the growth stopped, everything broke, but this time in a bad way. Our highest quarter was $290 million in sales, and based on the 20 percent per quarter rule, we expected to be well over $400 million per quarter six months later. We were hiring people based on that assumption. Instead, our sales six months later were under $200 million—less than half what we’d been counting on.

Dan didn’t want to do layoffs. He had done layoffs at his previous company, and I think he still felt guilty. But at the same time, he had very strong feelings about staying profitable. He felt that posting losses would be so damaging to NetApp, at a time when many companies were failing, that it would put everyone’s job at risk. Dan let profits go all the way down to zero, but when they threatened to go negative, he wouldn’t postpone any longer. Some companies announced a layoff and then took months to plan and execute. That approach hurt morale, and people spent so much time worrying about losing their jobs that nobody got anything done. We decided to act quickly.

We announced layoffs one day and did them the next. The day of the announcement we had a training session for all the managers who would be laying people off. They had many questions, like “Do I ask them to clear out their desks right away or let them come back later or what?” My answer was “Why not ask the person what they prefer?” We had a lawyer to answer legal questions, but I told the group, “The laws on this probably fill twenty books, and you’ll never learn it all by tomorrow. My advice is to treat everybody like a human being, the way you would want to be treated in this situation, and the odds are that it is probably legal. I trust you.”

The dot-com era was like a giant wave. It lifted us, and carried us, and when it set us down, NetApp was a completely different company—a large company, a billion in revenue, and we were helping even larger companies solve some of their most important problems, a far cry from the small workgroups that we started with.

The wave analogy encourages humility. Imagine you are surfing, and you spot the biggest wave ever. You decide to catch it, and you have the best ride of your life. You can be proud of spotting the wave, and of deciding to catch it, but don’t be proud of the wave itself. We didn’t invent the Web or even predict the Web, but we saw it coming and decided to catch it. I’m proud of how well we rode.

The key lesson is that change creates opportunity. With change, customers encounter new problems, and although they hate working with start-ups, they will if their problems force them to. As a small company, I’d much rather target a turbulent $1 billion market than a stable $10 billion one. If the chaotic market is adjacent to a giant stable one, so much the better; with luck, the chaos may spread. The Internet was a rare opportunity, but such opportunities favor the prepared, so I hope that describing our experience will help you spot the wave of a lifetime in your own industry.

Perhaps it is the nature of hypergrowth to always end in a thud. To optimize for growth, you assume it won’t stop. You hire well in advance, because new people can take six months or more to get fully up to speed. To double revenue, you double the sales force. We operated like this for seven years in a row. The problem is, when the end arrives, you will almost certainly overshoot. Slowing too soon is dangerous, so you just keep going. Thud.

The Stupidest Business Plan

The basic argument of the Stupidest Business Plan goes like this: “Coca-Cola sells $30 billion a year. If I could convince 1 percent of those people to buy my product, Koka-Kola, that would be $300 million. That’s a major company!”

It sounds good at first but ignores the question of how to get 1 percent of Coke’s shelf space or customers. Why would happy Coke customers switch? Targeting an entire giant market makes no sense. You should either target an unhappy subset, or a group that isn’t buying at all. That’s the dollar figure to talk about.

Ben & Jerry’s did this in the ice cream market. They didn’t try to grab 1 percent with an identical product. Within the niche of especially rich and tasty ice creams, they found a subniche that was willing to pay more for ice cream made by a company with high social values. Identifying a tiny new niche is better than trying to take on a giant market with a me-too product.

The rules are different for the market share leader. In a meeting with Coca-Cola, I asked how they can possibly expand, given that every store, cafeteria, and break room already has a Coke machine. The response: “Our CEO says our mission is not complete until every sink on the planet has Hot, Cold, and Coke.”

 

 

 

 

 

 

 

 

 

 

 

 

 

We survived the crash because a few years earlier we had begun selling to several new market areas, like banks, telephone companies, and the federal government. To recover, we shifted our focus much more strongly toward these new segments. I am very interested in how strategy changes at the transition from one period in a company’s history to its next. The details are a topic for Part Three of this book, but I am calling attention to it here because this transition is so important to NetApp’s maturation.

NetApp’s turbulent adolescence began with hypergrowth and ended with the crash. The next chapter focuses on this same period, but from the perspective of how values and culture created a company resilient enough to survive.

INTERLUDE

How to Fail in Executive Staff Presentations

Imagine this scenario: An old friend rushes up and says, “You wouldn’t believe the amazing car I saw yesterday. Twenty-five years old, but the paint is perfect, and it runs like a charm.” You ask him what his point is, but he keeps talking about the car. “It’s not expensive now, but a classic like this is sure to go up in value.” On and on he goes.

You look at your watch, and your friend suddenly says, “Wait! This car is for sale on eBay. I want you to buy it and lease it to me. It’s a great investment for you.” There you are, two minutes from your next meeting. How do you react? You need time to think, but he says, “The auction ends today. I gave you all the data you need. My facts prove that this is a great deal. You need to decide right now.”

Presenters in executive staff meetings often trigger this feeling, and I hate it. The meeting agenda has forty-five minutes on a vague but interesting topic (for example, Classic Cars). For forty-two minutes the presenter shares various facts and figures, and then—with three minutes left—the presenter puts up a complex proposal (say, Automotive Investment and Leasing) and asks for approval. You should know that presentations like this almost never go well.

This sounds idiotic, maybe even sneaky and underhanded, but I think people have good intentions. They believe they have an airtight case, and they want to present all the evidence so that when they get to the conclusion, everyone will immediately see that their plan is perfect. Kind of like in detective shows where the hero reveals the evidence point by point and then dramatically identifies the killer. The genius detective technique is great in movies, but in presentations it leaves the audience wanting to go back and reexamine the evidence.

The problem is lack of context. The presentation may be interesting and informative, but if you don’t know what the conclusion is, it is almost impossible to judge how well the evidence supports it. To return to my simple analogy, if you had known it was about buying the car, you might have asked all sorts of questions. What is the Blue Book value? Has it been inspected? How many miles? You can’t evaluate the arguments and ask the right questions unless you know where the presenter is taking you.

Perhaps people want to postpone the pain of rejection till the end of the meeting. But it’s better to find out concerns or objections right away, because that’s when the conversation gets interesting. Maybe you’ll change people’s minds. Maybe you’ll find alternatives that do work. Get shot down early and use the time to recover or to prepare for the next attempt.

Here is my advice: Always start with the conclusion. Somewhere in your presentation you have a conclusion slide that summarizes the proposal you hope to get approved. Put that slide first. Maybe you can get away with one slide of background information before the conclusion, but any more than that and you are probably trying to be a genius detective. As I said, those presentations almost never go well.