A fascinating article in technology news publication The Register revealed earlier this week the inner workflow of Amazon.
The article, which went off information from several unnamed sources, showed how a massive company such as Amazon can continue to drive innovation and maintain a laser-focus on the customer when the organisation is so complex.
The author argues that the company has adopted a number of well-known principles, some of which are famously associated with Amazon – such as customer obsession – and others like A/B testing and significant use of data.
But he also argues that there a number of unique aspects to the company’s workflow, some of which reflect research done by some leading lights of the “technology philosophy” world.
Before digging into the how, it’s worth considering why it’s necessary for Amazon to work differently.
“Once your engineers and technical staffers number in the hundreds or thousands, the organisation outgrows everything that works at the team level. When the whole mess is in production, some way must be found so those 20, 50, or 100 teams can get help from each other,” the author says.
And though there are existing ways of staying agile, they are generally designed for smaller problems, he argues.
“Agile, Scrum, and DevOps methods keep a specific project humming and evolving from conception to delivery, but they won’t keep the work of a score of teams coordinated.”
The Amazon way
The main differentiator that the author identifies is AWS’s adoption of a practice called ‘Away Teams’. These are teams that basically come in and help out on any projects that need it. They assist what are known as the ‘Home Teams’ – the teams that own any particular project.
Home Teams allegedly stick to the ‘two pizza rule’, which dictates that no teams should be any bigger than five or six people – few enough people that they could be fed by two pizzas (though some might claim they could get through two pizzas on their own), hence the name of the rule.
Those teams take ownership of their work to a fairly immense degree. They are given real autonomy; there is management oversight, of course, but a lot of it is from afar, and if the teams can justify their ways of working with data, then that’s OK.
The company uses a lot of what has previously been referred to as service-oriented architecture, but which it has evolved into ‘service-oriented collaboration’, as The Register calls it.
The latter, the article says, is a “system of optimising internal collaboration by organising development around a collection of independently managed services with a fascinating set of policies for governing it all”.
Collaboration and autonomous teams are commonly-cited methods, to the extent that they may have moved into buzzword territory, but it’s interesting to see what it means in practice for Amazon.
The Register’s research found three key points to this system. First is the team, which as we have already seen has a high level of autonomy. They’re given goals, and have to focus on “value to the customer”, and can make their own way to success.
Next is the development process. There are a number of development tools that can be used, but no hard requirements, the article says. Teams also do not need to worry about use of internal resources, within reason.
Importantly, source code is widely accessible and separate teams can see other teams’ work with little hassle and bureaucracy, it is claimed. There are some exceptions to this, according to The Register, but it is a significant measure.
Finally, the author highlights Amazon’s collaboration practices. As well as the formerly cited Away Teams, which have a number of failsafes and additional processes attached to them, there are also the Bar Raisers.
Bar Raisers are internal, but independent, experts who are employed to check teams’ work and ensure Amazon’s ceaseless quest for perfection continues.
Bar Raisers suggest changes and though team leaders can ignore them, sources say, they have to explain why, with data, if they do.
What it means for everyone else
Obviously, not every company has Amazon’s budget, data analysis toolkit and access to talent. But then, not every company has to deal with the logistics and problems that Amazon does either.
Some commenters note that these principles may be familiar on some level for those who have worked in the open source community, and they are certainly not brand new.
But what Amazon has done is take existing principles, evolved them and itself over time, and come up with a system that lets it serve its own priorities. That’s something every tech team could learn from.