Effective Teams
Effective Teams

Effective Teams

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.

What Constitutes a Team?

Team Components

Teams have five common components, according to Steve Sugar:

Shared Leadership
Mutual Responsibility
Conscious Authority
Agreed-On Goals
Mutual Effectiveness.

Shared Leadership

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.

Mutual Responsibility

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

Conscious Authority

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.

Agreed-On Goals

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.

Mutual Effectiveness

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.

The Spectrum of Teams

Teams Are Performance-Focused

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.

"A team is a small group of people (typically fewer than twenty) with complementary skills committed to a common purpose and set of specific performance goals. Its members are committed to working with each other to achieve the team's purpose and hold each other fully and jointly accountable for the team's results. Teamwork encourages and helps teams succeed; but teamwork alone never makes a team." (Source: The Wisdom of Teams)

Working Groups vs. 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.

1. Working group. "The members interact primarily to share information, best practices, or perspectives and to make decisions to help each individual perform within his or her area of responsibility. Beyond that, there is no realistic or truly desired 'small group' common purpose, incremental performance goals, or joint work-products that call for either a team approach or mutual accountability."
2. Pseudo-team. "There could be a significant, incremental performance need or opportunity, but it has not focused on collective performance and is not really trying to achieve it. It has no interest in shaping a common purpose or set of performance goals, even though may call itself a team. Pseudo-teams are the weakest of all groups in terms of performance impact. They almost always contribute less to company performance needs than working groups because their interactions detract from each member's individual performance without delivering any joint benefit."
3. Potential team. "There is a significant, incremental performance need, and that really is trying to improve its performance impact. Typically, however, it requires more clarity about purpose, goals or work-products and more discipline in hammering out a common working approach. It has not yet established collective accountability."
4. Real team. "A small number of people with complementary skills who are equally committed to a common purpose, goals, and working approach for which they hold themselves mutually accountable."
5. High-performance team. "A group that meets all the conditions of real teams, and has members who are also deeply committed to one another's personal growth and success. That commitment usually transcends the team. The high-performance team significantly outperforms all other like teams, and outperforms all reasonable expectations given its membership."

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.

How Teams Become Effective

Forming, Storming, Norming, Performing

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.

Forming is the initial stage, where team members wonder how they fit in, behave politely, and look to create clear structure, goals, roles and direction for the team. They often look to a leader to answer questions and ease anxiety.
Storming is the stage where the excitement wears off and the team shifts to concern and frustration. The group isn't making enough progress, and conflict breaks out. The team needs to resolve conflict, refocus on goals, and reprioritize tasks.
Norming is the stage occurs when the group begins to resolve the frustration and meet their own expectations for performance. People feel more acceptance toward one another, build trust, and communicate more openly and frequently.
Performing occurs when the team starts seeing real progress. People feel a sense of belonging, and feel confident in the teams' overall ability. They form tight bonds, they have fun, and they get results. Still, a focus on improving practices and rituals as the context changes is critically important to preserving high performance.

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.

"A team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level." (Source: Team Topologies)

Team Structures

Different Structures for Different Challenges

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.

Team Size

💡
"Athletic teams...usually consist of fifteen to thirty people. Army Ranger platoons are composed of forty-two soldiers. SEAL squads contain between sixteen and twenty people. Beyond such numbers, teams begin to lose the "oneness" that makes them adaptable. As the proverbial kitchen fills up, communication and trust break down, egos come into conflict, and the chemistry that fueled innovation and agility becomes destructive." - Stanley McCrystal (Source: Team of Teams)

Hunting Parties & Cliques

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.

Size = 5-9

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.

image

"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.

The Smaller, The Less Social Loafing

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.

Team Authority

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.

In Manager-led teams, team members execute tasks, but a manager decide what work to do, shapes the work, chooses how it will be done, and evaluates and reports on the results. The manager is the accountable party for results.
In Self-Managing teams, team members decide how the work will be done. These teams decide whether they'll use agile, Scrum, or Kanban methods, and how they'll interact with one another - the processes and procedures they'll use to get things done. The team is accountable for results.
Self-Designing teams decide who is on the team, may have hiring and firing authority, and decide what tasks will be done, with a Manager only setting a goal for the team.
Self-Governing teams are the most autonomous, deciding what work will be done, how it will be done, and what the mission of the team is.

The Right Context & Support for Autonomy

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.

🧰
Buurtzog is an example of an organization that uses coaches to pull off self-management at scale (Source: Reinventing Organizations):
  • Teams are given training, coaching and tools to make self-management work
  • People are trained on skills for group decision-making - different types of listening and styles of communication, how to run meetings, how to coach one another, etc.
  • They use a very precise and efficient method for joint problem solving
  • If a team gets stuck they can get an outside facilitator to help and get suggestions from their internal social network.
  • No regional managers to back up teams, only "regional coaches" who have no decision-making power over teams - they're not responsible for team results. Coaches have 40-50 teams so they can't get too invested in solving problems for any one team.

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.

🧰
Buurtzog's team principles are:
  • Teams no more than 12 people
  • Teams should delegate tasks widely so they don't organize into a traditional structure
  • Teams have regular meetings but also regular coaching meetings to discuss specific issues encountered with patients and learn from each other (using a group coaching technique)
  • Team members appraise each other every year, based on competency models they can devise themselves.
  • Teams make yearly plans for initiatives they want to take on in areas of client care and quality, training, organization, etc
  • Target for billable hours in mature teams is 60-65%
  • Teams make important decisions based on specific decision-making technique.

Two Breakdowns of Team Types

Product, Feature & Component Teams

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

  • Product Teams build the product. For less mature products with fewer features, a Product Team can work from end-to-end on a product. In an early-stage startup, a single Product Team can manage the entire product. As an organization adds new Products, they add new Product Teams to manage them. These teams manage to business results, not outputs (i.e. new features & components), and can therefore measure their performance using business and financial metrics. As features are added to a single product, single Product Teams can no longer manage the entire product, and the need for new team types emerges.
  • Feature Teams are cross-functional teams that build customer-facing features within a product. To assemble and utilize these teams, products must be divided into areas so that teams can work end-to-end with limited dependencies on nearby Feature Teams. They generally work from a backlog, fed by tight feedback loops driven by customer feedback.
  • Component Teams build components for products. While those individual components may not be customer-facing, they provide the needed infrastructure so that products have value to customers. Component teams might focus on the underlying database or the user interface or security and compliance.

Stream-Aligned, Platform, Enabling, Complicated-Subsystem Teams

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.

Stream-aligned teams are assigned to a single stream of work - it could be a single product, a set of features, a part of the user journey, or a persona. They work as independently as possible and every other team type revolves around the Stream-aligned team - enabling them to perform better. Their mission is to deliver value.
Platform teams build internal services that underlie the product. This frees up Stream-aligned teams to deliver products without having to build infrastructure. They build APIs and portals for Stream-aligned teams to use.
Enabling teams help Stream-aligned teams handle complex problems, by finding tooling, practices, and frameworks to help Stream-aligned teams get the job done. They often function like internal consultants. They help speed up delivery by providing expertise that the more generalist-staffed Stream-aligned teams don't have.
Complicated-Subsystem teams build and maintain parts of the product that need specialized knowledge that Stream-aligned teams don't have. Instead of attempting to staff highly specialized people on every Stream-aligned team, the Complicated-Subsystem team takes on that work.

"Two-Pizza" Stream-Aligned Team Principles

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.

🧰
A two-pizza team will:
  • Be small. No more than ten people.
  • Be autonomous. They should have no need to coordinate with other teams to get their work done. With the new service-based software architecture in place, any team could simply refer to the published application programming interfaces (APIS) for other teams.
  • Be evaluated by a well-defined "fitness function." This is the sum of a weighted series of metrics. Example: a team that is in charge of adding selection in a product category might be evaluated on:
    • a) how many new distinct items were added for the period (50 percent weighting)
    • b) how many units of those new distinct items were sold (30 percent weighting)
    • c) how many page views those distinct items received (20 percent weighting)
  • Be monitored in real time. A team's real-time score on its fitness function would be displayed on a dashboard next to all the other two-pizza teams' scores. The team will
  • Be the business owner. The team will own and be responsible for all aspects of its area of focus, including design, technology, and business results. This paradigm shift eliminates the all-too-often heard excuses such as, "We built what the business folks asked us to, they just asked for the wrong product," or "If the tech team had actually delivered what we asked for and did it on time, we would have hit our numbers."
  • Be led by a multi-disciplined top-flight leader. The leader must have deep technical expertise, know how to hire world-class software engineers and product managers, and possess excellent business judgment.
  • Be self-funding. The team's work will pay for itself.
  • Be approved in advance by the S-Team. The S-Team must approve the formation of every two-pizza team.

Dividing The Work

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.

Fracture Planes

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

"Traditional stonemasons hit stones at particular angles to split the rocks in clean segments, taking advantage of their natural fracture planes. We can look for similar fracture planes in software to find the natural split points that lead to software boundaries." (Source: Team Topologies)

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):

Regulatory Compliance - "In highly regulated industries, like finance or healthcare, regulatory requirements can often provide hard borders for software. They often require organizations to adopt specific mechanisms for auditing, documenting, testing, and deploying software that falls within the scope of those regulations, be it credit card payments, transaction reporting, and so on."
Change Cadence - "With a monolith, every piece moves at the speed of the slowest part. If new reporting features are only needed and released on a quarterly basis, then it will likely become very hard, if not impossible, to release other types of features more frequently than that, as the codebase is in flux and not ready for production. Changes get lumped together, and the speed of delivery gets seriously affected."
Risk Different - "Risk profiles might coexist within a large monolith. Taking more risk means accepting a higher probability of system or outcome failure in favor of getting changes into the hands of customers faster."
Performance Isolation - "Differentiating levels of performance might be beneficial. Of course, performance should always be a concern for every system; and it should be analyzed, tested, and optimized where possible. However, parts of applications subject to peaks of demand at a large scale (like yearly tax submissions on the last day), require a level of scaling and failover optimization not necessary for the rest of the system."
Technology - "Technology is often (historically) the only type of boundary used when splitting up teams. Consider how common it is to have separate teams for front end, back end, data tier, etc. However, these common kinds of technology-driven splits typically introduce more constraints and reduce flow of work rather than improve it. That is because the separate teams are less autonomous, as product dependencies remain while each team has less visibility on the work as a whole, and interteam communication paths are slower than intra-team."
User Personas - "As systems grow and expand their feature sets, their customer base (internal or external) also grows and diversifies. Some groups of users will rely on a given subset of features to get their jobs done, while other groups require another subset. In products with tiered pricing, the subset is built in by design (higher paying customers have access to more features than lower or non-paying customers). In other systems, admin users have access to more options and controls than regular users."

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

How Teams Coordinate

💡
"Teams of teams operate as 'cells' in the network, each with their own purpose and their own user(s). Talent and information flow freely. Over time the whole thing comes to look more like a marketplace than an org chart. Sure, hierarchies still emerge, but they are hierarchies of influence, reputation, and the work itself." (Source: Brave New Work)

How Do Teams Work Together?

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.

Familiarity Across Teams

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.

"We just needed everyone to know someone on every team, so that when they thought about, or had to work with, the unit that bunked next door or their intelligence counterparts in D.C., they envisioned a friendly face rather than a competitive rival...We needed to enable a team operating in an interdependent environment to understand the butterfly-effect ramifications of their work." - Stanley McCrystal (Source: Team of Teams)

How Do Teams Fit The Broader Structure?

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.

🧰
Spotify organized a now well-studied matrix organization where their teams (Squads) fit into Tribes (departments). They layered two lateral features - Chapters (similar to Communities of Practice), and Guilds ("Communities of Interest"). Chapters and Guilds aimed to help Spotify adopt helpful standards, build expertise, and create community outside of the atomic team.
🧰
Atlassian assembled teams (of 5-7) into Triads for each of their "Make," "Sell" and "Operate" structures. "Make" Triads included Product Management, Design, and Development, with specialized PMs focused on understanding the market and target personas. "Sell" Triads included Product Management, Design, and Marketing, with specialized PMs focused on the product's competitive landscape and overall market. "Operate" Triads included Product Management, Development and Support & Ops, with PMs focused on customer feedback.

Choose A Team Interaction Mode

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

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.

"Expect to have high interaction and mutual respect with the collaborating team. This typically means that team members should expect activities to take much longer than they might expect as the 'boundary spanning' aspects of collaboration discover and solve previously unknown problems." (Source: Team Topologies)

X-as-a-Service

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.

Facilitating

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.

Tactics for Networks

Central Repository

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:

"Everyone in the product teams synchronizes with the repository several times a day and will get all the changes that other people have made. So, when you update, spend two minutes going over the changes that were made by others and see if they relate to what you are working on now." (Source: Coordination & Integration)

Communities of Practice

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.

"The purpose of a COP is for participants to learn and share ideas, document lessons learned, standardize ways of working, initiate newcomers, provide advice, explore new technologies, and maybe even apply some forms of governance. A COP can cut across teams, products, business units, and other organizational boundaries. In doing so, it helps to strengthen the social network." - Jurgen Appelo (Source: Managing for Happiness)

Meetings

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

🔨
Scaled Daily Scrum is a Scrum@Scale meeting type where teams come together, either daily or 2-3x/week to answer:
  • What impediments does a team have that will prevent them from accomplishing their Sprint Goal or that will impact the delivery plan?
  • Is a team doing anything that will prevent another team from accomplishing their Sprint Goal or that will impact their delivery plan?
  • Have any new dependencies between the teams or a way to resolve an existing dependency been discovered?
image

Source: Scrum @ Scale

Scouts

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.

What Teams Need

Goals

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

"Significant performance challenges energize teams regardless of where they are in an organization. No team arises without a performance challenge that is meaningful to those involved...a common set of demanding performance goals that a group considers important to achieve will lead, most of the time, to both performance and a team." (Source: The Wisdom of Teams)

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.

Alignment

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

What is Alignment?

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.

How Alignment Works

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:

"Is everyone receiving the necessary information? Is the information useful? Is there information a team is not receiving that it needs? Are the team's meetings effective? Does the team have too many or too few meetings? Do team members take time to listen to one another, or do they assume that listening has occurred?" (Source: Games That Teach Teams)

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

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

🔨
Team Charter (Source: Organizing Effective Teams)
  • Team Values and Goals: What are our shared team values? What is our team goal?
  • Team Roles and Leadership: Who does what within this team? (Who takes notes at the meeting? Who sets the agenda? Who assigns tasks? Who runs the meetings?) Does the team have a formal leader? If so, what are his or her roles?
  • Team Decision Making: How are minor decisions made? How are major decisions made?
  • Team Communication: Who do you contact if you cannot make a meeting? Who communicates with whom? How often will the team meet?
  • Team Performance: What constitutes good team performance? What if a team member tries hard but does not seem to be producing quality work? How will poor attendance/work quality be dealt with?

Alignment & Conflict

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)

"The free flow of conflicting ideas is critical for creative thinking, for discovering new solutions no one would have come to on his own. Conflict becomes, in effect, part of the ongoing dialogue." - Peter Senge (Source: The Fifth Discipline)

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.

"We either struggle against or we struggle with. Struggling against is a process of opposition and destruction... Struggling with is a process of mutuality and creation. It’s about seeing the solution as a two-way street, viewing the struggle as an opportunity for a win-win outcome, and adopting an attitude of shared responsibility for resolving the discrepancy between what we want and what we’re experiencing." - Nate Regier (Source: Conflict Without Casualties)

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.

Autonomy

How Much Autonomy?

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:

"Contrary to the commonly held belief in the management and academic communities that self-managed or autonomous teams are preferable to closely-managed teams, the evidence suggests that non-autonomous teams are no worse, regardless of the autonomy measure considered." - Jed DeVaro (Source: Teams, Autonomy, and the Financial Performance of Firms)

Limit Dependencies

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.

"When a bunch of two-pizza teams with lots of dependencies between them spend a lot of time coordinating to avoid stepping on each other's code (due to the merging of the different teams' code branches), the benefit of the small team diminishes." - Dominica DeGrandis (Source: Making Work Visible)

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.

"The designer tries to create an end-to-end task so that the team has a complete piece of work. In this manner, the team controls most of the factors that influence its performance outcomes. The team can then be independently measured on its performance and held accountable for it. Management can give considerable decision-making power to such a group." - Jay R. Galbraith (Source: Designing Organizations)

Track Dependencies

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.

Trust

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.

"People on real teams must trust and depend on one another - not totally or forever - but certainly with respect to the team's purpose, performance goals, and approach." (Source: The Wisdom of Teams)

Two Dimensions of 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.

"I will trust you if I am confident in your motives. In the end, people who optimize their own interests over those of the collective should depart. We can usually identify them, and a good briefing process will help to flush them into the open." - Stephen Bungay (Source: The Art of Action)

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.

“I may be quite willing to trust you to drive me to the airport, but not trust you to fly me across the Atlantic. So it is up to me to create a context in which I can trust you." - Stephen Bungay (Source: The Art of Action)

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.

"Often when the mind doesn’t know, it assumes a potentially negative outcome or intention. And when we assume the negative, we become suspicious. In turn, that suspicion leads to a lack of trust. This bad cycle has an easy answer: communicate frequently." (Source: CEO Tools 2.0)

As Trust Increases, The Need for Accountability Tools Decrease

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.

"We talk about the trust battery as a metaphor quite casually...I can have a conversation with someone saying, 'Hey, you made a commitment to ship this thing, and you did. That's awesome. That's a super big charge on the trust battery, but you’re actually late for every meeting. Even though that's relatively minor — like it decreases 0.1% on your battery — you should fix that.' - Tobi Lütke (Source: Tobi Lütke)

Psychological Safety

Psychological Safety Creates Collective Intelligence

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.

"To feel ‘'psychologically safe,'’ we must know that we can be free enough, sometimes, to share the things that scare us without fear of recriminations. We must be able to talk about what is messy or sad, to have hard conversations with colleagues who are driving us crazy." - Charles Duhigg (Source: What Google Learned From Its Quest to Build The Perfect Team)

Members With Social Sensitivity

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.

Turn-Taking and Inclusive Behaviors

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.

Google's Full List of Psychological Safety Behaviors

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.

🔨
Demonstrate engagement
  • Be present and focus on the conversation (e.g., close your laptop during meetings)
  • Ask questions with the intention of learning from your teammates
  • Offer input, be interactive, and show you’re listening
  • Respond verbally to show engagement (“That makes sense. Tell us more.”)
  • Be aware of your body language; make sure to lean towards or face the person speaking
  • Make eye contact to show connection and active listening
🔨
Show understanding
  • Recap what’s been said to confirm mutual understanding/alignment (e.g., “What I heard you say is…”); then acknowledge areas of agreement, disagreement, and be open to questions within the group
  • Validate comments verbally (“I understand.” “I see what you’re saying.”)
  • Avoid placing blame (“Why did you do this?”) and focus on solutions (“How can we work toward making sure this goes more smoothly next time?”, “What can we do together to make a game plan for next time?”)
  • Think about your facial expressions- - are they unintentionally negative (a scowl or grimace)?
  • Nod your head to demonstrate understanding during conversations/meetings
🔨
Be inclusive in interpersonal settings
  • Share information about your personal work style and preferences, encourage teammates to do the same
  • Be available and approachable to teammates (e.g., make time for ad hoc 1:1 conversations, feedback sessions, career coaching)
  • Clearly communicate the purpose of ad hoc meetings scheduled outside normal 1:1s/team meetings
  • Express gratitude for contributions from the team
  • Step in if team members talk negatively about another team member
  • Have open body posture (e.g., face all team members, don’t turn your back to part of the group)
  • Build rapport (e.g., talk with your teammates about their lives outside of work)
🔨
Be inclusive in decision-making
  • Solicit input, opinions, and feedback from your teammates
  • Don’t interrupt or allow interruptions (e.g., step in when someone is interrupted and ensure his/her idea is heard)
  • Explain the reasoning behind your decisions (live or via email, walk team through how you arrived at a decision)
  • Acknowledge input from others (e.g., highlight when team members were contributors to a success or decision)
🔨
Show confidence and conviction without appearing inflexible
  • Manage team discussions (e.g., don't allow side conversations in team meetings, make sure conflict isn’t personal)
  • Use a voice that is clear and audible in a team setting
  • Support and represent the team (e.g., share team’s work with senior leadership, give credit to teammates)
  • Invite the team to challenge your perspective and push back
  • Model vulnerability; share your personal perspective on work and failures with your teammates
  • Encourage teammates to take risks, and demonstrate risk-taking in your own work

Tools for Teams

Team Foundation

Team Charter

🔨
Define the team's purpose and work in detail. From Brave New Work:
  • Why does this team exist?
  • How do we contribute to the organization's success?
  • What are we accountable for?
  • What is our essential intent for the next ___ days?
  • How will we know if we've succeeded?
  • What principles will guide us?
  • What will we prioritize for the next ___ days?
  • What are the roles required to do this work?
  • What roles will we each play?
  • Are there any roles not yet claimed?
  • What do we expect of one another?
  • Who are our users or customers?
  • What decision rights do we have?
  • What can we do without asking permission?
  • Within what guardrails do we have autonomy?
  • Are we responsible for anything that we don't control?
  • How will we make decisions?
  • What resources do we control?
  • What is our meeting rhythm?
  • How often will we conduct retrospectives?
  • What tools will we use to communicate and coordinate?
  • How will we share our work with one another and the organization?
  • What are the learning metrics that will help us steer?
  • How will we know if we're making progress?

Team Alignment Map

  • The Team Alignment map can be used to close meetings or can be used to structure conversations in a team meeting.
🔨
A simple tool that could be used in place of a Team Charter or in addition to a Charter. The Team Alignment Map is a Strategyzer tool.

Competency Matrix

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.

🔨
A couple of good guides: here and here.

Team Building

User Manual

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."

🔨
Khe Hy's Guide uses these prompts:
  • My work style
  • What I value
  • What I don’t have patience for
  • How best to communicate with me
  • My typical schedule
  • How to help me
  • What people misunderstand about me

Life Story Presentation

🔨
Have team members present their life story, or prepare another kind of presentation that can get people to share who they are and what's important to them. These can be simple slide presentations that take 15-30 minutes each.

One-Word-To-Describe-Them

🔨
A practice used in my Vistage group during anniversaries. Every member of the group describes the member with one word. This helps provide a positive feedback loop for the individual and seems to increase the sense of belonging in the group.

Conflict Resolution

The Nonviolent Requests Guide

From the NVC framework.

🔨
State your Observation, then your Feeling, then your Needs, and then make a Request.
  • When you [blank]
  • I feel [blank]
  • My need is [blank]
  • Would you please [blank]

Conflict Resolution Process

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.

🔨
If you are the facilitator, here’s how it works (the written method):
  • Step 1: Ask each person to write down their deepest thoughts about the other person.
    • You say:
      • “Open up a Doc. Please give me (the facilitator) access, but do not give access to the other person yet.”
      • “On the doc, write 5 categories:
        • Anger (present)
        • Fear (future)
        • Sadness (past)
        • Joy (present and past)
        • Excitement (future)”
      • “When you think about the other person, and you focus on the Anger that you feel, what thoughts come to mind? Please state those thoughts in the following way":
        • Feeling. I felt anger when …
        • Fact. I saw you doing ….
        • Story. The thought (or judgement) that I had was ….”
    • "Look at both docs and make sure that they are filled out correctly. Encourage the separation of fact and judgement as much as possible. Make sure they are as specific as possible about the actions the other person did and how it made them feel...Make sure there are no sweeping statements or value judgements."
    • "Ask each participant to cut-and-paste the Joy and Excitement sections to the top of the doc. For the person sharing their emotions and thoughts, it is hard to feel Joy and Excitement until they have first written down their thoughts around Anger and Fear. But when the recipient reads the doc, it is best for them to first see how the sharer actually has positive thoughts about the recipient. This validates the relationship and motivates the recipient to do what is needed to repair that relationship."
  • Step 2: Person A (the person with less power in the relationship) shares access to their doc with Person B.
    • Person B reads Person A’s thoughts around Joy and Excitement about Person B. Person B should simply say “thank you” to Person A when she reads these thoughts.
    • Person B then reads Person A’s first thought around Anger about Person B. You, the facilitator, then follow this script:
      • Facilitator asks Person B: “Do you want to make Person A feel Anger and have these thoughts?”
      • Person B: “No.”
        • "If the answer is “yes”, then the two should not be in relationship together. That means that one will likely need to be let go from the organization...the person to be let go should usually be the person who wants the other to feel anger."
      • Facilitator to Person A: “What request do you have of Person B?”
      • Person A: “Please do the following: ….”
    • If Person B agrees, have Person B write down the action item (with their initials and a due date) just below the fact/judgement of Person A.
    • Facilitator to Person A: “Do you feel heard? Do you feel that Person B wants to have a positive relationship with you?”
      • Person A: “Yes.”
        • If the answer is “no”, get curious and find out why. Repeat the steps above again until the answer is “yes”.
  • Step 3: Person B shares access to their doc with Person A.
    • Repeat the same script as in Step 2.
  • Step 4: When the ah-ha moment of understanding occurs, seal it with a physical connection: a hug, a handshake, a high-5.
  • Step 5: Ask each person for feedback on the process.
  • Step 6: Set a meeting for 1-2 weeks out between Person A, Person B and the Facilitator.