The Agile C-Suite

Idea in Brief The Principle If a company wants to continually outpace competitors, it needs more than lots of agile teams. It requires the company’s top officers—most, if not all, of the C-suite—to embrace agile principles too. The Team An agile leadership team must focus on striking the optimal balance between standardizing operations and pursuing innovations. The Challenge Executives on the team have to play multiple roles: build and run the agile enterprise operating system; oversee business units and functions; serve as mentors and decision makers; and handle the crises of the moment. “Brian Johnson” is the chief executive of a major consumer-goods company that has been remarkably successful over the past decade. Like his predecessors, Johnson runs a tight ship in all aspects of operations, boasting excellence in product and service quality and a finely tuned supply chain. The company capitalizes on economies of scale and enjoys the lowest costs in its industry. But when we first spoke with him a year and a half ago, he was worried that those managerial assets were turning into liabilities. “We’re seeing focused competitors in nearly every segment of our business,” said Johnson. (We’ve changed his name and other details to protect the confidentiality of our conversations.) “They’re small, but they attack like piranhas.” The new entrants were bringing out products and services that distributors loved. Their lenient return policies encouraged customers to try their offerings. Their faster deliveries within tight time frames reduced distributors’ warehousing costs and inventory levels. Johnson’s company was having trouble responding to the pressure, particularly when doing so required the denizens of its well-guarded organizational silos to collaborate with one another on innovations. As consultants, we hear similar concerns from many executives like Johnson interested in creating agile leadership teams. One of us (Darrell) has written about the opportunities and challenges of ramping up agile by adding more and more teams (see “Agile at Scale,” HBR, May–June 2018). But after studying hundreds of companies for our new book, we believe that if a company wants to be fast on its feet, transform customer experiences, and continuously outpace competitors, it needs more than lots of agile teams. To create a truly agile enterprise, the top officers—most, if not all, of the C-suite—must embrace agile principles too. This article explores how agile leadership teams function, how they differ from conventional executive committees and from other agile teams, and what agile means for senior executives’ day-to-day work lives. Creating Balance from the Top The job of a conventional agile team is to create profitable, innovative solutions to problems—come up with a new product or service, devise a better business process, or develop an advanced technology to support new offerings. The job of an agile leadership team is different. It is to build and operate an agile system—that is, an agile enterprise. Building an agile enterprise does not mean replacing traditional operations with agile teams everywhere. Agile is primarily for innovation, and the testing and learning it involves can compromise critical operating processes. Imagine the adverse consequences of encouraging wide variation, on-the-spot experimentation, and decentralized decision-making—all hallmarks of agile—in areas such as food or drug safety, antidiscrimination and harassment policies, accounting standards, and quality control. Thus, building an agile enterprise means finding the right balance between standardizing operations and pursuing (sometimes risky) innovations. If you were running a restaurant, you would want to make sure that the food and service were of consistently high quality and that the decor was always clean and appealing. At the same time, you would need to innovate: for example, introduce new menu items, new kitchen or front-of-the-house procedures, or new features such as a customer personalization program. If you pay insufficient attention to operations, quality slides and costs rise, harming both customers and the business. If you devote insufficient attention to innovation, your restaurant becomes boring and unable to adapt to a changing environment. In a large firm, it’s not easy to maintain balance. A business’s operating system is made up of many components—for example, the firm’s purpose and values, its talent engine, and its data and technology systems—and each of these can get seriously out of whack, becoming either too static and hidebound at one extreme or too risky and chaotic at the other. Balancing the Agile Enterprise A business operating system comprises many components, each of which can get out of balance. To create an agile enterprise, the agile leadership team identifies the optimal balance point for each component—this may not fall in the center, depending on the firm’s context and circumstances—and then assesses where rebalancing is needed. There’s no set formula for finding the right balance. Every company and every activity within each company will differ. Managing R&D activities for a robotics business, for example, demands a different balance point than managing operations for a salt-mining company. To find the optimal balance, the agile leadership team typically begins by creating new metrics to help determine how agile the company is, how agile it should be, whether it is moving in the right direction at the right speed, and which constraints are impeding progress. Surveys of internal and external stakeholders to obtain their subjective views of business processes combined with objective measures—such as innovation cycle times, flow efficiency (work time versus wait time), and market share changes—are useful for determining the existing state of the operating system components. The team then develops a sequenced list of activities aimed at achieving an optimal balance for each component. The agile process forces leaders to get out of their silos and work together as a multidisciplinary group, breaking through impediments and pivoting when necessary. By rebalancing whichever of the components are out of alignment, they will, over time, create an operating system for an agile enterprise. The Agile Leadership Team Typically, the agile leadership team includes part or all of a company’s executive committee. At a minimum, it consists of the CEO and the heads of finance, human resources, technology, operations, and marketing—the individuals most critical to the components of the operating system. For most types of agile teams, members are allocated 100% to a single initiative. That’s not possible for agile leadership teams. Executives must simultaneously play multiple roles. They have to build and manage the agile enterprise’s overall operating system, diagnosing which components need to be improved and figuring out when and how to strike the optimal balance in each. They have to sponsor and lend their expertise to teams tasked with redesigning and rebalancing one or more components. At the same time, they must continue to oversee business units and functions and ensure that operations run reliably and efficiently. They must serve as mentors, coaches, and decision makers. And they must handle corporate governance issues such as compliance and shareholder communications—not to mention the crises of the moment. While performing such operating roles, leaders should keep agile values and principles in mind, but they do not organize into formal agile teams with all the associated roles, ceremonies, and artifacts. Kenji Aoki/Trunk Archive Handling these responsibilities is a tall order, far different from both a traditional executive committee’s work and that of textbook agile teams. Let’s examine how this plays out in practice, returning to Brian Johnson and his company. The CEO. After our initial conversations, Johnson decided to create an agile leadership team consisting of the CFO, the CHRO, the CIO, the COO, the CMO, and himself. Then he took on the role of “initiative owner” for building an agile enterprise. It took about five months, he told us, for the executive committee to begin thinking and acting as an agile leadership team. Johnson’s first step was to articulate the need for change and restructure the agenda for the team’s six-hour Monday meetings to spend less time on operating details and more on strategic issues. In those meetings, the group clarified the company’s strategy, reassessed the value of current activities, and decided to stop a number of projects. And it committed to using agile approaches to focus on a major strategic initiative dubbed Project Fusion, which targeted a large customer segment with the goal of significantly growing market share and increasing revenues by billions of dollars. The team broke the initiative into three components: One focused on improving the product development process. Another examined ways to broaden distribution channels and improve the supply chain. The third explored marketing programs to increase awareness, trials, and purchases. Team members laid out their ambitions for each component and established metrics to track progress. They then identified all current work related to those areas and decided how to convert the most innovative activities into 25 agile teams. Some existing work was curtailed; some was combined and reconfigured. All of it was coordinated using agile principles and practices to prioritize activities and develop flexible road maps. The product team, for example, first sequenced a list of products to develop and then sketched out scenarios for collaborating with third-party partners on each one. To create a truly agile enterprise, C-suite must embrace agile principles. Johnson led the creation of a management structure for Project Fusion, consisting of a star senior manager from the operations department to head the project and three other respected managers to serve as “initiative owners” of the 25 agile teams. (An initiative owner—the person ultimately responsible for delivering value to internal and external customers and to the business—usually comes from a business function with expertise vital to the initiative and divides his or her time between working with the team and coordinating with key stakeholders, such as customers, senior executives, and business managers.) All four managers were assigned full-time to the project. The executives on the agile leadership team sponsored the parts of the initiative that were related to their areas of expertise. As sponsors, they mentored the initiative owners, helped them make tough trade-off decisions and find experts, and ensured that key departments executed the agile teams’ recommendations. (For more on how agile teams are structured and operate, see “Embracing Agile,” HBR, May 2016.) Meanwhile, Johnson led the members of the leadership team in drafting an agile manifesto to guide their own behaviors. The document would serve as a kind of north star to help keep them on track and prevent backsliding in their interactions with the team. An Agile Leadership Team’s Manifesto An agile leadership team should document the principles and behaviors that members will adhere to. Such a “manifesto” can serve as a mechanism for holding people accountable. This template, based on the original Manifesto for Agile Software Development, is an effective starting point for customization. Individuals and interactions, not processes and tools We set a clear ambition (“what” and “why”) and metrics for success but delegate the “how” to the team. We empower teams and believe that the right answer lies not with us but within the team. Customer engagement, not rigid contracts We encourage teams to seek feedback from a diverse set of customers and promote a culture of rapid adaptation to feedback. We believe that things can always be improved. Working solutions, not excessive documentation We strive for “good enough” working solutions rather than demanding perfection. We protect teams so that they can focus; we rapidly unblock key impediments. We support teams in breaking down complex problems and frequently iterating in order to rapidly deliver solutions. Flexibility, not concrete plans We celebrate learning and create a safe environment for teams to take prudent risks and test unconventional hypotheses. We embrace ruthless and constant prioritization and stop activities that are not yielding results within the defined time frame. In the past, similar “transformation” programs were managed on a part-time basis by mediocre people whose time was relatively easy to free up. The programs consistently failed. So this time around the leadership team decided to dedicate some of the company’s best, most admired managers to the effort and to design the work by starting with the customer. They further agreed to give the leaders of Project Fusion whatever support they requested, using short daily meetings (often called stand-ups) to help remove impediments—a topic we’ll discuss below. At least once a month, Johnson asked all 25 agile teams on Project Fusion to rate his leadership team on its adherence to the principles of the manifesto. He spurred the CIO to install software tools that increased the visibility of agile teams throughout the organization, with the goal of minimizing duplicative work and increasing collaboration. He encouraged the leadership team, other decision makers, and other agile teams to use the system to see in real time what everyone was working on, what their backlogs were, what they planned to accomplish by when, and what interdependencies existed among teams. He went out of his way to represent the voice of the customer in leadership work sessions. The CFO. Johnson’s chief financial officer quickly became one of the most active members of the agile leadership team. She worked closely with Johnson to focus work-session agendas on decisions and roadblocks and to call out behaviors that were inconsistent with the leadership manifesto. She applied financial tools to help the agile leadership team build and sequence the corporate backlog of initiatives. (The executive committee had historically struggled to prioritize its activities and wound up trying to do too many things at once.) The CFO taught leaders of all agile teams to sequence their activities by constructing a simple financial scenario: How much value would be lost if each initiative began six or 12 months from now rather than today? Initiatives that had the highest cost of delay—either because the benefits were so big or because seasonal opportunities or competitive advantages would be squandered—rose to the top of the backlog. Rather than predict the unpredictable, agile leaders build rapid feedback loops. Her most important work lay in her own domain. She began revamping the planning, budgeting, and reviewing process—first for Project Fusion and then for other parts of the company that were tackling innovation programs. She reset corporate objectives to reflect the new priorities. She created new financial reports for the strategic agile initiative. She also commissioned agile teams to develop planning and budgeting processes similar to those used by venture capital firms with start-ups. Previously done annually, the processes would now occur more frequently—at least quarterly—but would be less onerous. Rather than relying strictly on financial forecasts, teams would increase the transparency of key assumptions, create ways to test them, and identify potential impediments. For example, teams would not simply forecast sales; they would break them into the number of customers per year, frequency of purchases per year, number of items per purchase, and average revenue per item. The most critical and risky assumptions could thus be tested first, and deviations from expectations could be examined and refined. As data began to come in, frequent feedback loops would accelerate decisions to grow gains and limit losses, just as in the venture capital world. The CHRO. The head of human resources focused on revamping the company’s talent engine to power the transformation. Now that agile teams were using fully dedicated people rather than part-time allocations, the CHRO needed to develop new career paths and appropriate reward systems for members of the major agile initiative, along with processes for backfilling their previous positions. To identify the kinds of people who should be hired or moved and the skills they would need to succeed, he studied the effectiveness of previous agile teams in the IT department, which had adopted agile long before the rest of the company (a common phenomenon). A key determinant of a team’s success, he discovered, was its initiative owner, so he analyzed the characteristics of successful versus unsuccessful people in that role. He developed hiring, training, and coaching programs to build common agile skills across technology and business areas. He clarified decision rights among agile teams and operating managers—a frequent source of confusion in many agile transformations. The CIO. Since the IT department had the most experience with agile, the CIO took on the role of coach for the agile leadership team. He pointed out when team members were following agile principles and practices and when they were slipping into dangerous shortcuts or dead ends. He also developed templates that outlined for agile teams what was required before launching. To be “ready to begin,” each team had to identify a major customer opportunity; take responsibility for specific outcomes; staff the team with dedicated, multidisciplinary experts; and commit to applying agile values. It had to prove that it could work autonomously, create rapid prototypes, and collaborate closely with customers, and it had to have the support of a senior sponsor. The COO. This executive took on the role of chief integration officer, creating the processes that agile innovation teams and the operating units would need to work together and scale up. For example, he ensured that agile teams designing new pricing strategies connected regularly with his pricing execution team, and that teams studying the products that customers said they wanted worked closely with his product managers. He freed up several senior leaders from his department for Project Fusion. He committed to coaching them and to breaking through operational impediments. The CMO. The chief marketing officer’s role expanded from traditional branding and advertising activities to helping business units identify and prioritize strategic opportunities. She consolidated fragmented and often conflicting reports from various business units into a centralized source of data on customer segments, documenting their size, growth rates, changing needs, and satisfaction levels with the company and its competitors. She increased the frequency and depth of customer feedback, and she worked with the CIO to install state-of-the-art technologies for learning from customer communities. She also gathered intelligence on competitors, including their market shares by segment and their innovation activities. She shared this information with the agile leadership team weekly. The Time Problem Asking senior leaders who are already flat out to take on the new tasks and rhythms that agile requires sounds like a bridge too far. What Johnson and other agile leaders have found, however, is this: Agile enables top executives to delegate many of their activities to subordinates so that they can focus on what only they can do. Executives come to understand that an hour spent reviewing or second-guessing the work of experienced operating managers creates far less incremental value than an hour invested in developing major cross-functional innovations—a task those operating managers are not in a position to handle. We studied the calendars of three senior executives whose companies became agile organizations, quantified how they spent their time, and then interviewed them. We ran the findings past about a dozen other agile executives, and the results were consistent and eye-opening. By the end of the transition to agile (a three-year process for those firms), the leaders had quadrupled the time spent on strategy (from 10% to 40%) and reduced the time spent on operations management by more than half (from 60% to 25%). The time spent managing talent had risen slightly (from 30% to 35%). Agile Ways of Leading Senior executives of large companies know a lot. They brim with self-confidence. These are the characteristics that helped make them successful, but the same characteristics can turn into liabilities: Some executives believe they know more than they do; some issue orders without having all the facts. An agile environment has a way of challenging such leaders. People who work on agile teams—even if they don’t rank high in the organization—are likely to respond to orders with comments like these: “That might be the right answer, but we’d like to test it first.” Or “Our data shows that customers don’t value the feature you’re proposing.” Or “We tried that idea and rejected it. Here’s why.” Agile, in short, requires humility from leaders. We don’t mean a false humility but rather the sort that accelerates learning and bolsters the confidence of every team member. Humble people recognize the futility of predicting the unpredictable and instead build rapid feedback loops to ensure that initiatives stay on track. They understand that good ideas can come from anyone, not just from those with the highest status. They view their job as helping team members learn and take responsibility, rather than telling every team member what to do and how to do it. An agile leadership team has to adopt such attitudes or its pronouncements will ring hollow. Let’s now look at three examples of this kind of humble, agile mindset in practice to see how it affects everything an agile leader does—including operations management, coaching, and even administrative governance. Rapid feedback everywhere. Agile innovation teams famously use short sprints (one- to four-week work intervals) and daily stand-up meetings to create feedback loops that identify and resolve impediments to progress as quickly as possible. Johnson is taking these feedback loops to another level. Each of the 25 agile teams on Project Fusion meets at 8:30 am to talk for 15 minutes about plans for the day and potential bottlenecks. At 8:45, the leaders of the 25 teams meet in three teams-of-teams to share perspectives and jointly solve as many of the problems as they can. At 9:00, the leaders of the three groups—the initiative owners—meet together with the owner of Project Fusion to share their findings, resolve as many unaddressed problems as possible, and prepare to meet with the agile leadership team. At 9:15, the four of them meet with the agile leadership team to summarize plans for the day and present a list of decisions and impediments that they need the agile leadership team to resolve. Not every C-suite team member is able to attend every meeting, of course, and people on the road often join by video conference. But the team recognizes that coming together each day to make decisions—for just 15 minutes—is essential to avoid confusing and conflicting guidance. By setting aside this time and forcing discussions frequently, the executives dramatically speed the pace of decisions. This approach is working so well that Johnson is now experimenting with the process in more parts of the organization, including business units and functional departments. This is similar to the system of daily huddles that Marc Harrison, CEO of Intermountain Healthcare, uses to accelerate improvement in his network of hospitals and clinics (see his article “How a U.S. Health Care System Uses 15-Minute Huddles to Keep 23 Hospitals Aligned”). From commanding to coaching. As a management board member and chief technology officer of Bosch Power Tools, Henk Becker was asked to launch the division’s agile transformation in 2016 as part of a larger, enterprisewide initiative. He set up agile teams that developed collaborative approaches consistent with agile values and principles. Most leaders aren’t fighting agile. They just don’t see how it applies to them. Becker told us that he had to change himself as the teams changed their ways of working. A few courageous leaders had begun giving him feedback of a sort he’d never heard before. They told him that they wanted to be led differently. His leadership style, they said, wasn’t bringing out the best in people, nor was it positioning Power Tools to win in the marketplace. They cited times when he undermined their authority or unnecessarily delayed their work. The experience, he says, was “a click in my brain and in my heart.” He realized he needed to change his attitude and his behavior. So he began a process of self-reflection and asked for more and more feedback. At first people were dubious: Was this just a passing fad? Slowly, Becker began to build trust and broaden the group of people giving him feedback. He shifted his focus to concentrate on the potential of his people and the organization. He started using positive language, asking “How can we?” instead of focusing on why something couldn’t be done. He engaged in two-way communication instead of issuing one-way direction. To demonstrate his commitment, he gave up his office and parking spot. He also stopped asking people to make him PowerPoint presentations; instead, he began relying on the information they were already using. It took time, he says, but he became a different leader—the kind who could successfully guide an agile transformation. Becker is now CEO of Bosch Power Tools. From meetings to work sessions. Once Johnson and his CFO got comfortable with agile principles and practices, they grew increasingly frustrated with old-style management meetings. Most started with unclear objectives. People shared their thoughts on random topics in random order. After hours of discussion, meeting participants were in apparent agreement—but when it came time to act, participants frequently refused to do what others thought they had signed up for. They would say that circumstances had changed and that actions proposed earlier were now impractical. Johnson eliminated as many meetings as he could. He shifted the remainder from tedious reviews of activity reports to collaborative problem-solving sessions. He began every work session with a list of the issues to be resolved and barriers to be removed. When decisions required tough trade-offs among several functions, he pulled all the key people together into “swarming sessions” that made decisions in hours rather than weeks. He taught participants to address problems by describing the options, evaluating the trade-offs, recommending the preferred option, outlining the assumptions behind it, describing the action steps necessary to test the assumptions, and communicating explicit action items for each member of the leadership team. Executives noticed the difference. Many referred to the “constructive conflict” that replaced passive participation. The team pushed discussions into decisions. The decision-to-action pace increased. People left work sessions with a clear understanding of their responsibilities and a greater commitment to their goals. Johnson encouraged people to create flexible road maps that enabled everyone to visualize what would be accomplished, how soon, and by whom. Over time, this approach to meetings spread throughout the organization. CONCLUSION Agile teams often cite leadership and culture as the greatest barriers to the successful scaling of agile. But most leaders aren’t fighting agile. They simply haven’t understood how it applies to their roles or how to perform those roles in ways that enhance agility. Agile leadership demands that executives create a carefully balanced system that delivers both stability and agility—a system that runs the business efficiently, changes the business effectively, and merges the two activities without destroying both elements. An agile leadership team views development of the agile system as an agile initiative—in fact, as the most vital of all agile initiatives. Senior executives learn to manage the transition as an agile team. They view it as a continuous improvement program, not as a project with predictable end points or fixed completion dates. They realize that going too slowly may fail to achieve escape velocity, and that changing too fast will create chaos. So they sequence and balance all the components, recognize the value of role-modeling agile behaviors, and appreciate that how they make decisions will be as important as the decisions themselves. When it all works, they improve business results, unleash the potential of employees, and enhance their personal job satisfaction.

The Agile C-Suite

Summary.

Partner Center