“We are defined not by the technologies we create but the process in which we create them” – Clarence (Kelly) Johnson, creator of the Lockheed Martin Skunk Works
Many readers will have heard of the famous Lockheed Martin “Skunk Works”. It is an officially sanctioned pseudonym for Lockheed Martin’s advanced development facility, responsible for many innovative developments including the U-2 and SR-71 Blackbird reconnaissance aircraft. The “Skunk Works” was deliberately given autonomy within the corporation to ensure that it could develop and sell new projects without succumbing to the bureaucracy that would slow down the rest of the organization. Andrea Fosfuri and Thomas Rønde (2008) describe how other large technology companies including IBM, Siemens and Intel have created similar groups. Research has shown that the “Skunk Works” model can be effective in cases where internal conflicts would otherwise drive a Research and Development (R&D) group towards an incremental approach, instead of a more radical, recombinant approach.
It might surprise you to read that I don’t prefer the “Skunk Works” approach as a way to drive innovation. If your company is so large, and barriers so high, or the idea so radical that you need an autonomous R&D group, then a “Skunk Works” may, just may, be your best bet, but it brings its own challenges. The problem with the approach is that innovation cannot just be a “bolt-on”. Innovation must be embedded in strategy and therefore the innovation process must be owned by the whole of the enterprise or business. It’s not just the domain of one department – be that R&D, marketing or whoever. If you spin R&D off into a new organisation, you have to make that new organisation be operationally autonomous and responsible for its own manufacturing, supply, sales, marketing – everything operational. It is vitally important for an organisation to be connected to its environment to innovate successfully so no function can be hidden away. Effectively you have to create a brand new company, even if it might share “back office” functions with the parent. It’s better if you can have the parent organisation commit to the new idea and develop it as its own.
For innovation to work, the whole company has to be engaged in the process, and in many cases other companies too – be they partners, suppliers, customers or other stakeholders. If you create a “Skunk Works” organisation just for R&D, the whole company will not be involved, and you will have a hard time integrating the new invention into the company and commercialising it – in other words you will have a hard time innovating.
References and Further Reading
Fosfuri, A., & Rønde, T. (2008). Leveraging Resistance to Change and the Skunk Works Model of Innovation. Journal of Economic Behavior and Organization.
© 2020-2021 J M Clegg Ltd
Image © Yasmin – stock.adobe.com
3 thoughts on “What About a Skunk Works?”
Organisations who don’t grasp the difference between invention and innovation?
I worked for a fairly large engineer focused organization. Often times, the process took more time than the actual engineering and the politics involved in getting projects funded and resourced often turned what was perceived as a merit system into a pencil whipping exercise where the largest number wins. Smaller projects never got funded because their financial impact was considered too small on the scoring sheet used to fund/resource projects. A “Skunk Works” type second option would be ideal in this situation where limited resources can be used to get a product to market quickly. “Skunk Works” also works when an existing product needs a software/firmware or mechanical design change requested by a customer.
The larger Process created well documented, maintainable, well engineered products which were often times late to market because of the time it took to go through the Process. Some of these products lost millions of dollars because they missed out on the opportunities because they took so long to develop.
First to Market and timing are often the differentiators when creating a new product in a cyclical industry.
I side with the Full Engineering + “Skunk works” approach because often times I was called upon to create software/firmware outside of the formal engineering process. You don’t get a budget and there is a lot of begging for forgiveness (when the operation is truly covert) but it beats fighting the system for a year and being told NO.
Bryan, thanks for the comment. It sounds like the organisation you were working for had some big process problems – which unfortunately is not unusual. I completely agree that time to market is critical for most projects and that timing is a big differentiator. Processes need to be designed to expedite this, and a well-run organisation will prize on-time delivery over scope. So it’s important to demand a fixed duration (including approvals!) and a variable scope rather than the other way round. I can see how working outside the system can be attractive, and sometimes more effective, if an organisation is poorly run. My point is that it’s better to focus on running the organisation properly, with innovation embedded in strategy and innovation being the responsibility of everyone, than it is to use a band-aid to mitigate the problems that poor systems and process can cause. Clearly this comment is targeted at the people who can make those changes. My upcoming book will be targeted at those same people, among others.