5    Building an Accountability Framework

In the 2012 movie The Avengers, we see individual superheroes strutting their stuff and winning small victories. When it comes to saving the world, however, it becomes necessary for the superheroes to align their individual talents and work as a team to achieve a common goal. To pull this off, they don’t look to a manager to tell each of them what to do. In fact, the film’s World Security Council doesn’t trust the team and wants to send a nuclear bomb to stop the enemy. The superheroes make a different decision—a better decision—and by both exploiting and coordinating their individual talents, they save the world.

As companies populate their digital platforms and configure their digital offerings, they will be deploying their own teams of superheroes. Individually, these superheroes (which may be teams or individuals in the corporate world) can achieve great things like writing a cool app or developing an artificial intelligence algorithm. In other words, each superhero can successfully create components. But to meet big enterprise goals, superheroes must ensure that their individual components combine to deliver truly remarkable digital offerings.

Traditionally, companies have expected managers to know how to achieve business objectives and to instruct others as to what they should do. That approach can generate business efficiencies, especially when addressing well-understood problems. It does not foster innovativeness.

If businesses hope to succeed digitally—if they expect to develop valuable digital offerings at scale—they will need to empower their people to imagine and build great components. Just as important, they will need to align the efforts of those empowered people so those components work effectively together. This goal of empowering people while coordinating their individual efforts is why companies need an accountability framework. Your digital platform is the technology base for digital success. Your accountability framework defines roles and processes for building and using the digital platform.

Creativity, Not Chaos

Established companies designed for efficiency have usually relied heavily on hierarchical structures. They have done so because command and control management approaches have helped companies implement optimized enterprise processes. When reliability and predictability are the most important characteristics of a process, management will want to prescribe how employees should execute that process.

Developing digital offerings (and their underlying components) depends less on standardized processes and more on rapid innovation. Leaders count on people to imagine what’s possible and make it happen. To stimulate creative thinking and exploration, digital leaders are eschewing prescribed, hierarchical processes in favor of empowering people to identify, create, and manage digital offerings. Much like start-ups.

Empowerment pushes decision making to the lowest viable organizational level. Doing so ensures that the people making decisions actually witness the impacts of their decisions. Rather than wait for higher-level analysis, deliberation, and consensus building, decision makers can respond immediately when a change has a deleterious effect on a customer or another employee. These decision makers are also better positioned to think outside the box—to do whatever it takes to solve a problem rather than fall back on normal business rules or processes.

Of course, empowering teams individually to manage digital offerings could easily lead to organizational chaos. Employees responsible for any given component or offering could take actions that optimize that component or offering but fail to further company goals. Companies avoid chaos by developing an accountability framework, which we define as distribution of responsibilities for digital offerings and components that balances autonomy and alignment. The accountability framework building block establishes ownership for each digital component.

Most executives recognize that adopting the accountability framework necessary to build and leverage a digital platform (as opposed to an operational backbone) entails making fundamental behavioral changes. Some executives have suggested that they can enact this behavioral change by simply changing incentives. We wish! Incentives are merely one piece of the puzzle in the leadership of a more empowered, more componentized working environment.

Empowered teams establish metrics, define processes, assess outcomes, and adjust their own activities to meet team goals that contribute to larger company-wide goals. To ensure that the efforts of individual teams complement (rather than conflict with) the efforts of other teams, companies must carefully design accountabilities. Clear goals, access to supporting tools and resources, and lots of training and coaching are essential. Otherwise, empowered teams will unleash chaos rather than creativity. You will have components, but you are unlikely to produce competitive digital offerings.

Managing Living Assets

Digital offerings are software based. Because software is intangible, it is endlessly adaptable. Valuable software components can and should change regularly to reflect new learning about what customers want and what technologies can do. Apple, Microsoft, Salesforce, and any other vendor that creates software that people use to perform daily activities have made constant software updates part of our lives. Becoming a digital business will shift your company from one that grumbles when tech partners impose software updates to one that strives to regularly churn out value-adding software updates that benefit your customers.

Because software can and should change regularly, we think of digital offerings and their key software components as living assets. They start small and simple and then grow as they attract customer interest. Eventually, they may be retired. To adapt to customer needs and new technology capabilities, living assets need attention—in many cases, constant attention.

Updates to components are thus an essential part of most digital value propositions, but they place new demands on how people work. People must respond rapidly to new customer insights, which creates a dynamic working environment. It is this dynamic environment that makes empowerment—and accountability—so essential. Hierarchical decision-making processes are too slow, and leaders at the top of the hierarchy cannot possibly be aware of everything that is needed to respond to constantly changing customer demands.

The key role in an accountability framework is that of component owner. A component owner is a team or an individual who is not only responsible for building a valuable component but also for sustaining component quality, cost effectiveness, and usefulness to those who rely on it (employees, customers, and/or partners) throughout the life of the component.

Some component owners are responsible for digital offerings. They develop and maintain the code defining the offering. That code accesses reusable components, as needed, while also providing unique (non-reusable) functionality. Other component owners are responsible for the business, data, or infrastructure components that digital offerings rely on. They make it possible for owners of digital offerings to release new features as soon as they are ready.

It is important to note that creating an organization that can manage living assets is a much more fundamental organizational change than simply adopting Agile methodologies. Agile methodologies change how companies develop software. Rather than invest time upfront developing a detailed set of system requirements, developers surface requirements from users by eliciting feedback on software developed iteratively in short “sprints.” To manage living assets companies must assign accountabilities for constantly evolving software components.

Suresh Kumar, former CIO at BNY Mellon, described a component owner as a mini-CEO with total responsibility for the success of his or her product. (No wonder digital management is so hard—digital companies have many CEOs!) A component owner (a mini-CEO) manages one or more components and the value those components generate. The concept is simple, but the implementation is not. Kumar noted that only about one third of his original component owners took naturally to being a mini-CEO. Many, but not all, of the others could be trained.1 Delivering a great offering or component is challenging. Coordinating individual components and offerings to meet corporate business objectives is an even bigger challenge.

An Accountability Framework Promotes Both Autonomy and Alignment

The biggest challenge companies will face when trying to build and use a value-adding digital platform will not be technical. Building an API-enabled technology, data, or infrastructure component is reasonably straightforward for a trained engineer. It is much harder to define what reusable components are needed, how they will work together, what kinds of enhancements will add value, and what digital offerings have the greatest promise to contribute to business success. That’s why companies need an accountability framework. The essence of designing the accountability framework building block is adopting roles and processes that provide enough autonomy to unleash creativity while facilitating alignment across autonomous teams and individuals.

Based on research at companies like Spotify, DBS Bank, CarMax, Northwestern Mutual, BNY Mellon, and others, we have identified eight guiding principles for balancing autonomy and alignment (see figure 5.1 for a summary).

Figure 5.1

Management principles for designing digital accountabilities

Component owners, not project managers   Owners of digital offerings and components retain responsibility for what they create throughout a component’s lifecycle. They will not, as project managers do, hand code off to quality assurance, operations, commercialization teams, or customer service units. The philosophy is “you made it, you own it.” The range of responsibilities involved in component ownership is broad and the requisite skills are hard to master. Component owners must be problem solvers; they can’t wait for instructions. Many may need coaching to help them learn how to be effective in the ownership role, especially if they are former project managers.

Mission, not structure   Formal hierarchical structures provide stability and are useful for reinforcing standardized business processes. Component owners, however, are responding to changing customer demands and new business opportunities. They have less need for formal structures and more need for inspiration. To ensure their activities contribute to company goals, component teams need a specific mission linked to company goals. The mission clarifies what my team will accomplish and what other teams will accomplish. In this way, a mission gives a team both a goal and boundaries, thus reducing the need to delineate organizational boundaries in formal structures. The mission facilitates autonomy. Teams pursue goals within the boundaries of their mission and coordinate with other teams only when necessary. To sustain the independence of teams, leaders will need to work with component owners to constantly clarify team missions in ways that, as much as possible, avoid interdependencies.

Metrics, not directives   To deliver on their missions, component teams need to establish metrics that tell them whether they are making progress on their mission, as they build and enhance their components. To help them, leaders review teams’ proposed metrics and debate the suitability of these choices; they do not issue directives. In this way, leaders make optimal use of a team’s creative talents and help team members learn what does and does not work. If necessary, leaders will coach a team on how to get better at choosing and pursuing their metrics, but they will not usurp the responsibility of the team to define how it will accomplish its mission.

Experiments, not major launches   Teams pursue their metrics by hypothesizing what features or actions will yield the desired impacts. They test their hypotheses by setting up experiments. Invariably, that involves writing some code and releasing it to see how customers (or other teams) respond. Teams compare outcomes from their experiments to the metrics they established. If successful, they can set a new goal. If unsuccessful, they change the hypothesis or try a different experiment.

Continuous release, not scheduled releases   To ensure that teams learn and react quickly, they need to release new software code as soon as they develop it. Amazon releases code every few seconds.2 Most companies don’t need to match that level of frequency, but teams cannot wait for periodic, scheduled release dates to obtain feedback. Nor can they rely on an operations team that develops a queue and puts components into production at its convenience. To facilitate continuous release, technology organizations are creating DevOps environments, which minimize or eliminate the separation of responsibility for developing software applications from responsibility for putting applications into production and supporting them.3

Fully resourced teams, not matrixed functions   For component teams to succeed, they need easy access to all the resources required to deliver on their missions. To start with, that means most teams need to be cross-functional. Even cross-functional teams, however, cannot meet all their requirements for unique expertise. The complex matrixed structures that most big companies have developed to provide horizontal functional services across lines of business and geographies are too slow and too standardized to meet the needs of digital teams. Thus, leaders must trust their mini-CEOs to define and creatively address their resource requirements. Sound expensive? It is. Remember the operational backbone is about efficiency; the digital platform is about speed. Expensive does not mean wasteful. Give your mini-CEOs the resources they need and you get teams that are fully accountable for their outcomes and the costs of delivering them. No excuses!

Collaboration, not hierarchy   Well-designed team missions limit interdependencies among component teams. But with so much happening simultaneously in digital businesses, there are times when any given team must coordinate with others. When that occurs, hierarchical decision-making processes are a costly bottleneck. Teams need to learn what other teams they depend on and what teams are dependent on their outputs. Then they can work directly with the relevant parties as necessary. Leaders support these efforts by providing collaboration tools and processes such as co-location, visualizations depicting interdependencies, and weekly stand-ups.

Trust, not control   When something goes wrong, the natural instinct of leaders in traditionally hierarchical organizations is to step in and fix it. They need to resist that inclination. A component team with a clear mission and clear boundaries, actionable metrics, and access to the needed resources is in a far better position to fix a problem than that team’s boss. Leaders in digital companies coach teams to help members understand what went wrong, or how to go about deciding what to do next, but leaders know far less than the team does about a given problem or its solution. Leaders are not head coaches of sports teams (who synchronize individual activities through command and control) but rather process coaches who help individuals hone their skills at taking full responsibility for a component.

These principles highlight the magnitude of the management changes established companies face as they build and use digital platforms. Even at born-digital companies, these principles are hard to implement. Netflix leaders, who are committed to “freedom and responsibility,” note that things don’t work perfectly.4 Indeed, companies adopting these principles observe that accountabilities are constantly evolving. As a company addresses one challenge, a new challenge emerges.

Most of the established companies we studied were very early in their efforts to develop an accountability framework. To understand how such a framework evolves, it’s useful to understand what Spotify, the digital music service, has learned after wrestling for years with the dual challenge of empowering and coordinating component owners.

How Spotify Balances Autonomy and Alignment

Founded in 2008, Spotify is a music streaming company offering both free and subscription-based services. Like many other born-digital companies, Spotify is designed for speed of innovation, rather than efficiency. Like many start-ups, the company emphasizes growth over profits. The result is that Spotify’s digital platform is more developed than its operational backbone. To constantly enhance the digital platform, the company works to ensure that its digital teams address company-wide business goals while optimizing their individual components.5

Spotify has not always had a digital platform. Its initial offering, a desktop client providing music services, was a single, monolithic piece of software. This design was viable when the company’s product was simple, but as product teams multiplied and the company added features and subsequent offerings, the monolithic structure—like the legacy systems in established companies—increased business risk. In particular, its monolithic offering limited market response, because new code could only be put into production after every team had thoroughly tested its own code and the company had tested all interactions.

Recognizing the risks of monolithic digital offerings, Spotify reverse-engineered its earliest offerings, extracting reusable API-enabled components wherever possible.6 Technology leaders then continued to apply modular architectural principles in building the company’s digital platform.7 Half of Spotify’s 3,000 employees now build out and use the company’s digital platform to design, deliver, and sustain digital offerings and components.

Four mechanisms help Spotify balance autonomy and alignment.

Autonomous Squads Own Components

Spotify assigns ownership of digital offerings and key components to tribes and squads. In general, a tribe owns end-to-end responsibility for a digital offering. For example, the Music Player tribe handles the importing of audio from partners, as well as storing, streaming, search, and a variety of related services.8 The Infrastructure and Operations tribe, which is the largest, provides most of the infrastructure components.

The tribes are broken into squads, each of which owns one or more components supporting a digital offering or an underlying digital component. The Music Player tribe has a squad responsible for search; the Infrastructure tribe has a squad responsible for the AB test environment. Spotify leaders emphasize the need to define boundaries to limit the need for collaboration across squads.

Fundamental to squad autonomy is the premise that the people working on an offering or component are best equipped to make decisions about it. Accordingly, Spotify does not dictate process or technology decisions to squads. Instead, coaches work with squads to help them learn how to make these decisions. Squads set their own goals, choose their own processes and technologies, specify their metrics, conduct experiments, and assess the outcomes of their experiments against their metrics.

Modular Architecture Supports Autonomy

Spotify has designed a modular digital platform, which means the platform is a set of repositories of API-enabled components (as we described in chapter 4). This design supports a “limited blast radius,” that is, it minimizes the risk that one squad’s new code will take down another squad’s component. For example, one squad’s experiment might inadvertently take out the album pictures from the music platform, but because of Spotify’s componentized architecture the problem will be limited to the album pictures. The limited blast radius means that a problem with album pictures does not affect other important components, like a user’s ability to play music and search.

Modularity allows the company to create a DevOps production environment. The DevOps environment, in turn, allows teams to put new enhancements and features into production as soon as their code is stable. This allows rapid customer feedback, which accelerates learning and facilitates more experimentation.

Missions Come with Guardrails

The central mechanism for ensuring alignment within and across tribes is Spotify’s concept of mission. A mission is a statement of the long-term key strategic objective owned by each tribe (and ultimately individual squads). For example, the mission of the Music Player tribe is “providing fast and reliable access to all the world’s music.” The mission of the Infrastructure tribe is “enabling high product development speed while maintaining a highly available service.”

Missions are guided by—and to some extent help establish—the company’s “bets.” Bets are strategic objectives for the whole company, while missions define tribes’ objectives. Metrics then define how squads will contribute to tribe objectives. For example, a bet could be, “We believe we can increase retention or we can reach x users or more artists by [doing this].” Spotify Organizational Coach Anders Ivarsson explained further:

“Company bets” are what we call our top company priorities. They are the top 10 things, or the top five things we do as a company. We call each of them a bet, because we actually don’t know what the outcome will be. … We start with what are all the data we have around this? What insights are we drawing from this data? Based on those insights what are our beliefs about the world? Based on those beliefs what is the bet that we’re making?

Missions and bets are established both through bottom-up and top-down processes at Spotify. Some ideas come from leadership. More often, ideas come from individuals who work on (or use) Spotify components. Those ideas are then articulated as goals to be achieved within a given time and mapped to clearly defined metrics.

When market conditions change or when the company identifies new opportunities, bets and missions also change. Such changes can require that squads and tribes be reformulated. Change is a constant at Spotify.

Shared Knowledge Sustains Alignment

To synchronize daily activities across squads, Spotify has introduced two coordination and knowledge-sharing mechanisms, chapters and guilds. Chapters are organized around a competency like testing, graphical design, or backend development. Every squad member belongs to a chapter. The chapters facilitate learning that leads to more coherent technology decisions across squads. While squads do not have leaders, chapters have heads who function like line managers, in that they are responsible for the development of people in their chapter. This design fosters flexibility because individuals can move to a new squad without changing chapters. This is particularly valuable for enabling the formation of ad hoc, temporary teams to address a specific problem. Unlike component teams, these teams can form and disband as needed.9

Guilds bring together people who share similar interests across different tribes and sections of the organization. Guilds stage internal “unconferences” to share the latest discoveries in their domain and to formulate best practices. In this way, guilds help members develop new skills. For example, a blockchain guild would provide a learning forum for all those people interested in blockchain. Anyone can join any guild.

At Spotify, Agile coaches also play an important role in knowledge sharing, particularly around methodology. Because they work with multiple squads in a tribe, they can recommend practices that other squads have implemented. Other formal and informal knowledge sharing mechanisms include post mortems after failures, where squads can learn from each other’s failed experiments, and weekly standup meetings, in which everyone shares progress and surfaces issues that are blocking progress.

Leaders at Spotify note that the company is constantly evolving. No set of practices works exactly as planned and every solution exposes a new issue. Thus, the company constantly redesigns itself to address current issues and opportunities. We expect this will be the norm in digital companies.

Figure 5.2

Key mechanisms in an accountability framework

Figure 5.2 summarizes the key mechanisms in Spotify’s accountability framework:

At established companies, the mechanisms supporting autonomy and alignment must complement existing product development and operational processes. Because digital offerings initially generate only a small percentage of company revenues, leaders will want to define an accountability framework that develops digital offerings without disrupting traditional ways of doing business. This means that the mechanisms balancing autonomy and alignment target digital offerings rather than the entire product and service portfolio—at least initially. CarMax, which was founded in 1993 as an online used-car retailer, limited disruption by introducing a new accountability framework only in its digital innovation unit rather than the entire company.

How CarMax Balances Autonomy and Alignment

CarMax, the largest used-car retailer in the US, with nearly 200 stores and 25,000 employees, has redefined accountabilities as part of its efforts to transform the customer experience. CarMax has three lines of business: a consumer business that buys and sells cars, a financing business, and a wholesale car auction business. The company also offers used car buyers various complementary products or services, such as extended warranties, gap insurance, and car financing from other companies. Its new accountability framework includes teams pursuing opportunities to improve both customer-facing and customer-enabling (i.e., associate-facing) experiences. Like Spotify, CarMax relies on the four mechanisms in figure 5.2 to balance autonomy and alignment.

Empowered Teams and Groups

CarMax assigns accountability for building and sustaining components to more than 25 teams of 7 to 9 people with life-cycle responsibility for what they call “products.” Product teams are co-located and they are enduring. Examples of products include online financing, search engine optimization, and digital merchandising, as well as platform services. Groups (like Spotify’s tribes) of product teams (like Spotify’s squads) focus on different stages of the customer journey: Customer Searches, Customer Buys, and Customer Sells. Individuals identify strongly with their teams, even though they formally belong to different functional areas (similar to the chapters at Spotify), most often technology, marketing, or operations. The three key roles on each team are product manager, lead developer, and user experience designer. The individuals in these roles tend to stay together, to facilitate camaraderie and to help teams gel, while other roles are added or subtracted.

Missions

To clarify missions and help both teams and leaders track outcomes, CarMax uses “OKRs” (objectives and key results). As an example, the digital merchandising product team might establish an OKR to grow the click-through rate by 2%. Teams define two-week goals targeting their OKRs. Within a group, the teams share customer outcome OKRs, which align individual product teams with the company’s goals for the customer experience. While teams remain relatively stable, OKRs can shift. Like Spotify, CarMax empowers its teams by being specific about the what, and leaving it to teams to figure out the how. Leaders encourage team members to hypothesize, test and learn. This is a monumental shift from how CarMax operated in the past.

Modular Architecture

To facilitate autonomy, CarMax, like Spotify, uses Agile methodologies to build reusable components for a digital platform. Critical infrastructure allows teams to release code at least every two weeks (consistent with the pacing of their goals). Some product teams are releasing code multiple times a day. As at Spotify, modularity allows teams to change their components without having an impact on other teams’ components. This modularity is considered essential to team autonomy and to jointly achieving business outcome goals.

Knowledge Sharing

CarMax applies both formal and informal mechanisms for sharing knowledge to promote alignment across the company’s autonomous teams. At the executive level, the chief marketing officer, chief information and technology officer, and chief operating officer talk daily, and they retain personnel development responsibilities for individuals from their functions. Vice presidents in both CarMax Technology (the company’s IT group) and Marketing work closely together to provide team coaching. As at Spotify, group leaders shape priorities for their teams and work together to resolve any conflicts among groups—although clear boundaries have limited the number of issues that arise. Teams take responsibility for sharing knowledge in biweekly open houses, where they provide to one another—and to hundreds of others in the company—a 15-minute summary of their goals and results from the prior period. These sessions are live-cast to select CarMax locations and open to everyone. This knowledge sharing provides essential visibility and transparency, which has made it possible for the relatively small number of people on product teams to have a huge impact on how the company does business.

CarMax’s accountability framework has facilitated development of new digital offerings. For example, when the company wanted to add an online financing option, a team tested a concept with customers every two weeks and eventually rolled out an offering that allows customers to apply for and evaluate car-financing options at home. An enduring online financing product team now owns and improves the online financing product. This is how digital companies constantly evolve.

How to Develop an Accountability Framework

Many companies are accelerating software development by adopting Agile methodologies. That speed helps companies accumulate shared customer insights through constant feedback and iteration. It can also help populate a digital platform with reusable components—if the teams are charged with that responsibility. But don’t congratulate yourself on becoming digital just because you have Agile teams. Agile methodologies alone will not enable your business to create digital offerings at scale. You need an accountability framework that balances autonomy and alignment.

The principles and mechanisms described above can help you design an accountability framework that fosters digital innovation. Be aware, though, that there is no template for your digital organization. You cannot hire a consultant to define a target state. Instead, you will continuously evolve accountabilities to address current needs and resolve problems. Your company will have to learn how to succeed as a digital business.

Spotify is constantly tweaking tribes and squads and the mechanisms supporting them. CarMax is transforming through an innovation unit whose empowered teams share their goals and outcomes. Haier, the large Chinese appliance manufacturer, has divided its business into more than 4,000 microenterprises, most with 10–15 employees.10 These microenterprises each make market-based decisions about what services to acquire from other parts of Haier and which to acquire on the open market, thus optimizing autonomy. But Haier is also organizing related microenterprises into platforms, which encourages alignment across microenterprises. Every company building a digital platform is learning how to assign accountabilities that will balance autonomy and alignment.

Sometimes that learning will be painful. Leaders that have thrived in hierarchical and bureaucratic environments are likely to be more comfortable telling people what to do than trusting them to innovate and collaborate. They may feel ill equipped to coach rather than direct. Similarly, many people who have settled into a habit of taking orders will be uncomfortable making decisions and taking responsibility for them. In short, developing an accountability framework involves major culture change. Our research has identified some guidelines that help companies adopt an accountability framework and the culture it demands.

  • Distinguish responsibility for internal processes from responsibility for new offerings.
  • Implement gradually.
  • Create coaching roles.
  • Rethink governance.

Distinguish Responsibility for Internal Processes from Responsibility for New Digital Customer Offerings

An operational backbone and a digital platform are, as noted previously, both essential to business success, but they play very different roles. In general, the operational backbone enables efficient internal processes and the digital platform underpins innovative digital customer offerings. One measures success in terms of reduced costs and reliability; the other measures success in terms of revenue growth and organizational learning. Companies will be more successful if most of their people accept responsibility for one environment or the other, not both. If individuals throughout the company are constantly trying to reconcile the need for both efficiency and innovation, they are likely to do neither well.

Invariably, teams attempting to develop new digital offerings encounter issues related to the operational backbone. For example, they may not be able to get good customer data; they may need greater visibility into transactions; or they may encounter problems with supply chain processes. The inclination of these digital leaders is to do something to fix what’s broken (e.g., build a customer database or overhaul supply chain processes). That is a huge mistake.

Only process owners should fix broken processes. Otherwise, multiple teams will take different approaches to the same problem (e.g., create multiple customer files or fix supply chain processes in different ways). At a minimum, their efforts will be redundant; in the worst-case scenario, they will conflict.

It is useful to distance teams dedicated to supporting internal processes from those that are developing new digital offerings and their platforms. At Royal Philips, for example, the IT unit is responsible for the operational backbone. Responsibility for the company’s digital platforms, HSDP and CDP², rests with teams under the chief innovation and strategy officer.

Schneider Electric and Toyota Motor North America promoted their CIOs to head their digital businesses and gave them responsibility for both the operational backbone and the digital platform. Their digital organizations, however, have separate leaders for the backbone and digital platform. This arrangement distinguishes individual responsibilities while making it very clear that they are highly interdependent.

Implement Gradually

Autonomy principles allow component owners to address opportunities and issues creatively. Alignment principles ensure that the creative solutions applied to one digital offering complement others and fulfill the company’s mission. As a digital platform matures, and the number of employees developing and using the digital platform grows, it becomes increasingly challenging to maintain alignment without curtailing autonomy.

Multiple companies have found that their first digital team can release the first offering with few organizational issues. It’s also not difficult organizationally to create a second or third team to support the reusable components of that and subsequent offerings. It doesn’t take long, however, before the interdependencies of growing numbers of teams and components create new and unresolved management challenges.

Some companies are transferring large numbers of people at once into agile, empowered organizational environments. If the company has limited experience with defining accountabilities in an empowered environment, this tends not to go well. Start-ups initiate accountability frameworks when they have tens of employees, not thousands. Even then, it is difficult to get this right. Thus, it’s better to grow gradually into these new business designs. Remember: if you’re trying to act like a start-up, starting small is a design characteristic you’ll want to embrace.

A number of companies are learning how to develop accountability frameworks by starting within their IT units. This can be a logical starting point, because many IT people take naturally to principles of componentization and modular architecture. Often they have experience with Agile methodologies. That experience usually results in a preference for cross-functional teams and rapid, iterative delivery.

Northwestern Mutual, for example, sparked its business transformation by realigning its IT people around its three stakeholder groups: clients, advisors, and employees.11 IT leaders then assigned teams to manage, end-to-end, the digital products associated with each stakeholder group. As part of a commitment to build and enhance living assets, the company has started bringing non-IT business professionals permanently onto teams, and instituting business product owners.

Some companies implement accountabilities gradually by testing out an accountability framework in a separate digital organization. Audi Business Innovation (ABI), AUDI’s digital unit exploring new sharing economy–based digital offerings and new ways of working, is a separate legal entity based in Munich rather than Ingolstadt (where AUDI’s headquarters is located), which affords its staff significant autonomy. To ensure that ABI helps all of AUDI become more digital, it shares key personnel with AUDI. In addition, AUDI’s CIO is a member of the board of ABI, ABI is wholly owned by AUDI, and ABI leaders discuss the business cases for digital offerings jointly with AUDI.12

Similarly, in 2016, Toyota Motor North America set up Toyota Connected to isolate digital experiments from ongoing business priorities. Eventually, both AUDI and Toyota hope these digital units will act as nuclei that spread new ways of working to the mothership.

Codifying the principles guiding a company’s accountability framework helps make them explicit. Companies like Spotify and Netflix have put their principles of working into writing (and posted them on the internet). Similarly, companies like DBS Bank are finding they need to write down their intentions about how people will work, to clearly establish expectations. Paul Cobban, the chief data and transformation officer at DBS, says he wants to move beyond “typical value words” (think: “team-up,” “be decisive,” “empower”) and provide specific written guidelines on his team’s ways of working. For example, instead of just telling people to work across silos, DBS is changing the workspace and increasing co-location to foster working across silos. Cobban is also spelling out what it means to work across silos at DBS. Codifying your culture explicitly helps your current employees discuss it, debate it, and improve it. Externally, it helps to attract the right kind of talent for your company.13

Create Coaching Roles

At Toyota Connected North America, an executive leadership team at the 200-person organization defines its role as guiding the group’s product (i.e., digital component) owners. The Executive Action Team (known as EAT) meets daily. Zack Hicks, CEO of Toyota Connected North America, describes their efforts as follows:

Our job isn’t to tell them what to do. Our job is to remove the obstacles that are in the way, as senior leaders. The product managers can hire and do as much as they want, as long as they’re profitable. So they can reinvest their profits. That keeps them focused on what the business wants, and what the customers want. We do give feedback. I do one-on-one sessions with them, but it’s not to manage their daily activities.

Spotify emphasizes the role of its Agile coaches in helping teams define their processes and deliver to their missions. Companies are engaging Agile coaches for roles varying from teaching Agile methodologies to offering support for leaders who oversee digital teams.14 Because leaders will find coaching an increasingly important part of their roles, most will need coaching on how to coach well.

DBS Bank assigns a partner from its transformation office to the leaders of its autonomous teams, to help them learn the new “CEO” aspects of their responsibilities. It refers to the partner as a “Sherpa”—someone to help the team learn how to articulate and achieve its goals. Sherpas provide templates, methodologies, and guidance for the team. The transformation team wants to make sure that people within DBS feel equipped to handle their ever-changing roles. DBS is also heavily investing in formal employee training in innovation, Agile methodologies, evidence-based management, and related skills. This kind of investment is likely essential to changing an organizational culture. It will not serve companies well to design digital offerings but fail to invest in the people who will be key to the long-term success of those offerings.

Rethink Governance

Many leaders think of governance as the decisions that rest with senior executives related to formulating business strategy and aligning resources to ensure execution of that strategy. We have defined governance as specifying who makes—and is held accountable for—what decisions.15 Building an accountability framework is a governance effort.

The accountability framework for digital devolves many decision rights to autonomous teams while creating a context to help these teams make the right decisions. Paul Cobban explains what DBS is doing to push accountability down:

You have to set a clear outcome, and give people boundaries—what we call “the electric fence.” We are trying very hard to define the values very clearly, so people know when they are about to grab the electric fence. Anywhere inside the fence, and as long as you’re moving towards your goal, you’re empowered to do whatever you want. We’re trying very hard to coach people and teach people how to empower their teams.

Traditionally, the most important senior executive governance decisions in a company have involved the allocation of resources. After establishing business strategy, executive leaders would design structures allocating responsibilities for executing that strategy, and then make investment decisions to provide the resources for strategy execution efforts.

In digital organizations, the most important senior executive governance decision relates to the defining of missions. Well-defined missions enable autonomous teams to focus on meeting their goals. Because they are accountable for the costs and benefits they generate, teams are less likely to seek resources they cannot convert into value. If the missions are poorly defined or insufficiently distinct, the efforts of empowered teams will collide and company goals will be at risk. This is why defining clear missions supplants resource allocation as the key governance decision in digital organizations.

Most of the companies we have studied fund experiments knowing that some will fail. Those experiments usually have a short life. Many companies require that an experiment yield a minimum viable product (MVP) in two to three months. Future funding depends on demonstrating value. As one digital business head described the process:

If we’re seeing steady releases, then we’ll continue to fund them. If we don’t see steady releases, or they are not able to break through with customers, then they’re going to have to go through more governance.

Once teams become established, they tend to have a sustaining budget, but leadership teams monitor their results to ensure teams stay on track. Zack Hicks at Toyota Connected notes that because teams are specific about their missions and metrics, everything is visible:

I understand what’s in progress, what was released this week, and what’s their burn down chart. This is how, over a period of time, I can see how much they’re actually producing.

Senior executives will continue to make key decisions about which new strategic initiatives to pursue and which to forego. This includes investments in infrastructure components like the decisions Toyota, Schneider Electric, and Philips made to invest in connectivity. Some of these decisions may feel like venture capital decisions—identifying business experiments worth testing. Philips’s executive team explicitly considers the reusability of an offering (or its underlying components) as part of its decision on what digital offerings to fund.

At successful digital companies, leaders will make it a daily task to identify new offerings worth pursuing and new issues that are obstacles to digital success; leaders will then find people to own the missions related to these new opportunities and challenges. It may take time for people accustomed to fairly stable organizational structures to become comfortable with constantly evolving accountabilities. Over time, however, continuous change in accountabilities should become second nature.

Getting Accountability Right

Our research suggests that established companies are very early in their understanding and application of accountability frameworks that are essential to digital success. But they are learning! Their traditional reliance on organizational structures to allocate responsibilities will surely die hard. But once they adapt to an environment in which they see a problem or opportunity and immediately empower a team or individual to own that mission, they are unlikely to look back. Here are the key lessons from this chapter:

Building your accountability framework may be the hardest building block of all. Find the biggest obstacles to your company’s ability to manage living assets. Start experimenting to learn how to get your accountabilities right.

Notes