5
Working with the Performance Engine: Graduated Engagement

DOI: 10.4324/9780429433887-5

The Problem: Where You Stand Depends on Where You Sit

The Innovation Stage-Gate is concerned with innovation capability. It is focused on creating an innovation engine that is productive and that fits in the corporate setting.

The next challenge is to manage the dynamics of innovation in the corporate setting, which often means dealing with organizational resistance. Resistance to innovation is so prevalent in large companies that it is almost a proverb. It cuts across functions and across hierarchical levels and is a major reason that so many innovation programs do not achieve the business success that they could.

Dealing with resistance to innovation starts with the observation that resistance—though frustrating—is not irrational. People in organizations behave as you yourself would behave if you were in their shoes. Consciously or not, they calculate the best response to an innovation initiative—for their organization and for their own careers—and they act on that calculation. For those in the core functions, deviating from standard procedures is risky, at both a personal and a functional level. It is safer to stick to established ways of doing things. That the response is counterproductive to innovation is a side effect, not the objective.

Innovation teams often fail to appreciate this perspective. Instead, they tend to view those in the corporate functions as recalcitrant, reactionary, and unduly risk averse. As a result, they become angry, frustrated, and disempowered. They dig in their heels or escalate the lack of cooperation to higher management.

These are unproductive responses. They do not take into account that the people in the company’s core functions have legitimate concerns. If the innovation team does not understand these concerns, and does not actively seek to manage the interaction between the venture and the core company, the innovation program can be slowed, or even smothered to the point of suffocation.

A few examples illustrate the point.

Contracts 101

Imagine yourself as a bright, forward-looking contracts attorney inside a corporation.

One day, you are given a contract to review that is very different from a typical contract: It is focused on guaranteed service outcomes, rather than the sale of product. This is a new area for you. You don’t really know what new risks might be involved or how to protect against them. You can see a few of the risks right off the bat, but you wonder what you might be missing. It is a small contract, so the downside may be limited, but the contract certainly isn’t going to move the needle for the corporation in the next six months either. You know that the innovation team is hot to get this signed, but you think that perhaps you should do a little research first. You don’t have the time just now, given that large product agreement that just came across your desk from the head of the division—a contract that needs to be signed before the end of the quarter. You will help, but only after you have done your research. The new venture contract goes to the bottom of the stack.

The “Other” Category in Procurement

Something similar is happening in Procurement. The director of that function is considering a request from the innovation team for a new tracking system. She is asking herself, “What is this device, and what does it have to do with our business?” It doesn’t fit in any of the standard procurement categories, so she is not sure why it has landed on her desk. Not a problem, really; she can identify alternative suppliers, qualify them, and get the selected vendors put on the approved vendor list. Then she can put out a Request for Proposal (RFP) and bid the thing out. The only problem is that there really aren’t several vendors. If there were, she doesn’t know what expertise would be required to qualify them, and her team is busy (as usual). The deal itself is for less than ten thousand dollars, hardly worth a big effort. Still, if the new venture ever goes forward, the company may buy millions of them. Better to negotiate now rather than wait for the pilot to end when her company might be locked into a supplier with no leverage. On top of these issues, the director is concerned that the vendor doesn’t have the company’s standard liability insurance coverage, and the company is so small that it doesn’t seem capable of getting it. She can just imagine the liability risk. She sets up a meeting with her team to discuss alternate suppliers, but the innovation team wants to make the purchase now. The director longs for another straightforward purchase of 100 tons of carbon black!

You get the picture. Each department has analogous concerns and similar pressures. For these departments, the innovation team’s requests come with little upside and a lot of (potential) downside (see Figure 5.1). No one says this out loud, of course, because innovation is a priority.

FIGURE 5.1
Graduated engagement

Back at the innovation department, people are pulling out their hair. Moving the new venture even a small step closer to reality seems to take Herculean effort. No one really says no, but everything drags out forever. Rapid iteration is not even possible. The tension builds. There has to be a better way.

The Root Causes of Resistance

Govindarajan and Trimble have coined a term for the functions that appear to resist innovation—the “performance engine.” [Govindarajan and Trimble, 2010] The performance engine exists to maintain effective, efficient, and continuously improving operations—not to drive innovation. Innovation disrupts the performance engine and makes it harder for the people in the functions to keep the core business running. There is therefore an inherent conflict between the innovation team and the performance engine. This is what results in the appearance of resistance to innovation initiatives.

Lean Startup exacerbates this conflict in two general ways—through disruption of work and through the undermining of standards. Business experiments disrupt the work of the functions, yet they are the lifeblood of the Lean Startup method. They require people to set aside standard operating approaches and do things differently, at least for this project. Supporting innovation in this way can be risky for the people who work in the core for several reasons. First, it is easier to make mistakes in unfamiliar areas. Second, supporting a new venture may cause the function to shortchange its commitments to the core business client, a cardinal sin for a support group. Finally, supporting an innovation initiative may come at the risk of defying a supervising manager who is opposed to the initiative. Each of these risks is real to individuals in the functions, and they need to be acknowledged by innovation teams.

The second way that Lean Startup exacerbates the conflict is by undermining standards. For people who are leading functions—especially first-line managers—supporting innovation may mean making exceptions to the function’s established standards. This can be hard for the function to accept. The innovation team may want to bypass the existing Stage-Gate‘ product development process, for example, or it may need to use non-standard technologies (or even technologies for which the company does not yet have a standard operating environment). Standard practices for managing intellectual property or procurement may need to be relaxed to speed experimentation with clients or customers.

For the core functions, exceptions feel like a slippery slope. The processes and standards that they worked so hard to establish and to communicate and enforce will be undermined. The standards may not make sense for a new venture, but the functions fear that relaxing them will open a Pandora’s box of exceptions. Any resulting erosion of standards will increase day-to-day costs for the function and raise the specter of future cost increases as the functions struggle to support non-standard products.

Both of these risks—to the individuals within the functions and to the standards that are essential to routine operations—need to be recognized and managed if a venture is to succeed in a corporate context. The good news is that this is possible. It starts with an innovation team understanding (and even honoring) the roles of those in the performance engine. Once the interests of the functions are well understood, they can be harmonized with the work of innovation.

The Role of Game Theory

Making a collaboration between the functions and the innovation team work requires understanding the underlying dynamics of the organizational games being played. There is a branch of mathematics that can be used to do just that: Game theory. Game theory can help to identify and explain people’s personal “payoff matrices”—the calculations that drive them to behave as they do. Once you understand these forces, you can make changes that shift the rules of the game in subtle but productive ways [Ritti and Funkhouser, 1977].

Game theory uses mathematical techniques to predict the behavior of actors in a social context. The underlying assumption is that people will, subconsciously or consciously, calculate their risk/reward (payoff) from any situation (game). It predicts that rational participants will act in a way that will minimize their maximum loss. Both of the general patterns of resistance to innovation can be explained with game theory and this heuristic for decision-making.

Many different types of games have been articulated and modeled by systems modelers. Each has its own payoff matrix and dynamics. Two of these games are important for internal innovators: The Samaritan game and the Watchdog game.

The Samaritan Game

The first of the innovation games is the Good Samaritan game. It comes into play for those executing Lean Learning Loops in the corporate context.

Think of people in the functions as Samaritans, analogous to the Samaritan in the parable who helped the man who was robbed and left for dead. Like the Good Samaritan, those in the functions can choose to help the innovation function, likely for little reward, or they can choose to not help the innovation function, at some personal risk.

Choosing to help might come with a range of risks. It could put the person behind on other obligations or add to his workload. If the request is novel (as it often is), the person may make a mistake, and that mistake could have future consequences, which are at present unknown. On the other hand, the consequences of not helping are often minimal. The refusal may be explicit (an outright refusal to play) or implicit (repeated deferral of the request). In either case, the innovation team does not get the help it needs; it is, in fact, hampered by the expectation that it will.

Of course, helping the innovation team may offer some reward, but those rewards are mainly intrinsic, while negative consequences may affect the person’s career path or bonus. As a result, there are few Good Samaritans, beyond those acting on the goodwill of existing relationships.

For the function, the Good Samaritan payoff matrix looks like Table 5.1. As the table illustrates, the best solution for the core functions – the one that minimizes the maximum loss – is to refuse to help.

TABLE 5.1
The Function’s Payoff Matrix for a Good Samaritan
 Innovation result
Something goes wrongEverything goes well

Function helps

Bonus affected

Atta boy

Function refuses to help

Mild admonition

Nothing

What can the innovation team do about this situation? An obvious choice—one often pursued with short-term benefit—is to raise the costs of noncompliance, for instance, by escalating the issue. Raising the costs of refusing to help can tip the payoff matrix, creating an incentive to help (or at least appear to be helping). But escalations quickly wear thin, for everyone involved, and they leave a trail of ill will.

Another tactic is to reduce the costs to the function of helping. Senior executives, for example, might provide air cover (clear permission), reducing the risk of a negative payout. Alternately, the innovation team might fund dedicated resources in the functions to support the innovation team, reducing the risk of the function not meeting its other obligations. Or the innovation team might explicitly accept part of the risk of any mistakes that may be made, perhaps by signing off on exceptions to normal practice.

This approach has the advantage of being sustainable. In many ways, it creates a win-win scenario. The people in the function get permission, resources, and the potential to use their capabilities in a new area. The innovation team gets the help that it would otherwise need to source from outside the company.

The Watchdog Game

The second kind of innovation game is the Watchdog game. It comes into play for those building MVPs in the corporate context.

Part of the role of the manager of a function is to protect the function’s territory and processes, like a watchdog protects its territory. What the manager is protecting is the standards and ways of doing things that the function has established over time. The rules can seem bureaucratic and inappropriate to innovation teams, but they are there for a reason. The functions that have the strongest watchdog character are usually product development and IT; they have the most to lose if things get out of control because—inevitably—they will be accountable for permitting the project to move forward.

Confronted with a request from the innovation team, watchdogs have a choice: They can permit exceptions to policy to help the innovation function or they can stick to their guns. Often, they choose to stick to their guns, primarily out of a fear that one exception will lead to another, and pretty soon, the world they manage will become unmanageably chaotic. The costs of dealing with the exceptions will overwhelm the function and reduce the quality of their output. The watchdog sees how an apparently innocuous exception could have negative long-term consequences.

Again, it’s not hard for the function to undermine what the innovation team is trying to do. They can refuse resources to those who do not follow the established process or who do not work with the standard operating environment. They can demand a study of the proposed exception, which may take a very long time. They can escalate the innovation team’s noncompliance, which can result in cycles of meetings and justifications. Whatever the function does, the innovation team does not get the permission or the resources that it needs to proceed. The project is needlessly delayed.

Of course, the watchdog may also see some reward in helping the innovation team succeed. For instance, the innovation team may be on the cutting edge of a new trend that will affect the function in the future, like open-source software, cloud computing, or agile development. But most of these megatrends fade or are so delayed that they present more of a risk than an opportunity for the function.

On the other hand, if something is going to go wrong, it’s likely to happen much sooner than any trend will come to fruition. And as soon as it does, the manager will likely be called to task: Why did he or she permit this to happen? Don’t they understand the importance of standards? For the functional manager, the negative consequences of appearing to lose control of the function may far outweigh the risk of not being on the cutting edge of new technologies or practices. As a result, watchdogs tread very carefully.

The watchdog’s payoff matrix looks like Table 5.2.

TABLE 5.2
Payoff Matrix for the Watchdog
 Innovation result
Something goes wrongEverything goes well

Function permits exceptions to support innovation

Manager called to the task; budget issues

Atta boy

Function refuses to permit exceptions

Mild rebuke

Nothing

Permitting an exception comes with the biggest downside to the function. If something goes wrong—the solution fails, the product is hard to maintain, or costs are high—the manager is held to account for letting it happen. Clearly, the best choice for the watchdog manager is to drag his or her feet or at least to scrutinize the new request carefully before allowing it.

What can the innovation team do about this? The biggest concern of a watchdog is that any exception will get out of control: An experiment that starts small will turn into a deployed system that has to be maintained; everyone will want an exception, and the costs of managing the function will skyrocket; the alternative may not even work, and the functional lead will be held accountable—even though he or she objected up front.

The innovation team can help to reduce these concerns, through a process I call “graduated engagement” (see Figure 5.1). The basis for graduated engagement is the Innovation Stage-Gate. The idea is that the innovation team engages with the function with increasing intensity as the project progresses through the stages of the Innovation Stage-Gate. At the earliest stages, the functions are made aware of what is happening; they can ask questions but cannot impose standards or processes. Everything is too provisional and exploratory for it to matter.

At Incubation, a new phase is triggered. During that stage, which may last for several months or even a year, the innovation team works with the functions to define what it will take to scale the initiative. Standard operating environments are considered at this point—and created if they do not yet exist for a technology. During this phase, any needed product or system is redeveloped in a way that the core function can support and that satisfies core requirements for scalability, security, and maintainability. Issues with liability or accounting or intellectual property are thoroughly addressed.

Two things make this approach work. First, graduated engagement creates a clear point at which critical functions can make sure their concerns are addressed. This engagement happens, however, without slowing the innovation process. Second, the visibility that it provides reduces free-floating anxiety about hypothetical future problems. The early stages also give the innovation team and the functions the chance to identify and begin to address potential issues early. The lack of time pressure lowers the temperature and lets the issues be dealt with more rationally. Graduated engagement is a more sustainable practice than escalation and one that encourages collaboration, not conflict.

Summary: Managing Resistance to Innovation

There is a saying: Where you stand depends on where you sit. In other words, the way you view a particular issue depends on the role you play in the company. This is certainly true for a company’s functional leaders. This insight is at the heart of game theory, which assumes that each party will act according to his or her personal assessment of the payoff matrix. What the payoff matrix looks like depends on where you sit in the company.

To change behavior, you need to shift the payoff matrix for key players in the organizational games that are always going on. How you shift a given individual’s payoff matrix depends on the issue and the game being played. In the Samaritan game, the personal risks associated with helping the innovation team can be reduced with air cover and with dedicated resources to support the innovation effort. Watchdog games, which revolve around the organizational risks functions face in helping the innovation team, can be managed via graduated engagement and risk-sharing.

Suggestions for managing the inherent conflict with corporate functions are covered in a paper that Abhijit Ganguly and I wrote on “Conducting Business Experiments.” An excerpt of that paper is included in this chapter.

Conducting Business Experiments

Abhijit Ganguly and Jim Euchner

Govindarajan and Trimble (2010) discuss the inherent conflicts between any innovation initiative and what they call the company’s “performance engine.” These conflicts arise frequently in the context of business experiments, as experiments can challenge the working practices of existing functions and at times require exceptions to those practices. The specifics of the conflicts will vary by industry and cultural factors, but there are patterns. The most common conflicts concern intellectual property, marketing, risk management, procurement, and sales.

Intellectual Property. A strong intellectual property regime can be a key element of competitive advantage, and business experiments often come with the risk of exposing elements of intellectual property related to the concepts being tested. In many companies, concern about even limited exposure of an idea before patent applications are filed drives strict policies regarding disclosure. Goodyear protects intellectual property in business experiments but takes a different approach than that of the core business. Customers participating in experiments are informed that the information they will see is confidential and are asked to agree to keep it confidential. In some cases, that agreement is a simple, one-page form; in others, it is a verbal communication. In a few cases, when the concept seemed likely to result in a patentable invention, we have filed provisional patents before sharing it. We have not had any intellectual property issues arising from business experiments.

Marketing. Companies spend significant resources and time developing their brands. On occasion, concerns may arise that an experiment could damage the brand image with a particular customer set or some other stakeholder. Often, this concern can be avoided by not using the brand or logo in the experiment. When the brand is central to the experiment—when we believe that the success of the endeavor depends on its being offered by Goodyear—we work closely with the marketing function in designing the experiment. If the experiment is conducted in a local test market for a limited period of time, and if the marketing function has the chance to review the materials ahead of the experiment, it is often (but not always) possible to move forward with the experiment.

Risk Management. There is the potential in any experiment for something to go wrong, whether through a failure of the technology or a failure of the concept. It is possible that the failure might result in consequential damages. The need to manage liability can therefore be an impediment to conducting certain experiments. However, at times there is no way to learn about a new concept without conducting a real-world experiment, with all of its attendant risks. When we do such an experiment, we seek to identify the risks before the experiment begins, mitigate them as much as possible, note any concerns that can’t be fully mitigated, and document how they will be handled if they arise. We engage in practices analogous to those we use when conducting trials of new products in the core business. Careful experimental design, together with open discussion of possible risks with participating customers, is critical.

Procurement. We often conduct experiments with technology developed by partners. These experiments are generally designed to provide an opportunity to learn about the technology’s potential to support a new business. These experiments come with a risk that the collaboration could compromise future negotiations with that partner in some way. At Goodyear, we have mitigated the risk of ill feeling or compromised negotiating position by creating different types of agreements for different stages of business building. At the early stages, we may experiment with an off-the-shelf offering. If the partner is a startup or a small enterprise, we may enter into a joint development arrangement to pilot the technology, with intellectual property terms defined but business terms to be determined. In other instances, business negotiations may be deferred until we are clear about the business potential and can negotiate with clear intent. This flexibility works to the benefit of both parties; without it, the experiments can be significantly delayed.

Sales. Because business model innovation is aimed at creating growth in areas adjacent to the core business, we often work with customers of the company’s performance engine. This can create issues with the sales organization for two reasons. First, anything that is not a sale of a core product can be a distraction to the sales force, which already must meet challenging targets. Second, the sales organization may not agree with the concept being tested and may not want to expose it to customers. Sales organizations also have a natural concern that the innovation function may appear to promise something that may never be brought to market, and by doing so, may disappoint the customer. When approaching customers, we work with the sales organizations; we spend time discussing the concept and the experiment design with sales management. Often, we get useful feedback on the concepts. We also get good insight into which customers might be the right first targets. Done well, these discussions result in better experiments. Early in the business model innovation process, sales personnel will often accompany the innovation team in meetings with customers; over time, as trust builds, access to customers typically becomes more open.

Business experiments present clear risks in each of these areas, but there are also risks in not conducting experiments. Principal among these is that you will build the wrong product or service, partner with the wrong partner, or go to market with the wrong business model. Furthermore, the learning from these experiments, and from customers in particular, is very powerful in building internal support for the business you are building. Conducting experiments—even “quick” experiments—can take time, but they can help the organization to understand the opportunity and ultimately lead to a stronger offering.

Key Insights

  • Business experiments are an essential way of reducing the risks of a new business and are at the heart of the Lean Startup
  • Conducting business experiments in the context of the performance engine can be challenging, especially when they require putting products (or MVPs) into the hands of users
  • Game theory can be used to design approaches that increase internal collaboration and permit the experiments to proceed
  • The most important practices for working with the performance engine are Air Cover, Risk-Sharing, and Graduated Engagement.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset