Get best of the week

How Amazon is organized

Like many other U.S. companies, Amazon’s workflow organization is built on basic principles whose main purpose is to help employees make the right decision based on the company's values. We talked with a product manager at Amazon, who talked about what principles the company follows, how they help with tasks, and what processes the team goes through when developing a new product. Below we left a link to a video with a full interview.

Amazon Mission, Vision and Principles


In my understanding, the mission of Amazon is to be the most customer-oriented company in the world. All products that the corporation is working on are developed with the aim of first making the product for the customer, and then increasing their sales.

There are 14 principles that a company lives in and they are used in all work processes. These principles are quite basic, they are nothing special. They are guided by the launch of a new product, during interviews, or when giving feedback to a colleague. They are not forced to memorize, but when you work in a company, if you want, you don’t want, you start to follow these principles.

Many of them go apart with each other. For example, like Think Big and Bias for Action. One says, “Think globally,” and the other says, “Act, not plan.” In fact, there are many such principles that conflict with each other. But this is the whole point. If employees were fixated on the Think Big principle, then everyone would stretch the deadlines. And if only Bias for Action were adhered to, they would quickly carry out small projects and not think about large ones.

Many say Amazon culture is more demanding. People come here to work, study and develop. And when they get tired, go to Microsoft.

This is because Amazon is a more dynamic, fast-growing company. We are trying to grow in different directions. But the business model of Boeing and Microsoft has not changed for many years. Google has the same thing: the search engine remains their main source of income.

Amazon is encouraged to constantly generate new ideas. There are always a lot of projects in the development process. When work on one product ends, immediately everyone switches to another. And at the same time, high goals for each project are always set within departments.



Product development process


The first thing you must do before setting the task is to test the hypothesis. For this, MVP or MLP is used. Based on these concepts, a large document is compiled, which is then considered by the whole team. Two things should be highlighted in the document:

How will the project resolve the issue of clients? The document has 1 page in order to succinctly explain the idea and convey its value.

What questions can consumers ask about the product? And technical questions: how will we monetize? Where to buy technical equipment? Who will be the contractor? Everything should be described in the document in the format of questions and answers.

If we understand that everyone liked the idea, it goes into development. The product manager compiles a list of requirements, breaking them down at the Agile release stage. Everything is organized in such a way in order to step by step test one thing and get feedback.

The most important thing in the team is not to wait for instructions. If you come to the head with some kind of problem, then you should already have a solution. And the manager can only give feedback - whether you found a good solution or not.

The team always has a schedule for the days when it will be completed. Every week, employees gather to discuss tasks. We show them on a dashboard with the statuses - green, yellow and red.

Green means that everything is fine, attention to the task is not required. Yellow - something went wrong, but we know how to fix it. For example, they planned to finish the project by May 1, but there was a problem that we will try to solve by May 1. And red - something went wrong, and we do not yet know how to meet the deadlines.

After that, each developer shows demos with the work done. During such meetings, the product manager has the opportunity to give feedback and change the path of the task. For the rest - the opportunity to ask colleagues for advice, if it is not clear how to solve one of the problems. Weekly team reports support the Agile culture when everyone is trying to release something for release, rather than pulling with it for a whole year.

When the project is ready, it is approved by the product manager and sent to the next stage - testing. The company has internal testers who check whether the feature breaks, and a group of beta testers, who in turn give their feedback. After their tests, development is released in a couple of days. And this is where the work on the task ends.



Organization of work processes in the company


Scrum - a method of prioritizing tasks for the next 2-3 weeks - for a sprint.

Sprint - this is such a short run in which you say: “Okay, next two weeks we will do these 10 tasks. And we will work only on them and nothing else. ” This has its pros and cons. On the one hand, you are not distracted by other tasks. But you have to constantly make additions, and they are going to sprint quite a lot.

There is no such thing in programming that you just sat down and started writing code. First, the product manager collects all the requirements, describes the functions of the new product. Then everything goes to design. Programmers sit down and describe what they will need to do based on the requirements, for example, integrate with the system, make a specific framework, etc. The third stage is the code in progress, where the employee is already sitting down and starting to write code. Then testing. And the last stage is the release.

And here Kanban is a methodology in which you set limits for each stage. A group of “requirements” cannot have more than 3 functions. Until I transfer any of the requirements to the design, I cannot add new tasks.

That is, the flow of tasks is regulated. If you have more developers, you can expand the tasks. The advantages of the methodology is that it is flexible. Minus - prioritization can constantly change unlike Scrum. At any time, you can include a task that had not existed before.

Both approaches relate to the Agile methodology. Its meaning is that you always break a large release into small pieces and release them as often as possible so as not to do what the user does not need.

In Scrum, we evaluate each task in points. You can’t measure them with anything, it’s more a relative value. For example, a task is 4 points more than the task estimated at 2. Such points allow you to see how much the developer has closed his task.
At Kanban, this is more complicated.

Our other rule is to take only 3 tasks into work. If the team has 10 developers, then everyone is working on these tasks, no one can take a new one. Because if each developer takes on one task, which takes 2 months of development time, then there will be only 2 releases per month, respectively.

That is why there are restrictions on at least 3 tasks, each of which has 3 developers. Moreover, if someone is released, then he can not take on a new project. He should help colleagues complete the rest of the tasks set for the sprint. And only after the project went into release, you can take new tasks.

More articles:


All Articles