The Away Team Model at Amazon

Image not Found

Product-oriented organizations rely heavily on small cross-functional teams. These teams keep companies fast and nimble. However, I learned firsthand that the faster you grow, the more fragmented and complex your technical and organizational dependencies become. And then everything slows down again. Separating dependencies so teams can work independently is one of the most challenging tasks in software delivery. Amazon organizes as a network of separable single-threaded teams and is willing to tolerate, and then eliminate duplication to keep teams independent, but it is not always possible to eliminate all dependencies. Amazon uses the away team model to decouple teams’ roadmaps and avoid inter-team dependencies. The away team model has been critical for many new business launches such as Amazon Wardrobe and Amazon Prime Now.

An away team is a self-sufficient engineering team that works on code owned by another team (the host team) to deliver features they are dependent on. The away team design and releases the needed changes in the host team services. Amazon uses away teams to combat blockages based on the host team’s time or resource constraints.

Type of teamFocusResponsibilities
Away TeamEliminating dependencies with other teamsOwns project plan and deadlines
Fund development including staffing
Host TeamOngoing product workOwns architecture
Maintains service integrity
Defines quality standards

The away team model is overall an IT funding process in which the away teams finance the development of its dependencies to decouple both teams roadmaps. It doesn’t affect ownership. The service ownership remains with the host teams after the away team finishes its changes. The away team model also reflects how Amazon weakly assigns code ownership to service teams.

Weak code ownership: Developers are allowed to change modules owned by other people. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people.

Martin Fowler

Away teams accelerate software delivery by addressing roadmap dependencies

In small organizations, engineers can modify any aspect of the entire system and independently develop, test, and deploy the change. But as organizations grow, engineers’ code intertwines with other engineers’ work, making it difficult for teams to complete their features independently. Ideally, teams can consume extensible services with non or little intervention from the other teams in the company. Sometimes, applications don’t meet these expectations. On other occasions, an initiative requires a new feature on a service they do not own, but the owner team doesn’t consider it a priority. The away team model alleviates these scenarios by empowering teams to extend their dependencies according to their needs.

The most efficient, fastest, and safest way to add features to services is through their host teams. Therefore, away teams should first try to accommodate their requirements within the host team’s roadmap. If they don’t reach an agreement, the away team should own the process of adding the feature, and the host team cannot block the away team regardless of how important, complex, and sensitive the codebase is.

The away team model works best when the host team and away team work together to coordinate, implement, and verify the changes. However, the away team does not need to wait on the host team to make the code changes, and away teams must not require host teams to commit time to support their project, but if possible, the host team should provide advice, documentation, code review, Etc.

After the away team completes its changes, the host team owns code, ongoing support, and maintenance, including support for the use cases built by the away team and any future upgrades of its service (without requiring support from the away team)

away team journey

Engagement rules for away and host teams

Host and away teams should follow a few best practices to implement the away team model successfully. These tenets aspire to keep teams independent.

Away TeamHost Team
SHOULD engage the host team to work together on how best to make the design and code changesMUST NOT block away teams from working in their codebase
MUST NOT require host teams to support their project through advice and documentationSHOULD provide training, documentation, and support to the away team on how to make changes to their codebase (e.g., what they provide to their new hires)
MUST be responsible for their project plans and deadlines, including staffing of the away teamSHOULD help the away team meet its business launch goals, when possible
MUST meet the host team’s code documented quality standardsMAY provide that support for development centers whose time zone is outside of business hours
SHOULD engage host teams in reviewing their code changes. Quality standards MAY include handoff criteria of ownership and support of code changesMUST NOT require that their team members verify that the system quality standards are met
MUST own the code changes made by away teams in their systems

Teams should develop self-service and extensible systems

Our ultimate goal is not to get good at Away Team management, but to reduce Away Teams as much as is healthy by turning them into clients.

Terry Hanold - VP, International Technolog at Amazon

All services teams should aspire to develop hardened self-service and extensible systems. Organizations need to get their services and infrastructure to the place where, like cloud service providers, additional “clients” have minimal impact on a team.

While away teams may, in many cases, be necessary, they are also often inefficient. Working in an away team can be a poor experience for software development engineers due to the coordination and communication overhead. It increases waiting time for alignment with other teams, multiplies rounds of code review approvals, requires reading through undocumented code to add small features, and sometimes wastes time working across time zones meetings.

In conclusion

The away team model is a powerful and flexible mechanism for removing dependencies between teams. However, it should not be the first option for developing necessary changes to a system dependency. Away team work is complex and inefficient. Teams should first try to align features and timeframes with host teams and only resort to the away team model if necessary. If the requested functionality is unique to the away team’s business, it may make sense to decompose the service to enable the away team to own that part.

Finally, when teams keep requesting a host team to use the away team mechanism. We should ask them to consider improving the service architecture to make it self-service and extensible to avoid the constant inefficiency of using the away team model.

I will dive deeper in future posts into how to implement the away team model, combat dependencies, and establish IT funding models to keep the organization nimble. In the meantime, reach out via LinkedIn or Twitter

comments powered by Disqus

You May Also Like