I just finished reading The CIA’s Greatest Covert Operation: Inside the Daring Mission to Recover a Nuclear-armed Soviet Sub. I found it on the new non-fiction rack at the library, and although I had followed the evolving story of the Huges Glomar Explorer with interest for years (especially since I had long wondered what that strange barge in Redwood City was for), I had not yet found anything about the project that satisfied my desire for much greater detail about how and why. And frankly, anything that even obliquely touches on the exploits of John Piña Craven instantly gets my attention.
However, I quickly found this book to be an excellent example of the kind of book in another field that innovators should read. It describes in great detail how a team of people contemplated, designed, built, and mostly pulled off a monumental task nearly everyone said was impossible. It shows how different personalities kept the project going, yet perhaps also contributed to its failures.
It highlights everything bad when you have too many different teams that don’t talk to each other and test the interoperability of their systems before integration. More than anything, it shows the dangers of compartmentalization and not telling everyone building components exactly how they’re going to be used.
It’s not often that you get to read a story this detailed about clandestine CIA operations, and aside from that trait, there are several remarkable aspects of this book.
First, that it was so well-written. The author, David Sharp, was a key participant and technical manager in the design and operation of the entire project. For an engineer (who completed and defended a dissertation during the project), such good writing and story-telling is unusual. And for him to write well enough to earn the high accolades from the critics and authors featured on the back of the dust jacket is more than a feather in his cap.
Second, within the limits of the CIA redaction, the book is surprisingly open about all aspects of the failures. And in that lies the true value of the book. Today’s technology, both civilian and military, is littered with the carcasses of spectacular hardware, software, and integration failures.
All too often, the tendency is to cover failures up, so as to not embarrass the guilty. But our best knowledge comes from failure, and the postmortem analysis. Sharp is very open and specific about the many failures, and by the end of the book, I was quite convinced that had President Ford not canceled the second attempt in 1975—one week from sailing—that they would have succeeded in recovering the rest of the sub, and with much less drama.
Many of the failures remind me of those that plagued the Apollo project. For instance, the drill-rig–like system and its pipe-handling equipment had never been tested prior to sea trials, because the rig was built on the east coast, while the pipe was built on the west coast.
Perhaps the biggest failure was described near the front of the book, where a proposal to use deep-diving submersibles, explosives, and other relatively small equipment to effect the salvage was deep-sixed by one particular personality. I’ve seen this type of obfuscation before. Hiding this scheme from the higher-up decision makers deprives them of needed information, and harms the overall effort. This is, perhaps, the biggest lesson the book teaches, but you must read the whole story to fully grasp the importance of this fundamental, yet ever-so frequent error in information dissemination.
Anyone who builds anything of any complexity (read: anything more complex than a shell script or wooden furniture) should carefully read this book, and look for similarities in the processes and personalities so eloquently described by Sharp.
There are many good lessons in this book, and should I ever get a chance to work with the author on any kind of technical project, I would jump aboard so quickly my feet might never touch the boarding plank.