Did you know that Skunk Works has a set of rules laid down by its founder? If you aren’t familiar with Skunk Works, it’s a division of Lockheed Martin focusing on rapid completion of impossible projects, moonshots. The founder, Kelly Johnson, has recorded the axioms. Here’s what you can learn from them.
Rule 1 – Autonomy
“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.”
Your engineering team should be totally autonomous. The CTO needs almost complete control of the program in order to do the best work and make the best decisions.
Oftentimes, other departments will try to influence how and when engineers spend time on a product. Collaboration and receiving stakeholder input is necessary, but it should not be imposed. This especially applies when performing research work.
Rule 2 – Dual sided
“Strong but small project offices must be provided both by the military and industry.”
The company cannot do it alone, but instead they must be supported by the government. When it comes to startup life, there are many grants and experts that can be of use.
This also conveys the idea that you should hire the best people possible but keep the team small. A tight-knit group of experts can do more than a sprawling team of B-players.
Rule 3 – Size
“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 point takes the idea about team size and makes it very, very clear. The total team size should be 10% to 25% of what you would normally have. This allows the team to focus on proving the most important hypotheses during the research phase.
Lines of communication grow quadratically as the team grows.
Rule 4 – Release
“A very simple drawing and drawing release system with great flexibility for making changes must be provided.”
Your software team needs to be able to ship to production with the push of a button. Do you have a continuous integration and continuous deployment pipeline (CI/CD)? Is it fitted with automation that builds and deploys a new version of the product in under 10 minutes? Are automated tests included that keep quality high?
If the team cannot deliver changes quickly, then everything slows down.
Rule 5 – Documentation
“There must be a minimum number of reports required, but important work must be recorded thoroughly.”
Regular updates should occur but the critical path should be well documented. Are your engineers documenting as they go? Through our audits we find serious risk with many startups due to bus factor.
This is the case when information is consolidated in the mind of one or two key personnel. What happens if that person was to permanently leave your startup tomorrow?
By creating a culture of information sharing and evolving to be a knowledge-first organization, you can mitigate these risks. Additionally, when it comes time to scale, new employees can onboard themselves. This prevents wasted time when your most productive experts are teaching basic concepts that should have been written down.
The product that VCs are investing in is really your team. That needs to scale too and documentation is how it happens.
Rule 6 – Budget
“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.”
Startup life is all about trade-offs. What’s the time cost of implementing specific functionality and can it be done manually at the start to save engineering effort? Time is money.
How much runway do you have? Have you shared this with others in the organization? Are they aware of the ticking clock?
Not everyone in the company needs to understand the complete details of the budget, but it is important that they think about costs. I’ve seen cases where a complex database system has been used which solves the engineering problems well. However, the production costs of running the system weren’t accounted for, leading to a shortened time to prove out the business.
Rule 7 – Focus
“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 engineering team you work with must have full authority to manage the build versus buy decision. Anything that won’t be built by your team needs to be thoroughly vetted. Two mistakes are often made here: build everything and accept anything.
Some teams decide to rebuild functionality that exists in well priced and well created tools. That makes sense if it’s focused around your core domain, but oftentimes the scope is too wide.
Need a billing system? Pay for that. Need authentication? Pay for that. These are complex problems with many edge cases. Your job is to be the glue that fits the existing puzzle pieces together.
The other problem is related to smartly outsourcing things that aren’t the core domain. But teams run into problems when they aren’t evaluating the quality of the sub-contractors’ work.
Modern software development is like building custom furniture; it’s creative knowledge work. Artisans know the tools of their trade and won’t sacrifice quality to achieve their vision. The same is true of good software development.
Is the outsourced work covered in automated tests? Many software agencies offer reduced costs by cutting essential quality such as this. Keep an eye on that.
Rule 8 – Quality
“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.”
If the standards are in place, your technical team can easily evaluate the results. Code review (or better yet, pair programming!) and automated tests will ensure quality is high, but there is no need to then go and manually test everything yourself.
Testing core functionality by hand is important for the most critical paths of your application, but automated tools such as Cypress and Mabl do this for you. Don’t repeat the work.
Testing should also occur as early as possible. This is known as shifting left.
Rule 9 – Iteration
“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.”
Not only must the technical team have authority to do final product tests, they must also test in the initial stages. This rule is all about the build-measure-learn loop presented by Eric Ries in his novel, The Lean Startup.
Test early and often to build the best product. At madewithlove, we start day 1 with the production CI/CD pipeline. We ship to production every day to allow testing to begin immediately.
And when it comes to unclear requirements, the key is to build prototypal systems that are then thrown away and rebuilt from scratch. By following Double Diamond Design, engineers have a full context of the problem and can begin ideating on solutions before the final versions are started.
Rule 10 – Specs
“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.”
Hardware development is a bit different than software but the point still applies. You should know what outcome you are trying to achieve before you begin building.
Where is the discovery research documented? Which hypotheses are you attempting to prove or disprove by building software? What assumptions have you made? What is the measure of success?
By clearly documenting this at a project and Jobs-to-be-done level, your team will understand the goals and therefore only build necessary functionality. This will help you meet your budget requirements too.
Rule 11 – Funding
“Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.”
Pay your engineering team on time and without hesitation. Engineering tools can be expensive but providing your team with the very best hardware and tooling, their efficiency will reach new heights. I constantly see teams using inferior tooling because the costs are too high.
Well guess what… while you saved a couple bucks up front, your engineers have been slowed down. People costs are very high so would you rather your engineers be wasting their time fighting build scripts or working on delivering the next killer feature?
Rule 12 – Collaboration
“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.”
You should not hire anyone you don’t trust and once you do give them your trust. The number one trait of high performance teams is psychological safety. This is the shared vulnerability that exists because of implicit trust between team members. That trust allows them to experiment and fail. Without experimentation, the project will stagnate.
The next step is then to collaborate, every single day. Breakdown silos within the team and ensure that product, marketing, sales, and engineers are working closely together. A key way to determine if you have silos is to look at your documentation.
Do you have a sales section and a support section that are separated? Why? Both of these teams are focused on taking a finished product and putting it in the hands of users, ensuring that the customer’s needs are met.
Are your engineers working on individual issues or do they pair program to deliver results more quickly? Four eyes are better than two and your team will save time in the long run with this type of collaborative effort. Limiting work-in-progress is essential to building the best product in an efficient way.
Rule 13 – Security
“Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.”
Don’t forget security. Start day 1 with a password manager such as 1password. Don’t store secrets in your GitHub repository but instead inject them into your containers. These good habits will mitigate your risks and help you scale your team.
Rule 14 – Compensation
“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.”
As we’ve seen in the Great Resignation, the market for knowledge workers is incredibly competitive. Workers are tired of wage stagnation (among other issues) and yet they are the ones building value into your business.
Ideas are worth nothing; it’s all about execution. So pay the people who are putting in the work. If you treat them well, they’ll stay with you for a long time.
Do you measure up?
Engineering competency is just one of the five pillars we examine when performing due diligence and technical audits. Does your team live by these rules or will your startup go out of business before it can raise funds? If you aren’t sure, reach out and we’re happy to determine exactly where you can still improve.
Member discussion