Corporate innovation teams, here’s how to ‘get to yes’ with the rest of the company

I’ve been working with Roberto, the Chief Innovation Officer of a diversified company I’ll call Sprocket Industries.

I hadn’t heard from Roberto in a while, and when we caught up, it was clear his initial optimism had faded. I listened as Roberto listed the obstacles to the new innovation program at Sprocket: “We’ve created innovation teams in both the business units and in corporate. Our CEO is behind the program. The division general managers have given us their support. But the teams still run into what feel like immovable obstacles in every part of the company. Finance, HR, Branding, Legal, you name it, everyone in a division or corporate staff has an excuse for why we can’t do something, and everyone has the power to say no and no urgency to make a change.”

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1681186,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,enterprise,","session":"D"}']

Roberto was frustrated. “How do we get all these organizations to help us move forward with innovation? My CEO wants to fix this and is ready to bring in a big consulting firm to redo all our business processes.”

Uh oh …

—–

As Sprocket’s Chief Innovation Officer, Roberto was a C-level executive responsible for the corporate innovation strategy in a multi-billon dollar company. Over the last nine months, his staff got innovation teams operating with speed and urgency. The innovation pipeline had been rationalized. His groups whole-heartedly adopted and adapted Lean. His organization ran a corporate incubator for disruptive (Horizon 3) experiments and provided innovation support for the divisions for process and business model innovations (Horizon 1 and 2). He had an innovation pipeline of hundreds of employees going through weekend hackathons and 45 different innovation teams going through three-month rapid Lean LaunchPad programs to validate product/market fit.

The next day, Roberto and I sat together and listed what we knew about the innovation conundrum at Sprocket:

1. Sprocket is a permanent organization designed to execute a repeatable and scalable business model.
2. Roberto’s innovation teams are temporary organizations designed to search for a repeatable and scalable business model.
3. Sprocket had world-class resources and capabilities in brand, supply chain, distribution, sales force, financial metrics, all tailored to execute the existing business model, not to help search for a new one.
4. The resources and capabilities optimized for execution interfere with the processes needed to search for a new business model.
5. Sprocket needed new and different processes for innovation while retaining the ones that work well for execution.
6. Sprocket wanted to use the same organizations that provided support for execution (brand, supply chain, distribution, sales force, financial metrics) to provide support for innovation.

Roberto’s group had spent the last nine months educating the company about why they needed to deliver continuous innovation and why the execution and innovation teams need to work collaboratively. But while there was lots of theory, posters, memos, and lip-service to being innovative, it wasn’t working.

So what to do?

I offered that a top-down revamp of every business process should be a last resort. I suggested that Roberto consider trying a six-month experimental “Get to Yes” program. His teams, not outside consultants, would write their own innovation processes and procedures.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1681186,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,enterprise,","session":"D"}']

Recognizing the Roadblocks

Most of the impediments the innovation teams faced were pretty tactical — for example, an HR policy that said the innovative groups could only recruit employees by seniority. Or a branding group that refused to allow any form of the Sprocket name to appear on a minimal viable product or web site. Or legal, which said minimal viable products opened the company to lawsuits. Or sales, which shut out innovation groups from doing customer discovery with any existing, or even potential, customer. Or finance, which insisted on measuring the success of new ventures on their first year’s revenue and gross margin.

We agreed that the goal was not to change any of the existing execution processes, procedures, incentives, or metrics but rather to write new ones for innovation projects.

And these innovation policies would grow one at a time as needed from the bottom of the organization, not top down by some executive mandate.

If we were successful, innovation and execution policies, processes, procedures, incentives, and metrics would then coexist side-by-side. In their day-to-day activities, the support organizations would simply ask, “Are we supporting an execution process (hopefully 90% of the time), or are we supporting an innovation process?” and apply the appropriate policy.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":1681186,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,enterprise,","session":"D"}']

Get to Yes

The “Get to Yes” program was pretty simple. Every time an innovation team needed a new policy, procedure, etc. from an existing organization (legal, finance, sales, HR, branding, etc.), they submitted a standard Sprocket corporate “Get to Yes” request form. The form was a single page. It asked what policy the innovation group wanted changed, why it wanted it changed, how it wanted the new policy to read, the impact the new policy would have on other policies and organizations, and — most importantly — what the risks were to the core existing business.

The “Get to Yes” request form looked like this:

The appropriate department had one week to ask questions, gather information, meet with the innovation team, and evaluate the costs and risks of the proposed process. They could either:

[aditude-amp id="medium3" targeting='{"env":"staging","page_type":"article","post_id":1681186,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,enterprise,","session":"D"}']

1. approve and adopt
2. suggest modifications that the team agreed with
3. deny the request.

The approval form looked like this:

Although it was just a one-page form, the entire concept was radical:

• The innovation team would be proposing the new process, procedure, metric, etc. – not waiting for one to be written.
• There was a hard one-week deadline for the execution team to respond.
• Yes was the default answer, a No required detailed explanation.
• Appeals went straight to the Chief Innovation Officer.

The big idea is that Sprocket was going to create innovation by design not by exception, and they were going to do it by co-opting the existing execution machinery.

[aditude-amp id="medium4" targeting='{"env":"staging","page_type":"article","post_id":1681186,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,enterprise,","session":"D"}']

The key to making this work was that if the request was denied, it automatically was kicked upstairs to the Chief Innovation Officer – and would be acted on the next week. And it’s there that the execution department had to make its case of why this request should not be approved. (If there was still no agreement, it became an issue for the executive staff.)

The time for a process resolution in a billion dollar corporation – two weeks. At Sprocket innovation was starting to move at the speed of a startup.

Lessons Learned

• Innovation by design, not by exception
• Execution organizations now manage both execution and innovation
• Innovation teams write their own process and procedures
• Innovation policy, process, and procedures get written as needed, one at a time
• Over time, a set of innovation processes are created from the bottom up
• Bias for immediate action not perpetual delay

Steve Blank is a retired serial entrepreneur-turned-educator who has changed how startups are built and how entrepreneurship is taught. He created the Customer Development methodology that launched the lean startup movement, and wrote about the process in his first book, The Four Steps to the Epiphany. His second book, The Startup Owner’s Manual, is a step-by-step guide to building a successful company. Blank teaches the Customer Development methodology in his Lean LaunchPad classes at Stanford University, U.C. Berkeley, Columbia University, UCSF, NYU, the National Science Foundation and the I-Corps @NIH. He writes regularly about entrepreneurship at www.steveblank.com.

[aditude-amp id="medium5" targeting='{"env":"staging","page_type":"article","post_id":1681186,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,enterprise,","session":"D"}']