The Most Important Skunk Works Rules For Your Success

Thanks to Lockheed Martin, the word “Skunk Works” has become part of our language, and not only in aviation. It represents a secretive group within a company, often with “special rules.”

At one of my previous companies, I set up a locked lab that only the engineers working on the project (and I) could access. They were not allowed to discuss the project with other employees. One day, one of the other employees stuck a label on the door with only one word: “Skunk Works.” Everyone knew exactly what it meant.

Recently I read the autobiography of the man who started Skunk Works, Clarence “Kelly” Johnson, Kelly: More Than My Share of It All. Then I visited Lockheed Martin’s Skunk Works website, and found out what made Skunk Works so wildly successful, and better yet–what you can learn from it and implement yourself to be as successful. The most amazing part was that those rules were created in the 1960s.

Johnson’s rationale for Skunk Works was simple: “people challenged to perform at their best will do so.” All of his 14 rules boil down to one simple principle: “The Skunk Works is a concentration of a few good people solving problems far in advance–and at a fraction of the cost–of other groups in the aircraft industry by applying the simplest, most straightforward methods possible to develop and produce new projects. All it is really is the application of common sense to some pretty tough problems.”

While many of the 14 rules apply very specifically to the defense industry and the special relationship between defense contractors and military buyers, here is an adapted sub-set of those rules that apply to every industry, that you should use in your own company to be wildly successful:

1. The team leader must be an effective buffer.

The team leader must be delegated full control over the program, and report only to the highest possible authority. He or she must “protect” the team from the organization’s bureaucracy. There should be the minimum possible number of reports that the team should be required to generate, although important lessons should be well documented.

2. The team must be collocated in a small project office.

Co-location assures strong and productive team dynamics. Team members feel more comfortable with each other, and can argue better rather than prioritizing political correctness over creativity, productivity, and results.

3. Ruthlessly minimize the team size.

The smaller the team, the more productive it is. How can a single person contribute much when there are 1,200 people in the team? You can rely on people outside the core team, but make your core team small.

4. Prototype quickly.

Show the customer your prototypes, get feedback, make changes (if needed), and keep going. Sometimes we don’t want to show a prototype that is “quick and dirty,” and wouldn’t let go until it is perfect. However, creating too few prototypes or taking too long in demonstrating them to customers may delay the project rather than expedite it.

5. The team must be trusted by company management and the customer.

Without this trust, there will be continuous counter-productive outside intervention in the project. The team (and its leader) must earn this trust. You cannot mandate it.

6. Restrict access to outsiders.

While in Lockheed’s case the reason was the national security nature of the projects, in your company this will assure less interference and “design-by-committee” delays.

7. Involve people in the big picture.

Involving everyone in the big picture, including finances, quality, manufacturing, and usage of your product, service, process, or business model will allow individual team members to be the most creative. In Skunk Works, that also meant that every single team member got to stand on the flight line to see the prototype take first flight.

Perhaps the most telling part of success of the Skunk Works program (other than the ground-breaking military and civilian aircraft it produced) is something I found in a report created by the Rand Corporation for the US Air Force and Advanced Research Projects Agency in 1971. In that report, they analyzed project management of the Agena-D satellite development program and compared the planned versus actual results. The project was estimated to cost $60 million, but was completed in $32 million. It was going to take 18 months, but was finished in 9. 69 Quality control people were used, instead of the projected 1,200. While 3,900 drawings were expected, only 350 were needed, and instead of taking 30 days to release each of them, they were released in one day.

Wouldn’t you want to achieve such results in your company today?

To close, here are Johnson’s carefully-chosen words of frustration with how projects are typically handled in industry: “There is a tendency today, which I hate to see, toward design by committee–reviews and recommendations, conferences and consultations, by those not directly doing the job. Nothing very stupid will result, but nothing brilliant either.”