Skunk Works and the 14 Rules Behind Fast Engineering

In 1943, Kelly Johnson pulled a small team of engineers into a rented circus tent next to a factory that smelled so bad they named the operation after a comic strip moonshine brewery. He'd been given 180 days to build America's first jet fighter. He delivered it in 143.

Kelly went on to lead the design of the U-2 spy plane, the SR-71 Blackbird, and the F-117 Stealth Fighter. The SR-71 still holds the world speed record. The principles behind it haven't aged a day.

What made Skunk Works special wasn't secrecy or funding. It was how Kelly organized the work. He wrote 14 rules. Most engineers have never read them. They should. These rules predate agile by 40 years, and they describe what the best hardware teams still do today.

Here are all 14, and why they still matter.

The rules

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.

One person owns the program. Not a committee. Not a matrix org. One person with real authority and a short reporting line. When decisions require five layers of approval, speed disappears.

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

Both the customer and the builder need tight, empowered teams. Bureaucracy on either side slows the whole thing down. The strongest programs tend to have small teams on both sides working closely, with decisions made near the work instead of passed through layers.

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

This is Kelly's most famous rule, and one of the most ignored. More people doesn't mean faster. It means more coordination overhead, more meetings, and slower decisions. The best teams operate this way: small, senior, and empowered.

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

Your change management system is either an enabler of speed or your biggest bottleneck. If changing a requirement takes three weeks of paperwork, the team will stop changing requirements. And then it will ship the wrong thing.

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

Kelly was not arguing for no documentation. He was arguing for useful documentation. The work that matters should be captured clearly, but reporting should not become the work itself.

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.

Know where your money is going. Not just what you've spent, but what you're going to spend. Cost overruns rarely come from one dramatic mistake. They build gradually when nobody is watching the trajectory.

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.

Cut the procurement bureaucracy. Let the people closest to the problem pick the vendors. Kelly trusted his engineers and program leaders to make sound commercial decisions without dragging every choice through a slow process.

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.

Push quality responsibility to where the work happens. Redundant inspection at every level does not necessarily improve outcomes. More often, it adds time, cost, and distance between the problem and the person who can fix it.

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.

Test early. Don't spend years in analysis before discovering what fails in the real world. Kelly was practicing iterative engineering before the term existed. The fastest teams still learn by getting to test conditions sooner.

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.

This one is underrated. Kelly didn't just list what he would comply with. He explicitly stated what he would not comply with, and why. That prevents the kind of ambiguous scope that quietly kills programs. If a requirement does not fit the mission, say so up front.

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

Pay on time. If you want fast engineering, don't make the program stall on financing. Cash flow problems quickly become schedule problems.

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.

Daily collaboration with shared context beats status theater. When both sides are working from the same information, delays caused by misunderstanding start to disappear.

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

Keep the circle tight. Not just for secrecy, but for focus. Too many outside voices create delay, second-guessing, and noise around the core team.

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.

If you only reward people for managing bigger teams, you incentivize headcount growth. Kelly wanted the opposite. Reward great engineers for being great engineers, not for building empires. The best individual contributors should be paid like leaders, because they are.

Why this matters now

Kelly wrote these rules 80 years ago. Every one of them maps to something we see the fastest hardware teams doing today.

Small, empowered teams. Fast change loops. Early testing. Clear ownership. Close customer collaboration. Less process, more accountability.

The fastest teams today, whether they are building rockets, eVTOLs, satellites, or nuclear reactors, keep rediscovering the same lesson Kelly codified in a circus tent during World War II: engineering speed is not just a function of talent or tools. It is a function of how the work is organized.

The tools have changed. The physics haven't. And neither, it turns out, have the management principles that let great engineers do great work.