This publication is broken up into three sections:
TL;DR - For those wanting a quick take
Summary - For those wanting a bit more context and high level points
Article - Main body of work containing full detailed article and explanations that you might want to consume over several readings
TL;DR
There are no easy answers to forming high performing changes but a key part of the puzzle involves figuring out how to organise around value and to have a focus on small high performing teams as the guiding force that shapes what a highly networked and adaptive organisation should look like.
High performing teams like well tended crops require a few key environmental factors to be in place. It can be argued that it is the job of management and the leadership team of an organisation to create an environment and context for teams to be empowered to own and solve real business challenges attached to significant outcomes.
In the end if you want to build a responsive and adaptive organisation it is all about empowering teams at various levels of the organisation to solve real business challenges that are both valuable and impactful.
Summary
"You don't make great products because you want to make great products; you make great products by creating the conditions where great products can be produced" - Ben Thompson of Stratechery
High-performing teams are the critical piece connecting strategy to execution and achieving overall organisational purpose and objectives. High performing teams also need the right organisational environment for them to flourish.
Google researchers in Project Aristotle found that what really mattered was less about who is on the team, and more about how the team worked together (i.e., Check-out: Ways of Working from Atlassian)
Factors required for high-performing teams at Google: Psychological safety, dependability, structure and clarity, meaning and impact though there are other factors that were not found to be significant for Google could still be critical for other industries and functions like team size.
Small team sizes enable high bandwidth communication within a team. For example, problems where there is a lot of uncertainty and no single best solution require high bandwidth communication via collaboration.
The work of Matthew Skelton and Manuel Pais suggests that there is no one size fits all and universal best practices when it comes to team structure and modes of interaction for software development teams.
Best practice is contextual to the work being done, size of organisation, stage of organisational maturity and types of problems being solved.
High performing teams like well tended crops require a few key environmental factors to be in place. It can be argued that it is the job of management and the leadership team of an organisation to create an environment and context for teams to be empowered to own and solve real business challenges attached to significant outcomes.
There are no easy answers to forming high performing changes but a key part of the puzzle involves figuring out how to organise around value and to have a focus on small high performing teams as the guiding force that shapes what a highly networked and adaptive organisation should look like.
In the end if you want to build a responsive and adaptive organisation it is all about empowering teams at various levels of the organisation to solve real business challenges that are both valuable and impactful.
Article
The Manifesto for Agile Software Development or Agile Manifesto for short is 20 years old and much has been written and done to make the key values and principles practical.
The Agile Manifesto was primarily a means for Software Development teams to uncover better ways of developing software and helping others to achieve the objective of developing software better. The ideas of the Manifesto have definitely ‘crossed the chasm’ and have become part of the mainstream discourse on how to build digitally enabled products and services.
One of the key tenets of the Manifesto is 'Individuals and interactions over processes and tools'. This places the importance of individuals front and center however the Manifesto also centers teams as the primary delivery mechanism for getting work done.
Why should we care about the nature, structure and composition of teams?
With all the talk about Digital Transformation, Digital Strategy, Customer Centricity and Disruption one would be forgiven for forgetting that you need people working and collaborating in teams as a key value delivery mechanism. Teams are responsible for executing on organisational strategy initiatives. Teams make strategy happen, without the formation of long-lived, high performing teams a digital transformation becomes exponentially more difficult to execute successfully for example.
Below is a image showing layers related to moving from organisation purpose, through to strategy and execution as embodied and enabled by: organisational and team structures, generation of organisational culture and finally creation of product architecture.
From the perspective of Steve Denning's research, one of the key factors required to achieve organisational agility is to stay focused on a few select issues. He calls out the following: the value of small, cross-functional teams that are empowered to solve business problems in a networked organisation. He refers to this insight on teams as the 'Law of Small Teams'. This is best characterised by the two pizza rule that Jeff Bezos implemented at Amazon generally to manage meeting sizes.
If all that was required to create high performing teams was having small teams then organisations would have an easy way to become agile. Just breaking-up large functional areas into small working teams, is part of the answer but not the whole solution.
What organisational factors need to be in place to create high performing teams?
Google researchers in Project Aristotle found that what really mattered was less about who is on the team, and more about how the team worked together (i.e., Check-out: Ways of Working from Atlassian).
The key factors identified in order of importance are listed below:
Psychological safety: Psychological safety refers to an individual’s perception of the consequences of taking an interpersonal risk or a belief that a team is safe for risk taking in the face of being seen as ignorant, incompetent, negative, or disruptive. In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea. This is where team leaders play a critical role in helping to foster an environment where members of their team feel comfortable to be vulnerable by asking questions or saying that they don't have the answer to a question but they are willing to figure out an answer.
Dependability: On dependable teams, members reliably complete quality work on time (vs the opposite - shirking responsibilities). This can be summarised as having people on your team who complete work as expected or if they run into issues they are able to communicate that they are having some challenges and that delivery timelines need to shift out if required.
Structure and clarity: An individual’s understanding of job expectations, the process for fulfilling these expectations, and the consequences of one’s performance are important for team effectiveness. Goals can be set at the individual or group level, and must be specific, challenging, and attainable. Google often uses Objectives and Key Results (OKRs) to help set and communicate short and long-term goals. Though there are many challenges and nuances with working with OKRs like having well defined objectives with measurable key results that ideally can be quantified so as to be able to show progress or lack thereof for a team or the organisation as a whole.
Meaning: Peter Diamandis and co. in their work allude to this as a Masssive Transformative Purpose (MTP) whereas others refer to this as organisational purpose. Finding a sense of purpose in either the work itself or the output is important for team effectiveness. The meaning of work is personal and can vary for example: achieving financial security, supporting your family, helping the team succeed, or self-expression for each individual.
Impact: The results of one’s work, the subjective or objective judgement that your work is making a difference, is important for teams. Seeing that one’s work is contributing to the organization’s goals can help reveal impact. Objectives and Key results (OKRs) have been used by some organisations like Google to not only drive strategic organisational goals but to help specific teams to drive growth and development via ambitious team level OKRs.
The researchers also discovered which variables were not significantly connected with team effectiveness at Google:
Co-location of teammates (sitting together in the same office)
Consensus-driven decision making
Extroversion of team members
Individual performance of team members
Work-load size
Seniority
Team size
Tenure
Even though the above variables did not significantly impact team effectiveness measurements at Google, that does not mean they are not important in other organisations or industries. For example, while team size did not feature in the Google analysis, there is a lot of research showing the importance of it. Many researchers have identified smaller teams - containing less than 10 members - to be more beneficial for team success than larger teams (Katzenbach & Smith, 1993; Moreland, Levine, & Wingert, 1996). Smaller teams also experience better work-life quality (Campion et al., 1993), work outcomes (Aube et al., 2011), less conflict, stronger communication, more cohesion (Moreland & Levine, 1992; Mathieu et al., 2008), and more organizational citizenship behaviors (Pearce and Herbik, 2004).
Why is it that small team sizes enable high performing teams?
The 'Law of Small Teams' seems to be more relevant for achieving organisational agility than not. Small team sizes enable high bandwidth communication within a team. For example, problems where there is a lot of uncertainty and no single best solution require high bandwidth communication via collaboration.
Consider the below case study from Microsoft paraphrased from The Age of Agile by Steve Denning:
The goal at Microsoft in Agile at scale is to have alignment at the top and autonomy at the bottom. "The teams need autonomy" according to Aaron Bjork. That’s what drives them to come to work and deliver code that drives business impact. But at the same time, a team's work has to be aligned with the business. If there is too much management control, nothing gets done: no one is inspired to work above and beyond what is expected. It’s not an empowering environment. In fact, it’s a disaster. If there is too little control, it’s chaos. Everyone is building whatever they want. There are no end-to-end scenarios. Customers are frustrated. Nothing makes business sense. So the managers are always striving for the right balance between management control and team autonomy.
Given the environmental and organisational factors that need to be in place to foster high performing teams a few questions could be asked, do all high performing teams need to be cross-functional and are there specific interaction patterns best suited for a particular industry or organisational function?
This brings me to the concepts introduced by Team Topologies by Matthew Skelton and Manuel Pais.
Should all teams have the same structure regardless of the type of work that they do?
The work of Matthew Skelton and Manuel Pais suggests that there is no one size fits all and universal best practices when it comes to team structure and modes of interaction for software development teams. Best practice is contextual to the work being done, size of organisation, stage of organisational maturity and types of problems being solved.
An old way of thinking about organisational structure is to focus on developing an organisational chart with neat reporting lines and aligned hierarchical boxes denoting power, influence, and control. Team topologies forces us to consider how unwittingly the human resources department is the de facto architect of an organisations products and services based on the organisational chart. If we take Conway's Law and apply it in reverse we can use it to direct team formation to influence organisational structure and ultimately product, service and experience design architectures.
The beauty of the team topologies approach is that it offers a modular (lego-like) approach to building teams to enable creating value for customers and end-users. By taking simple team topology structures and interaction modes a flexible, agile, complex and networked organisational structure can be created organised around the creation, delivery and capture of business value.
Skelton and Pais's thinking around the various team types and interaction modes within and between teams has the potential to inform how various teams should be constituted based on the value delivery mechanism for their products and services.
A brief summary of Team Topologies:
Stream-aligned team:
Stream-aligned teams focus on a single, impactful stream of work. It can be a single product or service, a single set of features, a single user journey, or a single user persona. The team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work. Because stream-aligned teams work on the full spectrum of delivery, they are, by necessity, closer to the customer and usually using lean and agile development techniques. This team incorporates customer feedback in development cycles. While stream-aligned teams are common at many software and technology companies, other organizations may be more familiar with team structures organized by function (i.e. separate teams for engineering, design, QA), rather than a single delivery stream.
Platform team:
Platform teams enable stream-aligned teams to deliver work with substantial autonomy. While the stream-aligned team maintains full ownership of building, running, and fixing an application in production, the platform team provides internal services that the stream-aligned team can use. Platform teams create capabilities that can be used by numerous stream-aligned teams, with little overhead. Platform teams can provide capabilities that offer a cohesive experience that spans across different user experiences or products.
Complicated sub-system team:
A complicated-subsystem team is responsible for building and maintaining a part of the system that depends on specialised skills and knowledge. Most team members must be specialists in a particular area of knowledge to understand and make changes to the subsystem. The goal of this team is to reduce the load of stream-aligned teams who work on systems that include or use the subsystem. With the complicated-subsystem team’s expertise and capabilities, stream-aligned teams don’t have to build capabilities in areas too complicated for their daily work. Team members from this team may have specialised knowledge in certain areas (i.e., a billing service), or algorithms (i.e., personalisation or recommendation engines leveraging machine learning). A common failure mode is to embed specialists in every stream-aligned team who uses the subsystem. While this may seem aligned to having all the required skills to deliver e-2-e, it’s ultimately not a cost-effective approach for an organisation.
Enabling team:
Stream-aligned teams are under constant pressure to deliver and respond to change quickly, making it challenging to find time for researching, learning, and practicing new skills. An enabling team composed of specialists in a given technical (or product) domain help bridge this capability gap. These teams focus on research and experimentation to make informed suggestions about tooling, frameworks, and ecosystem choices that affect the tool stack.
This gives stream-aligned teams time to acquire and evolve capabilities without taking time away from their primary goals. The enabling team seeks to primarily increase the autonomy of stream-aligned teams by growing their capabilities with a focus on problems, rather than solutions. If an enabling team does its job well, the team it assists should no longer need help after a period of time. The enabling team should work to not be a bottleneck.
A question that immediately comes to mind is what does a functional or cross-functional team look like beyond software or technology based companies in say a manufacturing operation , an educational institution, a hospital setting, a construction company or a financial services company like an insurer, a bank, a brokerage or asset manager?
Can the concepts from Team Topologies be extended beyond software and technology teams?
The concept of Team Topologies can be extended beyond software delivery teams and can include all functional groupings within a business e.g. Marketing, Sales, Finance, Operations, Customer Service, Research and Development, Strategy and Product Management, Development etc. though the details need to be ironed out as to what constitutes an enabling or, complicated sub-system or platform team in these functional domain areas.
The work done by Skelton and Pais has plenty of implications in terms of how organisations organise around value creation, delivery and capture for their customers or end-users.
The infographic below highlights how the nature of a work activity as well as demand for that work influences the nature, structure and composition of teams.
Some service providers are beginning to extend these practices as evidenced by the perspective from Unfix that has taken inspiration from work done at Spotify and others and from the concepts shared by Pais and Skelton in Team Topologies.
What is the role of management and leadership in cultivating, nurturing and growing high performing teams?
High performing teams like well tended crops require a few key environmental factors to be in place. It can be argued that it is the job of management and the leadership team of an organisation to create an environment and context for teams to be empowered to own and solve real business challenges attached to significant outcomes.
Besides environmental factors not all teams are alike in the nature of the work that they do. Teams should be allowed to figure out how best to structure themselves within some organisational constraints or guardrails.
Legacy aka incumbent organisations find themselves with the added challenge of figuring out how to best organise themselves to deal with the emerging challenges of Big Tech companies and fast growing Digital Native Scale-ups. There are no easy answers but a key part of the puzzle involves figuring out how to organise around value and to have a focus on small high performing teams as the guiding force that shapes what a highly networked and adaptive organisation should look like.
If you are a manager or leader with decision-making power, how can you build empowered, networked, and high-performing teams?
By slowly adopting and shifting mind-sets, practices and ways of work, organisations can transition from being short-term focused and project-led to being long-term focused with a strong customer centric and product-led approach with a clear view on solving real business problems and achieving product outcomes and business impact.
Though there may be other issues requiring time, attention and resources specifically budgeting, financial accounting, incentivisation structure and processes that will need to be changed to support the move from project-based ways of thinking to product-led ways of doing and being.
The graphic below illustrates potential characteristics of product teams moving from ‘short-term project-based thinking’ to ‘longer-term product-based thinking’.
To close off maybe we can take inspiration from the product innovation and development practices at the likes of Apple and other leading digital companies e.g., Amazon, Facebook, Google, Netflix, Spotify, and Tesla:
Small, stable, long-lived teams dedicated to product, service or platform solutions - each sanctioned idea is allocated a small team responsible for taking it to market (e.g., the iPhone team). At Apple, product teams are siloed and separated physically: for example, iPad team members cannot access the iPhone section of the building, and this is true across the Apple product portfolio. However, there are common design and architectural principles, values, and practices that guide how products interface and interact with one another. At Amazon they used to mainly speak about two pizza teams for product development teams however based on the recent book by Colin Bryar and Bill Carr, Amazon has added on to the concept of having Single Threaded Owners for a specific product or business initiative at Amazon. This is quite similar to Apple’s Directly Responsible Individual (DRI) concept.
Cross-functional expertise - the team contains all the specialist expertise (i.e., Product Management, Industrial Design - also known as Product Design - and Product Engineering, etc.) required from functional areas to execute on a concept end-to-end (i.e., going from concept-to-cash). Cross-functional teams are typically necessary when dealing with unknown problems that have multiple impact touch points that cross organisational functional boundaries.
Empowered product teams – Core product team (e.g., Product Management, Design, Engineering and Analytics) is empowered to manage product development autonomously, whilst remaining within pre-defined constraints and led by highly capable leaders with high autonomy with Executive oversight at key inflection points. A high degree of trust needs to exist between senior business executives and the product development team leads, for the wider team to work in an empowered fashion. Soft organisational factors like trust between senior executives and product leadership teams and the existence of client-centric, strong product design- and product-centric cultures are the ‘glue’ keeping product development teams aligned to executive business strategy and product vision and strategy.
Management by exception through use of boundary constraints or guardrails as proposed by John Carter and Co. at TCGEN – The executive management team allows for decentralised control where boundary constraints/guard rails act as the contracting mechanism between executive management and product development teams which are enabled by a firm foundation of trust-based relationships with company executives. Apple uses boundary constraints as a contracting mechanism between the product executive management team and product development team to drive product focus. At the inception of new product development, the team and management negotiate a contract around approximately five dimensions of a new product development, usually cost, features, schedule, quality, and reliability, though these dimensions could be different. These boundary conditions identify the big, bold aspirations that the team has for its product. The team and management then agree on quantitative thresholds for each of the boundary conditions - for example, a target cost for the product at retail, or a “no later than” date for delivery tied to an important trade show. It is all-important to the success of the boundary conditions process that each of the dimensions of the project is defined by a quantitative metric. Boundary breaks lead to a management by exception process where the product team can propose a potential remedy. If the remedy is not accepted by executive management, there is a process to problem-solve a new boundary condition with the executive team. This process makes it simple and transparent for a business as to what they are committing resources and investment to and how outcomes should be evaluated.
Adoption of Lean-Agile development techniques for product development – leading digital companies make use of Lean-Agile principles, thinking, and practices to iterate on Product Design (aka Product Discovery) and Development (aka Product Delivery). Some of these practices could include use of Scrum, Kanban, Mob Programming, Extreme Programming, Design Thinking, Design Sprints, Lean practices borrowed from the Toyota Production System etc. Apple for example makes use of product development iterations to develop their product innovations to offer valuable solutions to important customer problems. Apple’s iteration on hardware consumer electronic designs prior to product launches is not a common pattern for most consumer electronics companies.
Narrow focus – product teams are dedicated to the product for the medium- to long term and employ a narrow product focus described within Apple as “inch-wide, mile deep”. Individuals and teams are not viewed simply as resources that can be moved between product lines very easily (e.g., the iPad team does not have access to the iPhone team office). Apple has a narrow product range architecture across product portfolios with a limited number of executives at Apple responsible for ‘micromanaging’ product design and performance factors that enable product differentiation at the UX/UI and product feature levels. The view from the Apple leadership team is that Apple products should be so good that they sell themselves with no need for aggressive sales and market promotion (e.g., When was the last time that you saw Apple products being discounted).
Marty Cagan of Silicon Valley Product Group captures the zeitgeist on teams by saying that product development teams need to be charged with solving substantial business problems and having the latitude to figure out how best to achieve their goal.
So in the end if you want to build a responsive and adaptive organisation it is all about empowering teams at various levels of the organisation to solve real business challenges that are both valuable and impactful.
#teamtopologies #aristotleproject #lawofsmallteams #conwayslaw #highperformingteams
PS. If you are moved please leave feedback so I can improve the publication and topic coverage.
Resources
Advances in Group Processes: A Research Annual : 1992 Hardcover – August 1, 1992 by Edward J. Lawler (Editor), Barry Markovsky (Editor), Cecilia Ridgeway (Editor), Henry A. Walker (Editor)
Aristotle Project from Google
Campion, M.A., Medsker, G.J. and Higgs, A.C. (1993), Relations Between Work Group Characteristics and Effectiveness: Implications for Designing Effective Work Groups. Personnel Psychology, 46: 823-847. https://doi.org/10.1111/j.1744-6570.1993.tb01571.x
Creating the Ideal Group: Composition Effects at Work by Richard L Moreland, John M Levine and Melissa L Wingert, GROUP BEHAVIOUR - Small group processes and interpersonal relations, Volume 2
Having great meetings from Amazon
Inside Apple by Adam Lashinsky
Jeff Bezos on Two Pizza Teams:
Mathieu J, Maynard MT, Rapp T, Gilson L. Team Effectiveness 1997-2007: A Review of Recent Advancements and a Glimpse Into the Future. Journal of Management. 2008;34(3):410-476. doi:10.1177/0149206308316061
Pearce CL, Herbik PA. Citizenship behavior at the team level of analysis: the effects of team leadership, team commitment, perceived team support, and team size. J Soc Psychol. 2004 Jun;144(3):293-310. doi: 10.3200/SOCP.144.3.293-310. PMID: 15168430.
Psychological Safety
The One Device by Brian Merchant
Team Topologies by Matthew Skelton and Manuel Pais
Team Topologies Video
The Age of Agile by Steve Denning
unFIX - Organisation design for continuous innovation and better human experience