Team Topologies Vs Feature Teams
Feature Teams here is intended as the successful socio-technical software development practice documented in the 2008 paper (*) that was mainstream during 2004รท2012.
Team Topologies here is intended as the set of team structures and interaction modes for software development teams, initially documented in the 2019 book of the same name (**) based on the principle of minimising the cognitive load, and informed by Conway’s Law. It became popular following the rapid growth of cloud computing. In more recent years, the brand Team Topologies has grown and evolved into a broader, non-tech-specific set of ideas.
| Both Feature Teams and Team Topologies describe ways of structuring and organising teams and cross-team collaboration around the work and the codebase, for departments and organisations having multiple teams working together on the same product. |
Many professionals have become affiliated with one or the other, leading to polarised conversations where the two practices are often treated as mutually exclusive opposites. That is far from true.
The superpower of Team Topologies lies in defining a vocabulary for talking about team structures and interactions.
On the other side, the superpower of Feature Teams is its ability to amplify continuous organisational learning beyond the boundaries of over-specialisation, creating resilience and flexibility.
In terms of codebase ownership, Team Topologies mandates a strict team-level exclusive ownership model, where Feature Teams advocates shared codebase ownership. These code ownership models align with modes of re-using code and, more in general, software across teams. So we have:
a) Black-box Reuse: where software is consumed as a closed system (e.g., commercial or internal binaries, or via IaaS/SaaS). Code ownership in this case remains exclusive to the team or the external company providing it (a la Team Topologies and Amazon’s 2-pizza team)
b) Source Code Reuse: where software is shared as internal or external source code. Code Ownership in this case is shared to some degree, granting users rights like autonomously making direct code changes (a la Feature Teams and, somehow, Google’s monorepo), autonomously forking, or at least posting a Pull Request.
These two models coexist in every organisation and codebase since the seminal book The Cathedral and the Bazaar. Their synergy is more prominent than ever, with each approach having its own way of planning, coordinating, and sequencing the work, and flexing the teams’ structure if/when needed.
Conclusions
Instead of pitting Team Topologies against Feature Teams as mutually exclusive opposites, our industry, professionals, and organisations need to have a conversation about:
a) Exploring and understanding the pros and cons of each approach,
b) Identifying when and where in the codebase and its specific context each approach fits well,
c) Finding practical ways to integrate both approaches within a department or an organisation.
This is the topic of my talk:
Team Topologies Vs Feature Teams: polar opposite or points of a continuum?
______________________________________________________
(*) Feature teams’ primer https://featureteams.org/
(**) Team Topologies https://teamtopologies.com/
Turbocharge your scaling initiative.
See how we can help.
You, your team, your organisation.