The Smell of the Skunk Is a Good Thing When You Need a Breakthrough Product to Power Growth
The Smell of the Skunk Is a Good Thing When You Need a Breakthrough Product to Power Growth
What keeps you up at night? Your competitors sell about what you do, charge about what you charge and talk to their customers about how you do. Then along comes the game-changer and you go from being one of the main obvious 3 choices to looking like 'yesterday'.
If you're a P & C carrier, serving drivers, your nightmare may turn out to be a new kind of competitor such as MetroMile. You sell being billed and then paying a claim – the customer sees you as charging monthly and then fighting you on getting their car fixed. Even if, they never have a claim, the average customer sees you as being a necessary evil, 12 months a year. MetroMile sells coverage by the mile, much like Progressive's telematics plug in, but incorporates a series of end-user oriented dashboards showing each policy holder their average gas mileage, average vehicle speed, ongoing gas consumption, trip length frequency and an ongoing benchmark (actually a customer retention genius move) comparing their MetroMile policy to the driver's previous plan. It's a daily friendly contextual conversation between customer and company. Even worse, MetroMile is not your traditional carrier, it's the aggressive technology front end of a smart insurer, and it's located in fast paced Redwood City, California, South of SFO. So it's a non-traditional market entrant, using breakthrough customer-engagement technology while you have a mobile enter-a-claim app – maybe revolutionary inside your HQ, but a nothing new to the rest of the market.
We all have strategic initiatives, run by our IT or a combined business-IT team as a parallel activity to daily ops. With Digital business, as with most strategic initiatives, linear or competitive match improvements are often insufficient, even if the easier path is to innovate and not pioneer. While living within existing innovation processes reduces stress on your employees, your internal processes, overhead assumptions, and bureaucracy, it does, however, leave the door open for someone else to shake up your market, leaving you in the 'other participants' line.
You already know the Bad Skunk
Poorly executed innovation initiatives often get bogged down in internal politics and bureaucracy from the beginning – they are doomed to come in late, over budget and scaled back to being an also-ran. In one case we know of, the deliverables were 6 months late, scaled back to being barely useful, and 8X initial cost estimates. Departments all want a piece of the new toy, at least while the initiative seems successful, followed by Senior Leadership level political jockeying as part of the post-cost overrun sharing process. Part-time resources get sucked back into their day-jobs, the office layout sending the message of 'old school spoken here', new non-BAU initiatives also have the burden of provoking their breakthrough innovation is worth the investment. The business needs this breakthrough fast to gain competitive advantage while the R & D and Dev teams want politically safe, non-confrontational, sequential processes.
How does the organization respond to a troubled initiative? First comes early warning – they get the 'smell of the skunk', way before they collapse. Who has not heard of a key initiative referred to in terms of "I hear it's not going well, the word is, they're going to miss their dates".
ESPecially with new and complex business driven applications where the technology is not fully baked, it's easy to have an initiative start to smell really badly, really quickly. First comes over commitment to the end user buyer, either inside or, worse yet, outside the corporate walls. In short order, all the RAG reports go from Green to Amber to Red, highlighting Risks, and Issues and escalation dates, but nothing moves the needle, it's just reports. Panic follows at some point (usually when Senior Management starts to ask really hard questions), and a War Room is established. Since the core way the initiative is run has not changed, it's the same people getting the same results, only more colorful as every War Room I've ever seen a dashboard published daily.
As everyone who has ever had to deal with a dog who thought it could overpower a skunk knows, the skunk always wins and you wind up buying Costco package amounts of tomato juice. The dog did what it always does, paid the price, and then retreated.
Now you need The Good Skunk
We have to realize when we want real breakthrough, 'wow !!!' kinds of new products, our internal innovation and standard incubators are not going to get us there. They too much reflect the basic organization and are loathe to having a conflict with other groups, such as Product Management or IT. We need a Skunkworks.
Why? When the stakes are high enough, and a breakthrough product is required, the company sets a high-bar stretch goal, binds it within meaningful but still loose constants, pulls a few of their best cross-disciplinary staff from their day-jobs, sets up shop offsite and lets the Skunkworks create the solution. In some companies, this is called R & D and has its own campus, complete with test manufacturing facility. Others, such as Google, require employees to set up temporary 2 and 3 person Skunkworks to develop non-incremental products.
Steve Jobs was famous for at least 2 of these. The first, in the early '80's, was located behind the Good Earth Restaurant in Cupertino, CA. Fifty top flight employees produced the Macintosh. The second was a team of carefully selected 'pirates', located 3 blocks from the main camp near a Texaco gas station. Who knows what's still up and running, post Jobs, but we can hope. Job's motto for his Skunkworks was "It's better to be a pirate than join the navy." It was business driven asynchronous commercial 'warfare'. Can it work inside a big, process bound and regulated company?
Lockheed Martin has their famous Skunk Works, officially known as the Advanced Development Programs, specializing in designing and delivering revolutionary, needle moving, results. Go to Wikipedia and you can see their list of breakthrough airplanes and other vehicles. Contrast this with the far less complex typical business system project with the usual time delays and end-user feeding frenzies when deadlines are missed, or a system is said to be ready when in reality, behind the scenes, it's been cobbled together and brittle. Airplanes do not do well with brittle. Their Skunk Works got its name due to the strange smells emanating from the circus tent housing it, with the help of the Lil 'Abner cartoon strip' Skonk Works'.
How do we know if we can use a Skunkworks for a particular strategic initiative? Is it too radical for our organization and culture? What are the Thresholds to help us know when to employ a Skunkworks?
Threshold # 1 – Ask "Is this going to innovate or will it transform the business? Is this a new and improved moment or a brand new product category? Do I need this quickly or can this bounce around for a while as we polish it ? "
We all like to think we work on only the best and newest stuff, but in reality a lot of programs / projects have more of an impact on ongoing operations, or growing the business by doing more of the same at less cost, then dynamically moving the business in a new and explosive-growth trajectory. Let the BAU structure handle the former, and give the latter to the Skunkworks. For example, Sony kept iterating and innovating on the Walkman (Regular, Sport, etc.), and then Apple came out with the iPod.
Threshold # 2 – Ask "Whom do we have to staff this new type of group? Do I always need a cast of thousands?"
An 'A' project (new product intro or any other game changer, including M & A execution or advanced systems) must be led by an A-Player. A-Players can hire and retain other A-Players. B-Players hire and retain unambitious B-Players or even C-Players, which means you're potentially betting a strategic initiative on those very resources least in demand by others. Therefore, go with only A-Players from top to bottom. Caveat here – by an A-Player I do not necessarily mean the brightest in an SAT sense – I mean most creative, and quite frankly, most flexible and resilient. Combine that with a personality appreciative of the chance to do something special, who does not feel they inherently deserve to do it, and you have your super-stars. As Steve Jobs determined, you needed something civil renegades, not smart functionaries. The risk adverse need not apply.
Not every initiative needs a Skunkworks with hundreds of players. We have used as few as 3 on highly focused single process improvement initiatives, 20 on new software products and over 50 on major product creation and rollouts. Some personnel are very specific SME's and needed only at discrete times, such as Legal and Market Research. Finance, however, has to be a full time member, as does Sales.
Threshold # 3 – Ask "Has someone figured this out before? I do not have time to reinvent this"
Listed below is my adaptation of Clarence "Kelly" L. Johnson's cardinal rules for his original Skunk Works. My edits / changes are italicized. These rules work, no need to reinvent, just adapt. The key is his recongizing when their existing BAU innovation process would not deliver within their required timeframes and the radical requirements. Onr the new airplane was tested adna ccepted, their BAU factory then built those planes on a massive scale. We can not run a breakthrough initiative using the same pace, people and PMO's as we would employ on something entirely more routine and sometimes, linear and predictable.
1. The Skunk Works Program Manager must be delegated practice complete line – responsibility control of its program in all aspects. He should report to a division president or higher.
2. Strong but small project offices must be staffed by the smallest possible combined Business, Content / Branding, Technology and Operations team. They must have line-decision power, not just focusing on reporting.
3. The number of people having any connection with the project must be restricted in an almost wicked manner. Use a small number of good people (10% to 25% compared to the so-called BAU project). KISS means, here, 'Keep It Simple, Small'. Large groups mean added wasted time managing the larger group. They must be co-located even if virtually (no other responsibilities but this program)
4. A very simple specifications and design release system with great flexibility for making fast changes must be provided. Let them develop their own methodology, based on Agile and Xtreme Management principles.
5. There must be a minimum number of reports required, but important work must be recorded thoroughly. At the end, information and technology transfer will turn an invention into a business.
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.
7. The Program Manager must be delegated and must absorb more than normal responsibility to get good 'vendor' bids for internal and external resources on the project. The Skunk Works Program Manager has the right to interview all potential participants from all departments, with a right of refusal. This does not mean cheapest hourly costs – think in terms of cost per deliverable done-done.
8. The multi-stage BAU testing function / groups, as currently used across the board, and which has been approved by IT, Compliance / Internal Audit and the Central PMO , meets the intent of existing evolutionary BAU requirements and should not be used on Skunk Works projects. Push more basic inspection responsibility back to the originat o r, and earlier during the development process . Do not duplicate so much inspection. Fixing Show Stopper and even High to Low defects found after the fact is too recursive. Fixes made in this manner can easily destroy the application architecture or product design if not done properly (and often they are not).
9. The Skunkwork personnel must be delegated the authority to test their final product in actual flight, so they have business context and are not developing in a vacuum . He can and must test it in the initial stages, using Testing Forward design concepts and then test end-to-end before transfering Testing to the User Acceptance Testing function (which is more of a certification and hand-off process).
10. The specifications and desired end take-away result must be agreed to well in advance of estimating . The Skunk Works practice of having a specification section stating clearly which important [military] specification items will not knowly be complied with, and reasons therefore, is highly recommended.
11. Funding a program must be timely so that the Program Manager does not have to keep running to the bank to support business projects. The Skunk Works Program Manager is the paymaster for the project, payable by deliverable upon acceptance.
12. There must be mutual trust between all participants , with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures. When assigned to the Skunk Works project, they have only 1 boss, the Skunk Works Program Manager. This is easier when the Skunkworks is properly located offsite, and HQ security badges will not open the doors.
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.
Threshold # 4 – Ask "How soon do we need this?"
The typical PMO is staffed from a compliance and managerial-support point of view and employee personality. We know of a financial institution where the Central PMO Project Master Data Schema collects hundreds of elements, with all projects / programs being forced into this schema. Set up alone can take weeks for various approvals and rework. This approach is solid for monitoring BAU programs, where you have done these x-times before and other than a few peculiarities, you can do this in your sleep if necessary. They are overlays and while necessary, add little to velocity.
War Rooms are fun. I've created and worked in several, and the excitement of the very name is kind of catchy. They are excellent at providing a single version of program / project status, particularly when multiple PMOs are involved. The issue is as with the standard PMO described above, War Rooms are reporting and not actions oriented and, therefore, do very little to bring successful results. They can report late dates just as well as they can report on-time results. They leave it to the management to interpret the data, which may be out of their experience-zone. War Rooms do best in a heavily matrixed environment, functioning well as an overlay and are often imposed on a failing program when Senior Management does not fully trust anyone else and wants their own view.
Skunkworks are all about fast, coordinated action – when you need a fast and new approach to something, this is your organization structure of choice. Reporting is strenuous, but only as required. Management layers are thin, and the organization is flat, but there is the 1 person who is in charge of each initiative, from funding to deliver and sign-off. They are not matrix friendly – no one can hide by being a member of some larger committee. There is a program management capability adapted to the faster pace and empowered to directly manage the potential impact of unknowns and even unknown unknowns. A Skunkworks has to be self-contained, with all required skills and resource levels dedicated to an initiative.
Choosing a PMO / War Room vs. a Skunkworks depends the level of innovation vs. breakthrough required and the time frame in which you need it. It depends on you deciding to be an evolutionary vs. a revolutionary company, of having others respond to your vision, envying your EBIDTA and P / E ratio, not the other way around. To continue our analogy, in fighting for business growth, it's almost always better to be the skunk and not the dog.