Amazon Hierarchy


One of my friends recently transited to a startup and was explaining how chaotic their organization was. As a PMM from Microsoft, the lack of a solid management structure was both a blessing and a curse. Without management’s vices, he has been able to ship and create products at an astounded speed. Without management’s guidance and structure, however, many startup employees misalign on vision and conflict on work and ideas.

One of Amazon’s Vice Presidents, Laura, gave a talk late last year and explained Amazon’s hierarchy principals with more clarity. While Amazon does its best to avoid the traditional blogs and pains of bureaucracy, a company cannot get as big as Amazon does without some level of hierarchy. As Laura herself explains, the work life tends to morph as an employee move up from an entry level individual contributor into a manager role, and then finally into a manager of managers. Now, Laura’s day is mostly spent in meetings. She primarily attends 3 types of meetings:
1. Normal business status meetings with directs, such as weekly business reviews and monthly business reviews
2. Strategy or road-blocking meetings to move forward new projects, new processes, or fix areas that are faltering or behind plan
3. Developmental meetings with directs and more (For example, this talk to the RUP class is an example of a developmental meeting)

Individual contributors (ICs) are the employees that do work. As the majority of employees, they spend a smaller portion of their day in meetings, and instead focus on coding, actual execution, analysis, writing, and so forth. Laura believes a successful employee holds fast to Amazon’s leadership principles. While they are all important, she believes the 2 most important leadership principles of a successful individual contributor are first, bias for action, and second, dive deep.

Amazon, by design (and sometimes by accidentally) is is a chaotic place to work. Jeff Bezos had once famously decreed it important to isolate teams to increase innovation and cut down bureaucracy. Because Amazon is also rapidly iterating, launching new processes, and innovating on the business, it is by nature more ambitious and chaotic. Part of the chaos also occurs because of the vast number of products and selection. Items are always moving in and out and around our systems due to automated classifications and offering selections, and many of the individual contributors are responsible for managing it, auditing it, and running a business where a machine can accidentally adjust salable item for the worse. For example, if a product is accidentally put in the wrong classification on the website, customers may have trouble finding it. Sure, this can be fixed one time as a add hoc move, but when you multiply this by several thousand or tens-of-thousands other products, what do you do?

In a chaotic business, it is very, very crucial to identify the signal out of the noise. Valuable and high performing individual contributors will not have an a BI team or analyst that sends a pre-packaged report to him. A successful IC will hopefully be able to dive deep and actually identify the problem. A successful individual contributor can not only find the problem, but have the bias for action and improve processes. Automate, fix, improve.

However, as people transition up into management, it becomes more important to hire and develop the best and earn trust, as responsibilities transition from action to influence. A great manager has the ability to guide and lead a team in a direction. An amazing manager will amplify and empower his/her team’s efforts. When you are managing a team of 5 ICs, it may not be best to spend 95% of your time gathering and analyzing data. It may be best focusing more time addressing your team’s roadblocks, issues, and thoughts so your entire team of 5 will match the productivity of 10 poorly-managed ICs.

As managers manage more ICs, and then start to manage managers, she has found a higher percentage of time is spent in meetings. Communicating the rollout of a feature and the deprecation may be more important than participating in the code-base of yet another new feature. She reads, meets, influences, makes decision, but it has been a while since she has pulled a SQL query herself.

When someone does transfer from an individual contributor into a manger, the transition can sometimes be very drastic. Typical A-type players are accustomed to the norm of controlling everything. Managers lose this privilege, and instead move to a realm of influence. There are 2 common flaws of a new manager. The first is a manager that becomes a bottleneck out of either habit, careless tact, or pity, and withholds information or difficult projects. As a result, employees may be in the dark, may spin their wheels, and the manager itself will become over-worked. The second is a manager who doesn’t have a strong awareness of others’ performance and abilities. A very strong manager will very astute about employees performance, strengths, and weaknesses. Laura claims that a strong leading indicator that someone is ready to be promoted to a manager is their upward feedback about peers’ performance and status. A successful manager will be one who evaluates their employees accurately, delegates all tasks effectively, and mentors each one to grow them and their strengths.

While Amazon is not the perfect role model of hierarchy or organization, having a strong leadership and a management structure that makes sense can make a profound impact on ICs/employees ability to roll out an amazing new product or simply spin their wheels around each other. What is better? It frankly depends on the size and nature of the company. Having this structure at a lighting fast startup may be a self-crippling curse. For example, one of my feature requests was delayed by several months until I was able to present my analysis and projections to a VP and a senior manager. Having a start-up leadership structure (or lack of) at Amazon may hilariously reduce productivity. Take it too far, though, and the bureaucracy may hinder productivity and innovation even more.


I love Adam D’Angelo’s answer that explains his opinion on CEOs coding (acting as a individual contributor).
I generally do not think writing a lot of code as a CEO of a company this size is a good idea. But there are some benefits to writing small amounts and staying in touch with the codebase:

  • It gives you a good understanding of how difficult it is for other people to get things done. This is really important for building intuition about what will be easy vs hard, which then helps you naturally push the company toward doing higher impact projects.
  • It helps you empathize with engineers. Did a project take too long because it fundamentally was just really difficult? Or because people weren’t motivated enough? Or because the wrong people were working on it? It’s possible to get answers to all these questions through other means without having a sense of the code but if you have it, your intuition will be a lot better and conclusions will be more accurate.
  • It helps you draw a conclusion like “we really need to slow down product development a little and make some investments in developer productivity.” In many companies a tradeoff like that just won’t happen. Yes a head of engineering can push for it and a debate can happen but I think companies systematically underinvest in technical infrastructure because the costs and benefits aren’t visible to the CEO.


Leave a Reply