in Information Technology

The Nudist on the Late Shift, or what we can learn from the last great tech bubble

This is another in the series of technology management, entrepreneurship, and business book reviews that I’m doing.

Po Bronson has always been one of my favorite journalists if for no other reason than that his book, What Should I Do With My Life? was instrumental in setting in motion my career direction (minus a brief stopover in journalism-land myself). Bronson wrote that book after he’d been a reporter for Wired in Silicon Valley through the 1990’s. After the bubble burst and he became disillusioned with tech and startup culture, he took his career in a different direction and now writes commentary about the evolution of American society.

Bronson’s The Nudist on the Late Shift And Other True Tales of Silicon Valley was published in 1999, right before the end of the dot-com bubble. Knowing how the story ended up gives us the ability to look more broadly at the tales told here and assess them critically. For example, if we had hypothetically read this book in 1998, could we have predicted the bursting of the bubble? (Probably.) Are we in a bubble now, and will it burst again? (Possibly-to-probably.) But more importantly: what forces underlie the industry, and how does one remain optimistic in the face of so many actors who aren’t primarily motivated by the tech itself?

Raise your hand if you had a dialup account through these folks.

Raise your hand if you had a dialup account through these folks.

If you can, cast your mind back to 1995 or 1996, assuming you were old enough to be on the Internet back in the day. Despite the fact that network access speeds were thousands of times slower (being that we were all on dial-up), and that the names of the leading technology companies were (mostly) different — Yahoo! is one exception, at least for now — the 1990’s Silicon Valley that Bronson describes in this book is only imperceptibly different than today’s. For instance, the physical architecture is no different. Like Bronson, I too was astonished when I finally visited the Valley in-person during my interview process at Google. One expects to encounter some marker indicating that you have arrived in the center of the greatest hotbed of innovation in the last several hundred years. Rather, for all the creativity that the tech titans exhibit externally, Silicon Valley is but a endless parade of nearly-identical, low-slung office buildings with surrounded by sprawling parking lots. America’s smartest programmers basically work at IniTech. The companies themselves, and the engineers that work for them, appear to differ from today’s in name only, with lofty expectations about “changing the world” and doing revolutionary things. “I’m contributing to something that has historical implications,” one says. Such a quote is laughable only in the rear view mirror because in 1998, this engineer worked for InfoSeek. Who remembers what that company did, let alone what happened to it? (Ultimately purchased by Disney, it was merged with go.com and shut down.) But in 2015, if those same words came out of the mouths of, say, an engineer at Docker, Inc., we probably wouldn’t laugh.

On and on the parallels march. What’s fascinating is not that certain companies failed, but that the ecosystem firms largely didn’t. Kleiner Perkins Caufield Byers, for example, not portrayed particularly kindly in this book, is still around, as is Draper Fisher Jurvetson (DFJ), which happens to now be one of Chef’s investors. So, too, is R.R. Donnelley, the printing company that churned out IPO prospectuses. How have all these firms outlasted the tech startups they were involved in? It starts to become impossible not to think about technology startups as just a long game by the folks who really control the world: venture capitalists, lawyers, and bankers. There’s a yawning gap between an engineer who wants to create something that has “historical implications” and the lens through which the folks who hold the money see tech companies: a way, in aggregate, to deploy capital from lower-performing asset classes to higher-performing asset classes. As long as 1 out of 100 startups IPOs, that’s enough of a return to pay back the LPs in a fund, and the cycle starts anew. (Things get even harder once you IPO, since the Street is now making decisions about you by simply comparing your growth against totally unrelated sectors like manufacturing or retail.)

Once you understand the entire machine (and realize it hasn’t changed much from the 90’s), it’s easy to become jaded. I think it’s possible to not be cynical as long as you’re realistic. Here’s how I look at the situation and why I still keep going to work every day:

  1. First, unless you’re a founder or a C-level executive with a large chunk of options, you’re unlikely to make off like a bandit even in the improbable situation that your company has a successful exit. So options are properly thought of as icing on the cake.
  2. Understand the low probability of a successful exit and take your executives’ dreamy predictions with a grain of salt. They are trying to motivate the troops, as they should (especially the sales force), but the historical record shows that it is very, very difficult to IPO, and even more difficult to become a corporation that lasts generations.
  3. Live in the present & focus on the product. Concentrating less on lofty, hypothetical outcomes, and more on simply running the improvement kata to incrementally make a better product is much more fulfilling.

To emphasize the last point: my manager, Chef’s VP of Product Alex Ethier, recently showed this “equation”:

idea * product * team * execution * luck = success

luck = rand(0, 10000)

As engineers, we can’t really control any of external factors, except to know that they are there and to notionally keep them in mind while making product decisions. In other words, don’t ship shit, but also don’t over-optimize code or design as though it’s going to be around in five or ten years. Along these lines, in a future post, I’ll be addressing the topic of “what exactly does product management do for engineers?” — stay tuned for that.