Organizing for Innovation: How We Succeed at Amazon

Jeff Barr, VP and Chief Evangelist for Amazon Web Services, has FAQs he'd like to share. In this talk from HashiConf 2018, he answers the questions he keeps being asked, such as: * How does AWS innovate and succeed? * How did he end up doing what he does at AWS? * How can people get hired at AWS?

Transcript

I was invited to talk on a couple different topics here. And, as I was reviewing my presentation this morning, I realized that there were a couple of questions that I get asked all the time:

• I get asked, "How do we innovate and succeed in AWS?"
• Less often people say, "How did you actually end up doing what you do for AWS?" I wanted to answer that.
• I often get asked, "How do I get hired at Amazon?" And I get asked that so often, I actually will try to cover that peripherally in my talk.
• And there's a fourth question I'm gonna let you figure out for yourself.

I'm gonna talk a little bit about how I got here, our leadership principles, how we succeed, and talk about some of the results of that.

How I got here

A tiny, tiny bit of background: middle to late last century, I earned a degree in computer science. This century: I've got five children, and not that long ago three of the five were in college at the same time. And they were all having a super, super great time in school. I got a little bit jealous of them. And so, I went back to school at the University of Washington, got a degree in Communication and Digital Media.

During my career, I've been a developer, I've been a dev manager, I've consulted on web services way, way back in the days of ugly things like WSDL, and SOAP, and UDDI. Anybody remember any of those? Ah. Good memories? Bad memories? Ah, okay. Thought so.

I joined Amazon in 2002 as a dev manager, but quickly found my home as a Web Services Evangelist. Around early 2004, Andy Jassy came on to the team I was on, and he started writing this document called a narrative. I'm gonna talk all about narratives in a little bit. A narrative is a document that we write that says, this is a business we propose to launch at Amazon. I was just one door up the hallway from Andy, and so he had me review a bunch of his narratives. I started to see this awesome document that says well, we're going into the cloud computing business, and we're gonna launch this service, and this service, and this service.

At that point in my career, almost all of my evangelism was: go out, and speak. I would take invitations from anywhere in the world, and I would go out, and I would speak. I'm seeing this incredible laundry list of really cool services that we're getting ready to launch, and I'm thinking, there's really no way that I can really scale my actual in-person travels. So, I went to Andy, and I said, I'd love to create a blog, and I just wanna share some of these cool new services that we build, and bring in some customer stories.

And in late 2004, I launched the AWS blog, and at first it was just a tiny, tiny bit of my job. And then over the years, it grew to more and more, and more of my job. At this point, I'm now, at 2,988 posts I've written. So, I'll hit 3,000 posts somewhere in the next month or so.

So, I've been at Amazon for over 16 years. Now, we have this actually funny thing at Amazon, you might have heard of, called The Old Fart Tool. And The Old Fart Tool actually gives you a couple interesting metrics. We're very, very much metrics driven at Amazon. I checked just this morning, and I've been at Amazon more than 99.43% of my Seattle colleagues, and 99.81% of my global colleagues. So, I've been around there for quite some time.

So, that just just a little bit of how I got here. I'm gonna give you a brief introduction to the…

Amazon leadership principles

This is a set of guiding principles that we use every day at the company. You're gonna see some interesting little Lego in these pictures. A few months ago I was invited to Lego headquarters to speak about leadership principles. I love to build stuff with Lego. Don't tell my wife, but I have about 300,000 loose bricks in my home office. Far more than she ever realized, and they're mostly hidden away so she can't find them.

Anyway, I love to build things, I love to kind of use Lego as part of my messaging. So, whenever you speak to an audience, the best way to speak to an audience is, of course, in their own native language. I get invited to Lego, and I say, "Okay, I'm gonna actually reconstruct all the Amazon leadership principles in Lego form." Lets see a few of those in my presentation today. Because we only have half an hour, I won't get to actually go through all of them, but let's just kind of review a few of the highlights here.

So, we have 14 separate leadership principles: Customer obsession, ownership, invent and simply, and so forth. Now, we think of the first 13 of these principles as inputs. These are things that we can actually do to effect the outcome. And this is our working vocabulary.

We use this at all different parts of our relationship with the company. The very, very first time that a candidate is on the phone with a hiring manager, the hiring manager has probably picked out in their head one or two leadership principles. We abbreviate them as LPs. They've probably picked out one or two of these, and they're gonna interview the candidate against one or two of those LPs. If the candidate gets through that first phone screen, then the candidate comes in for a full days worth of interviews.

At that point, the hiring manager is gonna pick five different people to interview that candidate throughout the day. He's or she's gonna assign usually two different LPs to each of the ... interviewers. And the idea is that we try to go for about 50% technical knowledge, domain knowledge, for that candidate, and 50% cultural fit. So, we might find a candidate who's super, super awesome in the tech, but we don't really think that they really do well against leadership principles. Probably wouldn't end up hiring that particular candidate.

Once the candidate comes on board, they've passed through the interview process. We've said, OK they're thumbs up on tech, thumbs up on the LPs. We're going to first at orientation day, we're gonna review them, make sure everybody's really in sync with the whole set of LPs. And then, you will find this is actually our working vocabulary. But, if you were to be a fly on the wall in any hallway discussion or meeting, you would that we actually use these phrases quite often in our day-to-day discussions. And when we're trying to prove a point, or talk about how well someone's doing, or maybe a missed opportunity, you're gonna really express it in these terms.

Like everything we do, this is our current set of principles, if we can come up with some better ones tomorrow, we will adopt those. From time to time, we do take some of these and we look at them and we say, "Are we serving our customers well with these principles? Are we making sure that these are producing the right outcomes for us?" And if they're not, then we will improve them. We don't think that we're perfect in any way. We always think there's definitely a way for us to do a little bit better.

So, there's the 14. We are very, very happy to share these publicly, and openly. If you think these are good, take them as is. Use them. Even better, take these, invent a better set of principles. Innovate from these as a base and go forward from there.

Lets talk a little bit more about this hiring process. So, I told you we go through the first phone screen, we do the full day interview. Now, one of the unique parts of our hiring culture, is this special model we call a bar-raiser model. This is represented by my colleague over there in the corner. So, in addition to her regular job, she has a kind of a little flag on her employee record called a bar-raiser. That means she's a super, super good interviewer. She's great at helping us to make great hiring decisions.

And the idea is, after we've gone through, we've got the five different people that are going through and doing the interviews through the course of the day. The 50% tech, the 50% leadership principles. The bar-raiser helps us to make the decision that says, "does this person, in this particular job, and at this job level…" (For every job we have a set of leveling guidelines that say a level six, level seven, level eight—these are the expectations for what level of scope they should have.) The bar raiser helps us to say, "Does this new person actually raise the bar with respect to that position?"

This means that as we bring new candidates into the company, and we make new hires—every time we do it—we're notching things up a little bit over time.

Now, when we choose a bar raiser, we very, very carefully choose someone not from within the same organization that needs to fill the seat. This means that they can be very, very objective. It also means that if we know that within the team that we're really really really desperate to fill that seat and fill that position, the bar raiser doesn't know anything about that, and they're not going to be swayed by any internal pressure to get that person hired, so that we can move forward on some really high priority project.

So the bar raiser comes in from outside. They're probably going to spend about 20% of their working week is gonna be spent in interviewing and bar raising activities. So, the bar raiser comes in to our interview room like that. We each go around, make sure that we are all thumbs up on the candidate. That we bring that candidate in, and make that great hire. We continue to use the leadership principles throughout the employee's time with the organization. And we'll review time, we're going to express our own strengths and weaknesses with respect to leadership principles, promotion time. You write a document that says, "Well, Jeff is really good at diving deep, and invent and simplify. Not so great at for frugality, or bias for action, lets say. Another important principle we call…

Having a backbone; disagree and commit

This is a really unique part of our culture. Let's say we get into a situation, we need to make a really important decision of some sort. We're gonna enter that meeting with our data, our research, with our facts. Might be two separate possible paths and maybe I represent one, one of my colleagues represents another. We're gonna be arguing—based on data—and with calm respectful voices we're gonna argue back and forth, do we go with this direction or that direction? We're gonna examine all the data, examine all the facts, try really hard to make the best data-driven decision possible. It's not a fight to the death, it's not really a deathmatch like we've got here with my little sword fighters, but we're expected to be pretty strenuously in favor of our chosen path.

At the point when we make a decision, let's say that I walk in and my colleague's got a far better plan, and at a certain point we're gonna take my colleague's plan instead of mine. At that point the second part of this principle comes in, the disagree and commit. The idea is, no matter how deeply I believed in my data and my research and my plan, I set all that aside. I will throw all of my support behind my colleague's plan, I'll do everything possible to make sure that that plan actually succeeds. I don't harbor any resentments, I don't secretly think that, "Oh okay I'll pretend to go along but I really hope that it fails and that they fall flat on their face." At the point where we say commit, we are wholeheartedly behind that chosen plan.

How we succeed

So let's talk about some other principles of how we succeed. We're gonna talk about "Day 1 thinking," we're gonna talk about narratives and press releases and peculiarities. We are very willing to share all of these. I was talking to my manager a couple months ago. He said, "We love to share these. We think if more organizations were run on principle basis we think the world would be just a little bit better place." So take our principles, take our mechanisms, use them as is or subclass them, take them and customize them a little bit, make them even better. So this is all open and available for you to use and innovate from. Let's talk about what's called…

Day 1 thinking

A couple years ago at an annual meeting one of my colleagues asked Jeff—and Jeff's always open to questions—they really innocently said, "Well, Jeff, what does day 2 look like?" So he's been telling all of us for years and years he says, "We're a 'Day 1' company. Always think that it's still Day 1." In fact, the building in my previous picture, that's one of our buildings in Seattle called the "Day 1" building. And so they said, "Jeff, what would 'Day 2' be?" And Jeff being Jeff had a great answer he said, "It is stasis. Followed by irrelevance. Followed by excruciating painful decline," which sounds really really painful, "followed by death." And he said that is why it's still "Day 1" just as a reminder to us that we don't rest on our laurels, we never stand still, we never say, "You know what we've accomplished all these great things and now we're good enough." We still try to keep ourselves as a "Day 1" organization.

One thing I've noticed is that we're actually starting to build an internal list effectively of signs that we could be maybe transitioning into a "Day 2" company, and we're now setting up internal alarms and monitoring just like you do with any automated system and say if we start to think like this, this is almost a warning sign that says we're heading toward being a "Day 2" company. So we're very conscious of trying to stay nimble, trying to stay agile, moving quickly, staying on that "Day 1", always creating, always innovating.

Some of the principles of being a "Day 1" company: we make decisions quickly. We know that speed matters a lot in business. The disagree and commit principle applies here. I'll talk in a little bit about how we use narratives. One of the things I was presenting to a group of military folks a couple years ago, it turns out this idea of rapid decision making has been studied and codified, it's actually called "Boyd's Law of Iteration." And that the principle there, I think his name is John Boyd he was an Air Force colonel, and he said that the speed of iteration beats the quality of iteration. And the idea is that making a very long series of pretty good decisions is gonna give you a better result than a much shorter series of better decisions. And we practice that quite a bit in our bias for action principle.

Now another aspect of "Day 1," really focusing on innovation. Now a lot of companies when they get to be a certain size, they did their first thing and that got them to a certain level of success and they're not quite sure what to do next. And they start to just kinda say, "Well, let's just invent a bunch of random things and see what happens. Surely something we invent might be of value to somebody somewhere." We don't do that. There's no R&D lab, there's no ivory tower kind of with all of our smart but socially misfit folks put off on the side. We always invent on behalf of our customers. So anytime that you see someone building something brand new, you can go and say, "Hey who are you building this for? What is the customer challenge that you're solving? What actual customers did you talk to?" And they'll say, "Yep I went to this customer, I went here, I talked to these folks, and they told me this, and told me this, and told me this, and my first product I'm building I'm gonna try to hit 50 or 60% of these requirements from this customer." But we're always inventing on behalf of real needs expressed by actual customers.

We're also very very willing to experiment and try things out. Jeff has famously told us that if we're not doing enough experimentation, if we're not failing enough then we're not really trying hard enough, we're not really pushing the boundaries, we're not pushing the limits. We're very very willing to fail. We know that giving everything that we try is going to be some kind of experiment. It's okay if a certain number of things that we try fail—we're gonna do our homework, we're gonna do our planning, we're gonna make sure that we think we're gonna succeed, but we think of every step possibly forward effectively as some kind of an experiment.

The last one, I love this one, being willing to be misunderstood. What this means is that sometimes we're gonna be out there, we're gonna put forth our first offering, our first service, our first product in some new market area. You put it out there and sometimes people look at it they're like, "Hmm. WTF? What's this all about? This just doesn't make any sense. I thought Amazon was this kind of company but now they do this other thing totally weird over here. Doesn't make any sense." Some companies would say, "Wow the world's a bit confused we better go out, we better kind of explain our long-term thinking, and paint the big picture and tell them how this new piece fits in there." We're actually okay with some level of misunderstanding. Now we'd never ever do something to mislead, but we're okay with putting the products out there, letting the new products actually speak for themselves.

If you think back to when we first launched AWS, the very first AWS service, somebody out there probably knows it, anybody know the very first service? SQS was the first service that we launched. We launched SQS, at that point most of the world thinks of Amazon as their bookstore. So your bookstore launches a message queuing service. Kind of bizarre. We could've gone out and we could've said, "Well, rest assured that we have big plan and we're gonna do this and this and this and we're leading off into the brave new world of the cloud." We're okay, we put SQS out there. Here's a message queuing service, here's the API's, here's some suggestions for how to use it, here's the prices. Let the world figure it out for itself.

Or when we launched the first Alexa Echo devices, we had an internal belief. We thought that a voice operated device would be a pretty powerful thing. We had great ideas for the long-term future of where Alexa and Echo could go. When we launched that first device, I like to think of it as basically the talking Coke can, we launched the talking Coke can we didn't have to lay out that big vision. We simply said, "Here's the service, here's the product, if you like it, great, if not, well it's just there for you." So that willingness to be misunderstood, is a fundamentally important part of our culture.

Now I'm gonna talk to you just about two different documents and two different things that we create that helps us to drive our business. The first kinda document we create is called a…

Narrative

A narrative always has to be six pages, identify the customers, identify the problem to be solved, a time-frame to deliver a solution. With that narrative, you need to say, "This is what I wanna do. This is the value of what I wanna do." And the idea is, you're gonna use this narrative to actually make a decision happen. It's not a position paper, it's not just kinda something that gets floated around from inbox to inbox to inbox and people like, "Yeah, maybe, kinda, sort of." The narrative document is there to help us make a decision. If you own a narrative, you're gonna put probably weeks of part-time effort into writing this document. Maybe making it super super super good and super polished. So you're gonna do your research, you're gonna write an awesome narrative.

You get six pages—with reasonable fonts, reasonable margins. You can have some supporting data in your appendices, but you really can't count on your audience to read them. And then you actually want to make the decision happen. So you identify the decision makers, you invite them all to a one hour meeting. And that's when things get a little bit unique. You don't printed copies of your narrative ahead of time. You don't email, you don't lobby people to say, "Hey, I'm bringing this narrative, please support it." You simply show up, you bring printed copies for everybody in the room, and then the first 20, 25 minutes of that meeting is silent reading time. Like you probably had in elementary school. It's everybody sitting there reading the narrative quietly, making some notes in the margin, forming their thoughts, forming their opinions, figuring out what questions they might want to ask.

At the point when it's clear everybody has thoroughly absorbed the document, were not skimmers, were deep readers, we're going to discuss, we're going to dissect. The absolute goal of that meeting is to walk away with a solid commitment to either move forward or not move forward with that actual narrative. The other kind of document we write is called a…

Press release

We actually augment this with, we put a FAQ, a Frequently Asked Questions just at the end. So, the most common document that I get sent when I'm working on a blog post is called a PRFAQ: a Press Release FAQ. The idea of a press release, is we're going to start from a customer and work backward.

The reason we do press releases rather than blog posts: A press release is a very constrained form of communication. Take a press release and cover over all the boiler plate parts of a press release, the blah, blah, blah parts that don't actually convey any information. You'll find you really only have a couple of sentences, a few paragraphs to really convey the essence of what you're doing. So the idea of a press release is to have us be very expressive, very frugal with our words, and to make sure that we know exactly what it is that we're building.

Before we have written any code, before we've hired the full team, before we have any kind of architecture, the owner of that product they are going to invest their energy building a press release. The idea is you build this as if it's the first thing the customer is going to see. So you write the press release first, you iterate until it's really awesome. I've seen press releases with versions up in the 10's, 20's, and 30's sometimes, before we get it really, really right.

The press release is—by our internal process—is always the way that we build something new. Now we do this always for anything that we launch externally, but I've seen them used internally as well. When we've done a big network upgrade of some of our AWS regions, when we've figured out a way to make some part of AWS run more reliably and more efficiently. We'll even issue an internal press release to really summarize and to keep us in this model of building these really, really important documents.

So we're always going to have a title, we're going to summarize the product, we're going to talk about the problem it solves. We often go out to real world, trusted customers, and we say, "This is what we're building. If we were to build that, what might you tell us about it that we could actually include in a press release?" So our trusted customers actually have access to our press releases, and we will then get their input, we'll seek their input and get actual real world quotes from those customers in the process of putting the press release together.

So like any press release, you get about a page and a quarter, a page and a half to really express all this. That constraint on your thinking really helps you to make sure that you use the exact, precise, minimal set of words that you need to convey that information. We highly value written communication at Amazon.

The press release: limited space. Behind it is the FAQ, and the idea is that we're going to take the press release, and then the first part of the FAQ is the publicly shareable questions. At the point when we've gone from the press release, we've actually built the product, we're ready to launch it, we're going to take the press release, and that public FAQ and publish them essentially as is. So before we've built anything, we're making sure that we know how to properly launch the thing that we would like to build.

Occasionally, I'll talk to teams and before they were at the point of having a press release, they'll say, "Yeah, we're working on this thing, and we're working on the press release." Then I don't hear from them for a bit. I say, "Whatever happened?" And they said, "Well, we never actually converged on a press release that really could convey what it is that we wanted to do. We realized we didn't really know what we wanted to do, so we're not actually moving forward until we have a press release. This is a gating aspect of our launch process.

The FAQ might be anywhere from 10… I've seen up to 50 printed pages worth of questions. All the things a customer is going to ask. We'd like to get all those things figured out very, very early in the process. And then, the internal part are the questions that make sense to us internally that we want to make sure that we share that information, but probably don't make any sense for our customers, so we don't publish that part of the FAQ.

When a team is getting ready to launch, and they want me to write a blog post, they know that the thing that they always do, they simply create a ticket in our ticket system. They attach the PRFAQ, and that one document should give me probably 80+ percent of what I need to do to actually write their blog post.

Peculiarities

We've got some interesting Amazon peculiarities. When we are making decisions, we worry about a model we call, 1-way doors versus 2-way doors. The 1-way doors? We proceed with extreme caution. We know that once we do one of these, we can't undo, we can't revert, we can't go backward. So often, these are the kinds of things that change the direction of the company or the kind of business that we're in.

2-way doors often incremental improvements easily reversed if it turns out that we were experimenting and didn't get it right the first time. We're okay with doing those reversals. We're also okay with 1-way doors. We just want to know if we're walking through a 1-way door. We want to know that we are doing that and that we don't do something that we might regret later—that we are saying, "Well, we're committing something to customers that we can't easily back out from if it turns out to not be the right thing to do." So within our press releases, within the FAQ, there's a question that always says, "Which 1-way doors are you walking through?"

Patience: We like to always learn from our failures. If we make a big mistake, that's okay. We're going to dissect it, we're going to figure out why we failed, and what we didn't understand, and hopefully try again somewhat smarter the second time around.

We talked about willing to be misunderstood. Being peculiar, we do some wacky stuff at the company from time to time. And it all works.

Results

A couple numbers here, I just pulled off a couple of these interesting numbers. We've got almost 600,000 employees. We have got 100 million subscribers to Prime. Echo is now well known AI powered hardware. We just actually launched the fourth Go store. I think there's a Go store now here in somewhere in San Francisco.

If you've never been to the Go store, very, very cool. You put an app on your phone, you walk in, you take what you want, you walk out. You're thinking you're a shop lifter, but you've actually just made an effortless purchase.

AWS

We launched it in 2006, it's now a $24 billion business. We launched 1,400 new products and features last year. This actually I found really interesting. I was going through some old slides, and when I launched S3 in 2006, and EC2, my two initial slides. And back then, S3 was 15 cents a gigabyte. It's now 2.3 cents a gigabyte, and then EC2 was 10 cents an instance. The cheapest EC2 instance is now a half of a cent per instance hour.

And the funniest thing, so we put up this other slide, we call this an eye chart slide, because it's actually unreadable. But the funny thing is, if you go really, really close to this, if we take those initial two services, the storage and the compute, those are literally just a couple pixels down here in the bottom left hand corner. There's a little bit of EC2 there, a little bit of S3, so this is the result over 12 years of applying all those principles that I have shared with you.

Anyway, looks like I'm just about out of time. So thanks so much for listening and watching. I hope this was of value to you. I'm going to actually be over at our AWS booth a little bit later today, would love to meet you and chat a little bit about this in person. So thanks a bunch, and enjoy the final day of your conference.