This piece was adapted from interviews Jeff Bezos gave at the Economic Club of Washington in 2018, and the Reagan National Defense Forum in 2019. Both are included in Invent and Wander: The Collected Writings of Jeff Bezos, which was co-published by PublicAffairs, an imprint of Perseus Books, and Harvard Business Review Press.

Zero-sum games are unbelievably rare. Sporting events are zero-sum games. Two teams enter an arena. One’s going to win; one’s going to lose. Elections are zero-sum games. One candidate is going to win; one candidate is going to lose. In business, however, several competitors can do well. That’s very normal. The most important thing for doing well against competition — in business and also, I think, with military adversaries — is to be both robust and nimble. And it is scale. So it’s great to be in the U.S. military because you’re big. Scale is a gigantic advantage because it gives you robustness. You can take a punch. But it’s also good if you can dodge a punch. And that’s the nimbleness. And as you get bigger, you grow more robust.

The most important factor for nimbleness is decision-making speed. The second-most important factor is being willing to be experimental. You have to be willing to take risks. You have to be willing to fail, and people don’t like failure.

I always point out that there are two different kinds of failure. There’s experimental failure — that’s the kind of failure you should be happy with. And there’s operational failure. We’ve built hundreds of fulfillment centers at Amazon over the years, and we know how to do that. If we build a new fulfillment center and it’s a disaster, that’s just bad execution. That’s not good failure. But when we are developing a new product or service or experimenting in some way, and it doesn’t work, that’s okay. That’s great failure. And you need to distinguish between those two types of failure and really be seeking invention and innovation.

To sustain it you need the right people; you need innovative people. Innovative people will flee an organization if they can’t make decisions and take risks. You might recruit them initially, but they won’t stay long. Builders like to build. A lot of this stuff is very simple, really. It’s just hard to do. And the other thing about competition is that you do not want to play on a level playing field. This is why you need innovation, especially in domains like space and cyber.

A level playing field is great for Monday night football. We have for decades enjoyed an unlevel playing field in areas like space and technology. I’m very nervous that this is changing rapidly. The only way to stay ahead and to keep that unlevel playing field, which is what you certainly want, is to innovate.

In the space domain we are facing adversaries who are going to innovate. So that’s the real issue. If you’re facing adversaries who are not good at innovating, then you don’t have to be that good at innovating.

When it comes to competition, being one of the best is not good enough. Do you really want to plan for a future in which you might have to fight with somebody who is just as good as you are? I wouldn’t.

***

We worked on Amazon Web Services (AWS) behind the scenes for a long time, then finally launched it. AWS has become a very large company by reinventing the way companies buy computation. Traditionally, if you were a company and needed computation, you would build a data center, and you’d fill that data center with servers, and you’d have to upgrade the operating systems of those servers and keep everything running, and so on. None of that added any value to what the business was doing. It was kind of a price-of-admission, undifferentiated heavy lifting.

At Amazon we were doing just that: building data centers for ourselves. We saw it was a tremendous waste of effort between our applications engineers and our networking engineers, the ones who run the data centers, because they were having lots of meetings on all these non-value-added tasks. We said, “Look, what we can do is develop a set of hardened application program interfaces — APIs — that allow these two groups, the applications engineers and the networking engineers, to have roadmap meetings instead of these fine-grained meetings.” We wanted to build in a service-oriented architecture, where all of our services were available in hardened APIs that were well documented enough that anybody could use them.

As soon as we hatched that plan for ourselves, it became immediately obvious that every company in the world was going to want this. What really surprised us was that thousands of developers flocked to these APIs without much promotion or fanfare from Amazon. And then a business miracle that never happens happened — the greatest piece of business luck in the history of business, so far as I know. We faced no like-minded competition for seven years. It’s unbelievable.

When I launched Amazon.com in 1995, Barnes & Noble then launched Barnesandnoble.com and entered the market two years later in 1997. Two years later is very typical if you invent something new. We launched Kindle; Barnes & Noble launched Nook two years later. We launched Echo; Google launched Google Home two years later. When you pioneer, if you’re lucky, you get a two-year head start. Nobody gets a seven-year head start, and so that was unbelievable.

I think that the big, established enterprise software companies did not see Amazon as a credible enterprise software company, so we had this long runway to build this incredible, feature-rich product and service that is just so far ahead, and the team doesn’t let up.