Creating an agile enterprise nearly always involves changes in a company’s operating model and in all that the operating model entails. Roles and responsibilities need to be redefined and decision rights adjusted. Core management practices and procedures must be refined. Talent management practices have to be reconsidered and basic ways of working overhauled. Organizational structures must often be reshaped as well. Unless leaders decide to change everything at once—seldom the best option—they must figure out how to sequence and test all these changes in good agile fashion. It’s a tall order. People who are accustomed to bureaucratic methods—most leaders, in other words—often find themselves tempted to look for a shortcut.
The most common temptation, without a doubt, is to redo the company’s structure and stop there. It seems so easy! You can reshape the org chart just by moving around the boxes and reporting lines. Restructuring lets you remove people and costs. It lets you fill important roles with individuals who are supportive of the change you have in mind. If you change the jobs, you might think, you will force changes in how people approach their work. Changing the ways of working, in turn, will change outputs and outcomes. Presto: an agile enterprise.
A related temptation is copying. We have mentioned the danger of copying earlier in this book, but it’s particularly germane to the question of organization because you can actually look at some other company’s org chart and take that as a guideline. So let’s examine the org chart of Spotify, the Sweden-based music-streaming company that is probably the most frequently emulated agile organizational model of all (figure 6-1).
As you inspect the illustration, you may be surprised. It probably looks a great deal like your own company’s org chart, and indeed like the org chart of nearly any traditionally organized enterprise. Of course, if you were to dig down deeper, you would find a lot of squads and tribes and chapters and guilds, all relatively unfamiliar terminology. But most of these agile teams and other groupings are embedded within Spotify’s R&D function. Other people, those in the operations and support and control functions, are organized into traditional departments. R&D does account for about half the employees of this digital-native company. In other companies, however, the proportion of employees focused on agile innovation may be only 10 or 15 percent.
Spotify organization chart
Source: “Spotify,” The Official Board, https://
We offer these observations to introduce three points:
Fortunately, there are better, more holistic ways to change an organization. This chapter discusses our recommendations, such as why we seldom begin with restructurings and why tuning the talent engine is a critical and often underestimated lever in the transition. We’ll illustrate them with the experiences of Bosch, a company you have already read about, and those of other companies as well.
Most human resource executives can recite Alfred D. Chandler Jr.’s famous quote: “Unless structure follows strategy, inefficiency results.”1 But structure isn’t the only thing that follows strategy. The entire operating model—structure; leadership; planning, budgeting, and reviewing; even processes and technology—must follow strategy, integrating and harmonizing the pieces to make the company more valuable than the sum of its parts.
Corporate strategy determines where to play, how to win, what business units will be required, and how they will operate. For example, is our strategy most likely to succeed with centralized divisions, decentralized business units, or a matrix organization that tries to capture the benefits of both scale and autonomy? Once these decisions are made, two more become critical: How many business units should we have, and how should we define them so that business unit leaders have the authority to quickly make tough trade-offs without causing problems for other performance units? Define business units correctly and you create highly empowered leaders who take full ownership for delivering results. Define them incorrectly and you create intracompany overlaps and chaos.
To define business units, executives often use simplifying shortcuts and mathematical clustering techniques. Calculate the amount of cost sharing among operating units. Determine their potential to share capabilities. Measure the overlaps in current customer purchasing patterns. If these quantifications yield high numbers, then combine the operations into a single business unit. If not, separate them. These techniques can yield quick insights into effective business definitions in current market conditions. But the work isn’t finished until you work backward from customer needs. Business units exist to satisfy customer needs profitably, not to crank out products. Printed encyclopedias and Wikipedia are in the same business, even if their cost structures and manufacturing processes are quite different. The same is true of incandescent light bulbs and light emitting diodes (LEDs). Business definition and matrix choices that give a company an advantage in meeting today’s customer needs must not impede its ability to change how it meets customer needs in the future.
Bad business definition is a leading cause of rising business mortality rates. Physical retailers get destroyed by Amazon. Chemical photography is ravaged by digital cameras. Typewriters are wiped out by word processors. Video rental companies are bankrupted by video streaming. These are all because too many businesses define their boundaries by how they make products instead of why customers buy them. Then, suddenly, new competitors seem to come out of nowhere. There is no cost sharing with current products. The innovations require entirely new capabilities. And some of the customers that buy these new products aren’t even current customers. In order for business units to both run the business and change the business in such turbulent times, they must be defined in ways that proactively encourage them to continuously adapt to changing customer needs.
Agile teams can provide that adaptation, and proper business definition should guide where they are placed and how they are used. Placing agile teams within the right business units improves the odds that their innovative work will be adopted and scaled quickly and effectively. Ensuring that agile teams do not break the business unit into fragments that destroy responsibility and accountability improves performance. Giving agile teams customer-oriented missions helps leaders to change their businesses with—or even in advance of—changing customer needs.
When executives do this correctly, they create a structure that looks something like figure 6-2. Agile innovation teams will be spread throughout the company. Except for disruptive innovations that fall outside of existing business units or across several of them, agile teams will be located as close as possible to the operations that must adopt and scale them. This recommendation runs contrary to many scaling models, which prefer to pull the teams away from operations and cluster them together in large tribes. But there are good reasons for business owners to own agile teams whenever possible. First, the best leaders are change oriented. When accountability for change is removed from a business unit, the move takes away a leader’s vision, creativity, and inspiration. He or she is no longer leading the business into the future. Companies that want high-performing leaders need to empower them and design accountabilities that let them lead. Second, generating creative ideas is not usually the hardest part of successful innovation. Scaling is. Building a prototype is relatively easy compared to profitably scaling that prototype across the business. Unless line managers own innovative solutions, those solutions will lie fallow inside the snazziest of innovation labs.
What might the structure of an agile enterprise look like?
An organization’s structure is the easiest part to illustrate, but it’s important for companies to sketch out their entire operating model. How will decision rights work? Who sets budget levels? Where is an employee’s home base? Who handles recruiting, training, performance reviews, compensation, promotions, and career tracks? Which functions should be centralized shared services versus decentralized operations? How are cost allocations determined? Can business units decide to purchase shared services from outsider third parties? Can shared services sell their services to outsider third parties? No structure will ever be perfect. The good news is that it doesn’t need to be. By intelligently mixing all the elements of the operating model, executives can ensure that no single element constrains success. A structure change may not be needed—or else it can be significantly delayed in order to focus on changes in areas such as decision rights, leadership, and ways of working. Forming agile teams may not even require changing reporting lines for employees. Agile team members would still report to their home departments, but their managers would act as long-term professional development coaches rather than as day-to-day supervisors. Daily activities would be planned and executed with the teams.
A company embarking on an agile transformation has a built-in advantage over companies seeking other kinds of changes, because it has the tools of agile at its disposal. It naturally has to ask how far it wants to go, how fast, where to start, and how to sequence the changes. If its leaders are familiar with agile principles (and we hope by now that they are), they will understand that the appropriate sequence is test, learn, and scale. They will also understand that they must engage the organization in the process, designing and cocreating changes to test with people from every discipline and level of the company—no closed doors. At each phase, the design process will need to clarify what work is to be done by which group and who will be responsible for each key decision. Agile works best when decisions are pushed down the organization as far as possible, so long as people have appropriate guidelines and expectations about when to escalate a decision to a higher level.
The company also needs to take into account the entire landscape of proposed changes in the operating model: not just structure but changes in accountabilities and decision rights, in the management system, in leadership, and so on. It can speed up or slow down based on how things are working out. Companies that move with deliberate speed to create pull from other teams generally achieve better business results than those that try to move as fast as they possibly can. The latter group usually find themselves creating disruption in the organization without any obvious benefit, thereby undermining their claims for the future.
Bosch Power Tools offers an almost textbook case of these precepts. The division took a carefully sequenced, multiyear approach to becoming an agile enterprise. The first pilot teams were in the home and garden business unit. After learning from the pilots for about six months, leaders began expanding the number of teams until they eventually encompassed the entire unit. The division then began transforming its other five business units in sequence over a two-year period. At this writing, Power Tools is focusing on how to improve the support and control functions, such as finance, HR, and logistics.
At the outset, the division established five pillars to guide its transformation: strategy, organization, leadership, processes and methods, and culture. As each new business unit began the process, volunteers from every level and department staffed temporary project teams to design the new organization. The discussions were wholly transparent, and the teams used an iterative process to incorporate feedback and adapt accordingly. In one unit, the team responsible for organization structure used Lego blocks of different colors to represent various disciplines. The exercise allowed team members to discuss and test how people would be deployed under different alternatives. Building a prototype was much more powerful and inspiring than drawing boxes and lines on paper.
Over time, the leaders of Power Tools learned from their experience and adjusted their approach. By the time they launched the third business unit, for instance, they were spending the first two months on the why, so that people would understand the reasoning behind the transformation. And although they focused on structure during the first year of the process, they concluded after a year that collaboration and culture required more emphasis. Ways of working were more important and represented a bigger change than the structure alone. Leaders also significantly increased their focus on supporting new leadership behaviors, holding leadership days across the enterprise. And they made significant investments in learning. Depending on their positions, some people might attend a leadership academy while others attended functional academies. Employees received focused feedback and coaching. They learned agile basics, design thinking, and mindfulness. Having agile coaches in place early on helped each business unit understand the new approaches and drive productivity improvements.
Power Tools did undergo a sizable change in structure, and company leaders view it as a key enabler of the agile transformation. The new structure broke down functional silos, created smaller P&L units, and reduced the levels of hierarchy from five to three. But the company made the change carefully, piloting it first and then implementing it over three years. Also, structure was just one of several tracks, and in fact the bigger impact may have been on ways of working. Over time, the division created fifty-five business teams with end-to-end accountability and decision rights, even including manufacturing. This change, combined with the agile leadership process described in chapter 4, sped up decision making. The teams were close to their units’ operations, which allowed for faster response times when issues cropped up. Decisions that once went up the manufacturing silo and then over to other relevant silos could now be made on the spot. “We all belong to one purpose team,” said Daniela Kraemer, a business owner in light drilling and chiseling. “For instance, we have a plant in China. People at the plant detected a problem with a supplier, involving the switching elements, and stopped production. That same day, we took countermeasures, and the sales and marketing teams communicated with customers. We could not have been faster. We were solving the problem together.”2
“I wish our company had started work on talent earlier.” We can scarcely count the number of times we have heard that regret from executives whose companies are launching agile. Conversely, companies that gave HR leaders a seat at the table right at the beginning—and then asked those individuals to lead the way in talent development—found that their transformation process sped up immeasurably.
Why so? In any company, business strategy informs talent strategy. The company’s strategic and operational requirements determine not just the kind of people it needs but also what those people can reasonably expect and aspire to. Oddly, many companies don’t do the kind of workforce planning that this linkage implies. They may not assess the talent implications of a new business strategy. They may not figure out what sorts of people they need, how many, where those people should work, and whether they should be accessed through partners.
An agile transformation can’t succeed without this kind of planning. Agile almost by definition requires specific new skills and hence new talent. HR leaders at nearly every company will discover right away that there are gaps in the workforce, particularly in critical in-house technology disciplines. As they begin to dedicate resources to projects, they will likely find gaps in specialized areas of expertise. In the past, the experts might have been shared across a dozen projects; in an agile environment, that is not an option. A company is also likely to find that it must carry a bench for some capabilities—that is, whenever the cost of carrying a bench is less than the potential cost of not having the necessary skills. The good news is that agile itself can be helpful here. For example, HR managers can prototype workforce planning improvements for one bottlenecked resource in one part of the business. Then they can learn from that experience and scale the planning accordingly.
In some situations, HR may find that it is cheaper and easier to train people in new skills than to find talent externally. A hire and fire approach is expensive with severance cost, recruitment cost, and joining incentives. Most of the time, indeed, the vast majority of people who will be working in an agile enterprise are the people who are in the organization today. That is an asset, not a liability. After all, you need people who have experience dealing with your customers and who understand what they value. You need people who understand how your operations and processes and systems work. People trained in agile aren’t particularly distinctive. People who know how agile might work in your organization are. Anyway, many of these people will not be using agile methodologies directly. Operations teams will need to know what the transition means for them; they may be involved with agile teams and may have to learn new skills, such as participating in testing and scaling. But most will not be on agile teams, and so will need only to adopt agile values rather than agile methods.
Talent strategy informs a company’s talent system, meaning the processes it relies on to acquire, develop, deploy, manage, and reward its people. Several aspects of this system will have to be revamped as part of an agile transformation. Senior leaders and HR staff will need to figure out how each one should evolve—including the HR department itself. An example may help to show some of what’s involved.
Walmart has more than a million associates. So Julie Murphy, the company’s chief people officer for the United States, has a lot of customers, and she is responsible for improving their experience. To do so, she studies the different segments of her customer base and tries to understand both their overall journey and key episodes in it. She and her team define their priorities based on the importance, the frequency, and the opportunity for improvement in the various episodes.
In early 2018, Murphy established five agile teams based on these priorities to accelerate the pace of innovation. The teams focused on hiring, learning, progression, performance management, and simplification. Changing to agile teams brought more transparency to the work. It improved the group’s ability to set priorities. And indeed, the pace of innovation increased dramatically. One team, for instance, focused on the hiring of front-line associates. The group working on this experience—which included fully dedicated members with expertise in HR and tech—developed a tool to better assess potential candidates, reduce bias in the hiring process, and decrease the administrative burden for everyone.
The team’s first release provided field HR reps with a prioritized list of candidates, powered by an algorithm in the background that aggregated and analyzed more than twenty data points. Team members launched the tool in one market, captured feedback from store managers and HR people in the field, and then launched a second release in a different market for more testing and learning. By mid-2019, the new tool—dubbed Hiring Helper—was showing a 20 percent improvement in hiring fit compared to traditional selection methods. In addition, candidates selected using the tool showed a 5 percent decrease in attrition and a 15 to 30 percent decrease in absenteeism in the first two releases. At this writing, the team was continuing to test, learn, and scale.
Walmart, of course, is just one company. The number of agile teams other companies require in the HR domain will vary based on the magnitude and scope of the changes needed to support the agile transformation. Simple HR policies or practice changes may be straightforward to implement. Bigger process and technology innovations may benefit from agile teaming. Let’s discuss some of the principles guiding these changes.
Leadership means more than simply being in charge of a group and delivering the desired outcomes. Agile leaders in particular should be rewarded on how they contribute to an agile environment. In one area of Bosch Power Tools, for instance, leaders asked a group of more than fifty people to define a set of leadership attributes—skills and characteristics that would be used to assess candidates for advancement. The group defined five criteria: observation, empathy, heart, autonomy, and adaptability. In short, it wasn’t enough for someone to produce great results; he or she also had to be the right kind of leader. The division also moved away from a boss-nominated process to a self-nominated process in which a committee judges the candidates. The new system mitigated the common situation in which managers move from one assignment to another and never stay with one boss long enough for that boss to nominate them for advancement.
Agile enterprises also emphasize coaching over career paths; there is no longer one road to the top. Employees in an agile enterprise can learn, take on big opportunities, and make themselves more valuable without getting promoted. In more of a choose-your-own-adventure world, many companies are shifting career development to the individual and providing coaching support. These companies are also supporting leaders in building coaching skills. At Bosch, coaching was a key theme of the learning program for the agile transformation, and it extended beyond the agile teams and into operations. One plant manager in China was so inspired by the learning that he invested his personal time in becoming a certified coach.
Agile companies focus their talent acquisition approach on mission and results rather than on status or a glossy résumé. Stripe, a digital payments company, leads with its mission in describing how candidates will have an “unprecedented opportunity to put the global economy within everyone’s reach while doing the most important work of your career.”3 Stripe uses few titles. It warns candidates, “After a few years your LinkedIn might not look as tricked-out as your peers’ at other companies.”4 As a result, it attracts people who are comfortable in the company’s culture and agile environment. And it isn’t just the cultural benefit. The research reported by our colleagues Michael Mankins and Eric Garton in their book Time, Talent, Energy suggests that inspired employees boost productivity.5 People can be inspired by the company mission, by their immediate supervisor, or by participation in a productive agile team.
Agile teams set clear goals for themselves. They try to understand what goes well and what doesn’t go well as they pursue those goals. Feedback should encourage this learning, with the objective of improving results in the future. It should not be all about compensation. When performance management focuses too much on rewards, the discussion changes: superiors may feel constrained about what kind of feedback they offer if they know it will change someone’s compensation. Bosch Power Tools used to give employees feedback once a year at an annual performance review, just as many companies do. As the division evolved into an agile enterprise, people developed tools that allowed regular feedback to each team. “That feedback is leading to flexible changes of behavior and attitude,” division CEO Henk Becker told us.6
Agile companies simplify their job architecture—titles, levels, and pay grades—particularly in the disciplines that are most likely to provide members for agile teams. So some companies may also need to develop expert tracks. Teams need to be able to easily describe the resources they need and take part in selection. “Before, HR was involved and the boss was involved,” said Becker. “Now we have team staffing, with involvement across disciplines and hierarchy. The team should have a vote on whether they want this kind of boss, regarding competence and personality.”7
Employees need to be able to grow without moving up a layer, and their titles should make sense throughout the enterprise. At Bosch Power Tools, said Becker, “The career path is different. We have expertise roles, excellence roles, business owners. We created new roles, which gave people the possibility of forming a T-shaped profile, competence where they are deep but also the top of the T where they work on the complete value chain.” Becoming an agile master (Scrum master) is also a new development opportunity at Bosch.
Bosch Power Tools was experimenting with a variety of managerial tools to help teams be more successful. The division had a tool called individual development discussions (IDD), for example, through which an employee could invite coworkers to provide feedback. In the past, the input would have come from people in other areas or disciplines. Now, some teams were using the process to gather input from those whom they worked with every day. “People are more and more starting to ask for feedback,” said Anne Lis, an HR specialist with the division.8 Power Tools was also sponsoring team target workshops, in which a team meets together and defines collective targets based on input from leaders on financial expectations. Members define the competencies they need to reach those targets and determine what they need to do to attain them. The sessions may be moderated by an agile master, by someone from HR, or by a team member.
Companies can think about rewards at four different levels: the individual, the team, the team of teams, and the enterprise. Agile companies focus their rewards both on the value individuals bring to the organization and on the collective success of the teams those individuals are a part of. Base compensation may be market driven, but incentive compensation nearly always has to be based on team or enterprise outcomes. As people advance and take on more responsibility, the proportion of enterprise-based rewards increases. More junior employees may be compensated on individual and team outcomes while senior employees are compensated on a mix of individual, team of teams, and enterprise results. Of course, rewards should always be viewed in context: they must be based on the culture, values, and behaviors that the company is trying to encourage.
Microsoft’s infamous approach to performance management and rewards in the early 2000s offers a cautionary tale. For many years, the software giant used a stack ranking system as part of its performance evaluation model. At regular intervals, report Mankins and Garton, “a certain percentage of any team’s members would be rated ‘excellent,’ ‘good,’ ‘average,’ ‘below average,’ or ‘poor,’ regardless of the team’s overall performance.”9 Since compensation was directly tied to each employee’s performance rating, exceptionally talented people avoided teaming with other exceptional players, because it would risk undermining their performance rating and compensation. In effect, the internal market system discouraged teamwork, with predictable effects on productivity. “It took just 600 Apple engineers less than two years to develop, debug, and deploy OS X, a revolutionary change in the company’s operating system. By contrast, it took as many as 10,000 engineers more than five years to develop, debug, deploy, and eventually retract Microsoft’s Windows Vista.”10 At least a portion of this fortyfold difference in productivity can be explained by Apple’s emphasis on team-based rewards and Microsoft’s use of individually based stack ranking.
There is a lot to consider in designing a holistic operating model—integrating your organization structure, accountabilities and decision rights, the management system, ways of working, talent practices, and so on. When you do it well, you create mission-inspired teams that work together across the organization, both the run-the-business and the change-the-business elements. You won’t have all of the answers at the beginning. That is OK. You are not supposed to.
FIVE KEY TAKEAWAYS