Planning of invention 2: lessons from Sidewinder and China Lake

I read an interesting book about the sidewinder missile development at China Lake. The  book is hyperbolic in places, and seems to leave out the prior art in IR guided missile development; quite a lot of which was horked from the Germans,  presumably because it was a distraction from the story and theme. He also fails to mention how shitty all early guided missiles were. None the less, the sidewinder is a hugely successful decades old design, our oldest, and it’s a little known story which probably wouldn’t have been told without the author’s efforts. It also tells us much about building innovative companies and organizations.

The missile itself is quite beautiful as a technological artifact; something a space alien from a parallel universe, or one with religious prohibitions against computers might have come up with. It didn’t look real cool, but its insides are glorious, at least in the early models, and the story of its design makes one realize how damn clever it was. At the time IR guided missiles were widely seen as impossible, as there is lots of IR bouncing around due to the sun. Sure, now a days you could probably guide a missile using visual imaging, but back then, electronics was done with vacuum tubes and relays, so they were hardly in a place to do that kind of processing. The IR detector was nothing special; sticking it on a precessing gyroscope with a checker pattern for detecting differential motion of the target was an innovation (albeit one which resembled something on the Blohm & Voss missile). Also worthy of note: the steering fins in the front were the result of a design compromise where the head had to be fitted to the rocket body separately due to a limitation in navy ordinance lifter lengths. The fiddling required to make it hit a target without being distracted by reflections on clouds was the real innovation.

China Lake of that era was a classic Klein type-1 organization. It had every quality Klein listed; from use of contractors to rapid prototyping to lack of hierarchy. While there were bosses, and a genius in William McClean on the top, there was a decided lack of hierarchy. Engineers didn’t lord it over technician-slaves: engineers and technicians worked side by side, fiddling with with electronics and machine tools. It was recognized that engineers had skills and perspectives that wouldn’t occur to technicians, but it was also recognized that genius isn’t restricted to people whose ass warmed a chair in a university for a few years. Many of the technicians solved show-stopper problems and their contributions were respected and recognized and they were promoted accordingly. Another characteristic; there were basically no paper managers: technical leadership was everything. The entire effort was run like a pirate ship; funds were taken as booty from other projects. There were formal managerial structures as there are in any large organization, but there was also an informal hierarchy and rules that were more important and which were enforced by Bill McLean and his lieutenants. Bureaucrats were incapable of running the thing: on paper it didn’t really exist.

There were numerous stories of Bill McLean showing up on Friday night and working with a team until the following Monday on a problem. It sounds horrible; the big boss showing up on Friday night to shepherd a problem to solution, but … he stayed with the men, manning the soldering iron and so on. This is actually good for morale; adds a sense of urgency and shared suffering. All the best managers lead from the front on technology projects and otherwise, and you see good ones doing this all the time. Speaking of shared suffering; during the most productive era, everyone lived on base in shitty barracks. While there was after work social life; it was entirely with coworkers at China Lake. This level of social intensity solved lots of problems, and nobody was miserably socially isolated in the suburbs, or rotting in a long commute. This suggests something unpleasant about remote organizations: if you stop to think about it, most startups stop innovating when they move out of the garage. This might be OK if you don’t need to innovate after the original insights, but if you must remain a type-1 company (say, for trading a rapidly changing market), you probably want to put everyone in one place.

The lack of hierarchy in type-1 organizations bled over in other ways. If you’re building an air-to-air missile, it’s obvious (to me anyway) you need to work with pilots. It’s less obvious to modern twerps, you also need to work with the guys bolting the missiles to the planes. The pilots all had strong engineering background, and went on to do great things later; names like Wally Schirra, Tom Moorer, Tom McElmurry. Less known, but arguably more important were the friendships forged by small gestures from the China Lake guys bringing aircraft carrier technicians tools and so on. The little people have much to teach the great and the powerful (and the merely overeducated). You see this sort of thing with many successful and innovative firms; from early Ford to Edwards Demming showing the Japanese they have to listen to the peasants on the assembly line. It was more widely known and accepted pre-1950s as we had great examples of uneducated inventors like Edison to remind us that “experts” were overrated; the rise of managerialism eclipsed this knowledge. There’s the more workaday result of all this; it is insanely good for morale when end-users discuss problems and solutions with the people tasked with solving them.

The project was customer oriented, but bureaucratic customers didn’t dictate design; aka nobody asked for the sidewinder. As McLean put it “I think that a lot of the most interesting and novel solutions come when you don’t have a definite specification.” The Navy, aka the naval bureaucracy who funded it, were not consulted at all. The sailors and pilots who would use the things; they were consulted and their feedback was considered crucial, but even they didn’t exactly guide the design. It was known that such a thing as an IR air to air missile was desirable, and it was the job of the sidewinder team at China Lake to deliver one which worked. Even later in the game when the project became official, the change orders would be done as an end run around the Naval bureaucracy to solve real problems rather than imagined nonsense thought up by a paper pushing dipshit with fruit salad on his chest. I think this was absolutely crucial. Great innovation centers all did this: the U-2 and SR-71 developed by the Skunk Works weren’t designed to specific specifications. Same with the Manhattan project and both US and Soviet space programs in their innovative stages. They were simply built using the best possible path towards hitting a general mark.

Bureaucracies dictating specific crap will always include a patridge in a pear tree and you end up with nonsense science fiction garbage like the F111 or F35; planes which are good for absolutely nothing beyond dropping expensive bombs on cavemen: something a biplane could achieve more efficiently. For innovation; set goals for a smallish team, supply them with barely sufficient money, preferably cadged from non-innovative research groups and get out of the way. You might not get the thing you want, but you’re more likely to get something that actually works, possibly better than the thing you thought you wanted.

Countless videos like this of bureaucratic designed missiles you never heard of missing

One of the obvious reasons for success: the Sidewinder used various rapid prototyping techniques. One of the early ones was an old SCR-584 radar-mount pedestal which was used for IR tracking head development. You could bolt a new idea to it, see if it tracked the correct things, or was distracted by cloud cover, or if you fucked up the servo mechanism or your electronics broke something. Fast and cheap prototypes lead to rapid development. This is true across all fields, and though it is little appreciated in current year of FEA CAD developed atrocities,  this the same idea as “fail fast” from software development mapped back to the world of matter. There is some dim awareness of this in military circles with NGAD, but I have my doubts as to whether they actually understand this in their proverbial bones.

McLean also wouldn’t let engineers sperg out too long on a Platonic solution to a problem; you identify the crucial pieces you don’t know how to do, set in motion multiple groups to solve them and get multiple prototypes done and test for performance versus each other. McLean was trained as a physicist in a golden era when everyone knew the theorists were monkeys; everything important was decided by experiment. You’d rough the math out, then try experiments. All paper (and slide-rule/computer) calculations leave things out, and those things are often what drives performance. Rather than nerding out too much on mathematical models: just build a prototype and test it. Again, if it was a mission critical unsolved piece, like the tracking-head, multiple competing teams would be set in motion and even maintained late in the game: that way you’re less likely to be boxed in by over-committing to a design which later proves unsuitable, or prone to some un-thought-of weakness that shows up later in the development process.

McLean favored the simplest possible solution; also “don’t solve problems you don’t have to solve.” Too often on R&D projects people engage in yak-shaving and bike-shedding on all manner of non-critical path problems. You see this in spades with modern American weapons development; completely irrelevant or simply solved subsystems are festooned with electronics and complexity. You also see this all the time in software development. I have always hated this when I see it and kill it whenever I am able.

Speaking of software development: there wasn’t any. No computer was used at any point in the early development and successful deployment of the sidewinder. Literally every room in China Lake was a laboratory and workshop involving bits of actual matter. There were no carpets on the floors. Old timers at China Lake attributed the downfall of the place to the arrival of computers and carpets. There is something to this: for myself, if I sit in front of the damn computer too long, my brain ossifies into repetitive patterns. Sometimes those patterns are great for grinding something out, but more often, what I really need is a walk, an interrupt; maybe fiddling with some paints or my machine tools or barbells or anything else using different circuits in the brain but the ones connecting eyes to brain to keyboard/mouse. Most code monkeys interrupt themselves with slack or email or social media: this is probably the worst thing you could do. For myself the effect is so large; one of my tricks is I actually switch offices when I get stale: go to a coffee shop, go to my library, sit in the Eames instead of in front of the “big board,” grab the laptop and go sit outside. Sitting in same place doing same thing, you’re going to have same thoughts.

This is a very old problem which even religious monasteries recognized. People get weird if they sit still for too long in one place, and not weird in a good way. Chinese Buddhist monasteries invented the ultimate take you out of your head and into the world technique: boxing and martial arts. Zen Buddhists have all kinds of variants on this, including the master simply clubbing the shit out of you. Saint Benedict invented the concept of ora et labora; prayer and work. Before this, many Christian monks would do weird stuff like sit on a log and pray all day; the eremitic tradition. The Benedictines and their descendants restored Western Civilization after the Roman collapse by combining contemplation with action in the world of matter; the cenobitic tradition. Innovators outside of a few spergs doing math proofs are entirely cenobitic. They engage with each other and the wider world. I’d go so far to say that the modest successes of agile are about 90% attributable to the stand up meeting simply because it forces addle-pated software goobers to physically move. I should create a software development methodology which includes brewing beer or making birdhouses in wood shop or something: I guarantee this will not only create extra revenue for cash-poor startups, it will double usable software output. Maybe we’ll get more innovation in birdhouses or beer brewing, both of which could use some help in current year (IPA makers have ruined everything). FWIIW I have seen very successful startups deal with this problem by only hiring practicing athletes for management. Not only does it somewhat solve the mind-body problem, they’re usually better at motivating people and teamwork as well.

Speaking further of computer dudes, I’m pretty sure the Google 20% idea came from China Lake of this era, as it was in place there. People were encouraged to have hobbies. The hobbies often fed back into the project, since in those days hobbies were entirely physical in nature; people would make things. The place was even mocked for it, as “Bill McLean’s hobby shop.” I want my next company to be compared to a hobby shop; this is a sign you’re winning. It’s how I pick my hobbies too: the less sitting in front of the computer the better.

One of my key takeaways from this book was that “becoming an expert” in a topic is the time of maximum creativity. This is one of those things which I had never heard articulated before but which is almost self evidently true once it is pointed out. While you’re trying to master something, you’re using all your resources to come to grips with it. You’re drawing upon mental faculties which may or may not be useful for your efforts; trying things, discarding them, like a kid learning engineering with the erector set. You’re thinking outside the box because there is, as of yet, no box to think outside of: you’re drawing on all of your military and naval power. Once you’re an expert, the creative stage is over; you’re an expert now. You may push a subject forward as an expert, but you’re more likely to adhere to established conventions and ways of doing things rather than thinking creatively. McLean thought humans were better while they were in the process of becoming something else; took a quote from Locke “you are now what you are in the process of becoming” as his motto. One hack I’ve seen in continually innovative companies recognizing this dynamic: use a weird programming language nobody knows.

McLean didn’t come up with all this in a vacuum; he studied industrial psychology and the successes of the OSRD during WW-2. Kelly Johnson’s managerial innovations all came from the same place McLean got them, with his own personal touch. Same story with both Soviet and US space programs in their most innovative times (long ago). It was a sort of peacetime wartime mentality. People were vested in the result, and everyone was excited about building something new. The OSRD and its legacy are something that ought to be studied more carefully and used as a template for new projects; something I plan on going into more later.

http://www.donhollway.com/foxtwo/

http://www.ausairpower.net/TE-Sidewinder-94.html

https://www.sciencedirect.com/science/article/abs/pii/S0263786313001567

https://www.sciencedirect.com/science/article/abs/pii/S0263786313001567

How to squelch genius according to Bill McLean:

1. Coordinate work carefully to avoid duplication: Everything new can be made to look like something we have done before, or are now doing.

2. Keep the check reins tight; define mission clearly; follow regulations: Nothing very new will ever get a chance to be inserted.

3. Concentrate on planning and scheduling, and insist on meeting time scales: New, interesting ideas may not work and always need extra time.

4. Ensure full output by rigorous adherence to scheduled workday: Don’t be late. The creative man sometimes remembers his new ideas, but delay in working on them helps to dissipate them.

5. Insist that all plans go through at least three review levels before starting work  Review weeds out and filters innovation. More levels will do it faster, but three is adequate, particularly if they are protected from exposure to the enthusiasm of innovator. Insist on only written proposals.

6. Optimize each component to ensure that each, separately, be as near perfect as possible: This leads to a wealth of “sacred” specifications which will be supported in the mind of the creative man by the early “believe teacher” training. He will the reject any pressure to depart from his specifications.

7. Centralize as many functions as possible: This creates more review levels and cuts down on direct contact between people.

8. Strive to avoid mistakes: This increases the filter action of reviews.

9. Strive for a stable, successful productive organization: This decreases the need for change and justifies the opposition to it

 

More rare McLean:

…the weapon system acquisition process is now dangerously inadequate because
1. We have forgotten the importance of a senior designer to guide development of each system
2. The need for development prototypes to demonstrate technical feasibility before the writing of military requirements has been ignored;
3. The total acquisition process reward the design of complex and expensive systems and penalize work on simpler, and therefore, less expensive ones
4. The budgetary process, I believe, has become ritual with no content, which is occupying more the 50 percent of the productive time of our best technical people at the laboratory level and the full time of large numbers of technical people in Washington.