Scaling Product Teams
Repost from my personal blog
Having had the opportunity to start my career as a software engineer right in the heart of product development, through to working as part of the c-suite in multinational enterprises being tasked with transformation across a range of operating models, it’s fair to say patterns of success and failure present themselves often at all levels of a business. These patterns although not absolute, highlight where improved performance can be made as well as where failure is likely.
A common challenge which emerges from success is maximising productivity through scaling. Where operational domains contain more knowns and less variance, efficiency can be had through standardisation, constraints, replication and repetition. Consider mass-producing identical products and ingredients of manufacturing where it’s essential to limit variance for assembly and repeatable operation. However, where the domain is complicated, these same traits are inefficient because repetition and variance are counter-productive traits for exploration and discovery. Consider the cognitive requirements of software engineering, research, or multi-functional collaborations between departments to complete complicated objectives. Most attempts of scaling fail to recognise state or do so in a superficial manner, advertising agility with just marginal benefits at best.
The Kernel Of Small Teams
The Agile community has long advocated small, cross-functional teams of typically 3–9 people which are re-enforced within the principles of the original Agile manifesto. It’s commonly believed that one of the aspects of success behind Amazon is it’s proliferated structure of two-pizza teams, advocated and driven by none other than Jeff Bezos. When overcoming the challenges of scale in the earlier years of Amazon, two-pizza teams provide focus, reduced administrative overhead, improved responsiveness and autonomy.
If we observe that this is the heart of team productive structures, then why is scaling so hard and broken?
What We Can Learn From Dunbar’s Number?
Enterprises might be recognised as entities, but in reality, they are simple virtual boundaries constructed of people, bound by identity and governance. Enterprises are not machines, but clusters of people working together towards common goals, to share common rewards in a competitive environment; a tribe with a purpose. If we consider enterprises to be constructs of people as opposed to faceless machines and functional structures, then we can learn a lot from anthropology, social sciences, phycology and be inspired by biomimicry.
The studies of Anthropologist Robin Dunbar, propose there are limits to the number of social relationships and group size can manage in relation to cognitive capacity. His studies propose that there is an average limit of 150 meaningful stable relationships per person, whereby when the network exceeds 150 people their likelihood of cohesion and longevity diminishes. Furthermore, the level of intimacy correlates to the size of the group where layers imply increments of dilution in intimacy in steps of from 5 through to 150. This presents a real challenge for most companies who significantly exceed these numbers, but could lead to rational causation of why enterprises struggle to scale. If we fail to recognise the beneficial constructs of communication and team cohesion, enterprises are likely applying scaling models which categorise function over focus, leading to diluted performance potential.
What We Can Learn From Cellular Division (Mitosis and Meiosis)
The patterns of scale and growth might be challenging for enterprises, but we can draw inspiration from biomimicry, where pre-existing biological patterns such as cellular division. These patterns exist to support scale within an immensely more complex environment. In the most simplistic terms, cells maintain strong embedded relationships to know when to divide and when to stop through special proteins called cyclins. They also use some simple rules such as having limits to size. Cells don’t grow in size, they replicate structures.
In the most simplistic explanation of Mitosis, signals trigger a parent cell to divide into two daughter cells containing 2 chromosomes, through a repetitive cell cycle. The daughter cells have the same number of chromosomes and DNA as the parent cell, providing exact copies and allowing aggressive and successful duplication. Meiosis, on the other hand, is where cells split from one parent into four daughter cells with just one copy of each chromosome. Through sexual reproduction, the cells combine to construct two chromosomes, resulting in a new pattern, but based on some inheritance to which give us our individuality, but alignment to species.
If we were to draw inspiration from these patterns, we can learn to apply more effective models on how to better scale and balance organisations. After all these patterns have a lot of evidence of success and adaptability, in far more competitive and hostile environments than business.
Team And Cellular Constructs And Division
Recognising the upper limit of Two-Pizza teams in Amazon and Agile principles of 9 people, for this article and exploring the model of scaling, we will infer this is the optimal point for the division. Similar to the limit of a single cell size discussed above. When a company needs to grow, this upper limit is a trigger for creating new teams. Similar to the pattern of Meiosis, a cell size has a minimum and maximum size and inherits from the parent.
Teams can divide with an inheritance from experienced team members who bring knowledge with them in a similar fashion to chromosomes in meiosis, reducing the need to train and re-learn and increasing the rate to become most effective. Meiosis is the pattern advocated here not mitosis as the uniqueness and diversity of humans would make it impossible for a literal pattern of replication to be applied and assuming this would be naive. Miosis is better suited for systems which can be explicitly duplicated such as software for operations, which speaks to why technology is better for repetitive tasks than humans. When variance is expected, it can be nurtured to deliver value, but where it occurs and isn’t expected you will yield suboptimal performance and likely ineffective management.
It’s important to note that triggers are not exclusive to size. The trigger for team expansion also relates to flow in terms of team volume and cognitive capacity. A team should be balanced to allow for confidence in the predictability of volume and responsiveness. Therefore balancing the overhead to avoid too much context switching and cognitive load, with consideration to allocated slack, will help ensure the teams can provide repeatable high-quality outcomes. Maximising the utilisation of these teams without consideration to cognitive load and capacity will likely decrease quality, overall system throughput and balance between the teams. Consider the teachings of theory of constraints to inform this balance.
In terms of team size, an upper limit of 9 team members is an optimal performance size based on social cohesion. If the input increases and your team is less than 9, increasing the team to 9 is logical. However if the complexity of the input increases or where more specialism is sought, this might increase a step change to flow. So where you might have a team of 7, but a new expectation increases demand in a step pattern and not a linear pattern, then it might make sense to split the team into 2 teams with a minimum of 5 in each. Directly correlating team size to flow in the absence of social cohesion, cognitive load and context switching decay will yield negative results in overall performance.
In this model not too dissimilar to a biological cell having a purposeful function and form, so should a team. Work should be routed to the teams and not teams to the work. By mapping function and form in team constructs, you can then begin the balanced flow with team size. Many software teams introduce interfaces and clear interaction models when constructed as product teams above. This format decouples teams, allowing for Mastery, Purpose and Autonomy of each. If teams are constructed as random units of delivery such as those found in project constructs, this interfacing can become complex and less efficient, not allowing for autonomy and mastery by design.
For this article, we will not explore team designs for type and domain, we are focused on the social dynamics, team and company constructs of teams. If you are reading this from a digital or software team background, then to learn more about constructs and models for domain application in relation to team design, I would recommend exploring Team Topologies which covers these areas well.
Scaling Teams With Consideration To Cohesive Limitations
As more teams are created, the complexity of management and communication increases as well as the quality of relationships. Following the limits proposed by the Dunbar number, we could assume there is an inflexion point of transformational change near at various the layers between 5,15,50 through to 150 people. Using the team upper limits of 5–9 people, this ranges between 16 teams of 9 or 28 teams of 5.
Approaching scaling through these layers and considering them to be triggers, we can consider scaling enterprises in a very different way to what is advocated by many scaling and growth frameworks. We can design an organisation which scales but recognises its limits with organic boundaries. The model for scaling shifts from functional groups delivering projects through controls to cross-functional units delivering to purpose, bound by the optimal boundaries of human knowledge networks. The relationship between the teams can also be positioned for optimal interactions considering the complexity introduced by abstracted layers.
If we expand the cellular pattern to a cluster of cells using the pattern discussed, we align teams to the Dunbar number upper limit of 150 as the optimal constraint to expansion. The 150 limit would be the boundary or a product line or business unit to obtain Autonomy, Mastery and Purpose. Consider this to be a cross-functional unit with the skills necessary to deliver outcomes which are aligned to the logically grouped teams and the groups inherited purpose.
This model for scaling would expand on a similar foundation to the individual teams, simply based on the construct that a company is a purpose boundary such as a business unit and a product line and a group is a collection of teams with a purpose. Extending the enterprise would then look like the following :
Conclusion
Scaling frameworks and transformation programs tend to focus on managing large functions reactively, with some illusion of control. The purpose is instructed top-down with KPI’s and metrics which despite best efforts still measure by outputs; outputs are measurements of control. Functions are expanded sometimes under the pretence of Agility, but in many cases are illusions where iterative internal release cycles follow the mass production for mini-waterfall like delivery models. Improving linear delivery by reducing delivery times isn’t adaptive or agile.
If we are to observe the teachings in Biomimicry which thrive in complex systems and explicitly have regenerative cultures and recognise that people are complex and constrained by social limitations, then we can improve how teams and companies work. Great companies enable great teams, which in turn create great products. This construct presents a paradigm shift in the popular definition of enterprise from being slow-moving, all-consuming empires, towards purposeful and collaborative teams who are autonomous but bound by a set of values driving towards a common purpose.
An adaptive and responsive company needs to recognise the benefits of total system design and the limitations of human networks. When recognised this way, a system of teams of teams, layered through interconnected responsibilities and groups like a biological entity, can yield optimum form and operating models. These constructs allow for autonomous cellular functions to work as a united body, whilst maintaining some independent focus and form, where each teams purpose is connected to the purpose of the groups it belongs to. At the same time some guiding principles such as team and network size, provide a template to encourage collaborative interaction with minimum decay.
