In Greg's provocative comment, he says, “The idea that contributor initiatives are a drag on an organization speaks more to the insecurity of the management than to its skills.” I've been noodling that comment since I received it. I agree with Greg that some managers are insecure enough to insist that they make all the decisions about the work that the organization should do, who should do it, and when. But that's not where I was going with my general suggestions about not allowing skunkworks projects to continue. Here are two examples of skunkworks projects that hurt the organizations:
In the early '80s, I worked for a machine vision company. As an organization, we were bad at estimating, managing, and finishing projects. We started having a layoff every quarter. One of the people who'd been laid off kept coming back into work to finish his project. This project had one potential customer (it was a specialized application). The developer wrote the code so no one else could understand it. However, he needed changes to the set of libraries for his application to work. He worked for free, but the work to support his project consumed several people over the course of several weeks, starving other projects of necessary people. Our management wasn't talented, but they had decided on a strategy, and this project didn't fit. But this project stole cycles from other projects, preventing them from success. And the potential customer wasn't willing to pay for it.
A few years ago, a very large client reorganized their product offerings. One of their strategies was to stop supporting old products and migrate customers to a newer product that cost less to support and had more features. The manager could not bring himself to stop supporting the customers for the old products, and attempted to support both old and new products — an impossibility given the number of staff. Here, the first-line manager was the one keeping the skunkworks projects going.
Maybe neither of these is a typical skunkworks project. I've certainly worked on skunkworks projects where the technology was new and exciting, and our current management could not see how to exploit it. That's why I believe every technical person needs some slack time now and then, so they can be thinking of ways to exploit the technology they are working on. As much as I respect the talented marketing guys and senior management strategy (when it really is a strategy), there's nothing like letting a technical person play around with prototypes, a whiteboard, and a few good buddies to develop/exploit a new technology/product. That's what happened in the Graphing Calculator story.
But what I mostly see in skunkworks projects is not exploitation of a great idea or new technology. Most of the time, I see people wedded to projects that no longer fit the organization's strategy — old products that should be put to death. And the more people work on them — even for free — the more those old products cost the company. Greg, I agree with you that managers who feel the need to micromanage everything are insecure and don't belong in a healthy organization. But I don't agree with the notion (not that you said it) that all technical-contributor-led projects need to continue. Sometimes technical people are wrong-headed about their product ideas too.
I wish I knew of a recipe to develop a reliable product strategy. I don't think you can create a real product strategy without input from the technical people (in the form of prototypes, or even partially finished products), nor can you create it without understanding what your known buyers want (product marketing input). The technical people may well create something that breaks you out of your current market — or breaks open your current market to something much bigger. But that comes with hard work on all sides: management for taking the time to think about a strategy and eliminating the dead products; marketing for looking for the needs that exist and the needs no one knows about yet; and the technical people who know how to exploit the technology looking for something new and different. Ignore one of these, and you've eliminated at least 1/3 of the potentially great ideas.
A little slack time for technical people goes a long way towards developing a product strategy — and reducing management insecurity.