Introduction When Bad Things Happen to Good Teams
Paul Davidson (not his real name) and his team of three engineers had just received permission to work on the second version of a software product that promised exciting things for the company. They brought in ten more engineers and set about including all the features they thought customers wanted. Paul had just finished a course in machine learning and was anxious to apply his new knowledge. After working hard to get an elegant design and prototype, the team put together an overall plan, identifying tasks and setting achievable delivery dates. The team members committed to the schedule, agreed on a clear set of goals, and moved into full-scale implementation. Excitement was high. They knew what they wanted to build and hoped to show top management just how well they could deliver on those specs.
Then, a few months into the schedule, an upper-level manager suggested that the product be changed to meet some needs that customers had raised. Paul was reluctant to make the changes, saying that the team members were committed to the schedule and didn’t want to do anything to jeopardize meeting their deadlines. They were on a crusade to show that machine learning works, and they would meet their schedule no matter what. The team members saw the manager as engaging in some kind of power play; the manager felt that the team was inflexible and unresponsive.
When layoffs came, the team lost two members and resentment grew. Paul’s request that more people be assigned to the project was denied. Deadlines slipped, two more team members left, morale dropped, and Paul left the company—feeling that he had no future with such an inhospitable organization. None of the other three original engineers wanted to fill the void, and the team just kept falling further and further behind—while they all circulated their résumés.
How did a team that started off with so much talent and enthusiasm end up failing? Here was a group that considered customer needs—or at least what members thought the customer needed—and strove for efficiency. Here was a set of people who worked well together, committed to a plan, and were motivated to make that plan a reality. They were excited and energized, and then it all fell apart for one primary reason: the team was too inwardly focused.
This diagnosis may surprise you, given that focused, inward-looking teams have traditionally been considered ideal. But this approach can lead to negative outcomes. For example, the team’s inward focus caused it to build a wall between itself and the outside world. Team members came to believe that they had the answers and that anyone who disagreed with them was wrong, and perhaps even had bad motives. They became more and more rigid in their practices and beliefs, eventually seeing everything through an us-versus-them lens. The more negative feedback they received, the more they rebelled against what the company and customers were asking of them. A vicious downward spiral ensued.
We have seen many teams fail, or slowly decline, just as Paul’s did. One such team in the financial services industry had a highly promising product, but because members failed to get buy-in from division managers, they saw their product slowly starve from lack of resources. Another group, in a computer company, worked well as a team but did not gather important competitive information. Its product was obsolete before launch.
These stories are doubly sad because they are about good teams made up of talented, committed individuals. These are teams that seem to be doing everything right—establishing roles and responsibilities, building trust among members, defining goals—and nevertheless see their projects get axed.
Why do bad things happen to good teams? As we have already begun to explore in our analysis of Paul’s story, teams often fail because their members are following the models and theories presented in bestselling books on team effectiveness. This view of performance, which dominates executive team training, asserts that to succeed, teams simply need to focus within—on their own process, on the problem at hand, and on their members as collaborative colleagues. This is the mental model that often guides our actions when we create teams and set their agendas. This is the model that feels comfortable to most people—they want to be part of a team whose members care about each other and get the job done quickly. And this is the model that makes us effective at shaping the internal dynamics of teams—how to build team spirit and work around a conference table, how to make rational decisions and allocate work, how to set goals and create roles for individual members.
The problem is that this model of internal focus doesn’t work so well anymore. Fierce innovation-driven competition has forced dramatic changes in organizational life. As competitive wars rage, battles are being won with weapons of creativity, agility, and organizational linkages, creating synergies that efficiently satisfy customer needs. Organizational teams are increasingly called on to lead these battles.
In this new world, leadership can no longer exist only at the top of the organization; it must also be distributed throughout the organization and shared with teams. When innovation is king and keeping your finger on the pulse of technology and changing markets is critical, it is no longer the case that someone at the top will figure it all out and everyone else will execute the plan. When organizations are faced with complex problems and resources are dispersed, leadership needs to be spread across many players, both within and across organizations, up and down the hierarchy—wherever information, expertise, vision, commitment, and new ways of working together reside. In this world of distributed leadership, teams cannot look solely inward.1 Called to take on a new leadership role, they must become the eyes that read the changing environment; the people who bring commitment and energy to the task; the visionaries who help shape a new future; and the inventors of innovative solutions for business. Now teams must work with others to enact distributed leadership as they innovate and create change.
Therefore, the old way of carrying out teamwork, with its focus on the team’s internal dynamics, is only half of the story. The other half—managing externally, across team boundaries—gets ignored. And being only half right means that you are half wrong. We are not suggesting an either/or. The ideal is to have an internal focus combined with an external approach. Evidence now exists to suggest that a team’s success at leading, innovating, and getting things done requires managing both inside and outside the group. That’s where x-teams come in.
The Other Half of the Story: X-Teams
What does managing both inside and outside the team look like? Consider the Cascade team at Microsoft. The team was formed in 2016 when company management, led by Amanda Silver, a vice president in the developer division, was grappling with the question of whether Microsoft could grow a profitable tools development business, leveraging Microsoft platforms for use by a broader range of developers than they were currently serving. In the spirit of distributed leadership, a team was formed to move ahead. They realized that the market for software developer tools was rapidly evolving to meet the needs of an emerging generation of web developers. Such a set of products could help the company adapt as industry preferences shifted over time, a trend accelerated by the cloud. The team’s challenge was to see if they could unlock entirely new experiences and ways of developing in the era of the cloud. To remain competitive and spearhead industry transformation, Microsoft would need to get to know the new generation of developers and create novel tools for them.
To understand this new customer segment, Cascade brought in exploratory market researchers to carry out in-depth interviews with next-generation developers—a move that it felt was justified given top management’s views about people having the freedom to think and act differently for greater innovation and learning. The research team eventually saw patterns in the work challenges and experiences that modern developers described. Most notably, the market was in dire need of products that facilitated teamwork. Software development is like a team sport—yet at the time, all the tools on the market were focused on the individual experience. None offered capabilities for developers who worked in teams and needed to collaborate. To address this problem, Cascade developed a real-time collaboration tool called Live Share, a multiauthor collaboration system that enabled simultaneous editing regardless of the programming language a member was using or the apps they were developing—like a Google Doc but for coding.
The team’s efforts resulted in tremendous success. Live Share was one of the very first forays into the subscription service space for developer tools, and it helped with Microsoft’s customer acquisition in the developer space. After Live Share, the team continued to innovate based on Cascade’s early research. Another set of products came out of the idea that you could have an AI “buddy” called Intellicode to help with coding. This took some time to develop, since the technology was mostly science fiction at the time of the early research. Finally, the early research showcased the problem of developer machine setup and consistency for both teams and individuals. This spark led to another series of products. The company is now the dominant provider of software tools in terms of global usage, with over 25 million users—more than 50 percent of the world’s developer population. Furthermore, competitors are now mirroring what Cascade started. The challenge now is where to focus, given the many insights from the early work.
Beyond Cascade’s successes in the market, the Cascade team itself had a huge impact on how Microsoft approached innovation (explained in greater detail below), demonstrating how a small innovative group can fundamentally change a larger organization. The team served as the poster child for the shift from a know-it-all culture to a learn-it-all one—a shift that had been championed by the company’s CEO, Satya Nadella. Not surprisingly, Live Share became a central example used to teach new employees how to engage in continuous learning and distributed leadership, accessing expertise and talent wherever possible both within and outside of Microsoft.
The Cascade team is what we call an x-team. The “x” underlines the point that the team is externally oriented, with members working outside their boundaries as well as inside them. The “x” also emphasizes what years of research and practice have shown: while managing internally is necessary, managing externally enables teams to lead, innovate, and succeed in a rapidly changing environment.2 An x-team differs from a traditional team in three main ways.
- X-teams focus externally (outside the team). To create effective goals, plans, and designs, members must go outside the team; they must have high levels of external activity—both within and outside the company as well as the team. Cascade did this in many ways. For instance, within the company, the team sought regular feedback from senior leaders and interacted with them on an ongoing basis. When team members gave presentations to leadership, these presentations were two-way conversations. One of the product developers noted: “We would still do a deck and we would present, but it wasn’t like we were doing an end-of-the-quarter business review kind of thing. It was a little more like [senior leaders] were part of the team. They knew all the mistakes or problems, so we reported back to them and they’d give us pointers.” This approach allowed team members to consider how much enthusiasm leadership showed for different ideas in the presentations, helping them pinpoint ideas with the greatest business interest.
The team also remained externally oriented in how it looked outside the company. Members spent hours with customers to understand what work problems they had, which industry sectors mattered most, where their products could make the most difference, and which ones customers would pay for. They also looked to competitors to ascertain where they were in their development. They found that most of their competitors had impractical solutions or were doing a less sophisticated version of what they were contemplating. They also learned that they had identified important, solvable problems that others had not. Thus, the Cascade team found the closest approximation to competitors’ products and examined what Microsoft could do differently or better. For example, the team looked at Google Docs, because it already had a solution for how multiple authors collaborate in a document. Cascade translated this knowledge into its own work, considering the differences in how two people work on one document and how they work on a large codebase with many different files. Despite all of this looking, GitHub actually came out with a similar product on the same day—both companies had been working behind closed doors, so this was a surprise. They ended up collaborating on solutions.
- X-teams combine their productive external activity with robust processes inside the team. They achieve this by developing internal processes that enable members to coordinate their work and execute effectively. For example, in its product development phase, Cascade fostered a sense of openness to new ideas, which allowed team members to feel comfortable making mistakes and sharing novel product concepts. As one team member noted, “We did so much learning.… It was a constant, continuous learning process from start to finish. That’s the thing that sticks in my mind. We just never stopped learning.” As a result, the team seamlessly coordinated external processes, remained cohesive, and integrated new information and expertise. Cascade also constantly incorporated new customer feedback in creating Live Share and set up a Slack channel to get suggestions on Live Share. Every day the research team would go into the Slack channel, read through the messages that had come in, and share the input with the rest of the team.
- X-teams incorporate timely transitions, shifting their activities over the team’s lifetime. Cascade members engaged in exploration—learning about customer needs, organizational expectations, and their own passions about what they wanted to create. Then they continued on to experimentation and execution—actually developing the software that customers wanted and that competitors did not yet have. Finally, they moved to exportation—transferring their learnings to the developer division more broadly. Across these transitions, the Cascade team shifted people and processes. For example, Cascade members entered and exited the team as different expertise was required for different phases of the work. So, while the external market research group was brought in at the beginning, once the team had developed a strong understanding of its clients, Microsoft product designers were brought in, then employees in software engineering, then people in marketing, and so on. As with other effective x-teams, Cascade changed its processes over time to keep the product moving along and to deal with the demands that different phases of a task presented.
Together, these three elements—external activity, a robust internal environment, and timely transitions—form the principles by which x-teams guide themselves.
X-teams have helped firms solve complex problems, adapt to changing conditions, innovate, and gain competitive advantage. Their entrepreneurial focus aids them in getting resources and in seeking and maintaining buy-in from stakeholders. Their links to top management, customers, competitors, and technologies enable them to link high-level strategy with knowledge and ideas from the ground up. Their external focus helps them respond more nimbly than traditional teams can to the rapidly changing characteristics of work, technology, and customer demands, and to more effectively link their work to other organizational initiatives.
X-teams consistently outperform traditional teams across a wide variety of functions and industries. One x-team in the energy business has done an exceptional job of disseminating an innovative exploration method throughout the organization. X-teams in sales have brought in more revenue to a telecommunications company. Drug development x-teams have been more adept at getting external technologies into their companies. Product development x-teams in the computer industry have been more innovative and have outperformed traditional teams on time and budget metrics. Management consulting x-teams have been better able to serve client needs. Startup x-teams have attracted more investments from venture capital firms. C-suite x-teams have executed strategic change initiatives more effectively.
Will every team that is internally focused fail? Should every team be an x-team? The answer is clearly “no.” X-teams are not needed when team goals and organizational goals are clearly aligned and the team has the support it needs, when team members have all the information needed to get their work done, and when the team’s task is not highly interdependent with other work within, and outside, the organization.
However, as we’ve said, the world has changed, and we believe that x-teams are better equipped to deal with the challenges that this new world holds. Specifically, the shift from command-and-control leadership to more distributed leadership requires additional dialogue and alignment up and down the organization.
This book is the story of x-teams. It is a story about ordinary people doing extraordinary things simply by shifting to a more external approach. The book contains many examples of specific teams but also examines forward-looking companies that have established structures, incentives, and processes to create and maintain whole systems of x-teams. We will see how such systems are established, how they are structured, how they are nurtured, and what the subsequent results are of these endeavors. We will focus on the full story—the integration of the internal and external approaches to team management—and the organizational context needed to make it all work.
Who Should Read This Book?
In any organization in which teams are important, managers at all levels will find this book useful. This includes a broad range of people: senior-level executives whose organization’s performance depends on the success of its teams; team members in the trenches responsible for getting the job done; those tasked with creating the conditions and incentives to make teams successful; those responsible for team member training and development; individuals working on large, complex projects involving cutting-edge technologies and hundreds of people; and, finally, those working in small groups trying to make ongoing improvements in their work or community.
For this broad audience, the book answers important questions: How can firms move to more decentralized structures and become more innovative? How do we shift leadership to lower levels within the firm? How do we get people who are already overwhelmed with day-to-day work to focus on new directions for the future? How do we unleash the creativity of people who want to make a difference and create change but don’t know how to make it happen? How do we link top-level strategy with new initiatives? And, at the most basic level, how can we improve performance and satisfaction in the teams that form the core of today’s organizations?
We hope that this book will be a valuable resource to academics, consultants, or anyone else struggling with the challenges of understanding and managing teams in a new organizational environment. We hope to provide a framework that will reshape some of the fundamental assumptions that permeate the world of small-group research and practice. We hope to shift the research lens from one that rests on the team’s boundary and focuses inward, to one that moves inside and outside the team. We also hope to shift your ideas about what a team is, how to make it function effectively, and, ultimately, how to create innovation in organizations.
Research Approach
The ideas behind the x-team concept emerged from a research program that occurred over many years and featured several coauthors. We watched real teams discover that taking a more external approach enabled them to succeed. The research included many different kinds of teams, including executive teams, sales teams, consulting teams, startup teams, and product development teams. These teams spanned multiple industries, from telecommunications, education, energy, and pharmaceuticals to big tech, health care, nonprofits, and financial services. The results have been written up in many journal articles, some of which are referenced in this book for those readers who would like to see more of the statistics and sampling procedures that provide the basis for this book.
By collecting both qualitative and quantitative data, looking at the logs of team member activity, and interviewing scores of members and leaders in consulting teams, product development teams, drug development teams, and oil exploration teams, we saw answers begin to emerge. What differentiated high- and low-performing teams was an external emphasis paired with a robust internal environment, as well as an ability to shift activities over time and not get bogged down in one phase of work.
But these high-performing teams were ones that already existed within their organizations. The next question was this: Could we create such teams? Furthermore, could teams work with top management to lead change? Here, we moved into consulting and executive education mode and actually intervened in organizations to create x-teams. At Accenture, Boehringer Ingelheim, the Broad Institute of MIT and Harvard, Li & Fung, Merrill, Takeda, and within our own institutions, our interventions have been very successful, with teams developing new products, processes, strategies, and business models. We’ll look at some of these teams—and how companies can develop their own x-teams—in the last part of this book.
About the Book
We have divided this book into three parts. Part 1 (chapters 1–2) describes the dominant “internal view” and explains how the world has changed in fundamental ways, rendering the old paradigm of teams obsolete and surfacing novel challenges. Part 2 (chapters 3–5) builds a framework to overcome the challenges teams face today. It outlines the building blocks (or what we call x-team principles) needed for teams to engage in a complex web of complementary internal and external activities. Part 3 (chapters 6–8) pulls it all together and explains how managers can make the x-team model work for them.
Part 1: Why Good Teams Fail
Before offering a solution, we need to understand the true nature, scope, and depth of the challenge. Thus, we begin this book with a journey through the landscape of existing thinking on teams. Chapter 1 describes the view of team effectiveness that we have all learned, the one we carry with us in our heads and execute daily, the one that has always made the most sense to us. We then begin looking at the evidence showing that this dominant view does not work anymore.
In chapter 2 we explain why the old model does not work. The reason? Driven by increasingly fierce, fast, and innovation-based competition, organizational life has changed in several fundamental ways. First, organizational structures today are loose, spread-out systems with numerous alliances rather than multilevel centralized hierarchies. Second, organizations are dependent on information that is complex, externally dispersed, and rapidly advancing. Third, teams’ tasks are increasingly interwoven with other tasks both inside and outside the organization. Finally, all these shifts are taking place against the backdrop of an increasingly volatile, uncertain, complex, ambiguous, diverse, and asynchronous reality that is changing at a furious pace. We refer to this context in which we live and work as an exponentially changing world. Because of these changes in organizational life, distributed leadership is now part of the landscape. All of these changes have had a profound impact on teams’ job descriptions; in fact, they have fundamentally changed the rules of the game. We explain how.
Part 2: What Works
To deal with the new realities, teams need to engage in a range of external activities. This is the first principle of x-teams and the subject of chapter 3. The range of activities we address are sensemaking, ambassadorship, and task coordination. First, sensemaking helps a team gather information located throughout the company and the industry. It involves searching inside and outside the organization to understand who has knowledge and expertise. It also means investigating markets, new technologies, competitor activities, and organizational cultures. Second, ambassadorship is aimed at managing upward—that is, marketing the project and the team to the company power structure, maintaining the team’s reputation, lobbying for resources, and managing allies and adversaries. Third, task coordination is for managing the lateral connections across functions and the interdependencies with other units both within and outside the firm. Team members negotiate with other groups, trade their services, and get feedback on how well their work meets expectations.3
As chapter 4 lays out, internal processes are needed to complement external ones. The second principle of x-teams, build a robust internal environment, refers to what’s needed to seamlessly coordinate the external outreach of an x-team, hold the team together, and enable members to integrate information and expertise. By using the term robust, we underline the fact that external activity does not eliminate the need for internal teamwork; rather, it expands that need. External activity brings additional information, divergent opinions, and political bickering into the team. A robust internal environment is needed to keep the team moving in the face of these additional challenges. Such an environment, as we will explain, has three components: get the basics right, build psychological safety, and learn.
Chapter 5 describes the third principle of x-teams: make timely transitions. This is a model consisting of three stages—exploration, experimentation and execution, and exportation—as illustrated by the story of a team at Merrill.4 The chapter is a critical part of the x-team story because it lays out how team activities need to shift over time to maintain innovation and speed. We outline a set of structural features that support making such shifts while still executing on the other principles of x-teams (engaging in external activity and setting up a robust internal environment).
Part 3: How to Make It Work
In the final part we pull everything together that the book has described so far and offer a hands-on guide to creating x-teams—or, as we like to put it, “x-ifying” your team. In chapter 6 we provide concrete steps for teams to move from a more traditional form to an x-team approach. Chapter 7 shows how systems of x-teams can be developed into an infrastructure of innovation and change, illustrated by examples from Takeda and other companies operating in an exponentially changing context. Chapter 7 also invites you to dig into the step-by-step processes of building systems of x-teams. If your organization is not at the stage of detailed implementation just yet, then you can safely skip both this chapter and the next one. You can always come back to them when you are ready.
Chapter 8, our final chapter, outlines how top management can build an organization in which x-teams thrive. We show how the Museum of Modern Art, Takeda, and HubSpot create an environment of learning and innovation through x-teams. Here we see distributed leadership in action. The chapter articulates the key functions of distributed leadership, the leadership skills needed to work in such an organization and in x-teams, and what top management can do to foster such an organization. After all, x-teams cannot meet their full potential to lead without a supportive organizational context. While building such a context only happens over a long period, and with a lot of work, organizations need to foster the processes, structures, and culture necessary to unlock the potential of x-teams. In turn, x-teams help to model and shape these processes, structures, and cultures.