Want to drive innovation? Go full skunk

(PHOTO: SHUTTERSTOCK)

(PHOTO: SHUTTERSTOCK)

Two years ago, I had a very enlightening conversation with Thom Albrecht (now CFO at Celadon). We were talking about why innovation was so rare within trucking companies. Two key items came up during this discussion that rang true to me then, and still do now. First, everyone talks about how public companies are driven by short terminism, the same could be said for most trucking companies (and most businesses in general). In trucking, since the industry is cyclical and a leading economic indicator, the underlying marketplace can turn on a dime, and leave many operators in a precarious position. As such, there is a common theme to be conservative when it comes to large capital investments, unless there is a reasonable way out (e.g. flexible delivery or cancellation terms with OEMs, and a strong used truck market). Second, the whirlwind which is trucking doesn’t lend itself to having the time and resources available to build an innovation strategy and make some big long term bets.

Thom then proposed that instead of simply trying to make time and people available within the confines of the existing trucking enterprise, and all the distractions and variable that comes with it, he made the position that trucking companies borrow a chapter from other industries and movements – while the going is good. Budget a certain percentage of operating profits to build a ‘skunk works’ program to build real competitive advantages. I had never heard the term before, but was familiar with real examples he provided, such as Xerox’s PARC team, which gave us (among other things) the mouse and the GUI interface for software. In trucking, examples of these types of initiatives would be JB Hunt’s Carrier 360 application. They key thing Thom wanted to reinforce in this conversation was that trucking companies are far too eager to have third-party companies build solutions to their long list of operational obstacles. Further, once the solution is in the hands of a third-party, it becomes everyone’s solution. I agree with this proposition.

Don’t get me wrong, building your own TMS or accounting system would not be a wise choice for almost any carrier. However, there is an abundance of low-hanging fruit – customer-specific problems that should be looked at as opportunities to put a ‘fence’ around them. Before we dive into the framework for setting up your own ‘Skunk-works’ team, you need to ask yourself “How much have I budgeted in 2019 for innovation”. If you answered no, you’ll be in the majority. However, in business, the minority is where the real dollars are made.

We all want our project teams to accomplish more while using fewer resources – both in terms of time and costs.  Everyone wants to develop that next “disruptive” (getting sick of that term) innovation that changes our industry forever. Unfortunately for every game changer, there are hundreds or thousands of projects that only deliver an incremental change, probably within the realm of “keeping up with the Jones’”.  Why? And more importantly - why are we settling for these results?

In many cases it could be the design of the project team itself.  A significant number of projects do not have a clear mandate in terms of requirements and are likely given too many unnecessary constraints. Project timelines are kept relatively open, resulting in a sense of urgency coming too late in the plan, causing overruns and delays. Budget overruns are expected, and buffers tend to be built into the plans.   Many teams are brought together including people who really don’t need to be there. Instead they are there to “represent their department” or to increase the prestige of the project leader through their managing a large team. If the organization already has silos, then any project team that doesn’t have “full” representation faces distrust from those areas not represented.  Team members probably are also trying to accomplish their normal jobs at the same time as being on the team. The result is divided attention and loyalties, organizational politics influencing outcomes and decisions by committee that will focus on minimizing the boat rocking when maybe the project focus requires being blown up.

Maybe what you need is a small, agile team that is taken out of their day-to-day roles and encouraged to develop something new and truly innovative, with an emphasis on determining how to make something happen as opposed to why it can’t be done. A team that will be challenged to run on tight deadlines and limited resources.  What you need is to set up your own “skunk works”.

The term Skunk Works came from Al Capp’s hillbilly comic strip Li’l Abner, which was popular in the 1940’s and 50’s. The “Skonk Works” was a dilapidated factory located on the remote outskirts of Dogpatch, in the backwoods of Kentucky. According to the strip, scores of locals were done in early by the toxic fumes of the concentrated “skonk oil”, which was brewed and barreled daily by “Big Barnsmell” (known as the lonely “inside man” at the Skonk Works), by grinding dead skunks and worn shoes into a smoldering still, for some mysterious, unspecified purpose.

The original Lockheed Advanced Development Projects Division was set up during WWII in a circus tent adjacent to a foul-smelling plastics factory. Germany’s first fighter jets had been seen in the skies over Europe in 1943.  The US War Department hired the Lockheed Aircraft Corporation to build a working jet fighter prototype in only 180 days. The company did not have enough floor space, which resulted in the unusual location. Irv Culver, a Lockheed engineer referred to the facility as “Skonk Works”. As the division was secret, employees were cautioned to be careful even when answering the phone. When the Department of the Navy called trying to reach the Lockheed management for the P-80 project, the call was transferred to Culver’s desk. He picked up the phone and stated “Skonk Works, inside man Culver”. The name stuck.

Lockheed changed the name of the advanced development company to “Skunk Works” in the 1960’s at the request of the comic strip copyright holders.

Clarence “Kelly” Johnson was the first team leader of Skunk Works and was the designer of the P-80, U-2, SR-71 and many more. Johnson developed 14 rules that fed his rationale that “people challenged to perform at their best will do so.”  These rules boil down to one simple principle – “the skunk works is a concentration of a few good people solving problems far in advance – and at a fraction of the cost – of other groups by applying the simplest, most straightforward methods possible to develop and produce new projects. All it is really is the application of common sense to some pretty tough problems.”

The 14 Rules:

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.

2. Strong but small project offices must be provided.

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).

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

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. Don’t have the books 90 days late and don’t surprise the customer with sudden overruns.

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.

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.

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.

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.

11.  Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.

12.  There must be mutual trust between the military project organization and the contractor 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.

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.

As you can see, some of these rules are very specific to the military industry.  However, the principles can very easily be adapted to any company. Keep in mind that these teams will often operate with limited resources and budgets. Famous examples include the Steve Jobs-led lab that created the Macintosh computer, or IBM’s use of the process to develop the original PC’s.

The first principle is that the team leader must be delegated full control over the program and report only to the highest possible authority.  This leader must then be able to protect the team from the normal bureaucracy of the company. They will also act as a gatekeeper for the project team, resulting in a minimum number of reports or meetings as the focus is on action and results.  Internally, the team must keep accurate documentation of all procedures and results so that what the team accomplishes can be replicated and learned from.

Next, have the entire team in one location, separate from their normal work environment. This will encourage positive team dynamics and bonding.  The goal is to have a strong team that feels comfortable with each other and can argue and debate amongst themselves freely. The free flow of ideas is needed to provide an emphasis on results and productivity over any political silos that may be attached to their normal roles. Related is the need to keep the team to the absolute minimum size required to get the necessary results.  You can rely on others outside of the core team, but the core must be small.

Prototypes should be “quick and dirty”, not held onto until they are perfect.  Show them to the customer, get feedback, make any required changes, and keep moving forward.  Having too few prototypes or taking too long to demonstrate them can result in delays to the project.  It can also result in missed opportunities by casting too narrow a net. The idea of using a skunkworks is to develop something new and radical. By having a too narrow focus at the prototype stage the team may rely too much on what already exists, resulting in just an incremental change instead of something truly new.  The focus should be on “how can we do this” instead of “why we can’t do this”. Look at your smartphone as an example. They are almost universally touchscreens. If the team at Apple working on the first I-phone only focused on what was then possible, perhaps Blackberry would still be the market leader with their physical Qwerty keyboards!  That team had the vision to eliminate the keyboard, make the screen larger and expand what a phone could be used for, opening it up to a whole new world of potential users.

A crucial factor is that the team must be trusted by the company’s management and by the customer.  This trust will minimize any outside intervention with the project. Getting agreement on the deliverable and any “must-haves” or crucial criteria should come either before the team is assembled or very shortly afterwards.  Any other constraints must be similarly documented, but these should be kept to an absolute minimum. The point is to have agreement on what the result should be able to do and what it can’t do without specifying the outcome.  If the outcome is preordained, then a skunkworks team is not needed.

Restricting access to outsiders is another key element.  The reason is that you want to avoid having paralysis by analysis.  By having too many people involved, valuable time can be wasted through “design by committee”.  Different people will try to attach their favoured ideas and the result can sometimes end up resembling Frankenstein’s monster.  Too many people can also allow the “that can’t be done” mindset to creep in. Lockheed originally had to be concerned with national security, but your team may only have to worry about being left sufficiently alone to be able to get the job done. Johnson put it this way: “There is a tendency today, which I hate to see, toward design by committee – reviews and recommendations, conferences and consultations, by those not directly doing the job. Nothing very stupid will result, but nothing brilliant either.”

Finally, involve everyone on the team in the big picture, including finances, quality, manufacturing, usage, etc. of your product/service/process.  This will allow the team members to be at their most creative. Buy-in from team members will be maximized as they will feel that their input is critical and that they are trusted enough to be informed on all aspects of the project.

In a real-world example, the Rand Corporation produced a report in 1971 about the project management of the Agena-D satellite program, comparing the planned versus actual results.  The key results included:

Screen Shot 2018-12-01 at 10.38.19 AM.png

Imagine, a military project being completed in 50% of the allocated time at 53% of the expected cost!

Think about the sort of results your teams could accomplish using this method?