Advice for the Founding Engineer, part 3
March 8, 2018
Engineering decisions made at the very early stages of a product’s life can have repercussions which extend far into the future. Making well-informed, thoughtful decisions is important.
In this series of posts I condense my advice on how to make the correct decisions as a founding engineer down into three maxims. In the first post in this series I introduced the first maxim - You’ll Never Know Less Than You Know Right Now. In the second post I covered maxim 2 - Optimize For Iteration. In this post I’ll cover my third and final maxim - “Boring Is Good”.
Maxim 3: Boring is good
Your goal as a startup engineer is to not use cool tech (despite the fact that there is likely no-one who’ll stop you from doing so). Your goal is to deliver a product rapidly on top of a nimble technical foundation which will allow rapid iteration (see Maxim #2). Established technology is more likely to get you there. Buying technology will get you there quicker than building it.
Buy what you can, build what you must.
Modern startups can achieve so much with so little because we can now buy capabilities off the shelf that previously we’d have had to build by hand. Instead of racking up servers and configuring networking gear we now click a few buttons in AWS (or even better run a declarative infrastructure-as-code tool like Terraform). When you’re dealing with an extremely limited resource - engineering time - it only makes sense to build something yourself if you really have to. This boils down to only building things if they are your product differentiator - and even then you are usually “building” by assembling open-source or SaaS capabilities.
If you’re building something that isn’t unique to your product, challenge yourself as to why. Why are you building user login when you could use Auth0 or Okta? Why are you hand-rolling your marketing pages as a Django app when you could be using a Wordpress installation? Why are you operating a Kubernetes cluster when you could be deploying on Heroku? Why are you managing your own databases when you could be using a hosted DB-as-a-Service? Sometimes there are good reasons to build, but when we are really honest with ourselves, often we’re building rather than buying because it’s fun to play with shiny toys. One way to keep yourself honest is to consider the opportunity cost - ask yourself what more product-differentiating feature you could be working on if you were to buy the thing you’re about to start building.
Choose boring tech
(with due credit to Dan McKinley)
Cutting-edge technology will be buggier with less community support and a weaker ecosystem of supporting libraries and frameworks. How will you feel when explaining that rather than building a key feature for your MVP you’ve instead spent the last 4 days implementing the first OAuth integration in the shiny new web framework you picked. Or even worse, you’ve spent the last 6 days playing whack-a-mole fixing bugs in the existing OAuth integration that has only seen production usage in 4 other apps so far?
Hint: you should feel bad about a situation like that - unless your startup is innovating in the SSO space your OAuth implementation is very likely an uninteresting-but-necessary requirement that should be achieved in as safe, cheap and boring a way as possible.
As humans - perhaps particularly as engineers - our cognitive biases pull us towards shiny new things. For example Availability heuristic bias may lead you to think that the exciting new thing you just read about on Hacker News solves all of the annoying pain points of whatever tech incumbent it aims to overthrow, when actually it’s just that the new thing hasn’t been around long enough to accumulate evidence of its very own annoying pain points.
Consider using shiny technology only where it will truly contribute to your product differentiation. If your entire startup hypothesis is centered around using deep AI to disrupt the dog grooming industry then maybe picking up Tensor Flow makes sense, as a way to build out that deep AI. However, keep in mind that even if you’re doing deep technical innovation around your differentiator you still don’t need to use shiny tech everywhere. The user signup flow for your deep learning dog grooming app can still be built out as a vanilla Rails app.
The other reason to favor cutting-edge tech is when it will truly allow you to iterate faster - this has true value at an early stage startup. Perhaps you’re convinced that building your mobile app in React Native will get you to market quicker, or allow you to deliver new releases quicker than a native Swift app. In that case, go for it. But again, keep your biases in check. Play devil’s advocate for a moment and sketch out what a solution would look like in a more established technology and whether it would truly lead to slower delivery.
Look beyond your experience
Don’t forget to be humble and look outside the technology ecosystem you’re comfortable with when assessing whether you should build something or buy it. When Twitter started working on breaking apart their monolithic Rails system one of the first things they did was introduce asynchronous queues between processes - a very sound scaling decision. Unfortunately, the Ruby ecosystem didn’t have any great distributed queues at the time, and so Twitter engineers decided to implement their own using the technology they were comfortable with - Ruby. Hindsight being 20-20, they might have endured a few less fail whales if they had looked hard at existing distributed messaging systems from outside the Ruby ecosystem.
If you need to add full-text search to your Golang-based product, consider ElasticSearch before you start building your own inverted search index in Golang. If your Scala product needs a rich web client, consider React and ES6 before you start building a cool UI framework in Scala.js.
Great startup engineers ship product, not tech
This all comes back to the same key idea - your job as a founding engineer is in enabling fast, predictable delivery of product features. The only time most people care about the tech behind a product is when it breaks. Focus on technology that will fade into the background, allowing you to focus on building great product.