More on Skunk Works

Following up on yesterday's post, and pointed to some stuff by Steve C: some radically different skunk works innovation stories, with huge business success.

Firstly, the actual original Skunk Works at Lockheed, and a list of their principles for successful operation. A few of the more interesting ones, applicable to software:

The contractor must be delegated the authority to test their final product in flight. They can and must test it in the initial stages. If they don't, they rapidly lose their competency to design other vehicles.

There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

A very simple drawing and drawing release system with great flexibility for making changes must be provided.

The principles point to small, flexible, efficient, with well-understood budget and cost accounting procedures; and in sharp contrast to most other skunk works projects in software, blessed by directorial or higher level executive support who gives them autonomy.

Finally, I like this nice quote at the bottom of the principles list: "Reducing the time to evaluation of a system almost always leads to lower costs, greater flexibility for change, improved overall performance, and less risk."

For a sharp contrast, there's this classic and fun read on the creation of the Graphing Calculator at Apple by two unemployed guys who snuck into the building to work on it anyway. It reads like fiction, but you know it isn't. I admire them for their attitude towards teamwork and quality, if not corporate legality.

Next, we needed help writing software to draw the three-dimensional images that our software produced. A friend with expertise in this area took a weekend off from his startup company to write all of this software. He did in two days what would have taken me a month. My skunkworks project was beginning to look real with help from these professionals as well as others in graphic design, documentation, programming, mathematics, and user interface. The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.

They have a nice page of lessons learned from designing for the PowerPC, and it has a nice list of UCD items in it, as well as some smart observations on how to do screen-drawing behavioral things that are important to users rather than just clever or fast because they can be.

The goal is to maximize use of whatever processing power is available in the design of the user interface...

1. Tackle expensive computations when they can improve the interface.
2. Eliminate dialogs and command lines in favor of direct manipulation.
3. Drop old assumptions and idioms. Use the processing power to explore new interfaces.
4. Provide a starting point for exploration.
5. Avoid programming cleverness. Instead, assume a good compiler and write readable code.
6. Invest development time in user-centered design.
7. Learn the new rules for performance.
8. Design tiered functionality: take advantage of whatever hardware you're running on.
9. Test on real users.

I suppose one of the things I like about their story, apart from the lesson that "it takes a team of different skills to make something really good," is that they did a good root cause analysis of their success. You can't replicate what you don't understand. Although their motives in doing this while unemployed were admittedly murky to the end of the story. This kind of thing wouldn't have flown at Lockheed.

Finally, here's a link to an article on What Drives Innnovation (pdf) with some case studies and lessons learned. Their heuristic process to decide if an innovative idea is worthwhile for the business or executable inside a business culture is simple, but it's hard for me to figure out what to take from it... Despite the "possibly" and "no" frequency in some of the case studies, the idea was still successful. So, hmm. But worth a read.