Organizing Product & Technology Teams: A Team of Teams Perspective
How adaptability, not efficiency, must become your central competency
In Team of Teams, general Stanley McChrystal outlines how the team of teams organization model looked at the behaviors of the special forces smallest units and found ways to extend them to an organization of thousands. Stanley McChrystal makes the case that being effective in today’s world is less a question of optimizing for a known (and relatively stable) set of variables than responsiveness to a constantly shifting environment. Adaptability, not efficiency, must become your central competency.
Scaling Technology Teams Challenges:
Scaling technology teams represents a particular challenge.
Communication and coordination: as technology teams expand to multiple teams, communication challenges increase, information silos form, making it increasingly challenging to keep effective coordination between teams. Without the right organization, teams spend an increasing amount of time managing work about work.
Cognitive load: as the scale of the technology grows, so does the cognitive load on the teams required to maintain an ever-expanding code base. The right organization approach can go a long way in effectively managing the cognitive load put on teams.
Team culture: Maintaining team culture is a delicate balancing act when scaling. A small team often has a close-knit culture. Fostering a sense of unity, shared value, common focus and ownership across a growing organization can be challenging.
What do we Mean by Scaling Technology Team:
The Dunbar rule is a concept in anthropology and psychology that suggests that there is a cognitive limit to the number of stable social relationships a person can maintain. Dunbar's research suggests that our social networks are structured in layers. Applied to a technology organization, this means that an organization is limited in its ability to scale by the number people involved. In the business world, this translates into the following constraints:
The single team, 5-8 people
The team of teams, no more than 50
The division or product line, no more than 150 to 500
Technology Organization Design Considerations:
When designing a technology organization, key principles of team topologies should be considered:
First, Ruth Malian's principle, “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”
Second Conway's law, "the way organizational interrelationships constrain the design of systems we build"
The organization design needs to be optimized for continuous flow of information aligned to a business domain.
Two key considerations need to be considered when designing domain and team boundaries:
Inter team communications or information flow, and
Desired architecture
The reverse Conway methodology reconfigures teams inter communication and states that organizations should evolve their teams and organizational structure to achieve the desired architecture. They should enable teams to get work done without requiring high bandwidth communication between teams.
Organizing for success:
When focusing on optimizing for work and business outcomes, the functional organization model is highly inefficient. Paradoxically, as organizations grow, they tend to organize functionally. The Team of Teams organization approach is aimed at solving these inefficiencies. The bottom line is that if the military can do it, you can do it as well.
From Team of Teams by Stanley McChrystal
We restructured our force from the ground up on principles of extremely transparent information sharing (“shared consciousness”) and decentralized decision-making authority (“empowered execution”).
Applying the team of teams’ principles and Dunbar law, below are core building block that I have seen work successfully when organizing and scaling technical organizations. An effective technology organization approach uses 3 primary dimensions:
The product triad which includes a product manager, technical lead and UX design lead. Its primary purpose is to facilitate continuous and collaborative discovery efforts to build products that align with customer needs and business goals. The product triad aligns with a primary development team but is loosely coupled from the development team allowing for swarming of resources when required.
The domain (the Spotify model refers to it as Tribe) which is a team of teams’ organization constructs with a cross functional domain strategy team responsible for the domain strategy and prioritization, x-triad coordination, x-domain dependency management, domain alignment and execution optimization, release management and launch planning.
The portfolio team which is the governing body across multiple domains including the domain strategy teams leadership and responsible for portfolio strategy, x-domain coordination, portfolio prioritization and portfolio initiatives.
Domain-based vs Functional Organization:
The team of teams’ organization model combines a functional organization with cross functional teams that work in a highly empowered manner. It promotes team alignment, collaboration and communication, but requires a strong operating model to be effective and avoid team silos.
A typical team of teams’ organization will look as follow:
Putting it All Together
Get x-functional leadership buy-in:
Building x-functional team requires the full buy-in of the functional leadership. This applies to strategy team and to triads. I especially recommend incorporating product marketing in your strategy teams. In Loved, Martina Lauchengco outlines the critical role that product marketing plays in championing the buyer and the entire buyer journey. Any good product strategy must build this in.
Realigning your teams to your to be architecture requires an architecture vision. This is harder said than does and often results in the need for significant realignment and change management within your technology organization.
Map out your to be architecture:
No matter how hard you try, your architecture will mirror your organization.
Use the reverse Conway approach to design your organization so that it aligns with your to be architecture.
Map your teams to the components of your architecture:
Once your architecture is clear, map your teams to components of your architecture
Form your product triads, and clearly articulate a charter for each of your triads.
Keep a loose coupling between the product triad and its assigned dev team. This gives your organization the flexibility to swarm some of the dev teams to support critical initiatives. But in all instances, the dev team should have a primary ownership of components and services.
Group your teams into domains with a clear mission and goals:
This requires a clear understanding of the business goals and alignment of a group of teams towards a clear mission. It also forces you to manage by outcomes, not managing features roadmaps or building a feature factory.
Identifying the right dimension to establish domains can be challenging especially for organizations that are not outcomes centric. Some options to get starts:
Align with personas / archetypes goals
Align with customer segments goals
Align with specific investment goals. If you choose this option, make sure that your goals have a long enough runway. You don't want to reorganize every 6 months.
Above all, remember that adaptability must become your central competency. Your approach to organizing your teams must enable you to adapt to an ever-changing customer, technology and business environment.