Problem-solving in the past has been dominated by methods involving rigorous and meticulous planning and flawless execution – something that has been questioned, largely by results (or rather the absence of it) in the recent years, if that is (still) the best approach when there are so many moving parts and the external world changes in a blink. We frequently ‘blame’ old practices of assembly plant-style waterfall days where it took years to get a project team to jump multiple hoops and just get a project done – in most cases, hopelessly delayed, unacceptable quality and overbudget. Building process frameworks was once thought to be the panacea for all these maladies, especially in mid- to late-nineties, as we say with a series of processes – CMM, ISO, BPR, and so on… And thus, birth of agile movement came as a big relief and promise to speed and improve things up a bit. The idea of starting out with just enough requirements and iterating along with way had an intuitive appeal in this VUCA world, where no one had complete information nor all the time to wait for that perfect moment of epiphany – because that epiphany was a moving target in reality. With more efforts to design a solution, we learnt a bit more about the problem and this became an unending spiral – which was not necessarily a bad thing, but the gated processes didn’t provide much guidance on how to address it effectively. Clearly, we needed nimble processes that allowed for more iterative development without making too much commitment upfront, especially that couldn’t be easily changed downstream, and a matching sociological process that allowed teams to build unconditional levels of trust among themselves that stimulated collaboration and made them operate at the speed of light. Many of these ideas have emerged from multiple disciplines such as software development, behavioral psychology, team dynamics, systems thinking and leadership, just to name a few, in the last ten to fifteen years, and have led to statistically significant successes in several domains. However, as we are learning, some of these practices have been around for decades – just that we haven’t ‘discovered’ them just yet. I just found out one such great example this weekend – the Skunk Works. Wikipedia defines it as blow:
A skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation. Everett Rogers defines skunkworks as follows: “[It] is an especially enriched environment that is intended to help a small group of individuals design a new idea by escaping routine organizational procedures. The R&D workers in a skunkworks are usually highly selected, given special resources, and work on a crash basis to create an innovation.” 
Clearly, developing skunk works is not a business as usual approach. It is a special quarantined environment created for the sole purpose to incubate a radically new idea under special conditions that catalyze teamwork and collaboration and accelerate innovation. Another definition describes it as:
A skunkworks (also known as Skunk Works) is a small group of people who work on a project in an unconventional way. The group’s purpose is to develop something quickly with minimal management constraints. Skunkworks are often used to initially roll out a product or service that thereafter will be developed according to usual business processes.
However, there is more to Skunk Works than this. Starting out in 1943, Skunk Works at Lockheed owes its foundation to a mantra of “quick, quiet and quality” that still continues after seventy years. The first project, XP-80 Shooting Star jet fighter was designed and built in only 143 days – seven days less than required and without any contract or an official submittal process! The formal contract for XP-80 did not arrive at Lockheed until Oct 16, 1943; four months after the work had already b
egun! However, when we look at its operational record, it was delayed – it was pressed into service only towards the end of WWII – something that clearly didn’t meet its original objective. There were many accidents, and several ace test pilots were killed on the test flights. Given that there were several innovation on this ‘product’ there seems to be a strong flavor of fail fast, fail cheap and keep iterating – even though the loss of human lives seems to be tragic and perhaps avoidable in some cases. However, this blog post is more about the underlying process and associated principles that led to such innovation in the first place. Upon reading further, I was impressed by its founder, Clarence “Kelly” L Johnson, who started it all. He broke the rules, challenging the then bureaucratic system that stifled innovation and hindered progress. I think these rules have never been so important ever before… Kelly’s 14 Rules and Practices Kelly wrote down these 14 rules that led to the successful culture of innovation at Skunk Works at Lockheed. Let’s study them and understand their context in today’s workplace, and if our practices address them effectively:
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.
There must be a clear-cut responsibility, ownership and accountability lest there be diffusion of responsibility leading to confusion, chaos and associated symptoms of delays and poor quality. As much as we need self-organizing teams with democratic decision-making process, we still need to have a clearly defined ownership – someone who is tasked with breaking all rules to get the job done! Agile teams make the team responsible for delivering to its commitments, and agile thought process doesn’t generally support the notion of a ‘manager’ but a product owner is still responsible for eventual success of the product. Yes, the notion of what constitues work for a manager will keep changing with the times, but in some shape or form, I believe there has to be a sense of final responsibility for the outcome.
2. Strong but small project offices must be provided both by the military and industry.
There is no denying the importance of reducing management and administrative overheads but making them more effective. Bloated models that create large hierarchies are on a wane, and new-age program management is all about leadership by influence rather than using positional power to get the job done. Scrum takes a leaf from servent leadership to describe the role of scrummaster, which is a significant departure from having a manager with positional power to get the job done.
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).
More than the ability to actually work with small teams is the recognition that having a small team is much more productive and effective compared to the “so-called normal systems”. Of course, not all problems can be solved by having small teams, especially if one is looking to complete them faster than the competition, but one needs to weigh-in all the factors, but definitely in favor of small teams. Agile makes a strong case for small teams.
4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.
This sees like making big commitments upfront is being deemphasized. This principle sounds very simple to what Lean Construction Institute, several decades later enunciated when it said, “…design decisions will be deferred until the last responsible moment if doing so offers an opportunity to increase customer value.” Agile thinking is very much aligned to avoid making heavyweight commitments upstream, especially when there is a heavy cost of change them later, and given the rapid pace of changes around us, it is certainly not a hypothetical and extremely rare situation for which we are delaying making the decision.
5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
It’s so funny to imagine that in the era of typewriters too, they were sick of reports! I think there is nothing that can justify having a disproportionate number of reports under any circumstances. The old thinking was to increase the micromanagement when in crisis, or even otherwise (I fondly remember a General Manager in at an old job who would come to our cubicle every hour and check the status update on ‘design document’!). I think asking for a number of reports smacks of Theory X, where the underlying assumption is that unless you make people work, they won’t take initiative and most certainly won’t assume responsibility. So, the hierarchy gets created simply for asking for more frequent status updates, and since the higher levels wield considerable power in deciding renumeration and career progression for the ‘lowly underlings’, who do you think wins in the end? Certainly not the project, I guess!
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.
I see no reason this doesn’t apply in any possible context. Any sponsor needs to know how is the team doing. The team owes it back to their stakeholders, management and customers to keep them posted of what is keeping them busy, and when are they likely to be finally done. When I look at agile thought movement, there was an almost anti-establishment feeling that was so palpable in numerous views on dozens of discussion forums, that it is not a surprise that agile didn’t find too many favors with ‘management’. I don’t think it is called prudent wisdom to take money from a project sponsor and tell them they are ‘chickens’ :). Thankfully, I see more maturity among agile thought leaders today, and any level of project team owes it to keep their first-level of ‘customers’ engaged through the development phase.
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.
There was a time when people outsourced to save a few dollars. Not anymore. With such tight integration of your suppliers in your value chain, it is not about cost anymore – they need to have much more than their skin in the game. A strategic project can’t afford to have relationships that seldom go beyond conventional commercial considerations. Perhaps the best-known example is how Toyota treats its suppliers – “…we believe in developing mutually beneficial, long-term relationships based on mutual trust. To foster that trust, we pursue close and wide-ranging communication with suppliers.” and “…We at Toyota rely on outside suppliers for most of the parts and materials in the vehicles we make. Every step in making Toyotas, from development to production, consists of joint work with suppliers. The suppliers we seek are companies that have the will and the ability to become active partners with us. We are looking for suppliers who possess world-class competitiveness in terms of quality, cost, delivery, and technological capabilities.“. I don’t believe without such strong win-win mindset, a company can succeed in achieving the agility required to compete at big game.
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.
Inspection is essentially a waste. Deming was vociferous in his views on this “Principle#3: Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”. Clearly, there is no way we are ever going to completely do away with any form of inspections – there are far too many normal and special variations in any process to be able to run subsequent part of the process in autopilot. However, a more conscious effect to eliminate duplicacy in inspections not only improve the value stream but also fosters the culture of trust and interdependence among all players which can eventually help everyone run faster rather.
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. If he doesn’t, he rapidly loses his competency to design other vehicles.
If you can test components of an aircraft in initial stages, what stops you from doing the same for, say, software? Some of the biggest opposition to early testing comes from enterprise software and from software platforms – that they can’t possibly test half-baked functionality? However, nothing could be further from truth. If we are not testing product and its components early enough, we are accumulating significant risks downstream that can force untold miseries during the big-bang integration. I don’t think anyone disputes it seriously today.
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.
I think there is nothing wrong with this idea. However, there is a presumption of technological stability that doesn’t hold so well anymore. The pace at which newer technology gets productized is unprecedented, and one can’t sit comfortably having zeroed-into the hardware platform at the start of the project. However, there are surely classes of problems where for regulatory reasons, the technology cycles are much longer, and hence it makes sense to be cognizant of them. However, the advise is generic enough to be universally applicable for all class of problems.
11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
Simply put, if you don’t pay your suppliers on-time, they will have less motivation to work on innovating the next big thing and more to worry about how to pay salaries to their staff! Perhaps this was a big deal in early 40s that Kelly has to write it down! However, lack of funds can surely cripple or kill a project and hence enough care must be exercised, commensurate to the project size and impact, that ensures this is not on critical path.
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.
Again, Deming has some useful advise here too “Principle #4: End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.“. While one can debate if having one single supplier is a wise thing to do, there is no doubt that one needs to build a long-term relationship on a foundation of loyalty and trust. A relationship on short-term commercial interests might hold critical projects to ransom in times of crisis, and control or coercion might backfire. However, trust will almost always be reciprocated with accountability.
13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
This might be more relevant in military, but in true innovation projects where a mere whiff of what are the designers thinking is likely to be significant competitive intelligence in the hands of competitors, a sense of maintaining right amount of secrecy is not unusual. Apple is well-known to maintain absolute secrecy about its new products, and goes to any lengths to protect its competitive advantage. I also think it is not just about the secrecy due to competitive reasons, a little bit of ‘confidentiality’ might actually increase the amount of buy-in from team members and make them more ‘possessive’ about their work, making them all come together. However, it’s clearly a double-edged sword, and one must choose what works for them.
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.
I think Kelly was either a battle-scarred veteran of performance appraisal systems (back then!) or a visionary to be able to call a spade a spade! Perhaps the conventional systems at that time rewarded people for the number of personnel supervised, which might have no bearing on ability to innovate or deliver performance. This might even be his pet peeve, because in an earlier principle, Kelly has called for smaller teams, and here he is asking for rewards to be performance-based and not based on the team size. As we have seen in last few decades, power-hungry managers have only worked towards building large self-serving empires with no relation to the nature of work. In the end, such pyramid structures has become just that pyramid-shaped ponzi schemes. However, today’s social norms and professional values don’t support such stone-age thinking, and hence, this is only a gentle reminder to today’s managers. However, it must have been very profound at the time Kelly jotted this down. While reading these 14 principles, I couldn’t help but admire the genius of the man behind it – Kelly was not only on the top of his game, he was willing to literally fight the establishment to get his job done. If he perceived his process as stifling innovation, he was willing to talk about it, and make necessary changes commensurate to what was expected of him. A lot of people take refuge under and behind the process frameworks without thinking if it meets their needs. The thought process is that you buy a certain level of performance with established processes, and hence if you fail, it must be due to the process and not entirely because of you. This gets aggravated in organizations that apportion praise on the process and management, and failure on the managers and the individuals. As a result, people stop sticking their necks out, and instead choose the trudge along the status quo. But think about it – are you paid to preserve status quo, or to push the thinking, bring about changes, break some china…in short, deliver some skunk works… So, does your process help you preserve status quo, or deliver some kick-ass skunk works?