Foreword

“And what happens if the engineering firm doesn’t turn it around?” David Guttman asked me on our walk around his Los Feliz neighborhood.

“Well, then begins operation David, save us, save us!” I answered.

Just four months later, I texted David “Save us, save us!” and that is how David came to run the engineering function at my fourth company, Outlier.org. From a standing start, he hired a team, and in a few short months turned around the disaster the prior engineering company had left us and got us to launch day. This is also how I was introduced to the output of the philosophy you are about to read in The Superstruct Manifesto.

This was not the first time I’d come to David for help. We met years ago at an engineer/artist meetup he runs called Spec.la. It has a simple rule: the first time you attend, you have to present one of your creations that doesn’t involve your day job. This simple filter meant that the meetup was tuned specifically to people who would enjoy being around each other. It wasn’t tuned to the largest projects, the most daring, or even the most serious. Everyone showed up, from SpaceX employees creating fantastic augmented reality games to a mechatronic dressmaker, experiential artists, an urban coyote behavior expert, and even me with my electromagnetic field detector that plugged into a smartphone. The gathering was filtered for pure doers, not talkers, and was my favorite monthly activity in Los Angeles before I moved to San Francisco to start MasterClass with my co-founder. David’s simple filter is a good example of the way he thinks about maximizing systems of people.

At MasterClass, I held the strange role of being a co-founder as well as both the CTO and Creative Director for the company. My degrees are in Computer Science and Mass Communication, and my first company was highly technical, an industrial robotics company I sold at 24. It was stressful. Errors with a 2,400-pound robot wielding a diamond saw and a waterjet cutter meant that a single mistake could make a human lose to a robot in the worst possible way. Engineering on critical real-time robot systems and engineering at a large scalable video-serving company is fundamentally different. Especially if on the latter you’re trying to fix the CSS on a mobile build for investors in between asking Christina Aguilera questions on camera. I’ve built apps, video games, run teams of various sizes, put in my time on the product side, and have been programming since I was five years old. That experience gives me perspective on the philosophy of The Superstruct Manifesto as a classic engineering CTO, a more modern web app CTO, and a consumer of the output of a department created by David and this philosophy. And I can say that David’s approach would work for any and all of these applications.

Many engineering departments refuse to take the occasionally bitter pill of pragmatism that ultimately leads to the philosophy of The Superstruct Manifesto. It urges you to throw out anything that is tradition for the sake of being tradition, to challenge your status quo bias. The clear-headed and logical approach will ultimately save you a lot of time however you interact with an engineering department. I remember being asked at MasterClass if we had the smartest engineering department in the valley. That struck me as an extraordinarily uninformed question. I believe my answer was rather gracious, but intelligence is far too broad of a metric and produces an ineffective real-world signal on its own (see Chapter 2).

Similarly, David’s psychology background pokes through in Chapter 4: “Do not tell your dev what the estimate should be. If a dev does not feel like they made the estimate, they will not own it.” This may seem obvious, but we’ve all been tempted to tell devs that they should finish in half the time/they have to finish in half the time/that I used to be a dev too and I could do it half the time. I’d file this portion of David’s philosophy under “annoying but correct.” It’s the harder way to do something for a manager, for a founder working with an engineering department, for anyone working with people who build things, but it’s a more effective one.

This manifesto will become required reading for anyone I hire that works with engineering teams. I’d urge anyone else to do the same. There is an extraordinary amount of compressed wisdom and experience about working with the curious psyches of developers and ways to save yourself a lot of pain. It shouldn’t be taken as gospel, and that’s a core part of the philosophy itself: doing things just because they’re the way it’s been done is no reason to do them.

David’s experience goes well beyond engineering and product. Much to my own detriment, I have not taken his advice on occasion, only to come back around a year later and find that I could’ve saved myself a lot of time. One particular example of this was when Outlier.org moved to fully remote. David had a punch list of best practices, given that he’d run remote teams for a long time. One big suggestion he made was to default all conversations to a public channel, if possible, instead of DMs or small groups, that way everyone could be informed and information didn’t get siloed. We only half-heartedly attempted this for the first year of being remote and stuck to our DMs and silos in most departments. Sure enough, we had some information asymmetries that caused unnecessary thrash in some projects, and we came back around to defaulting to public channels. Simple, but powerful. Because of our increased coordination, we were able to launch three associate degrees with Golden Gate University in just six months, not something we would’ve considered possible with our old methodologies.

Regardless of your role in a company, if you interact with engineering departments, or interact with those who do, you should read this book. Read it in parts, out of order, and realistically, a couple times. It is easy to fall into the well-trod grooves of tradition, and David’s Superstruct Manifesto will extract you from those deep ruts and put you back in control of your engineering destiny.

Sincerely,

Aaron Rasmussen

Co-founder MasterClass, founder Outlier.org