What are Stream Teams?

Software products are hard to build, particularly as they become successful and grow in complexity. In an ideal world, a single team would be able to manage the development of the product but there is only so much work that a single team can do.

We need to split the responsibility for developing the product across multiple different teams. Every way of splitting teams introduces dependencies, which slow down product development, but some dependencies are worse than others. To minimise dependencies in the flow of work from idea to satisfied customers, we need to identify independent, end-to-end pieces of our product. We call these value-streams. And the teams that are assigned to each value-stream are stream teams. 

While not a perfect analogy the customer journey provides a good way of thinking about how these could be split out.

Why not just call them Product Teams?

The biggest risk of having multiple autonomous teams is that the product lacks direction. We want to give teams autonomy, because without autonomy we lose accountability: “I did my job”. But this introduces an alignment risk.

We need a new team who are responsible for ensuring this alignment. And this time the team is aligned to the full product. So it makes more sense to call this team a Product Team.

The Product team is responsible for creating a compelling product vision, defining the product strategy, designing the boundaries between stream teams, funding stream teams, recruiting and leading people, and defining the systems and processes that empower teams.

I’ve seen a huge amount of confusion from people working in stream teams, but calling them product teams. They believe that they should be doing all of the talks listed above because they are “managing” the product, but in reality they are doing stream team tasks like research, design and delivery.

That’s why we need a new team name.

Conclusion

I’ve borrowed Stream Teams from Team Topologies, and I agree with their reasons for why they didn’t want to use the name Product Team. I believe that it provides a lot more clarity around what each team is actually responsible for.

We love inventing new terms in this industry, almost as much as we love corrupting existing terms. Here’s hoping this one can stick though.