Architecture Ownership Patterns for Team Topologies. Part 2: Single Team Patterns
The systems we build are composed of many pieces. From mobile apps, to domains, to user journeys. How should we slice up the system and divide responsibilities among teams in our organisation?
This article represented my mental model at the time of writing, but I’m always iterating on it. You can get an idea of how some of my thinking has changed since this post here: https://github.com/NTCoding/prod-domain-biz-arch-building-blocks
In Part 1 of this series, a shared language was proposed to accurately describe different elements of a business’s architecture. We can now start to slice and group those architectural pieces into team-sized chunks and analyse the trade-offs of each pattern, and explore contexts in which they might be applicable.
The third part in this series will look at multi-team ownership patterns, exploring how to distribute cohesive parts of an architecture among groups of collaborating teams.
If your familiar with the Spotify model, this part is about squad-level patterns, and the next part is tribe-level patterns.
Product Ownership Patterns
Taking an outside-in perspective, the following patterns look at splitting up the responsibility of owning the frontend product responsibilities. Later sections of this article look at domain ownership and hybrid patterns.
Product Variant Team
A common pattern is for a single team to own a product variant. A web app, an Android app, or an iOS app for example. It’s a nice pattern which enables a single team to own the entire codebase, user experience, and deployment process.
Multi Product Variant Team
Consistency of user experience and available feature set can suffer when multiple product variants are owned by multiple teams. One solution is for a single team to own multiple product variants. They can then ensure UX consistency and feature parity across all variants.
An example of a multi product variant team is a mobile team which is responsible for the Android and iOS app.
In order to own more of the architecture, a team needs some way to manage the additional effort. Growing the team is an option, but large teams can quickly become problematic. An alternative option is to maximise reuse using technologies like Flutter.
Product Area Team
Many products are too large for a single team to own. Instead, multiple teams each work on a specific area of the product. They are each responsible for a related set of product features.
This pattern can introduce challenges if multiple teams are working in the same codebase and using shared a release pipeline. Also, with this pattern, responsibilities for the user experiences start to fragment across multiple teams which can lead to inconsistencies in the UX if not managed.
An alternative version of this pattern is the Cross-Variant Product Area Team, in which the team owns certain features across multiple product variants.
Journey & Persona Teams
In product-led organisations, everything we do has a strong connection back to the customer’s problems and their experience of our products. It makes a lot of sense to organise teams around specific user journeys or user personas in order to design the optimal end-to-end experience.
The problem with teams owning user journeys, is that user journeys can cut across multiple devices and cut across many product features exceeding the limit of ownership for a single team. However, when a small user journey is limited to a single product variant and touches on a group of closely related features, there is a possible 1:1 team-sized mapping between a user journey and a product area.
The topic of user journeys and aligning teams to user journeys requires more coverage than this. There are a lot of variations and scenarios to consider.
Domain Ownership Patterns
The following patterns can be useful after you have identified boundaries in your domain.
Domain Team
One team may own an entire domain. For example, the Reviews Team may own all system responsibilities that require collecting music from record labels.
A caveat of domains is that they are a fuzzy and hierarchical concept, and they contain no sizing guidelines. If your domains are too granular, you don’t have an easy way to describe a group of related domains (we can use the concept of levels but I’d avoid that to begin with). Therefore, use domains as a higher-level container to group related subdomains. The following patterns give some guidance on subdomain sizing.
Single Subdomain Team
Some subdomains are so large that it requires the full dedication of a single team to develop, maintain and support them. A subdomain should ideally never be larger than a single team to ensure teams have autonomy and ownership of their work.
A single subdomain team is a convenient team that allows a single to focus and specialise all in one are of the system. One piece of advice I would offer is to avoid specifically sizing subdomains for teams. I.e. don’t group parts of the domain that should logically be decoupled just because it’s convenient for a single team.
If two parts of the domain look closely related, but have indicators that they are unique in some way, consider modelling them as multiple subdomains. A single team can still own all of them, yet they will be more loosely coupled offering greater future flexibility.
Subdomain Group Team
A Subdomain group team owns a collection of closely-related subdomains which belong to the same domain. Subdomains which are closely related and part of the same domain share some of their domain concepts or contain adjacent steps in a business process.
An example subdomain group team is a Search & Catalogue Team which owns the search and catalogue subdomains which are both part of the content discovery domain in the business architecture.
A subdomain group team is a desirable pattern because the team can become experts in a specific domain and stay fully focused on it. They aren’t context switching between different subdomains which are drastically different in nature.
Bits-n-Bobs Team
The Bits-n-Bobs Team is how I label a team that own a bunch of parts of the system that have little to no relationship to each other. It feels like the team has just become a dumping ground for things that nobody else wants to own. Usually a Bits-n-Bobs team has a generic name because it’s difficult to summarise their purpose using domain terminology.
Often the Bits-n-Bobs team is not one of the most enjoyable teams to work on. But it’s not always a bad place. If the subdomains are interesting and the context switching costs are reasonable, it can be enjoyable for a team to work in disparate parts of the system.
A Bits-n-Bobs team can contain non-domain responsibilities too like parts of the UI.
Integrations Team
One of the dubious is the Integrations Team. The Integrations Team is responsible for connecting systems together, often internal systems with external systems.
The reason I think this pattern is a little dubious, is that there is often very little similarity between the different types of integration. The team works on the edges of multiple domains which makes it hard for them to gain the required domain knowledge in any of them.
I wouldn’t call an integrations team an anti-pattern, it’s not inherently bad. I would advise carefully exploring multiple possibilities before settling on this solution.
End-to-End Ownership
It is possible, and common, for teams to own product parts and domain parts. These teams are referred to as end-to-end teams, full stack teams, or Self Contained Systems (SCS).
The benefit of end-to-end ownership is the elimination of handovers between frontend and backend teams solving different parts of the same puzzle.
End-to-end ownership is characterised by teams owning the external presentation and internal mechanics of a specific domain capability. There is cohesiveness between the frontend and backend elements these teams own. For example, a recommendations team may own all of the domain rules and logic for creating recommendations and a micro-fronted UI component that displays recommendations on the company’s homepage (Amazon style).
Some end-to-end teams are responsible for both user-facing product features and internal-facing product features like admin consoles. Check the Reviews team in the Org Design for Design Orgs example later in this article.
Wide vs Deep Ownership
A product variant team may have many dependencies on domain teams. Each feature in the app that requires information and/or services from the domain will be a social and technical dependency.
So the obvious questions arises: if end-to-end teams remove the frontend-backend dependency, why not make all teams end-to-end teams to remove all of the social and technical dependencies?
End-to-end teams are widely applicable. In general, I think they are under-utilised. I don’t believe they are a silver bullet, though. It’s important to consider some of the trade-offs:
- The user experience is shared by multiple teams. This increases the chances of an inconsistent, fragmented user experience.
- Team members need to learn and keep up to date with a wider range of technologies. This adds to their cognitive load. However, some frameworks cover frontend and backend minimising the range of skills required.
- Many people want to specialise in frontend, mobile, or backend and may not enjoy this arrangement.
- Teams have a limited amount of cognitive load. If teams own a deeper slice (UI and domain) they must reduce the width by owning less of the domain or less of the UI. This can increase the chance of horizontal dependencies (new work spanning multiple parts of the UI and or subdomains).
- End-to-end teams may really stretch individuals if there are many product variants they have to support (e.g. web, Android, iOS…)
Solving the UX Issue
Dedicated frontend teams aren’t the only solution to reducing the risk of fragment user experiences. Look into design systems and micro-frontends for technical solutions, and consider social solutions, too like communities of practice and dynamic reteaming.
In Org Design for Design Orgs, Peter Merholz and Kristin Skinner propose creating dedicated design teams focused in the end-to-end UX in addition to autonomous development teams who own deep slices. To avoid handovers between design and development, they suggest having designers associated with a specific team.
Many More Patterns and Insights Out There…
There are many more patterns, nuances, and trade-offs than those discussed in this article. There’s plenty still to think about. How about a team that owns a product bundle delivered as a single mobile application?
The goal of this series is to start the conversation rather than to end it. Feel free to leave a comment adding links to other patterns, your personal insights, or your favourite case studies.
In the next part we’ll take a look at organising teams into groups working on closely related parts of the system and assigning responsibilities among them. We’ll explore the trade-offs and again look at social and technical solutions for maximising autonomy and preserving alignment.
