FUNDAMENTALS OF PRODUCT LEADERSHIP: TEAM TOPOLOGY
A product leader’s guide: team topology essentials that empower
Team topology empowers teams, defines the scope of work, shapes the team composition, and sets boundaries
All product teams start somewhere, but when they become more than 15 engineers, communication, empowerment, autonomy, alignment, and decision-making efficiencies drop and the need to split teams and look for more effective team structures, topologies, and ways of working is felt.
It’s the joint responsibility of various leaders across product, design, and engineering to stay on top of team topology and efficiencies. Product leaders should consistently monitor efficiencies, check in with their teams, and evaluate team topology through empowerment, ownership, autonomy, alignment (within the team and with the larger organization), and decision-making.
Team topology is important as it defines and structures:
- Who people work with
- What skill sets are required and how many
- What team members work on
- What dependencies will exist, and
- The nature of their interactions
Any change to team topology needs to be thoroughly contemplated as it can hinder the work and progress of work in individuals and teams
Various changes in factors such as team/business growth, business or product strategy, product lifecycle, technology, business objectives, etc. can result in the need for a change in team topology. Usually, there are clear indications that the team topology needs to change such as:
- A Frequent need to shift developers between teams
- A consistent need for product leaders to resolve conflicts and dependencies
- Growing levels of dependencies
- Lack of team motivation with a narrowed scope of work
- Too much complexity to deal with
When such circumstances arise, it’s best to keep current teams intact and give them new responsibilities to maintain their established relationships and working methods. When making changes to team topology three critical factors need to be considered:
- Empowerment
- Team composition and scope of work
- Proximity
1. Team empowerment
Team topology defines the scope of work and boundaries between teams and is a critical decision that a product leader makes. Therefore rather than taking the path of least resistance that considers current legacy systems, organizational charts, skill set groupings, and business operations, product leaders need to build team structures that optimize for empowerment.
Empowerment can be defined as providing teams with hard problems to solve and giving them the space to find solutions
While there is no single perfect structure and topology for a product team to be termed as “empowered” and many trade-offs need to be made, great product leaders empower teams by balancing the following three interrelated goals when forming teams:
- Ownership
- Autonomy
- Alignment
Ownership
Building teams for a maximal sense of ownership is more than just setting team goals but about setting the scope of each team’s responsibilities across product functionality, experience, quality, performance, and technical debt and holding teams accountable for delivering with excellence on all of them.
Product leaders need to be purposeful when defining a team’s scope of ownership. A narrow one can demotivate teams as they lose connection with the product vision and strategy while too broad of a scope can cause burnout.
A correct level of scope in ownership should meaningfully connect a product team to the large cause including the business and product visions
Furthermore, in addition to a well-defined level of scope, product leaders need to communicate and clarify the scope of ownership with teams. Any ambiguity will undermine and hurt a team’s sense of ownership.
Autonomy
Autonomy is defined as providing teams with enough control so that they solve problems in the best way they see fit through product discovery. This does not mean that empowered teams should have no dependencies nor that they can pursue whatever they please.
However, effective and empowering team topologies minimize intern-team dependencies. For example, a topology based solely on technology subsystems rather than customers creates significant friction with dependencies and the more teams get closer to customers the fewer function and dependencies they experience.
Alignment
By definition, alignment refers to how well product teams track progress with other aspects of their strategic context. In action, when alignment is high, teams have fewer dependencies, make faster decisions, and are connected with business-level outcomes. This means that when alignment is high, teams are empowered.
To maximize alignment, product leaders need to align teams with business and architecture needs:
- Alignment with business: this means how product teams relate to the larger organization, including the various business and functional units and their customer needs, and project pipelines
- Alignment with architecture: since the job of the product architecture is to enable the product vision, product teams aligned with the architecture are also aligned with the product vision which will create meaning and purpose for the teams. However, in organizations with large technical debts and/or debilitating legacy systems, due to the clutter of dependencies and complexities, product teams will fall out of alignment with architecture needs. This can be a massive challenge for product leaders and usually a difficult problem to solve if the C-Suite and senior stakeholders do not have a product culture in mind
2. Team composition and scope of work
While building the correct team composition and scope of work depends on the unique aspects of the business and its context, there are some best practices that product leaders can pay attention to.
Any team topology requires product leaders to pay attention to the architecture and business needs. Hence, both product management and technology leaders need to collaborate and contemplate the correct team composition and scope of activities.
When thinking of team topology, there are two fundamental types of product teams that product leaders need to account for:
- Experience teams: are responsible for how the product value is delivered to and experienced or perceived by users/customers through apps, UIs, and end-to-end journeys
- Platform teams: provide leverage as they allow for various teams to use common and shared services as they are implemented once
Experience teams
Experience teams are either customer-facing, where they directly create value for end users, or customer-enabling, where they provide service for internal use to help deliver another product or service. Depending on the situation and business context, there could be several teams of both customers facing or enabling that work together to deliver the final experience.
Product leaders need to define the scope of work for Experience Teams so that it creates meaning and purpose. Experience teams are most motivated and empowered when they are given as much end-to-end responsibility as possible and this will also help improve the sense of ownership and autonomy.
Experience teams: composition and scope of work
To provide Experience Teams with ample end-to-end responsibility, the scope of ownership for each team should follow other natural paths of the business which most often means aligning teams by customer type or sales channels. Alignment by customer or channel could mean different things for different products, such as:
- At a ridesharing organization, teams are aligned by user personas such as the rider and driver sides of the business (this is the case for most of the marketplaces)
- At an e-commerce business, teams are generally aligned by product or market segments such as electronics or fashion
- At a social networking or media/entertainment company, teams could be aligned by the customer journey such as onboarding or retention
- Other alignments of team topology could include geography, business KPIs, or sales channels such as online, offline, direct, retail, self-service, industry verticals, etc. Such alignments are more common in Enterprise (internal or external) or B2B products.
Such alignment strategies in team topology help ensure that Experience Teams are working on problems that deliver key business outcomes. Furthermore. Furthermore, to ensure the delivery of great products through empowered teams, the team composition:
- Should consider the Product Designers and Engineers as first-class members of the product team rather than an internal agency
- Should build teams of various engineering experts (i.e., frontend, backend, infrastructure, data, etc.) working as a team based on the experience team’s key objectives and strategy as they report to separate managers for technical coaching and training purposes
Platform teams
While platform teams have little interaction with key stakeholders (e.g., customers), they are an important part of the product organization as they contribute immensely to scalability and cost reduction and most often the best engineers and technical staff are assigned to platform teams. While at a startup the number of platform teams can be small, half of the teams in a large product organization can be platform teams.
Examples of platform teams include teams responsible for authentication or authorization, maintaining a library of reusable components or features such as a video player, or providing test automation tools to developers to test and release. Such examples help a product organization develop common services once and reuse them across various products.
Another important role of platform teams is that they help manage complexity and reduce the cognitive load of Experience Teams by concentrating on specialized expertise. For example, a platform team that manages payment processing or a highly specialized financial analysis will allow experience teams to focus on the core of their experience as a priority.
Platforms teams help manage technical complexity, reduce cognitive load for experience teams, and empower them to have product discovery focus, enable scalability, and reduce development costs
Platform teams: composition and scope of work
Due to the nature of platform teams, their contribution is indirectly felt in the organization. To empower platform teams, we need to understand that they have two categories of work that need to be separated from each other:
- Product discovery work: that moves the purpose, vision, mission, and objectives of the product and larger team forward
- KTLO: is ongoing obligatory work that“keeps the lights on” (KTLO) such as critical bug fixes, performance issues, and adding critical capabilities. KTLO may constitute 10–50% of a platform team’s engagement
As long as KTLO is separated from product discovery-related work and acknowledged, then platform teams should feel empowered and with a sense of purpose. To further empower and elevate platform teams by appropriately defining their scope of work:
- We can provide them with shared team objectives to pursue work along with other platform and experience teams, working together to discover and develop solutions. The extent of the collaboration can vary depending on the situation where teams could be a) deeply integrated as one and working on the same task, b) partially integrated, and c) segmented where teams work independently on different tasks that contribute to the overall share goals. No matter the scope of collaboration, it’s critical to have teams understand and share the same strategic context and goals and stay connected through shared business outcomes
- We can treat Platform-as-a-Product where the team sells APIs to users/customers/developers so that they can build on top of those capabilities whether that be for internal or external stakeholders. In such circumstances, the objectives of platform teams should look very similar to those of experience teams such as the number of users/customers, engagement rates, retention rates, etc.
3. Proximity
Due to resource limitations, rarely will a product organization manage to recruit all its staff from the same location of its headquarters — which are usually located in high-cost-of-living locations. Therefore, remote work and alternative options are always on the table.
Options at the disposal of product teams include a) fully remote employees (i.e., fully distributed or decentralized working-proximity model), b) remote offices which carry the benefit of finding local talent with the benefit of working at an office, and c) everyone working in the same office (i.e., collocated or centralized working-proximity model).
When choosing team topology for proximity, the goal of the product leader should be to help optimize for the product team as opposed to optimizing for customers, sales, or managers. To achieve this, product leaders need to consider the following stakeholders and factors and related trade-offs when thinking of proximity:
- Immediate team members. For teams that depend on innovation, co-location will bring significant advantages during product discovery as it will help impactful collaboration among product managers, designers, and technical leads
- Customers. It’s important to have teams close to customers. That is why global brands have local offices with teams to stay on top of consumer trends and their desires. It will be impossible to serve clients in the EU or US when for example the engineering team is fully located in India
- Business Partners. At times product teams need to be close to business partners to discover and develop products, however, they could travel or collocate temporarily to meet up if the proximity does not need to be permanent
- Managers. For managers, it would be ideal to have team members working close to them for reporting and coaching purposes, however, this may not always be the case due to resource limitations and they will need to find workarounds
- Other teams. Swarming is the practice of product teams coming together to solve complex problems. Therefore proximity to other product teams will be needed to help ease collaboration on large and complex problems and needs to be considered based on the product scope and business context
- Senior Executives. Depending on the company’s culture and strengths, senior executives may request to be close to product teams and their requirements should be considered when designing team topology for proximity
Next to read: A product leader’s guide: staffing competent characters
Hope you enjoyed reading this article! :)
If so, then:
- Follow me on Medium
- Become a Medium Member
- Subscribe to hear more
- Let’s connect on LinkedIn
