If you have even a bit of familiarity with aviation, you’ve probably heard of Clarence “Kelly” Johnson.
If not—Kelly Johnson was the famous engineer who helped Lockheed’s Skunk Works earn its reputation for making aircraft that smash through the boundaries of what is technologically possible. He contributed to well-known aircraft such as:
- The P-38 Lightning, a unique twin-engine fighter that came to shine in the Pacific and North African theaters of World War II, and was the first fighter to reach speeds over 400 miles per hour in level flight. (It’s also my favorite airplane.)
- The U-2 Dragon Lady, a reconnaissance aircraft that flies so close to the edge of space, its pilots are required to wear space suits. Its operational ceiling of 70,000 feet means there is barely a 10-knot margin between its maximum airspeed and stall speed, cheerfully called the “coffin corner.”
- The SR-71 Blackbird, a long-range, high-speed recon aircraft intended to address some of the U-2’s weaknesses by just plain adding more speed. If it detected an inbound missile, the standard response was to accelerate above its cruise speed of Mach 3 and Looney Tunes roadrunner-skedaddle out of range.
Part of Johnson’s legacy has become his 14 Rules of Management. This is a collection of ideas by which he ran Skunk Works. As the name suggests, these are primarily aimed at folks heading entire complex development efforts—program managers, chief engineers, and the like.
But despite the focus on bids, program offices, and other aspects of higher management, I think these rules still hold some excellent takeaways for the rest of us engineers.
Especially these days, many UAV design teams are blessed with a healthy amount of autonomy and the ability to move fast and break a few things, reminiscent of the early Skunk Works. I think it’s worth channeling that spirit and using these rules as guidelines, to help those design teams be as effective and innovative as possible while they can.
The full 14 Rules are outlined at the end of this email. I’m going to highlight four of them: the ones I think are most valuable to practically any engineer.
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).
I wouldn’t say a project’s team should be restricted in a vicious manner. But Johnson still has a point: whenever you can, choose a small number of truly capable, enthusiastic people who know their stuff. A handful of subject matter experts working together can often get more done faster than if everyone in the engineering department were on the project.
This also encourages ownership of the effort and outcomes: having fewer contributors results in each taking more responsibility for their part of the project, and ensuring its quality and completion. Engineers who can take initiative will work to cover any gaps in capability or knowledge, whether that’s asking someone outside the project for advice or learning a skill themselves. A much larger team can contribute to a version of the bystander effect: everyone assumes someone else is handling the work, so progress is slower and likely not as cohesive.
If you need to have a larger team, make sure there is a clear “owner” of the work. Aero tasking can be assigned to three different engineers, but ensure one of those engineers is actually responsible for all the tasking getting done.
Rule 4
A very simple drawing and drawing release system with great flexibility for making changes must be provided.
If you want to move fast and have hardware being fabricated ASAP, you need to have the infrastructure to make it happen. Configuration and version management is important, but it needs to be implemented at a level that best supports the actual project.
If you’re making prototypes or a few first articles, you probably don’t need eight different approvals from all levels of management. It might take a week just to track everyone down to approve a change to one part. Imagine how much more progress could have been completed in that week.
In our modern age, I think this should apply to all our other digital work, too. Version control of code, scripts, and digital models is valuable, especially when working with multiple people or between disciplines. It helps avoid questioning which versions are the most recent, and having to rely on the “date modified” property of each file to reconstruct a timeline.
On past efforts I’ve used Bitbucket very effectively, controlling one repository of all the aero database files and giving other disciplines read-only access to use them. Git is another excellent option for implementing better version control than just adding dates to the end of folder names.
Rule 5
There must be a minimum number of reports required, but important work must be recorded thoroughly.
Call me impatient, but I strongly agree with this. Enable your engineers to spend most of their time actually doing the work, not making expansive slide decks to update upper management about said work. For the reports that truly are required, ensure their completion doesn’t block any of the critical-path project work—if needed, reassign tasking among the team to keep things rolling.
But also be sure engineers are documenting the important work, not just for any later reporting, but also to help untangle the reasoning behind a certain design decision. I’ve written before about how helpful it is to keep track of all the contributors to a certain design choice, even if they’re as simple as “this was the only COTS part available without a 20-week lead time.”
Try to include as much context in this documentation as possible, as if briefing a new team member; you never know if the solution to a problem a year from now might be sparked by this project’s reports.
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.
A simpler version: identify which specifications you will aim to hit thresholds on, know which ones are not feasible at this point, and communicate clearly what you are and are not focusing on.
This is important for both your working relationship and the engineering scope. In some programs (more often in defense) the customer will give you plenty of leeway to determine which requirements you’ll pursue, or even to rewrite the requirements to require “characterization” or “evaluation” instead of prescribing a certain performance number.
Especially for quick-turn projects that are meant to be exploring the feasibility of a given design, this isn’t “lowering the bar”—you’re acknowledging the reality of the project’s investigative nature, and giving yourself room to innovate without being penalized (or worse, failing to fulfill the contract) for not hitting an arbitrary number.
Being clear on your achievable versus out-of-scope requirements is also vital for the engineering side. It helps your team understand which requirements they actually need to focus on hitting and therefore flows into the initial design decisions and trade-offs. If hitting a certain endurance is the true “driving” requirement of the entire project, then the engineers know they can be flexible with cruise speed in order to make that endurance possible.
This also helps with the inevitable second-guessing later in a project. Once you determine up front which requirements you are designing for, if a team member later says “we can’t achieve XYZ!” you can point to your initial priorities and say you’ve already accepted that requirement not being in scope. I’m certainly guilty of this, so finding notes or being reminded of our customer’s awareness addresses that concern and returns focus to the work at hand.
I’m a firm proponent of assembling a good team, providing them with direction and clearing roadblocks, and then getting out of their way. I’m sure you’ll disagree with some of what I’ve said, based on your own experiences and beliefs. But hopefully I—and Kelly Johnson—have given you a few ideas to chew on, and that in one way or another they help you make your teams more effective and your programs even more successful.
As promised, here are all 14 Rules of Management:
- 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.
- Strong but small project offices must be provided both by the military and industry.
- 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.
- There must be a minimum number of reports required, but important work must be recorded thoroughly.
- 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.
- 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.
- 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.
- 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.
- 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.
- Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
- 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.
- Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
- 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.