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.

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.

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. After the away team finishes its changes, the service ownership remains with the host teams. 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 service features 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 the code, the 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)

Teams should develop self-service and extensible systems

All services teams should aspire to develop extensible self-service 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. Due to the coordination and communication overhead, working in an away team can be a poor experience for software development engineers. 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, untangle dependencies, and establish IT funding models to keep the organization nimble. In the meantime, reach out via LinkedIn or Twitter