Skunk Works' 14 Rules and How to Use Them

The Skunk Works

It conjures ideas of government secrets, brilliant engineers, and incredible projects. From the U-2 to the F-117 Nighthawk to the SR-71 Blackbird, Lockheed Martin's Skunk Works division has turned out some of the most incredible, most iconic, and most secretive airplanes in the world. And, like many great things, the Skunk Works was born from a moment of panic and necessity.

In the spring of 1943 (and the height of WWII on the eastern front), Allied intelligence was shocked to learn of the German Me 262; the first jet powered fighter in the world. The Allies were incredibly and hilariously behind the curve. Shortly following the news, the Air Force went to Lockheed with a preposterous proposition: design and deliver a jet fighter in no more than 180 days.

The young Kelly Johnson, a brilliant engineer, led a team of only 28 people into the top secret project. The design for the fighter was submitted on the 26th of June, only 30 days into the project, and the first prototype was delivered to Muroc Army Airfield on the 16th of November, just 143 days later. By some miracle, Johnson and his team had delivered their airplane 7 days ahead of schedule.

The prototype would eventually become the P-80 Shooting Star, and saw combat at the end of WWII and during the Korean War.

Johnson would go on to lead the quickly growing Skunk Works division in the same manner as he had with the P-80, developing airplanes quickly, effectively, and with nothing more to go off than an idea and a handshake.

During his time there he developed 14 Rules and Practices that made Skunk Works successful. Here, I'll explain these 14 rules and provide context on how we can use them today on our own teams.

Rule #1

The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.

The manager is to act as a shield around the team, guarding the team from outside forces, bureaucracy, red tape, and shifts in focus. He or she should report to the highest person possible to keep the chain of command short and concise. This allows the team to focus and allows for rapid pivoting.

Rule #2

Strong but small project offices must be provided both by the military and industry.

Working in the same space allows for disagreements to flourish, arguments to proceed uncorrected, and teams to grow together. While arguments and disagreements may seem, at first, a negative experience for a team to go through, make no mistake; the strongest bonds are forged in the hottest fires. Working in a confined space with other people make these conversations natural and allows your team to build mutual trust. This trust is vital for the success of any team, and necessary for a team to move quickly. We'll talk more about trust later.

Rule #3

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).

No one feels responsible or impactful on a team of 1000 people. To move quickly, each person on the team needs to feel ownership. Ownership breeds passion and responsibility that can crank performance up to 10. This is also one of the reasons that side projects are so important. A smaller team will naturally hold more responsibility and feel a greater impact on the work they do.

Rule #4

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

"Move fast and break things" is one of my mottos. Not that breaking things is good, but breaking things highlights weaknesses in our processes. Once a weakness is identified, it can be strengthened, resulting in a very strong and resilient process over time.

In this same vein, this rule tells us to make changes fast and often, and adopt tools that support that. The tools we use should help us more than they hurt us, and if we want to move quickly, our tools need to be flexible enough to support that. If you have tools or processes that are cumbersome, get rid of them in favor of smaller, lighter weight tools. Changing your processes becomes much easier with a smaller team (see Rule #3).

Rule #5

There must be a minimum number of reports required, but important work must be recorded thoroughly.

Keep reporting and analytics to a minimum. It takes time away from people being creative and often offers little value. A small, close knit team that trusts each other can replace reporting in most cases. BUT, keep a detailed log of changes, decisions, and thought processes.

One of my favorite policies in a team is the "Hit-By-A-Bus" policy. This policy says that the team or business needs to be able to continue even if an important person gets hit by a bus. What this means for our reporting and logging is that important domain knowledge needs to be well documented instead of living in one persons head. This policy not only protects us from untimely bus collisions, but also means that important knowledge is freely available to other members of the team.

Rule #6

There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.

Keep on top of your budget. When we move quickly, logistical analysis tends to fall to the wayside. Keep on top of this by having a monthly review of the budget, including projected costs. This is important for the team, the company, and the client to know ASAP.

Rule #7

The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.

Trust your vendor, or find another one if you can't. The reason we hire vendors and subcontractors is to offload part of the work that someone else can do better. Too often though, we try to micromanage a vendor to ensure QoS. The time spent doing this can add up quickly, sometimes to the point where it would have been better to bring that service in-house to begin with. While QoS and other metrics are important to track, establishing a good relationship of mutual trust with a vendor is far more important. That relationship can help make both teams better by building off of each other. Always remember that a vendor is an extension of your team, and should be treated with the same level of respect, trust, and inclusion that a normal team member would be.

Rule #8

The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.

Trust your team to inspect their own work, and don't waste time reinspecting things that have already been inspected. This is yet another reason why trust is so important. A team you can trust represents a body of work that you can trust.

This is not to say though, that there is no room for inspection or review. In fact this means exactly the opposite. A team that trusts one another has the ability to inspect each others work and approve or reject that work without consequence. The most important part of this rule is to avoid over-inspection. Over-inspection wastes time and is unnecessary in a team that trusts each other. Work should no longer need to be reviewed by three or four people up the chain of command if one engineer at the bottom gives his or her approval.

Rule #9

The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.

Bring your vendor into the fold. A good working relationship with your vendor is important in that it builds trust, allows for mutual creativity, and speeds the development process by effectively offloading work.

For your team, allow the people who developed a product, process, or feature to test it in the greater machine. Those are the people who understand the process best, so why not let them test it? Let the guy who designed the chair sit in the cockpit.

Rule #10

The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.

Establish contracts early and stick to them. This allows teams to work independently of each other which means less inter-team communication which means faster, more agile projects. If a contract does not follow an industry standard, establish and document this early and require hard justifications for that decision.

Sometimes contract changes are necessary. Part of the joy of working fast is that not all the variables will be visible at the beginning of the project. If information arises that requires a change to the contract, it's important to bring everyone together to discuss that change. Make sure no parties are left out. The contract represents a manifestation of trust and it's vital that that trust is kept intact.

Rule #11

Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.

Establish funds quickly and precisely. If you want a product completed quickly and with quality, you'll need to pay up. Be prepared to do that without hesitation. Skunk Work teams are expensive.

Rule #12

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

Trust your teams, vendors, and subordinates to do the right thing and make the right decisions. In addition, your teams, vendors, and subordinates must trust you. Mutual trust across the board keeps communications lean, and frees people to be creative and move quickly.

Like I've said above, this trust helps to establish a close working relationship. That working relationship will reduce misunderstandings and reduce the amount of fixes that need to be applied at the end of the project.

Rule #13

Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

Your team's time and space is extremely valuable. Protect it from forces outside the team at all costs. Do not allow other teams or departments to demand or control the time and space of your team. When outside forces act on your team, they draw focus away from the task at hand.

In many team sports there is the idea of "doing your job." This means that if everyone on the team does their job, then the goal of the overall team will succeed. For example, if every person on a football team's offensive line holds their block, the quarterback will be free to wait for an open receiver, and complete a pass. The linemen don't need to think about the mechanics of the pass, or who's open, or where the defenders are; that's the job of the quarterback. Likewise, the quarterback doesn't need to think about who's blocking who. He or she trusts their teammates to do their job. That is, until someone misses a block and the quarterback's attention is suddenly drawn to the defender barreling down on them.

The same if true for your team. It is the manager's job to protect the team from outside distractions. By keeping your team's time and space controlled and secure, the team can focus on the task at hand.

Rule #14

Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

Reward your workers well and diligently with adequate compensation. Compensation should be based on the success of a project or completion of a milestone, not on the number of reports, time spent behind a desk, or tenure.

Conclusion

Lockheed's Skunk Works has been churning out projects at an astonishing rate for over 75 years, and the principles outlined by Kelly Johnson are in practice there to this day.

If you learned only one thing from this synopsis, I hope it's the importance of trusting your team. A team that you trust, and who trusts you, is one of the most important driving factors in a fast-paced, agile project. I would even say that a project cannot be agile without trust.

In Simon Sinek's book The Infinite Game, the author discusses a principle of trust used by the US Navy SEALs: trust is more important than performance. The SEALs represent one of the highest functioning teams in the world. They are experts at their craft and relentless in their improvement, yet trust in one another is more important to them than any one individual's skills or abilities.

Such is the same with Skunk Works, and such should be the same with your team.

Happy Building!