This page is a work in progress, part of a multi-year effort to capture and share learnings, frameworks, tools, and processes to run organizations. See Running Organizations for more.

Teams have five common components, according to Steve Sugar:

Teams need leadership. Ideally, leadership forms organically and is shared, or at least rotates across group members, so that no one person is "in charge." If no single person is always in charge, everyone on the team is responsible for the team's performance.

If everyone feels responsible, not just accountable to a "leader," then the team will work together to get the job done.

The team should make its own decisions about how decisions will get made, how work will be assigned, how deadlines will be set, and how the day-to-day tasks will be handled.

Each member of the team agrees on the team’s goals. If there is no agreement, the team will not work together effectively.

In the course of work, prioritization and resource-planning decisions will create conflict. That conflict will re-surface goals ("what are we trying to accomplish here?") and require recommitment to goals or a changing of goals.

The team needs the skills, abilities, and will to do the work in service of the goals. Teams that have the other four components, but not the ability to do the work, can't be effective. Staffing the appropriate skills often requires specialization.

Teamwork is the human value of people working together. You can promote teamwork in your organization and see gains in performance, but just because you have teamwork doesn't mean you have teams. The distinguishing factor about teams is that they focus on performance.

If you want teamwork but don’t build teams, you’ll end up with a lot of people who get along and play nice but don’t hit ambitious goals. If you want to pursue a BHAG, you need teams.

The Team Performance Curve, from The Wisdom of Teams, explains the spectrum of "teaming," from a group of individuals working together, to a high-performing team.

How many organizational teams are actually just working groups or pseudo-teams? How many Leadership Teams want to display more teamwork and common purpose, but are stuck without shared performance goals and mutual accountability? There's nothing wrong with working groups - working groups help share and spread information and can improve performance - but they don't work when the performance challenge demands a team.

Tuckman's Stages of Group Development explain how teams form and grow together. There are four stages of the model: Forming, Storming, Norming and Performing.

Teams take time to come together and be effective. "Durable" teams, ones that are built to endure through multiple projects, are more likely to build excellent teamwork as they work through each of Tucker's stages and become high-performing.

There are many ways to structure teams. The microcosm of how a single team is structured can ultimately dictate how the entire organization is structured. Structure is highly dependent on what you're selling and the type of products or services you're building.

Developer-driven organizations have common team structures from birth to scale. Most begin to form official teams with their hire of their first Product Manager (PM). As they grow, they hire another PM, then specialized PMs (i.e. one PM for customer research, personas). Depending on how fast they grow, they'll frequently evolve cross-functional structures, as Buffer explains here.

Scrum teams have well-defined team compositions. Here are several examples of organizations and how they organize their teams to build products. Instead of attempting to prescribe good structures, or cover every possible team structure, this section will cover common team structures and examples to draw from.

Robin Dunbar is famous for "Dunbar's Number," which says that 150 is the cognitive limit of the number of people we can have basic relationships with. Dunbar broke down further groupings into Bands of 50 people, Hunting Parties of 15 people, and Cliques of five people.

Bands are the size of a typical organization's "community of practice," too large to function effectively as a team, but capable of building and maintaining relationships and working together in groups. Hunting groups of 15 people can form organically but are difficult to manage effectively. Cliques of ~5 offer our closest connections in the workplace.

A team size somewhere between Clique & Hunting Group is optimal.

Metcalfe's Law is a networking law that explains the complexity of communication lines as team sizes grow. Five team members have 10 communication lines, ten team members have 45 communication lines, and 15 team members have 105 lines. These communication lines create transaction costs that make operating cohesively very difficult - emails, chat messages and meetings drastically increase.

"The Magical Number" is George A. Miller's theory that the number of objects an average person can hold in their short-term, or working memory, is seven, plus or minus two. If we can only keep track in our working memory of the work of 5-9 people, logic would follow that a team of 5-9 would be more cohesive and connected than a team of 10.

Social Loafing increases as team sizes grow. As people’s impact is diluted, they feel like they have less control over whether goals are reached or not. This can lead to "free riding."

There are strong cases to be made for teams of three, or "triads." A smaller group may be able to move faster than a larger one, but teams of three will have less specialization and expertise than a larger group.

Choosing how much authority teams have is a critical organizational design decision. Richard Hackman broke down four levels of authority for teams: Manager-Led, Self-Managing, Self-Designing, and Self-Governing.

For Self-Managing, Designing, and Governing teams, having the right organizational context that supports autonomous decision-making and innovative mindsets is critical. Assuming that people have the right skills to manage these teams is unfair and unlikely to lead to productive outcomes. A coaching approach is required.

Just having coaches and training isn't enough, for Self-Designing and Self-Governing teams. A strong set of rules and principles completes the organizational context necessary to pull off this advanced level of teaming.

Product, Feature and Component, teams are three basic team types in product-focused organizations.

Team Topologies breaks down four team types. Stream-aligned teams are the most common team type. Large organizations may have a few platform and enabling teams, and one or two complicated sub-system teams.

The Two-Pizza team is an example of a Stream-Aligned Team. It's run by a leader, approved by Amazon's Leadership Team, and governed through these principles.

Designing the work to be done by teams requires an understanding of the products and services and where they can be divided to allow for less interdependency and more autonomy. A lack of division will create a situation where teams sit and wait, or are bogged down with coordination costs such that they can't be effective.

Team Topologies explains the concept of the "Fracture Plane" - splitting a monolithic software system into "clean" component parts to be worked on:

Most organizations can benefit from studying their Fracture Planes and then using some combination of the examples below.

Here are the common Fracture Planes in software (Source: Team Topologies):

Here are two other Fracture Plane ideas from Pasquale Langella and Casey Winters.

If Teams are "cells," or "atoms" within the organization, how do they interact with the broader organization?

Whether a team is truly a team (i.e. "cell"), or just a functional department, individuals within these structures have to have an understanding of the organization as a whole and the part they play within it. If a team does not see how their contributions lead to organizational success, you'll at best get optimization of local maxima, but more likely get bottlenecks, poor delivery, politics, and lack of accountability.

Team members should understand what other teams are working on, and how their own work fits into the larger puzzle. They should know at least one person on nearby teams.

Stanley McCrystal used cross-training and networking across teams so that people on each team knew the basics of what other teams worked on and how they contributed.

Designing how teams fit into the organization allows you to determine what types of "lateral processes" and structures are necessary to allow for cross-team efforts to succeed.

When considering a "network of teams" model, McKinsey suggests utilizing a "hub-and-spoke" leadership model to keep teams tightly coordinated under common leadership while allowing for autonomy within each team.

It’s worth being explicit about how teams should interact with one another, even in small organizations. If teams know how they should be interacting with one another throughout projects, then expectations can be made clear upfront. Team Topologies breaks down three different types of team interactions: Collaboration, X-as-a-Service, and Facilitating.

Collaboration is the right mode for projects that can't be well-scoped in advance and require a lot of research and discovery. Without collaboration, these projects cause costly hand-offs. Collaboration can produce innovation and save time.

Collaboration can also be expensive and cognitively demanding, as people within one team have to learn to work with people on another team.

Often, one team can provide another with a tool or set of tools to solve their problems without the need for collaboration. In engineering, this is APIs and code libraries. In HR, this may be a knowledge base or handbook. This mode is about delivering a service that another team can put to use.

X-as-a-Service requires that a team think through the user experience they’re creating, including how to make documentation clear, and how to maintain the work so that it stays up to date.

A facilitating team interaction happens when one team can use the facilitation or coaching from another team to get expertise or skills that it doesn't have on its own team. This is the role of an "Enabling" team.

Having a central repository, whether it's open and available data, team communication, a code repository, or all of the above, connects teams naturally to the "hub," and to one another.

A code repository example from the LeSS framework:

Communities of Practice (COPs) link people who share interests or expertise to increase the strength of the network and develop people's individual skills and knowledge. Most COPs are informal and self-organized. They can be permanent or can come together for a big project and disband afterward.

Meetings are a rhythmic component that brings teams together. Two meeting types from the LeSS framework are Product Backlog Refinement and Sprint Planning.

During Product Backlog Refinement, all of the teams in the product group sit in the same room and split big items, clarify items, estimate their size, and identify strongly-related items that suggest shared work or coordination.

Sprint Planning meetings bring teams who are working on related features together to coordinate shared work, get clarification and find ways to learn from one another

Source: Scrum @ Scale

The "Scout" concept from LeSS is a simple, accountable way for teams to stay on top of what is going on in the broader department. The team assigns or rotates through Scouts every Sprint, and the Scout is accountable for reporting back to the team on a regular basis on the status of other nearby teams.

If the major difference between a working group and a team is a focus on performance, then the aligning factor in performance is goals.

A team needs a few goals, usually < 5, in order to function well and to have a chance to be aligned and moving in the same direction. Some of the best-performing teams set their own, translating the vision of leadership into tangible, achievable goals.

If teams aren't aligned, they will work in opposing directions, they will produce redundant effort, and they will waste their time and energy.

Aligning is making everyone's individual part play a role in reaching the shared goals of the team. High alignment within a group allows a team to grant high autonomy to individuals and expect great results. High autonomy without alignment will result in poor outcomes, no matter how motivating the goals may be.

Sharing relevant information, reaching "common ground" and coordinating time and resources effectively are key to aligning teams.

Alignment starts with communicating openly. That involves asking questions like:

Just communicating a lot is only a first step. A lot of information sharing can create the illusion of alignment, where people feel like because they said it and no one challenged them or told them 'no', everyone must be in agreement.

Members of the team need to reach a mutual understanding of what must be done to accomplish the goals, and how the work should be done.

Finally, teams have to coordinate the flow of day-to-day work, to make sure that people's individual work can integrate to produce the desired result.

Team contracts or charters can be created by answering these questions.

Disagreement, heated exchanges, and other forms of conflict are important for high-functioning teams. Mediocre teams suppress conflict or sit in ongoing conflict and turmoil. In both cases, the team never works through its differences and then struggles to reach its goals. (Note: There are five responses to conflict)

Good conflict is about struggling together to get to alignment, rather than struggling against one another. It's about prioritizing the group ahead of prioritizing individual agendas. Good conflict isn't "sticking to our guns" and "digging in our heels." Good conflict is a part of teamwork.

One way to work through conflict within a group is to refer back to goals. It's easy to get lost in dialogue and forget what the group is trying to accomplish. When people begin to prioritize their own personal viewpoints over the team's goals, bringing the discussion back to goals reminds people that the dialogue is about the team, not about winning. Further, some conflict pervades because there is a lack of agreement about goals in the first place.

Teams can't go it alone - they exist within an organization with a larger vision and mission. But they also need to be able to operate with some degree of freedom. There's an open debate about how far autonomy needs to go to improve performance. This study concludes that fully self-managed and autonomous teams are no better or worse than closely managed teams:

One way to assess autonomy is to analyze dependencies between teams. A team that is dependent on many other teams can optimize for its own local maxima but accomplish nothing for the organization if surrounding teams can't deliver. They may be granted high autonomy, but they won’t have the ability to deliver for the organization.

The ideal design is that each team has an end-to-end process they manage (i.e. Stream-Aligned Teams), which gives them both autonomy and a clear performance outcome.

It's hard to see dependencies between teams unless they're made visible and tracked. There are many ways to track dependencies. Spotify tracked them on a spreadsheet. In a Kanban design, they can be tracked with checkboxes or rows.

Any team that can work on end-to-end tasks, like a specific process, from start to finish, will have autonomy. Combine that with decision-making power and you have true autonomy.

Forming a basic level of trust is key to group formation and high-performing teams. Trust is hard. Luckily, we don't need complete trust.

There are two dimensions to trust - moral and practical. The moral dimension is usually the difficult one for many people. It's about trusting one another's motives.

The practical dimension is about trust in each other's competence. If you don't trust that I can do the work, you may trust that I mean well, but you don't trust that I can get the job done. And lack of practical trust is damning.

Each dimension matters and each takes time to develop. One way to shortcut the "time" element is through intensity - which means working together, communicating, and building the relationship.

When trust is high, the need to build accountability tools so that people can "check on" one another is drastically lessened. In high-trust situations, people take responsibility and don't need to always be held to account.

Trust can be viewed on a spectrum. It's rare we totally trust or completely distrust a person. I like Tobi Lütke talks about "the trust battery" as a metaphor for this spectrum.

Collective intelligence is more powerful than individual intelligence. When we create psychological safety for people to be themselves, to speak openly without recrimination, and to make mistakes, we can create high collective intelligence and enable high performance.

Research shows that teams with socially sensitive people who exhibit inclusive behaviors create psychological safety. When individuals on a team have high social sensitivity - when they understand how others feel - teams perform better.

Social sensitivity can be gauged through a test called "Reading the Mind in the Eyes". People who have high social sensitivity know when people are upset, when people feel left out of the group, and are empathetic towards others.

Teams in which individuals speak in roughly the same proportion perform better than those in which some members speak and lot and others speak very little.

Inclusive behaviors like allowing everyone in a meeting to speak and feel heard is a core behavior in fostering psychological safety in teams.

From Google's Project Aristotle findings and subsequent work in defining the behaviors that create psychological safety in groups, Google has a list of actions to improve psychological safety.

What are the various skills we have on the team? What are we capable of? What are we missing? With a new team, listing the needed skills for a project and having people put their names in boxes is helpful. Using some kind of scoring and differentiation between interest level and proficiency can also guide the team.

One of my favorite tools, as it explains very briefly who you are and what you care about, and it can be referenced by others throughout the organization. People putting one together for the first time seem to learn a decent amount of about themselves, too. Bridgewater uses "Baseball Cards."

From the NVC framework.

Make people feel heard following this highly prescriptive method from The Great CEO Within. Matt Mochary says you can do it verbally or in writing, and following the process in writing is his preference because it doesn't require a facilitator.