Want to innovate like Amazon? Here’s their formula

You can’t escape Amazon in the digital economy. Now a trillion-dollar company, they have disrupted diverse sectors from retail to software development with a deftness and drive that’s admirable and alarming. They actually seem to be speeding up their rate of innovation as they scale, defying the Law of Large Companies that causes giants to get dragged down by their own girth.

How do they manage that?

A week ago at the MIT Platform Strategy Summit, Dirk Didascalou, vice president of IoT at Amazon Web Services (AWS), laid out their approach to innovating at scale. It was a 30-minute talk that I think everyone in martech could have appreciated.

As a low fidelity substitute, I’ll share my notes and a few photos of his slides.

At a high level, Amazon champions three overarching principles in their culture:

• Customer obsession rather than competitor focus
• Builders and pioneers with a willingness to fail
• Focus on the long-term rather than the short term

Now, the cynics skeptics among you might be saying, “Really? That’s their alchemic formula for world domination? Because it kind of sounds like what a ton of other companies have said for years.”

And that’s exactly the point. Many companies say things like this. Not enough actually behave that way. Amazon is relentless with these principles, and that makes all the difference. It’s the difference between simply texting someone a heart emoji and being truly, deeply, madly in love.

Still, those are rather lofty values. How do they operationalize them?

Dirk presented their approach as a function of four factors (sketched at the top of this post), and he then drilled into concrete elements for each:

1. Architecture — Create a structure that supports rapid growth and change
2. Organization — Let small and empowered teams own what they create
3. Mechanisms — Encode behaviors into our DNA that facilitate innovative thinking
4. Culture — Hire builders, let them build, support them with a belief system

He had a summary slide for each, which I took photos of (you can click on them below to read a larger version).

Architecture: Structure for Rapid Growth & Change

One of the key architecture decisions was Jeff Bezos’ (in)famous API mandate, demanding that every software team across Amazon build their apps as services that would expose their data and functionality to other teams via APIs. (“Anyone who doesn’t do this will be fired. Thank you. Have a nice day!”)

Not all of these APIs were made available to the outside world, although they were supposed to be designed as if they were going to be published externally. It’s hard not to see this as the genesis of many AWS services.

The benefit of this “microservices” architecture across the company was that every team could move quickly to build their own pieces without having to coordinate deeply with other teams. They could use their own databases, their own tech stacks, their own internal design. But they had to make an API available for other teams to consume their work without knowing anything about those internals.

Teams could then leverage each other’s services and data via their respective APIs in their own projects, quickly and easily, without getting bogged down in cross-team design meetings. It was fast, flexible, reusable, and “loosely coupled” — the internals of these services could evolve as long as they maintained their outward-facing API.

With the evolution of microservices and “serverless” functions in marketing technology, this is an increasingly common pattern in marketing ops.

One other architectural point that Dirk made was “two is better than zero.”

It means that, yes, with highly distributed teams working in parallel, it’s entirely likely that two teams might inadvertently build the same thing (or close to it).

And… (drum roll)… That. Is. Okay.

It’s much better to have a couple of fast-moving teams duplicate effort than to have both of those teams lose days or weeks or months negotiating a common solution before either of them actually starts building. It completely sidesteps bottlenecked committee meetings at the cost of a little redundancy. If necessary, the two projects can be merged or one can conquer the other over time. But since the odds of both succeeding are low — Amazon encourages bold experiments that often fail — it’s better to just let them each run fast and see which one, if any, succeeds.

If both succeed wildly and then you have to disambiguate, that’s considered a small price to pay in the context of overall victory.

For those of you who were horrified about my laissez-faire approach to some redundancy in technologies as part of a rational approach to martech stack utilization or an “agile” approach to trying new martech products (at least those with relatively low risk and few dependencies), I’d humbly suggest that Amazon’s “two is better than zero” architectural principle is born of this same philosophy. It seems to have worked pretty well for them.

Organization: Small, Empowered Teams

Two-pizza teams are one of the Amazon memes you’ve probably heard of before: teams should be small enough that you can feed the entire team with two large pizzas. That’s about 6-8 people, depending on how much they each like pizza. (Some of you might be rounding that down to 2-4 people, but that’s more a statement about your love of pizza than the effective upper limit of an agile team.)

Why keep teams small? There are several good reasons:

• It’s easy for small teams to have full, open communication with each other. As teams grow, the number of links between people — different pairs of who talks with who — grows exponentially by n(n-1)/2, where n is the number of people on the team. So a team of 6 people has 6(5)/2 = 15 connections. A team of 40 has 40(39)/2 = 780. Small teams are highly coordinated but have low coordination overhead.
• Small teams are inherently limited in how big of a project they can undertake at one time — and that’s a good thing. Big, grandiose projects can grow out of control before they ever ship into the real world. Small teams are more likely to take an iterative, incremental approach, if only out of necessity, which is actually a great agile practice for adapting to feedback and change.
• Small teams can take more pride of ownership. It engenders a start-up mentality. Each individual is inherently a significant contributor to the success of the team. If someone isn’t pulling their weight, it’s going to be obvious.
• Small teams tend to be organizationally flat, there’s not a lot of hierarchy. Leaders of small teams are connected with the ground truth of what’s happening on the team, and they can provide hands-on support for nearly every aspect of the work under their mantle.
• Small teams can make decisions fast.

Amazon aggressively leans into that last point of ownership by insisting that teams have to take responsibility for operating the things they build. They can’t just build them and then throw them over the wall to some other operations group. For better or worse, the team “owns” the decisions they make in their design and implementation and has to deal with the consequences. Surprise, surprises, teams learn to make smart operational choices.

As a result, you want really good people on your team. Amazon has coded “raising the bar” into their hiring practices with a principle that everyone they hire should be better than 50% of the people they currently have.

Now, you may be reading this and thinking, “Crikey, a proliferation of small teams, each taking ownership of their own work, like a loose consortium of start-ups, all constantly raising the bar by hiring better people… there’s no way that this is scalable.” If so, then take a deep breath and remember that this is a trillion-dollar company we’re talking about.

If that’s not operating at scale, I don’t know what is.

Mechanisms: Encoding Behaviors into Operational DNA

Amazon has developed some quirky rituals for building products. But effective ones. They call these “mechanisms” that encode behaviors central to their culture.

One of them is the “press release.” No, Amazon didn’t invent the press release. But teams will write a simulated press release and accompanying FAQ — what questions would reporters and customers ask about it — as a way to tell/sell the story of what they’re going to build before they start building it. Often, these press releases are required to even get funding or the green light to undertake a project.

The principle that they’re aiming to embed through this mechanism is keeping the focus on what matters to the customer. Forget the internal rationale and techy jargon. If you can explain why you’re building something in a way that would be compelling to a prospective customer — and answer all the questions they’d likely have about it — then you’ve got a good justification for what you’re planning to create.

Amazon refers to this process as “working backwards from what the customer truly needs.”

It’s part of how they keep customer obsession at the forefront of the work they’re doing, even for software development teams that could easily lose touch with real customers.

Another mechanism they use to keep the customer in everyone’s minds is to have an empty chair in meetings, where everyone is encouraged to picture an actual customer sitting there. What would that customer think about their decisions? What would they ask?

(Hey, I did preface this section by labeling these practices as “quirky rituals.”)

In general, Amazon prefers written narratives — like the anticipated press release and FAQ — over PowerPoint presentations for internal decision-making. Another mechanism they use is the “six-page memo.” Before going into a meeting to make a product decision, the champion of that meeting will write a six-page essay that articulates their ideas. Everyone spends the first 30 minutes of the meeting silently reading and thinking about the memo, and then they discuss it.

Quirky, yes, but effective. The memo format forces the author to really think through their ideas and be able to crisply explain and justify them. The time spent reading the memo together forces everyone in the meeting to really absorb those ideas before they start discussing them. It avoids a lot of rambling and gets everyone focused on the real meat of the decision.

In addition to those mechanisms, which generally happen in advance of work being done, Amazon also has a well-defined mechanism for addressing problems and quality control issues that happen further down the road. They apply a Correction of Error (COE) process to analyze root causes and establish what will be done to prevent those issues in the future. The leader/team must answer:

• What happened?
• What was the impact on customers and your business?
• What was the root cause?
• What data do you have to support this?
• What were the critical implications, especially security?
• What lessons did you learn?
• What corrective actions are you taking to prevent this from happening again?

Errors happen, especially in a culture that is driven to move fast and try bold ideas. The COE is Amazon’s mechanism to make sure that errors are addressed in a thorough and consistent fashion — and that the same mistake doesn’t happen twice.

Culture: Hire Builders & Let Them Build

Dirk’s slide about culture was dedicated almost entirely to Amazon’s commitment to hiring “builders” and letting them build things (within the context of a shared belief system). They seek out coders and thinkers who love to experiment and get things done.

Many of the principles that Dirk described and that I’ve shared in this article are about empowering those builders to go build things with the minimum amount of overhead or big company red tape as possible. Again, if you’re dubious about the scalability of this philosophy, just keep remembering that Amazon is one heck of a scaled company. One could almost infer that perhaps these approaches are essential to scaling in today’s environment.

But still, how does Amazon get comfortable with so many semi-independent teams making so many decisions that can impact the company in so many different ways?

Part of it is recognizing that not all decisions are equal.

One last piece of wisdom that Dirk shared was that Amazon thinks differently about “two-way doors” vs. one-way doors. A lot of decisions are “two-way doors” in the sense that they’re reversible. If it doesn’t work out, it’s possible to walk it back. For these kinds of decisions, teams can be pretty agile and make many of these calls on their own. Risk is limited.

It’s really only big, one-way, irreversible decisions that should receive a lot of attention and debate. Once the company walks through a door like that, they can’t easily go back.

I took a lot of inspiration from Dirk’s talk. I hope you’ve found some of this inspiring too.

P.S. If the intersection of marketing, platform thinking, and innovation is exciting to you — I hope it is, especially if you’re a marketing operations and technology leader — you should join us for the upcoming MarTech conference in Boston, September 16-18. My opening keynote, Platforming Marketing: Marketing Operations as an Organizational Platform, will address the same overarching theme as this article: how do you innovate marketing at speed and scale?