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.

Secrets of Great Teams

There are some nice short articles on teamwork in business at CNN's site for Fortune.

The top story, Why Dream Teams Fail, points out some of the failure modes also described in other resources on teamwork, but in somewhat different terms:

• Signing too many all-stars
• Failing to build a culture of trust
• Tolerating competing agendas
• Letting conflicts fester
• Hiding from the real issues

The most interesting notes in there were on the difficulty of finding dream executive teams, because as you climb the ladder, you're supposed to be an all-star. So of course there's less likelihood of collaboration and trust at that level. When there is, it's usually a pair consisting of one famous "outward-facing" figure, and a lesser known, internally focused-on-execution person.

The article on the Motorola RAZR is a little painful; it's another case of skunk works innovative design breaking corporate rules and even breaking human factors rules. The importance of risk-taking and mold-breaking comes up a lot in these kinds of business success tales.

A good sidebar piece looks at optimal size of teams: 4.6 people. Another one looks at the network of communication in an organization and how it differs from the org chart. You know I love anything that looks beyond the tree and makes networks:

Excel Tricks

Gotten off Information Aesthetics, and making my weekend a thing of beauty (well, also the good weather helps): Lightweight data exploration in Excel, from Juice Analytics.

This is so simple it's genius. I feel like a dork for never thinking of it. These are some lightweight way to create visuals like sparklines inside your Excel spreadsheet using really simple formulae. (This will be built-in in Office 12, but meanwhile, why wait?)

The bar graphs are built using the Excel REPT function which lets you repeat text a certain number of times. REPT looks like this:

=REPT(text,number_of_times)

For instance, REPT(”X”,10) gives you “XXXXXXXXXX”. REPT can also repeat a phrase; REPT(”Oh my goodness! “,3) gives “Oh my goodness! Oh my goodness! Oh my goodness! ”

For in-cell bar charts, the trick is to repeat a single bar “|”. When formatted in 8 point Arial font, single bars look like bar graphs. Here’s the formula behind the bars:

As the guy notes, when you're doing data exploration, you don't want to struggle to figure out which values created which outliers. Big plots are nice for an overview, but you still have to do work to figure out which items generated which points. ("Data brushing" is the common technique in infovis circles for getting this kind of info, but it's work to implement.) Why not get at what you want right in the spreadsheet itself, so you're looking at the data and the visual right at the same time? He has a good example showing the value of this in action.

The followup responses to his original post got even better. Check out these tricks to do this kind of stuff:

Updated to add: Here's even more fun off Juice! Tufte-style charts in Excel, with a downloadable file to play with.

Graves in the North End, Boston

Joanna Grant, Copps Hill, Boston

Here Lyeth