In pioneering the market for cloud computing a decade ago, Andy Jassy, now chief executive of Amazon Web Services, also had to pioneer some new ways of managing.

After all, Amazon.com itself was running on the very same infrastructure of cloud services as the customers to whom he was selling those services. Among other things, as Jassy explains in this interview with SiliconANGLE, AWS had the advantage of being on the inside of one of the large users of cloud computing, giving it the ability to see problems and opportunities first.

So far, Jassy’s management style has paid off. AWS likely will top $13 billion in revenues this year, growing 55 percent a year and accounting for most of Amazon’s profits. In the process, the unit of the retail giant has defined the new world of technology, one in which many or even most information technology products can be bought as online services.

Jassy spoke at length on a recent rare clear November evening at his Seattle home about how Amazon Web Services got this far, how Amazon’s management style keeps it churning out about three new features every day, and what he views as the next frontiers.

The gravel-voiced veteran of Amazon continued the conversation in this second of a three-part series that will run through Thursday. The interview was edited for clarity.

Part 2: Managing at cloud scale

Q: How do you strike a balance between top-down management and decentralized teams like the “two-pizza” teams Jeff Bezos has always liked?

A: Like any company, we have some organizational structure. But we organize into as small and autonomous and as separable teams as we can, that have both the engineers and the non-engineers on that team. We didn’t want the engineers and the product managers pitted against each other. We wanted them to feel like they were on the same team.

The other big benefit we get is that there’s this huge level of ownership across the team for what they’re doing. And one thing that’s different about AWS than a lot of other organizations is that they spend a lot of time with customers who use their service, a lot of time with customers who say they have a need for that service, who aren’t using it. And so they’re constantly collecting signals and feedback from customers on what matters most and testing their theses against what customers are actually telling them matters. Whenever there’s a big argument inside of Amazon or AWS about an initiative, the person whom we believe is representing what customers want most wins the argument.

Q: So it’s a team-based approach, not siloed by department?

A: That’s across Amazon, but it is team by team. For example, our sales team will coordinate across a customer on which services they’re interested in, but they’ll plug in the Kinesis team  and the DynamoDB team and the IoT team. They’ll bring them into a meeting with a customer or calls with customers so they can get that feedback. We have Charlie Bell, who runs basically all the product development, all those AWS core services. He has a number of people who are general managers of these services, and they have high levels of autonomy and ownership.

Q: As a manager, are you a chess player or a gardener?

A: Most leaders of organizations that have any level of success have to do a little bit of both. And as an organization, we make decisions together. It is absolutely not [only] me.

Q: It sounds like you’re planting the crops and letting people tend their own gardens.

A: Yeah, it’s absolutely not me sitting in an ivory tower making the decisions. We’ve built mechanisms that allow us to evaluate, at the right level of detail, what’s happening in the business. The combination of the mechanisms that we look at regularly and the fact that culturally we are very willing to call a spade a spade means that when things aren’t working, we acknowledge them and we don’t try to make excuses for why they’re going to work.

And then we work on how to fix them. If you have a problem and you discover it a few weeks in, it is so much easier to fix than if you discover it six to 12 months down the road.

Also, we double down on things that are working. A lot of companies and organizations get fixated on what’s not working and spend a lot of their resources trying to fix things that aren’t working and forget about the stuff that really is working. And the spaces that we’re interacting with are so large that if you find something that’s working and you can double or triple down on it, it can have a disproportionate impact.

Overindexing on builders

Q: How have you set up the organization to move quickly?

A: Some of it has to do with whom we hire. We over-index on “builders” — specifically people who like to look at customer experiences, figure out what’s wrong with them and reinvent them, and who understand that launch is the starting line, not the finish line. Almost anything great that anybody has built, particularly anything that we have built that’s ever worked, you didn’t roll it out on day one and have them be an overnight success.

The second thing is how we organize. Organizing in these small, autonomous, separable teams that have all the resources they need to deliver quickly allows us to move much faster than I think other teams that have to rely on all these dependencies across lots of teams and all this coordination.

The third thing is that we are incredibly lucky that we get to use the same AWS building blocks and all the services we build that our customers do. One of the least understood stories of the last five years because people get focused on AWS is look at how fast our Amazon retail, consumer, and device businesses have moved. Look at the pace of their innovation building on top of those AWS building blocks.

Q: How do you hire?

A: We want people who are not just customer-focused, not just smart and analytical, but people who both are strategic but who really sweat and like the details. There’s a lot of companies where you’re discouraged from getting into the details. It’s almost beneath leaders. One of the things that Amazon does well is that they have leaders who are both strategic and who really sweat the details.

Q: So it’s big picture and then go deep?

A: Yeah, because I think any of us can fill up all the walls in this room with ideas, but where the rubber really meets the road is how you actually execute. You learn things along the way that you were wrong about or customers tell you about. Being both strategy and sweat the details is key for hiring.

Managing by mechanism

Q:  Is there a success formula for managing the tsunami of product introductions?

I think people who are both strategic and then sweat the details – you really want learning environments. I think that the world changes so fast in all of our spaces that the second you think you’ve got it figured out is the second that things are starting to unwind for you, even if you don’t realize it up front. And so I think we have a really good learning organization. And then I think something that’s really important is having the right mechanisms in place.

Q: What do you mean by mechanisms?

A: If you want something to happen, a lot of times you could say to the team: “Hey, I really think that we should be concerned about X.” And just relying on everybody to be concerned about X is relying on good intentions. Instead, we build mechanisms. Something that allows you to look at the business and look at that area consistently at the right level of detail with the right people in the room.

You can either double down or you can ask questions. Or if you sniff that something looks a little bit off, you have the forum to ask the right questions and to get the right group of people talking about it and course-correcting quickly. I think when you have a lot going on across a lot of dimensions simultaneously, it changes how you have to think about what mechanisms you have.

Q: How do you manage yourself?

A: I always work the week between Christmas and New Year’s, and it’s actually my favorite time of the year to work because very few people are in the office. So I don’t have to be in meetings. I spend almost an entire day just thinking about the mechanisms that we use and that I spent time on that prior year, which ones I want to change the frequency of or discontinue or change the format, and which ones I want to add.

Q: So a little self-reflection is important?

A: It is. As leaders as your business is scaled, you have to think about: Where are you going to spend your time? And what are the things that are most important as an organization to get right and which things that you’re going to audit and which things you’re going to ask your leadership team to audit and how that scales.

We have a meeting we run for two hours every Wednesday, which is where we go through all the operation and performance metrics of our platform. These are things like availability, latency, error rates, and things of that sort. And when we first put that mechanism in place, the first year/year and a quarter it was terrible.

Q: How?

A: It was completely ineffective. I did all the talking. The leaders, their services didn’t come prepared to own and manage what they were doing. And we would talk about it constantly as staff: “Why is this mechanism not working?” Over time the leaders learned how to kind of own the areas that they owned and step up and get the data they need.

And now they run it. I rarely have to say anything in that mechanism, and it’s an incredibly effective mechanism. We have probably about 250-300 people in that meeting every week. As a leadership team it gives us a great opportunity to model what we think matters and what we think doesn’t matter, what’s good performance, what’s not acceptable, what are the standards we expect.

Read Part 1 from Tuesday: Charting the cloud landscape and the emergence of the enterprise cloud.

Thursday: AWS’s innovation strategy and the next big hill.

Photo by Seth MacMillan/SiliconANGLE