Team topologies series: How ordinary people create extraordinary products

There are many different ways of organizing a company's team topology. Surely, not many organizations start from scratch without technical debt, and a bunch of product people, ready to be organized into new structures to create business value. Product development, and therefore teams, evolve over time and their structures and dependencies evolve with them. A critical question to ask when working on the typology of product teams is; how should the company organize its product people into teams to best enable them to do great work? One main principle should be the leading star in this work; Empowerment. When optimizing for empowerment there are 3 important goals that need to be balanced: 

1. Ownership 
2. Autonomy
3. Alignment  
    

1. Ownership 

Having a large scope of responsibilities around functionality, experience, quality, performance and technical debt naturally creates a need for trade-offs to best address the mandate to fit a team's scope of ownership. In most cases a larger scope of ownership is better for empowerment, though empowerment can suffer when the scope of responsibility is too broad for a team's size and skill set. Empowerment depends on the scope and clarity of ownership. When teams are unclear regarding which work applies to them, empowerment is undermined. A team that sees themselves as responsible for a meaningful problem is motivated by their connection to a larger cause, and takes more pride in ownership. With a narrow scope of responsibility, members of the team might find it hard to stay motivated. It may be difficult to understand how their contribution relates to the larger business goals, feeling like just a small cog in a big wheel, which is far from inspiring. 

Empowerment improves when all product teams have something meaningful that they are responsible for. There might be cases where the ownership of work is too ambitious. To support empowerment it is better to have a larger scope, and to be forced to prioritize, rather than a narrow scope without understanding what the team is contributing towards. A good topology should therefore resolve more ownership questions than it raises. 


2. Autonomy

Autonomy in product teams is often misunderstood as a concept within digital product development. It does not mean that teams should never have dependencies on other product teams or that the team is allowed to go ahead in whatever direction they like.

Autonomy means that when given problems to solve, the team has enough control that they can solve the problem in the best possible way. A team topology that results in too many dependencies to be able to solve the problem, is one that that hinders teams' autonomy. Teams given issues to solve are expected to use tools of product discovery to explore different options and approaches to the issue before coming up with a solution. When providing a solution, that solution is created by the team as a whole with the competences the team has at that given moment. It is then up to the organization to trust the decision made by the team, because that team is in the best position to make the decision. With this, a team has autonomy. 
 

3. Alignment

When alignment is high, empowerment is improved. Alignment, in this scenario meaning how well the boundaries between teams track with other aspects of strategy. The strategic context might depend on the architecture of the business. 

In an ideal world of development, the architecture is based on the product vision as the job of a company's architecture is to enable that vision. If the team topology also is aligned with the same architecture the teams can own a meaningful scope and be given autonomy to make significant decisions. This is often not the case. In companies with large amount of technical debt or legacy systems or are being digitalized later in the company's existence, teams are often not aligned with the architecture. The teams' work might have high dependencies and complexity. Simple tasks could take long time in this context, or not feasible at all. 

Alignment with business includes how the product team relates to the organization i.e to different business units, marketing strategies, customer types or segment. When product teams are not aligned with the business this is also a topic that creates friction. 

 

The leading star: empowerment

Most companies have some sort of product teams and an existing team topology today. When the number of product teams increases, the coordination needed or the complexity of decisions also increases.  Accordingly, companies reach the point where the need to re-evaluate the team topology. When evaluating the existing structure, optimizing for empowerment should be the main focus by balancing the 3 goals discussed above; ownership, autonomy and alignment.

Trying to improve empowerment in digital product development in organizations is hard work. In trying to do something different there is also a need for focusing not only on products and business value, but also on product people who make up the teams. The organization has made a big investment in establishing relationships to enable good collaboration - and this takes time to establish. It is often better to give an existing team new responsibilities rather than breaking up teams and redistributing these people to other product teams.

Typology determines who people work with on a daily basis, what they are working on and the nature of their interactions with others. When changing that, it can be extremely disruptive. The same goes for people moved from teams to work somewhere else temporarily. The team left behind will have to fill the gap of than person and the person needs to adjust to a new team.

Being humble and respectful of the competences of product people in digital product development have, is a critical skill needed to have, to be a good leader in product development.