I’ve noticed that high-performance engineering orgs have a clear preference towards deep-stack product delivery teams. Teams oriented around areas of a product, rather than around tech lines.
But where do you draw these team boundaries? I’ll list a few patterns I’ve seen...
But where do you draw these team boundaries? I’ll list a few patterns I’ve seen...
1/ Lifecycle Teams
Different delivery teams focus on different stages of the user's lifecycle within the product.
For example, an e-comm site might have teams focused on different phases of the shopping experience, from browsing through to purchase and delivery.
Different delivery teams focus on different stages of the user's lifecycle within the product.
For example, an e-comm site might have teams focused on different phases of the shopping experience, from browsing through to purchase and delivery.
2/ Audience Teams
Delivery teams focused on the different audiences (personas) of the product.
A food-delivery app might have a team that serve the needs of food couriers, a team for restaurant workers, a team for hungry consumers, and so on.
Delivery teams focused on the different audiences (personas) of the product.
A food-delivery app might have a team that serve the needs of food couriers, a team for restaurant workers, a team for hungry consumers, and so on.
3/ Product Line Teams
Delivery teams focused on a specific product within a broader product line (for example, different financial products at a fintech), or a coherant set of features within a product.
This one is very common. Spotify were early proponents of this approach.
Delivery teams focused on a specific product within a broader product line (for example, different financial products at a fintech), or a coherant set of features within a product.
This one is very common. Spotify were early proponents of this approach.
4/ Business Capability Teams
These teams own core Business Capabilities - the foundational software services which together form a business platform on which those Product Line teams build their products.
These teams own core Business Capabilities - the foundational software services which together form a business platform on which those Product Line teams build their products.
5/ Platform Teams
By my definition, a Platform Team is a product delivery team focused on providing a defined set of technical capabilities to other product delivery teams within their engineering org.
By my definition, a Platform Team is a product delivery team focused on providing a defined set of technical capabilities to other product delivery teams within their engineering org.
(What exactly constitutes a "platform team" is very vaguely defined, in my experience. I believe a product mindset and a clearly defined set of internal customers is the key to a successful platform team - one that actually delivers useful outcomes to the broader org)
My thanks to the teams I interviewed for my “Continuous Delivery in the Wild” ebook[1]. Those conversations helped me to refine my thinking about these team structures.
[1]: try.split.io/oreilly-contin…
[1]: try.split.io/oreilly-contin…
What do you think?
What product delivery team flavors did I miss? What did I get wrong?
Also, please let me know if you’d like to see these ideas written up in more detail, or perhaps delivered as part of a conference talk.
What product delivery team flavors did I miss? What did I get wrong?
Also, please let me know if you’d like to see these ideas written up in more detail, or perhaps delivered as part of a conference talk.
oh, and if you found these ideas interesting, you‘d probably also find Team Topologies super interesting.
itrevolution.com/team-topologie…
itrevolution.com/team-topologie…
