At our CIO 100 event in San Diego this week, I’ve been hearing a lot about how to build and manage innovative teams. This morning, Gentry Lee, chief engineer for planetary flight systems with the Jet Propulsion laboratory, gave a compelling talk about how to balance risk and innovation when developing new technology.
I’ll get to how this relates to project teams in a minute. First, you need to know about Lee. He oversees the engineering for such projects as the Mars rover mission, as well as the Deep Impact and Stardust missions that collected data from a passing comet. In the space business, missing a launch date costs researchers years, and technology that doesn’t work can torpedo an entire mission (not to mention send hundreds of millions of dollars down the drain). The teams that build the hardware and write the software for interplanetary missions need room to run, because they’re inventing new technologies. But they also need to mitigate the risks than inevitably arise.
It shouldn’t surprise you to learn that the structure of the project teams that build these systems is essential to achieving the balance between risk and innovation.
Among Lee’s tenets of team building for innovation is something you probably already do. You have to find the smartest people you can to assign to an innovation project and choose an experienced technical leader who can guide and inspire the group.
But what you might not do is pair that technical leader with a manager whose job it is to worry about the risks, the costs and the budget.
The reason? “People involved in the project cannot simultaneously throw everything they have into the development of the project and think about the risks. You have to have someone in a position to raise issues.”
In other words, the creative talent needs to be protected from bureaucratic pressures, so they can concentrate on the technical challenges in front of them. Nothing kills the imagination like having to count beans at the end of the day. But a project can’t succeed if no one keeps an eye out for how much money is being spent, what it’s getting you, and whether what you’re doing actually works.
According to Lee, a close relationship between the technical leader and the project manager allows risks to be addressed and managed. The technical leader, because she is trusted by the team, can deliver the demands from management (including bad news) and mobilize the team to solve problems in a way a “bureaucrat”—who doesn’t have credibility as an expert—can’t.
Some companies reject this approach, Lee says, because they don’t like the “friction” between the technical leader and the project manager. But friction is essential, because it helps create a better product. A product that is created absent constraints (whether a limited budget, or performance requirements) simply won’t be very good, because the team hasn’t been forced to work through the potential bugs..
Lee’s talk echoed a theme that came up more than once in different conversations about innovation during the past couple of days. On Monday, Stephanie Wernet, CIO and VP of IT at Goodyear, observed that rule-bound IT departments can put the kibosh on experimentation by insisting developers adhere to corporate standards. So she’s willing to let her R&D team use the tools they think they need. But as the manager, she wants to know about the “shadow IT” that’s lurking within her department and the opportunities and risks it presents.
Goodyear’s CIO 100 award winning project, which uses virtual supercomputers to design tires, was 10 years in development. During this time, the project did not operate in the shadows—the company had a way to measure progress and determine it was worth continuing. Goodyear had a technical leader who stuck with the project from start to finish—and who believed passionately in the idea—as well as a management champion who protected it.
Mike Jones, the CIO with Circuit City, addressed the question of building innovation teams during his talk on Monday. His company culled innovators from the corporate ranks in a process akin to a football draft – all the “players” went into a common pool, and the top talent was “drafted” to innovation teams. The members of these teams still had to do their day jobs, and give an additional 50 percent of their time and energy to new projects. But their work on innovation was separate from their “regular” work.
The CIOs at the conference that I talked to about these ideas agree there’s wisdom in them. How they’re implemented will probably look different in different organizations. For instance, one CIO tells me he plans to establish short-term innovation teams. He’ll dedicate a group to a project for, say six months. Then a new group will go on innovation detail.
How do you organize and manage your innovation teams?