Member-only story
Your Team Structures Ain’t Working. Let’s Apply Team Topologies
Structuring teams is always tricky. Let’s do it right
We want to understand why team structures matter and how to use them most effectively within the bigger picture of software delivery. The book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais explains exactly this. Let’s go over its key insights and how we can apply them.
Team structures can be a divisive issue. There have been some big controversies over team types. We’ll look at these first and then we’ll see how Team Topologies can move us beyond arguing about the best team types. Instead, it gives us tools to evaluate and adapt team structures to our situation.
Background: Controversies Over Teams
Let’s understand a couple of the biggest controversies around team structures. We can then return to these later, once we know more about the Team Topologies approach.
Controversy 1: Component teams vs. Feature teams
The classic examples of component teams are a ‘frontend team’ or ‘backend team’ or ‘database team’. These are teams identified by a technology area. Feature teams develop whole areas of functionality within a system, such as the part responsible for bookings or for new customer registration.
We can see feature teams as taking a vertical slice of skills. This means that feature teams often need frontend, backend, and any other skills. A component team is seen as slicing horizontally, so contain skills just for one specialisation, e.g., just frontend.
Usually, component teams get criticised as not aligned for direct customer feedback or aligned to customer value. Not being aligned for feedback is not great for agile. But can we simply do away with all component teams? We’ll return to this controversy later.
