SOBRE ESTE EPISÓDIO
A look at the use of skunkworks projects to circumvent bureaucratic hurdles. Full transcript of the episode with links to additional sources follows.
===
It was 1943. The world was at war. German engineering was producing an array of terrifying weapons, and even before the war, had already demonstrated working jet aircraft. German jet fighters and bombers could potentially leave the Allies nearly helpless to defend against this technological threat with their own outmoded fleet of propeller-driven craft.
In this ecosystem of urgency, the US government approached airplane manufacturer Lockheed Martin with an incredible challenge. They wanted an American jet fighter to be developed. It would need to fly 600 MPH, maneuver and perform in intense aerial combat, and as if that weren't absurd enough, it needed to be ready to demonstrate in 180 days.
Further constraints existed. Lockheed Martin was already using all of its floorspace for the war effort. How would it come up with a way to execute on this incredible directive?
The answer came in the form of Lockheed Martin's Advanced Development Programs (ADP), now commonly known as "Lockheed Martin's Skunk Works." The ADP is now the most famous example of the rapid solution approach now generically referred to as a "skunkworks project."
In the earliest part of the 1980s the personal computer market was dominated by Apple and Commodore, but IBM - who dominated the server-rooms of the IT departments at the time - had taken notice. IBM wanted to get a piece of the home user and desktop computer market, but - as dramatically stated in the PBS documentary Triumph of the Nerds, IBM's own estimate is that due to bureaucracy and internal controls, it would take nine months just to ship an empty box. The solution around this was a skunkworks project. IBM had been experimenting with "Independent Business Units" that could shrug off the limitations of normal IBM procedures and act swiftly to get things done. The skunkworks project it undertook became the IBM PC and the project's design choices became the new paradigm for business computing.
The name "Skunk Works" has an interesting origin. Because the group tasked with this 180 day miracle had no floorspace, they had to set up shop under a circus tent by a plastics factory in Burbank, California. The fumes from the factory reminded workers of a recurring feature of the popular Lil' Abner comic strip, a smelly factory outside the fictional town of Dogpatch, Kentucky known as the "Skonk Works." This became the name of the group until the copyright owners of the Lil' Abner comic strip complained in the early 1960s and Lockheed Martin formally changed it to "Skunk Works" to appease the lawyers. The name stuck and has become synonymous with this kind of project.
Another famous skunkworks project was the Apple Macintosh. The history of that project has become quasi-mythical because of books like Insanely Great, by Steven Levy and Revolution in the Valley by pioneering Mac programmer Andy Hertzfeld. This story was also heavily featured in PBS' Triumph of the Nerds. In 1981, Apple was primarily funded by sales of the Apple II, but it was desperately trying to create the next revolutionary personal computer. After some internal struggles, Steve Jobs took over a project that had originally been envisioned by Jef Raskin as a friendly and inexpensive home computer. Jobs changed the focus to make a revolutionary graphical user interface based machine. He embraced the "rebel" mentality for his team, famously telling them "It's better to be a pirate than join the Navy." The team took this mentality seriously enough to hoist a Jolly Roger flag over the remote office complex where the Mac team worked. While it was not an instant success financially, the Macintosh project would also change the world.
You can purchase a hand-painted Mac Jolly Roger flag from original artist Susan Kare (but they are pricey!)
Apple itself (and Microsoft, for that matter) took its transformative windows and desktop metaphor from an even earlier and more innovative skunkworks project - one run by XEROX. The big copier company had setup its legendary Palo Alto Research Center (PARC) facility and by the time Apple's Mac team got to visit, they had the Xerox Alto, a personal computer decades ahead of its time. Ethernet, the Graphical User Interface (GUI), the computer mouse, object-oriented programming (OOP), email, laser printers and a full concept of what is now the "modern office" all existed almost two decades before they would become ubiquitous parts of modern business.
There's a lesson to be learned from the Xerox Alto, but we'll get back to that.
Most skunkworks projects fail. We remember the successes but can't recall the failures because they never make it across the finish line into our consciousness. Researchers call this "Survivorship Bias" and it's important to keep in mind, but it also suggests a key concept to potential success: a successful skunkworks project keeps trying until it finds something that works.
In Silicon Valley, where tech startups rise and fall like sparks above a campfire, the innovations and lessons learned have been distilled down into the pithy phrase "fail fast, fail often." As with any catchphrase, it is frequently misapplied, misunderstood, and misattributed - but the core lesson is to try things, see if they work, change if they don't, and keep trying until you find the formulation that succeeds.
Of course, it helps to have a genius team. The original Lockheed Martin Skunk Works project was run by legendary engineer Clarence Leonard "Kelly" Johnson. His team consisted of 23 designers and 30 mechanics. Under a circus tent in the smelly shadow of the plastics factory, Johnson and his team put together a prototype in less than 150 days. That jet became the P-80 Shooting Star, America's first operational jet fighter. The same "skunkworks'' approach would be used to create the U2 Spy Plane, the SR71 Blackbird and the stealth fighter. Different leaders, different engineers and mechanics, but the same "outsiders on the inside'' method would drive their success.
The P-80 Shooting Star (wikimedia)
Apple's Macintosh team was full of superb engineers and programmers and their work continues to influence and inspire modern computing. Having Steve Jobs at the helm of the project, while certainly interpersonally challenging for the team, was also undeniably inspiring as well. The Mac team would dissolve shortly after the initial product release despite its accomplishments. Future successful Apple products like the iPod, iPhone, and iPad have not become synonymous with the skunkworks approach.
The original Apple Macintosh (wikimedia)
Most skunkworks projects are conducted by large businesses and should be funded accordingly, but sometimes these projects are done through stealth by rogue leadership. Often these are computer-related projects and have become known as Stealth IT or Rogue IT. As we'll discuss in a moment, the rise of such projects signals that your company has serious challenges that need to be identified. Such projects can be the result of interpersonal differences between the IT management and the business divisions, an IT delivery ability insufficiently fast at delivery, departmental functional needs not being addressed, or a variety of other causes. The emergence of such rogue efforts can also indicate that your knowledge workers have innovative ideas and are yearning to see them made real. Stealth IT is a bigger topic than we can address here, but it will be a future episode. These aren't technically skunkworks projects and therefore have to overcome not just the limits of doing the work without the blessing and funding of management but also with the risk of possible rejection of their output because of the manner in which it was created.
Skunkworks projects have historically been behind amazing innovation, but they are not a magic potion for success. There are specific places where they've been most helpful. Because of the wildly different backgrounds that have driven the use of skunkworks projects, some of the things one can infer from looking at the examples may seem conflicted, but here are a few observations:
- Skunkworks projects are often used to break through corporate bureaucracy to allow quick innovation. Before throwing together a skunkworks project, you need to make sure that the obstacles faced are the kind that can be worked around. For instance, if the obstacles are statutory or regulatory, then a skunkworks project might not only be ineffective, but illegal.
- Kelly Johnson came up with a set of 14 rules for running a skunkworks project. I will put a link to those in the show notes. His rules are written specifically for a government contract aeronautics industry, but some key points are still applicable. I'm going to distill a few of these:
-
- A skunkworks project's leadership should effectively have total control of the project, reporting only to a limited and clearly identified executive management structure.
- The project should have designated office space away from the regular workers. Isolation and exceptionalism are vital to making a skunkworks effective.
- Restrict access to the team. Use a small team. Use an exceptional team.
- Minimize the number of reports required. Let the team focus on accomplishment, not documentation - but appropriate documentation must be part of the effort.
- Fund the project adequately. Reward your team because you'll be asking it to do the extraordinary.
- A skunkworks project calls for exceptional workers. It will be an extraordinary challenge to manage a team that will likely contain the arrogant and potentially iconoclastic. The lead will manage not just the technical challenges but also the interpersonal ones.
- Skunkworks teams are a means for building entrepreneurial spirit in a mature - perhaps even stagnant - corporate environment. They are not typically suitable for start-ups themselves.
- Finally, a skunkworks project must deliver! To quote Steve Jobs, "real artists ship."
Skunkworks projects fit nicely into the human need for myth. The narrative of a rogue band of genius workers saving the company or even the world from some disastrous situation is literally the formula for thousands of movies, books and TV shows. But is that really the way business should get done?
As much as I understand the visceral appeal of such narratives, it is possible that a successful company that is not using skunkworks is actually a sign of health. There are other ways to achieve innovation. Google famously has its 80/20 rule. Since the mid-2000s, it has encouraged its workforce to spend 80% of their time on primary work tasks, but 20% on innovative side projects. But even with all that, the company set up its X-project division, which is a skunkworks-style incubator.
There is another way, a second route to achieving innovation, and that is adopting an internal policy of continuous integration and continuous delivery (CI/CD). In software, CI/CD means instead of producing single massive product rollouts, the engineers continuously provide updates and improvements with additional features and fixes. This becomes a reliable and continuous stream of innovation that never lets the project grow stale. This kind of corporate culture can avoid the need for a skunkworks approach because it is literally fed on the input and feedback from the users and that is a major pipeline for innovation and improvement.
The bigger a company gets, the more mired in complex organizational structures, the slower it tends to move. The corporation becomes a victim of inertia, slow to turn or maneuver.
A corporation is like a cargo ship maneuvering through an icy ocean. Icebergs are a threat that requires maneuverability, but bureaucracy can also be an ice-flow that stifles movement. We could think of our skunkworks projects as a kind of icebreaker, a ship that specializes in plowing through such ice and making safe passage for the bigger cargo ships. The CI/CD in this metaphor would be a large, maneuverable ship that avoids the ice entirely.
I wondered, "Could the need for a skunkworks project counterintuitively be a canary-in-the-coalmine that a corporation is in danger of getting stuck in the ice?" But then the mixed-metaphor police gave me a warning ticket, so I decided to check and see what companies are still using this approach. Samsung, Google, Ford, Staples, IBM, and many massive corporations still use the skunkworks approach to foster innovation outside of bureaucratic constraints. I suspect there is some risk that business journalists have, to some degree, confused the skunkworks approach with the kind of "pure research" labs of the type that AT&T famously ran. Which brings us back to Xerox.
In his book, The Master Switch, Tim Wu describes multiple examples of how massive corporations use their resources to find innovative solutions to problems, but then discover that their findings are so disruptive they threaten the structure currently funding their existence. Rather than monetize the new products at the risk of disrupting their own status quo, they succumb to the temptation to patent and bury the technologies. Again and again, this approach gives years to decades of protection to the old ways, but inevitably some outsider will find an unpatented approach to these institutionally suppressed innovations. It is shameful, but understandable, that innovations are often stifled because it is easier in the short term to maintain the status quo. It takes extraordinary leadership and vision to risk disruption in order to overcome the inertia of the mentality of "if it ain't broke don't fix it." Such corporate pivots are more often the result of desperation than insight. Which brings us back to Xerox.
The PARC team handed Xerox the future of business, but Xerox leadership didn't know what to do with it. Unexploited by Xerox, the various innovations of PARC crept out into the world either directly at the hands of individual creators, or through the emulation of their innovations by competitors like Apple. Innovations are going to happen - but who will control them? Suppression of innovation is a dead end, it just sometimes takes a decade or more to prove it.
So what is the right answer to your innovation needs? Do you need a skunkworks project? Do you need to adopt CI/CD in your organization? Will your stifling of discovery make your smartest and boldest workers break off and become entrepreneurs? There's lots to consider here. As always, Apex Process Consultants are here to help you figure this out with our team of expert consultants and software tools designed to foster innovation and help you accelerate YOUR business transformation. Check our show notes for links about the companies and people in this episode.
