The 4 Major Impacts of Amazon's Decentralization and Ownership Model
Amazon is decentralized and has a strong focus on ownership. This causes various positive and negative impacts. Let's walk through those impacts, and how you can navigate them successfully.
Welcome to the Scarlet Ink newsletter. I’m Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers and tactical leadership advice.
Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you’d like to read more, I’d love you to consider becoming a paid member!
When people ask me what Amazon is like, one of the main features I describe is (funny enough), that the experience of working at Amazon is incredibly individual.
Amazon, as I experienced it, was so decentralized to an extreme that almost anything I would describe could be different depending on where you work in the company.
I’ve repeatedly, to a hilarious level, been told by other Amazon employees that I was lying or wrong about an experience I had. “That would never be allowed, because it’s against Amazon policy.” or “No, that action would require VP approval.”
The issue is that very little (beyond things like RTO, unfortunately) is centralized at Amazon. This decentralization is a core aspect of how Amazon functions. Employee experience, product development processes, promotion processes, funding processes - everything can vary widely based on where exactly you work in the company.
This decentralization is core to the best and worst things about working at Amazon. I’ll go over how (in my experience) Amazon operates, and then get into those positive and negative impacts I mentioned.
Summary of how Amazon operates.
At a high level, Amazon operates like a large venture capital firm. The leadership of the company has billions of dollars, which they invest in various ventures. Some ventures are mature businesses, some are new ideas. It hopes to profit from its investment decisions.
However, instead of investing in external companies, this venture capital model works by investing in internal companies. But that’s not where the interestingness ends.
Each layer of management has (in general, with caveats) ownership over their virtual company. This virtual company functions in a similar way to Amazon overall. They also act like a venture capital firm, investing in small companies under them (or in this case, teams).
The thing being invested at all these layers is generally not actual cash, but headcount, and agreement to pay for other expenses. Things like “Sure, we’ll fund another 50 headcount for that project.” or “Yes, we agree to build two more datacenters there.”
In exchange for this funding, the leaders of these companies (aka teams) agree on a set of goals. Those goals are the results the leadership team expects to get back from these investments.
Essentially: “With those two datacenters, we will be able to handle another $2B in AWS service, leading to X profit.”
This ownership and goal model is the marrow of the ownership principle, and why the word ownership is used so frequently at Amazon. It’s core to how Amazon operates.
Organizational ownership example.
If you are the SVP of Alexa, you own the business of Alexa, the technology of Alexa, defining the long-term plans of Alexa, and the success or failure of the whole shebang.
You have a strong-willed investor managing you (previously Jeff, now Jassy), but for the most part the investor lets you run your company as you see fit.
Now imagine we zoom down five levels deeper into the organizational chart. That’s where we mortals sit.
You are now, in my hypothetical situation, a manager responsible for that cute light ring on top of Echo devices. You report up to the Alexa Echo hardware organization (let’s pretend, I don’t know their org chart at all).
The Echo Ring Light team is your tiny little company in my useful and creative metaphor. This is your business to run. You have a roadmap, goals, technology that you own, and a long-term roadmap of where you are taking this area in the future. You are a part of the Alexa business, and you will play a part in their goals. But you are also a part of the Alexa Echo hardware business, and you will play a part in their goals. And finally, you personally run the Echo Ring Light business. Of course, considering you’re five levels deep in the organizational chart, I’m simplifying matters, because there are many layers of ownership.
Every team / organization deals with the goals and requirements of the leaders above them. So as the leader of the Echo Ring Light team, you would be required to meet a hypothetical Alexa goal (that would be at your SVP’s level) to reduce hardware usage. If the Alexa Partnerships organization (a part of the Alexa team) convinces the Alexa team that it’s important to launch Alexa on smart coffee mugs, you may be required to meet that goal. Because as I was explaining, the investors (leaders) help decide what goals are worth pushing down the stack.
At each level, some number of goals will be pushed to your team, with accompanying funding. Finally, your team would create goals for yourself, depending on what you feel is important for your product. You would assign costs to achieving those goals, generally in the form of headcount (but sometimes in terms of additional hardware if it will be expensive).
This type of ownership continues to some degree from the top of the company down to every single employee. When an entry-level engineer is assigned to “create a report on Echo Ring Light usage” by their manager, they become the owner of that report. They are funded (assigned time) to work on this project. They need to build requirements, discuss their plans with their manager (who, again, is essentially an investor), and then build the report.
The success or failure of their project is expected to be owned completely by that employee. In fact, that’s the core issue that trips up junior employees. Once you join Amazon, even as junior as a college hire, the entire team anxiously waits for that employee to gain enough maturity and experience to properly own things. Because Amazon doesn’t tend to deal well with people who can’t own things end to end.
To be clear, before we get carried away, this is a rough interpretation of how Amazon operates. In general, people wouldn’t call their manager an investor, and we wouldn’t call the OP1 process a venture funding process. But it’s a great way to visualize the thought process behind how Amazon is organized.
That being said, I mentioned getting into the ramifications of this ownership model. So let’s get started with the four major impacts we encounter.
Impact 1: Amazon has junior decision makers.
The expectation at Amazon is that decision-making should go to the lowest possible location in the management chain. This aspect of the ownership culture ensures that the leader closest to the details makes decisions based on those details. One way to think about it is with that venture funding model. Your SVP could be prescriptive and say, “I’m going to fund you 3 engineers to rebuild that Echo Ring Light service to be more scalable.” Except that’d be dumb. Because your SVP has no idea about your architecture, and it’s a horrible waste of time for your SVP to dive into those details. So instead, we assume if you think your service needs to be rebuilt, you’d ask for the headcount to do it. Only the people who care the most about things are the ones who ask for funding.
Goals are written at all levels of management, but how you accomplish those goals tends to be up to the lowest possible level. This means I could theoretically be prescriptive as a senior manager on how to build a service on one of my teams, but Amazon culture dictates that I just leave it up to my teams to figure that stuff out. If I were to stick my nose in, trying to do things my team members could do, other employees would think it was weird micromanagement.
Another way to put that rule? Amazon decision-making goes to the most junior possible employee in the management chain. Right? Because it went to the lowest possible level, that’s simply another way of phrasing it. Which means what?
Positive impacts
At an employee level, this is fantastic for giving you agency and autonomy. You are rarely told how to do your job if you have a good manager. You might know you need to reduce your hardware usage, but it's your job to figure out how to do it. In fact, it’s up to the engineers on an individual team to decide who should work on it, when to work on it, how to measure success, etc. Every employee gets to practice exciting aspects of being a business leader.
You rarely end up in a pointy-haired boss scenario where an uneducated leader tells you to do something nonsensical. Your leaders might ask for the impossible, but at least they let you figure out how to accomplish it. And I’d say that there’s strong organizational support for pushback as well. Because as a part of autonomy and responsibility comes the authority to say, “This just can’t be done” or “Here are the tradeoffs needed to accomplish that.”
Negative impacts
Letting junior people make decisions means junior people making junior mistakes. Tell 1000 entry-level managers to decrease their hardware usage, and you'll have a few decide to throttle all their customers to achieve the goal. Or shut off their services completely. Or they’ll just shut off some servers and be underscaled, and have latency problems when peak traffic hits. When you’re letting large numbers of junior people make expensive decisions, you’re accepting inevitable mistakes.
Knowledge sharing is hard, inefficient, slow, and inconsistent. If you ask those same 1000 entry-level managers to decrease their hardware usage, 200 of them will independently research ideas. Many of them will discover the exact same methods of being efficient. 7 of them will share their ideas in a few mailing lists. 27 of them will tell their peers in the office next door. Another 300 will just ask around and do whatever idea is mentioned to them first. Probably 400 will just let their engineers figure things out. 1 of them will discover a really cool trick and will share it with 25 other people in a private mailing list. Unless people go out of their way to share knowledge, it won’t happen. And even if it’s shared, you end up getting overwhelmed by piles of junior people sharing dozens of ideas.