Some years ago, Frederic Laloux published a book called “Reinventing organizations,” which received quite a bit of attention in the media and industry. The basic premise was that organizations don’t need hierarchies, managers and bosses but should instead rely on other mechanisms. Mechanisms such as the advice process, agreements and roles. Others had published works in the same vein, eg on holacracy and exponential organizations. The idea behind these books is that existing organizational forms including hierarchies and managers telling people what to do and how to do it as well as all the processes are simply slowing us down, sap our energy and turn proactive, hardworking people into passive and reactive zombies that only move when they’re told to.
We kicked off a research activity around these principles to understand how they could work in large product development organizations. As many have realized, the concepts behind Agile are aligned with the principles of increasing autonomy and empowerment of individuals and teams. We worked with several companies and developed a maturity model on how organizations can transition from traditional to fully empowered.
As we continued our research, however, we started to realize that fully autonomous teams without any guidance suffer from their own set of deficiencies. We saw that the organization became increasingly chaotic with everyone doing what they felt was best. That resulted in vast amounts of local optimization at the detriment of end-to-end optimization of the value delivery to customers. And, contrary to what we expected, teams started to invest far too many resources into commodity functionality.
The reason for sharing our findings is to point out that teams need some level of steering and alignment with the rest of the organization, but that we need to be highly intentional about how we organize this steering as both sides of the fine balance that we’re looking to accomplish lead to either chaos or disempowered and unmotivated teams and individuals. Although teams and organizing teams have received incredible amounts of attention in both research and the business literature, I feel that most authors fail to identify and highlight this careful balance. Instead, many publish their bespoke and “n of 1” cases as if these are generic truths that apply everywhere.
Here, I want to share my learnings concerning steering teams in product development and specifically the software in products. In my experience, there are three main topics to consider: outcomes, cross-functional feature teams and integration. To start with outcomes, earlier in this series, we discussed the importance of quantitatively defining the desired results. Traditionally, most organizations used requirements as the ‘boundary object’ between the business side and the R&D side of the company. This leads to all kinds of dysfunctional behaviors. Instead, it’s much better to align teams around measurable and quantitative KPIs to improve.
Of course, teams can’t be responsible for all the KPIs the company aspires to improve. Instead, they could focus on one or a few and be given guardrails to ensure that their efforts don’t negatively impact other KPIs that they’re not responsible for. In fact, several SaaS companies have organized their R&D around the top-level KPIs in this fashion. For example, a company could have a revenue team, a customer satisfaction team, a new-customer acquisition team, and so on. Each team is responsible for one KPI and empowered to pursue their KPI in any way they want as long as they don’t cause harm to other KPIs.
Traditionally, teams were often organized around the components or subsystems of a product. This is perfectly viable if the complexity of each component is such that it requires a significant learning curve before engineers become productive. However, in most systems, the challenge is understanding and delivering end-to-end customer value. In those cases, it’s better to organize teams around features. The idea is that one team can create a feature from initial ideation to delivery with as little interaction with other teams. This requires each team to have all the necessary skills and competencies to be able to conduct their work.
Combining outcomes and cross-functional teams focused on specific KPIs results in a situation where each team can come up with their own ideas on how to move the needle on their KPI. In doing so, they take much more experimental approaches to rapidly and cheaply evaluate the potential impact of new features and functionality on their KPI.
For all the focus on the autonomy of individuals and teams, the reality is that all these efforts have to come together in a product or offering that’s appreciated by customers and, consequently, generates the revenue we need to keep the company going. There are at least three levels of integration: customer experience, architecture and quality. There’s a need to align the deliverables of all teams to ensure that the customer or user has a consistent and integrated experience. Without this alignment, we can easily get into a situation where the same task or interaction is solved in different ways in different parts of the product.
To maintain a product architecture that allows for future evolution, we need to ensure that the teams stay aligned with the architectural vision for the product. The same is the case for quality as many companies have experienced situations where the individual features perform as expected, but the system as a whole isn’t working properly. Hence, we need to align around product management, user experience, architecture and quality assurance across all teams.
Steering teams requires a careful balance between top-down steering and empowerment and autonomy of teams. Too much top-down steering leads to unmotivated teams that are highly reactive and need to be told what to do. Too much empowerment causes chaos, local optimization and focus on commodity. Instead, we should focus on quantitative, measurable outcomes, cross-functional feature teams and the right level of alignment around customer experience, architecture and quality. To end with a quote from Lawrence Bossidy: “Execution is the ability to mesh strategy with reality, align people with goals and achieve the promised results.”
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).
