What you can’t know about being a startup CTO
I have been an early part of three startups, so uh, yah — consider me “an expert”.
In the first, I was a junior programmer. I had no hand in decision making: not about the tech, not about the people, not about the culture. I wrote code and watched other people make… let’s say mostly bad decisions. If you’re counting, this is already the second logical misstep in this article, so prepare yourselves to doubt me. As it turns out, evaluating other people’s past decisions using my present knowledge is counter-productive. Additionally, and I didn’t know this at the time, but not making decisions is much easier than making decisions.
After numerous other gigs, where I started to unlearn what I was doing, I left the cushy employ of a respected (and profitable) company to co-found a startup as CTO. This title carries with it some serious decision making. Strangely enough, not making a decision when you’re the head cheese is actually the same thing as making a decision.
This first CTO gig was for a self-made Microsoft Mixed Reality partner — this is what happens when you are doing cooler things with the HoloLens than Microsoft is. A number of years later, I now find myself as CTO again, this time of an award winning social mobile game studio. This must mean I’m incredible at decision making.
I need to pause for a breather — geeze, stop reading so fast. Inflating my head to near bursting has left me a tad winded.
Imagine the author (me) now approaching our protagonist (also me), not unlike a certain daffy cartoon duck might carefully but excitedly tiptoe up to a house-sized water balloon, clutching a sharp pin. This entire exposition about “decision making” is a cleverly disguised exercise in long-form survivorship bias. *POP*.
I assume I know what I’m talking about simply because of a small modicum of success. I assume the things that I am about to say are true but due to how reality works (as I will further elucidate below), I could just as easily be some rando that has fallen by chance into circumstances a few σ beyond the average.
There are a staggering number of reasons for me (and you) to discard my “tried and true” wisdom.
Aristotle, one of the greatest minds of all history (I would say that our brains are probably not on the same level), observing the natural progression of birds through the seasons, concluded not that there were other parts of the world which birds may be traveling from, but that birds transformed themselves into different species throughout the year. Perhaps my confidence in navigating technology and teams is a similar mischaracterization of the available, scant evidence.
But I’m getting behind of myself — let’s talk about the future.
Tech trajectory
The challenge unique to a “startup CTO” (as opposed to other startup leadership roles) is making technical decisions for today that intersect with technology of the future, and all the while probably actually writing the tech and trying to keep that same tech intact. In other words, you need to decide on a starting point, you need to decide on a few points in the future, and then you need to decide how to hit them. This is called calculating a trajectory and gee-wiz did you see how many times I used the word “decide”? Exhausting.
You can see where I’m going with this. The Startup CTO is dodging logical fallacies right and left — what is correlation without causation? If I’m to set my eyes on the future, I’ve got to understand when I’m actually right, when it doesn’t matter if I’m right, and hardest of all — when I’ve just been lucky.
At the beginning of a startup’s life, your tech is a satellite orbiting a perfectly spherical planet. Your calculations are the easiest they are ever going to be. “Any old tech” will probably do, at first. I know, this is not what you want to hear as a “tech leader with unique and valuable insight,” but a dartboard is all you need to determine a starting point for your tech, because we are forced to consider that, just perhaps, initial tech choices don’t matter at all.
“Why — this is heresy! We are Pythagoreans! All hail the Integer!”
Unfortunately, we are confronted with a multitude of irrationals. Google still somehow runs Java on mobile hardware with, let’s say, decent success. Zynga built an empire on… Flash? And Facebook, which I would characterize as a “successful startup”, (in)famously pushed bad technology choices through the eye of a needle.
I know what you’re thinking. “We can’t all violate the privacy of our fellow students and successfully steal IP to reach breakout success.” This is true, but also: (and this is a nugget you should probably highlight) people are smart and figure stuff out. I am near-completely-convinced that pretty much any software can evolve into any other, if you make the right hires and roll up your sleeves. I’m currently writing this article in a web browser. Do you realize what those started out like?
In terms of our trajectory, the starting tech is of almost no consequence. However, the workflow is of immense importance.
Favor iteration over correctness.
This assertion is in the spirit of Gabriel’s “Worse is Better” style of design, which, if you’ve not read it, is what you should be reading instead of this drivel.
Let me give an example.
In backend development, it is common to setup virtual machines or build/dev/prod Docker images so that everyone is using a development environment that is as close as possible to the production environment. This is an excellent goal, but often what I see along the way is increased development friction. This is more deadly to a startup than choosing “the wrong technology”. If you add five seconds to your iterative cycle, you’ve just shot yourself in the foot. Think about multiplying that five seconds by the hundred times per day that you need to do it, and then tack on another multiplier: the number of engineers you’re going to hire. Favoring iteration over correctness, particularly at the beginning of a company’s life means increased velocity for the entire duration of your company.
Correctness is for the birds. It can either be fixed later or perhaps more likely, doesn’t need to be fixed at all.
Future Points
It’s probably hard to recall, because of all the mad wisdom I’ve been dropping, but we were using the metaphor of a trajectory — and we have so far only talked about the starting point! Good lord… Okay what’s next… We need to decide on a point in the future to hit. But how do we choose this future point?
You see through your CTOscope a distant planet: a very important planet that you, with your finely tuned insight (HAH!), perceive to be the next planet humans will be traveling to, and you need to both survive the trip and setup your space lemonade stand so that when the first humans arrive you will already be there with a welcome table and franchise paperwork ready to sign: an unfair galactic advantage.
There are approaches to guessing the future. Probably the most popular one is simply making stuff up whenever you feel like it. Neil Stephenson gets to make wildly inaccurate statements about the future without any sort of accountability — but tech leaders, unfortunately, do not. We should probably do better than random chance.
In the book But What If We’re Wrong: Thinking About the Present As If It Were the Past, Chuck Klosterman evaluates this problem, not in terms of “trajectories” and “calculations” (*pushes up glasses*), but in terms of the arts (*pushes up glasses… even further?*). Let me rephrase the question of future tech with books:
Why is it that Homer is still being taught in high schools but Apuleis is not? It does not appear to be about the quality of work. Apuleis nailed it, in this ass’ humble opinion. And Virgil’s Aeneid is factually, empirically better than Homer’s Iliad (come at me).
From Klosterman:
The reason something becomes retrospectively significant in a far-flung future is detached from the reason it was significant at the time of its creation — and that’s almost always due to a recalibration of social idealogies that future generations will accept as normative.
Can we apply this to technology? Let me rephrase this another way. Have you seen Zoom’s share price?
This wasn’t because Zoom successfully read the stars and aimed for this endpoint. Just like the arts, technology is heavily reliant on guesswork, luck, and apparently, coronavirus.
Reading today’s tea-leaves to figure out our tomorrows is a bit of an odd notion. You’ve probably heard of the butterfly effect? In some ways, patting yourself on the back for tech conjectures that turn out to be true is not unlike high-fiving yourself for having successfully forecasted today’s weather three years ago. Have you really outdone the Universe and redefined meteorology or does randomness sometimes give you a false sense of your abilities?
This means that an accurate tech prediction, as it turns out, is usually luck-based, and in my humble opinion (THREE STARTUPS!!), that’s not a sure foundation on which to build a company. We need to adjust our thinking about how much we can know about this trajectory. We are taught by numerous outliers to believe in some distant, future utopia — have an unshakeable vision, they say— but it turns out that (*visibly grimaces*) “it’s all about the journey.”
How are we to engage the Unknowable?
Whoops, we’ve accidentally hit Metaphysics. Let’s go back down a rung.
How do we lead tech development without knowing where it’s going?
There we go, that’s a better question.
We need a better model for thinking about tech development when facing a cloudy future and, bad news friends: you may not like my proposal. Unfortunately, this entire article is simply a basis for shedding your confidence in predictions and instead, building technology according to the tired old expression that “the only constant is change”. Perhaps I should have just shared a link to a motivational poster in the intro. Then you’d be done reading already.
The model I tend to think about when building tech in a startup is one that has always dealt with an unknowable future: investment.
Wouldn’t it be great if I had put $1000 in Apple sometime in the 1990s? Of course, but the truth is, tech unicorns are outliers. They are not normal. Just look at the numbers:
Among all startups, companies … of a $1B+ valuation … are exceedingly rare, at 0.00006.
“So… you’re telling me there’s a chance…”
Trusting your financial future to this type of investment would be generally, very disappointing. This is why intelligent investors don’t do this. They use intelligent investment instruments, like index funds. In index fund is fancy way of not putting all your eggs in one basket. With an index fund, you may not have a shot at being one of those six in a billion that gets insane returns, you will be able to build something sustainable.
This same egg-related basket principle can be applied when building tech in a startup. It’s fairly common wisdom that at a startup you need to stick to as few different technologies as possible. This is for a few decent reasons. You won’t need to hire experts in say, five different programming languages. There will be less you have to learn, and with focus, your team can probably develop more proficiency in those specific technologies. This is not the index-fund approach. This approach is for the birds — a mistake for a number of even better reasons (THREE STARTUPS).
For starters, a diverse tech stack is a pragmatic, built-in way of bringing education into the set of core activities for your engineers. Hooray! Turns out, education is your best offense against an ever-changing tech landscape. You and your team need to learn things in disparate ecosystems that cross-pollinate ideas. I constantly learn approaches that are common knowledge in one domain but unheard of in another. It’s like engineers on different stacks never talk to each other. Growing an organization around proficiency in specific technologies is not nearly as powerful as growing an organization around proficiency in learning. With a company of learners, you can tackle any challenge.
In addition, using an array of diverse tech allows you to hedge your tech bets. Recall that when Flash died, entire studios had to retrain and retool at once. Companies that built their stack solely on Parse had to pivot, quickly, when Facebook acquired it. This happens constantly — thanks HockeyApp, GameSparks, and maybe even GitHub??? A diverse tech stack ensures your team is not taking these types of development hits.
Final thoughts
Hopefully I’ve succeeded in my goal of disparaging myself enough to prevent any reader from taking me seriously. This is unfortunate, as I really think I’m right about being wrong about everything. My final thought, my TLDR if you will, is that building a company around your guesses about the future of tech unwise. Instead, build a company around tech iteration and around tech education. With their powers combined, you may make something taboo in the startup world: sustainable.
