Figure 5: A component team approach to painting
Technology strategy
Why products fail: five tips for product teams
IT’s role in the enterprise is rapidly shifting; from being a provider of commoditized solutions to becoming the core of modern businesses. As a result, many established companies are still struggling to organize their engineering and product development teams effectively around the things they’re building.
There’s no single way to structure teams successfully: organizational structure and politics have a huge influence. But given the benefits of good team design, I wanted to explore ways in which you can find a setup that works for your organization: one that creates the right environment, one that ensures your software delivery practice keeps pace with the fast-changing market.
Component teams are a specific type of functional team within a tiered software architecture. They need to deliver and integrate their release slices to provide meaningful functionality or “customer-valuable” solutions (Figure 2). Generally, these teams are optimizing for a particular “function” or discipline, such as internal scaling, optimization or things that foster some kind of specialized technical expertise with an eye to keeping costs down. Having the main focus there makes it generally quite difficult for a component team to spot new opportunities that increase revenue.
Cross-functional teams — sometimes called Feature teams — on the other hand, own a particular piece of new functionality through all the architectural tiers and have the resources available to deliver this functionality autonomously (Figure 3). These teams appear in different variations across the IT landscape. Some of the more popular examples include autonomous, independent teams at TransferWise or autonomous squads at Spotify. The key element they have in common is that they produce vertical release slices, meaning that they release new features through all the necessary architectural tiers of the product, as shown below.
These teams are often good at coordinating and delivering business growth around critical USPs and are optimized for speed. That’s because feature teams can quickly learn about their customers and / or partners, which gives them a strategic advantage. They’re able to accelerate the delivery of “customer-valuable” solutions because they frequently test new product assumptions in the real world and pivot based on these learnings.
So what's the point here? Should we all use feature teams or component teams? It depends. One problem I see highlighted in some articles is that the authors introduce a hierarchy that I don’t see supported in practice. There seems to be a dogma to promote feature teams as the pinnacle of agile / lean product development work and component teams are denigrated as the legacy waterfall losers.
The real problem organizations face is not choosing component teams, it’s choosing a team structure that doesn’t fit with the tasks at hand. A thorough understanding of the product objectives is the most reliable guide available when grouping team members functionally — by component or cross-functionally by feature — in order to use Conway’s law to your advantage.
One of the main challenges involved in such a scenario is to translate “real” customer problems into the component teams’ backlogs — which will already include other, often competing, priorities.
User stories, the essential building blocks of shipping customer features, quickly become scattered technical tasks that are then somewhat also detached from the overall product vision and business goals. Not only does that make the development of these tasks more difficult but managing and coordinating work across multiple component teams produces significant overhead for everyone involved. On top of that, project managers might as well quantify success as outputs rather than outcomes, as the business and product objectives aren’t consistent across the organization and meaningful data may not be available. The bottom line is: this kind of functional aligned environment can’t provide the component teams with the type of tools and resources necessary to achieve this type of goal, nor the ability to evaluate its consumer success. This creates a sort of pressure cooker situation in which all the responsibility is on the team, while all the decision making around the delivery and critical information necessary is controlled from outside the team. I believe that the component team setup is just not ideal for this type of job, however, it isn’t necessarily bad because of that.
An interesting analogy, I have borrowed from Jeff Patton, to illustrate the problem as to why a component team setup is not ideal for continuously shipping “customer-valuable” features — where time-to-market is critical — is to think about it like painting a picture. It’s a very individual process in which the artist is constantly evolving the picture all the way from a sketch, to the outlines to eventually adding colors and shadows.
Figure 4: A lean product approach is much like painting
This level of autonomy and experimentation the artist needs to paint the picture is very similar to what a team needs in order to make progress and develop highly competitive time-to-market critical product features. It’s how lean product development works at its core and component teams don’t really have the tools available to excel at this type of task. This situation would be much more like the illustration below slicing the painting into many many different parts and trying to paint each of the parts.
Such an approach doesn’t necessarily mean a team is doing waterfall but it’s a highly interdependent environment in which teams quickly lose the connection to the user / customer and their flexibility with regard to the scope. They may spend significant time negotiating priorities with other component teams, managing dependencies and so forth, so that the portrait will somehow fit together in the end. In reality though, especially with a lot of teams involved, the portrait doesn’t live up to the customer’s expectations or perhaps it’s massively delayed in the delivery while the market opportunity is long gone.
In the same way, cross-functional feature teams can be a big disadvantage when the business goals clash with the team design. This is because they usually apply a very different set of trade-offs towards the things they are building. A great example is Wonga. They were trying to keep a business-critical level of maintainability and code integrity needed to provide a highly scalable world-class infrastructure, and found feature teams didn’t work out.
There are tons of examples like this, in which teams continuously experience some form of friction when the boundaries of the underlying team structures conflict with the type of goals they’re trying to achieve. Dysfunctional team setups regularly outmaneuver the overall delivery capabilities. But because examples of malfunctioning component teams are so common, it can be easy to fall into the trap of thinking feature teams are the panacea.
What I’m trying to highlight here is a simple rule of thumb: that team design should always account for the type of desired product objective. Many of the issues we see in the current IT space are related to poor team design choices for the job to be done. Team design, however, is at the very heart of product success and some of the worlds most successful software companies demonstrate that very vividly.
One reason why feature teams aren’t more widely used — even in areas they’re well suited to — is that they require a high degree of maturity in terms of the environment and the management. Meanwhile, the frequency with which we see component teams fail owes much to the fact that they’re simply more common. Established companies find it hard to change their structures to support cross-functional teams — so even where there’s a desire to change from those in the trenches, it’s often not possible.
Moreover, the success curve is very steep in terms of the cultural change needed, especially when senior management are still operating within traditional project frameworks that like fixed budgets and scope. However, there are examples of success out there that demonstrate how different team designs can, for example, co-exist very successfully as well as focus and excel at the type of job they’re really good at. Investing into organisational learning, cultural change and outcome focussed leadership and management can really help established companies to create the environment needed to drive team design by actual business and product goals and therefore increase their delivery capabilities.
I recommend a pragmatic and thorough assessment of what your company is actually trying to achieve in order to understand how teams can be set up for success. Every situation is unique and what should be important for a successful software enterprise is to drive team design pragmatically, in a way that actually optimizes for a specific business or product objective. Modern product leadership understands that this type of management is the quintessential principle that should drive team design in practice.
There’s no single way to structure teams successfully: organizational structure and politics have a huge influence. But given the benefits of good team design, I wanted to explore ways in which you can find a setup that works for your organization: one that creates the right environment, one that ensures your software delivery practice keeps pace with the fast-changing market.
Don’t assume feature teams are always best
Most IT organizations group people either functionally according to a particular specialization or cross-functionally, for instance, by product feature, increment. There seems to be a common understanding that functionally aligned teams in software companies are organized around dedicated parts of the software product. These are often referred to as component teams. Functionally aligned teams are responsible for a specific part in a tiered architecture, meaning they produce horizontal slices to release their work (see Figure 1). For example, the frontend teams release frontend functionality, the backend service teams release backend functionality, data tier components release their functionality and so on.
Figure 1: Functionally aligned teams are responsible for a specific part in a tiered architecture
Component teams are a specific type of functional team within a tiered software architecture. They need to deliver and integrate their release slices to provide meaningful functionality or “customer-valuable” solutions (Figure 2). Generally, these teams are optimizing for a particular “function” or discipline, such as internal scaling, optimization or things that foster some kind of specialized technical expertise with an eye to keeping costs down. Having the main focus there makes it generally quite difficult for a component team to spot new opportunities that increase revenue.
Figure 2: Functional and cross-functional teams
Cross-functional teams — sometimes called Feature teams — on the other hand, own a particular piece of new functionality through all the architectural tiers and have the resources available to deliver this functionality autonomously (Figure 3). These teams appear in different variations across the IT landscape. Some of the more popular examples include autonomous, independent teams at TransferWise or autonomous squads at Spotify. The key element they have in common is that they produce vertical release slices, meaning that they release new features through all the necessary architectural tiers of the product, as shown below.
Figure 3: Vertical and horizontal slicing of work
These teams are often good at coordinating and delivering business growth around critical USPs and are optimized for speed. That’s because feature teams can quickly learn about their customers and / or partners, which gives them a strategic advantage. They’re able to accelerate the delivery of “customer-valuable” solutions because they frequently test new product assumptions in the real world and pivot based on these learnings.
So what's the point here? Should we all use feature teams or component teams? It depends. One problem I see highlighted in some articles is that the authors introduce a hierarchy that I don’t see supported in practice. There seems to be a dogma to promote feature teams as the pinnacle of agile / lean product development work and component teams are denigrated as the legacy waterfall losers.
The real problem organizations face is not choosing component teams, it’s choosing a team structure that doesn’t fit with the tasks at hand. A thorough understanding of the product objectives is the most reliable guide available when grouping team members functionally — by component or cross-functionally by feature — in order to use Conway’s law to your advantage.
Why component teams often fail to quickly deliver user value
Let’s stop for a second and look at a typical example. Imagine a component team organization of 20+ teams, grouped around specific services. All of these teams have their own backlog, roadmaps and belong to a cluster of other teams under the umbrella of different projects, with different sources of budget and leadership. Let’s assume that all of these teams together are trying to innovate around the enterprise's ability to stay competitive in the market by shipping new features that customers will value. And herein lies the danger: too often component teams are focused on building time-critical features to chase the market and optimize for speed.One of the main challenges involved in such a scenario is to translate “real” customer problems into the component teams’ backlogs — which will already include other, often competing, priorities.
User stories, the essential building blocks of shipping customer features, quickly become scattered technical tasks that are then somewhat also detached from the overall product vision and business goals. Not only does that make the development of these tasks more difficult but managing and coordinating work across multiple component teams produces significant overhead for everyone involved. On top of that, project managers might as well quantify success as outputs rather than outcomes, as the business and product objectives aren’t consistent across the organization and meaningful data may not be available. The bottom line is: this kind of functional aligned environment can’t provide the component teams with the type of tools and resources necessary to achieve this type of goal, nor the ability to evaluate its consumer success. This creates a sort of pressure cooker situation in which all the responsibility is on the team, while all the decision making around the delivery and critical information necessary is controlled from outside the team. I believe that the component team setup is just not ideal for this type of job, however, it isn’t necessarily bad because of that.
An interesting analogy, I have borrowed from Jeff Patton, to illustrate the problem as to why a component team setup is not ideal for continuously shipping “customer-valuable” features — where time-to-market is critical — is to think about it like painting a picture. It’s a very individual process in which the artist is constantly evolving the picture all the way from a sketch, to the outlines to eventually adding colors and shadows.
Figure 4: A lean product approach is much like painting
This level of autonomy and experimentation the artist needs to paint the picture is very similar to what a team needs in order to make progress and develop highly competitive time-to-market critical product features. It’s how lean product development works at its core and component teams don’t really have the tools available to excel at this type of task. This situation would be much more like the illustration below slicing the painting into many many different parts and trying to paint each of the parts.
Figure 5: A component team approach to painting
Such an approach doesn’t necessarily mean a team is doing waterfall but it’s a highly interdependent environment in which teams quickly lose the connection to the user / customer and their flexibility with regard to the scope. They may spend significant time negotiating priorities with other component teams, managing dependencies and so forth, so that the portrait will somehow fit together in the end. In reality though, especially with a lot of teams involved, the portrait doesn’t live up to the customer’s expectations or perhaps it’s massively delayed in the delivery while the market opportunity is long gone.
In the same way, cross-functional feature teams can be a big disadvantage when the business goals clash with the team design. This is because they usually apply a very different set of trade-offs towards the things they are building. A great example is Wonga. They were trying to keep a business-critical level of maintainability and code integrity needed to provide a highly scalable world-class infrastructure, and found feature teams didn’t work out.
There are tons of examples like this, in which teams continuously experience some form of friction when the boundaries of the underlying team structures conflict with the type of goals they’re trying to achieve. Dysfunctional team setups regularly outmaneuver the overall delivery capabilities. But because examples of malfunctioning component teams are so common, it can be easy to fall into the trap of thinking feature teams are the panacea.
What I’m trying to highlight here is a simple rule of thumb: that team design should always account for the type of desired product objective. Many of the issues we see in the current IT space are related to poor team design choices for the job to be done. Team design, however, is at the very heart of product success and some of the worlds most successful software companies demonstrate that very vividly.
One reason why feature teams aren’t more widely used — even in areas they’re well suited to — is that they require a high degree of maturity in terms of the environment and the management. Meanwhile, the frequency with which we see component teams fail owes much to the fact that they’re simply more common. Established companies find it hard to change their structures to support cross-functional teams — so even where there’s a desire to change from those in the trenches, it’s often not possible.
Moreover, the success curve is very steep in terms of the cultural change needed, especially when senior management are still operating within traditional project frameworks that like fixed budgets and scope. However, there are examples of success out there that demonstrate how different team designs can, for example, co-exist very successfully as well as focus and excel at the type of job they’re really good at. Investing into organisational learning, cultural change and outcome focussed leadership and management can really help established companies to create the environment needed to drive team design by actual business and product goals and therefore increase their delivery capabilities.
I recommend a pragmatic and thorough assessment of what your company is actually trying to achieve in order to understand how teams can be set up for success. Every situation is unique and what should be important for a successful software enterprise is to drive team design pragmatically, in a way that actually optimizes for a specific business or product objective. Modern product leadership understands that this type of management is the quintessential principle that should drive team design in practice.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
