From Agile to Radical: link architecture and teams 

Photo by Lala Azizli on Unsplash

Many of the companies I work with have a continuous discussion concerning organizing teams around the architecture, i.e. component teams, or organizing teams around features. Many factors play into deciding on the preferred model. My general advice is to focus on where the highest degree of complexity and challenge is. If specific components contain highly specialized and complex functionality, assigning teams to those components is likely the better approach. On the other hand, if the main challenge is the end-to-end integration of all functionality related to features, then it’s better to focus on feature teams. 

Although many seek to take a binary decision that uses the same approach everywhere, I think it’s important to realize that there’s also a hybrid approach. In this case, we use component teams for the small set of highly complex components containing some of the key differentiating functionality that sets the company apart from the competition. In parallel, we use feature teams for the rest of the system. This combines the best of both worlds and allows companies to drive innovation and efficiency. 

There is, however, a third perspective that I want to discuss here: classifying the functionality in the system using the principles of the three-layer product model. In this model, all functionality in a system, platform or portfolio is categorized into three categories: commodity, differentiating or innovative. Commodity functionality is the functionality that’s required for the system to function but doesn’t provide a reason for the customer to buy the product. Sometimes referred to as “table stakes,” we need it, but it isn’t special. Because of this, investments in this category of functionality should be as limited as possible and focus on minimizing the total cost of ownership. 

Differentiating functionality, as the name implies, is the functionality that helps us stand out from the competition. It’s what customers talk about when they’ve selected our system and what prospective customers use to evaluate us against competitors. Consequently, we should focus our R&D investments on this differentiating functionality. This is where the return on investment is earned. 

The challenge is that what’s considered differentiating inside the company is frequently already considered commodity by customers. This discrepancy causes companies to overinvest in commodity functionality, decreasing the investment in functionality that’s actually differentiating. 

The third type is innovative or experimental functionality. The word “innovation” is incredibly overused and often refers to differentiating functionality. In our model, however, this category contains those features, concepts and ideas for which we haven’t yet established that they provide value to customers. This is where we try to generate as many ideas as possible and then, through a variety of mechanisms, seek to establish as quickly and cheaply as possible whether they hold water or not. 

Innovation can refer to sustaining innovations that maintain the differentiation of the system, platform or offering and this is where we use the term in the context of the three-layer product model. However, innovation is also required to identify, build and grow entirely new products and lines for business. For the latter, I often refer companies to the Three Horizons model

A well-functioning innovation team should have a success rate that’s in the 5-25 percent range, meaning that all the other initiatives have failed in that customers didn’t consider the ideas valuable. If the success rate is higher, we’re too conservative in trying out new things, which is a risk as competitors and new entrants may identify areas of innovation that may cause us to be disrupted. 

The challenge with innovation and experimentation is that many who work with commodity and differentiating functionality fail to recognize that the nature of innovation is that most initiatives fail. Evaluating innovation activities from their perspective, where 95 percent or more of their efforts lead to successful outcomes, makes innovation seem incredibly inefficient. The consequence may be that those responsible for innovation start to act more conservatively to increase the success rate. At its worst, the innovation team becomes an extension of normal development, simply asking customers what they would like to see in the product and then building it. 

In addition to component teams and feature teams, the third alternative is to organize the teams around the three layers of commodity, differentiation and innovation. One team or set of teams is assigned to work on functionality that’s considered commodity and their efforts focus on minimizing the total cost of ownership. This often includes removing variants, replacing internally developed functionality with open-source or commercial software acquired outside the company or even creating open-source initiatives to share the cost of maintaining certain software with a community of developers outside the organization. 

A second team or set of teams works on differentiating functionality. These teams want to maximize the value of differentiating functionality to customers. This often includes adding variants, providing alternatives for the most valuable use cases, dealing with special cases and deeply understanding how customers use the functionality, both through quantitative data and customer interaction, to maximize the value of the system for customers. 

The third team is concerned with innovation activities. They’re the vanguard, trying out many, potentially crazy sounding, ideas with the intent of identifying the few nuggets of gold that can be used to provide future differentiation. Their focus is to try out as many ideas, concepts and features as possible to find the few ideas that bring home the bacon. 

In terms of resource allocation, our research shows that companies spend 70-90 percent of resources on commodity functionality, the remaining on differentiating functionality and hardly anything on innovation. My recommendation is to seek to limit investment in commodity to 35-50 percent, ensure at least 5-10 percent investment in innovation and use the rest for differentiating functionality. Of course, this depends on the specifics of each company, but it’s a rule of thumb that can be used as a starting point. 

The advantage of explicitly modeling R&D in terms of these three layers is that it requires explicit decisions about the state of functionality. The innovation team will transition functionality to the differentiating-functionality team when this functionality is desired by customers and we have the evidence to back this up. Similarly, commoditizing functionality is handed over by the differentiating-functionality team to the commodity team when the time is right and from that point on, the functionality is treated very differently. If you want to learn more about the model, I refer you to my book “Impactful software“, which can be downloaded for free from my website. 

Most companies have a constant discussion and tension between organizing R&D in terms of component teams or in terms of feature teams. There are arguments for both and I encourage companies to adopt a hybrid model. Here, I’ve explored a third alternative: organizing teams based on innovation, differentiation and commodity. In this setup, teams have very clear KPIs to focus on, i.e. trying out as many ideas as possible, maximizing the value of differentiating functionality for customers and minimizing the total cost of ownership for commodity functionality. To end with a quote from A.A. Milne: “Organizing is something you do before you do something, so that when you do it, it doesn’t all get mixed up.”

Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).