One of the most critical questions for early stage startup CTOs: Given a small team of very talented software engineers trying to find product market fit, how much technical debt should be deliberately introduced for the sake of quicker experimentation?
-
-
If your company is an API or PaaS then your customers consume then you carry the burden of bugs forever as unintended features. Bugs that explode in prod break your customers apps which means someone is pissed. Bugs that subtly deviate from intended behavior are tricky to change
Show this thread -
Counter intuitively though this means that your incentive as an API/PaaS product is to explode as quickly as possible if any invariant isn't as expected. Better a quick fix than a maintenance burden forever
Show this thread -
# of customers you have modulates the expected cost of a bug. If you have 0 customers using your product then a bug means nothing. If you have thousands using it every second then each bug is riskier. This is part of why startups have rate of iteration advantage over big cos
Show this thread -
If your product is web only but you're branching into mobile then things are about to get harder. Now you have to manage web being on one version of an internal API while mobile may be on another.
Show this thread -
Blockchain (specifically Ethereum) products are interesting. On the one hand you have these critical smart contracts where bugs can cost you millions. You also have frontends for interacting with the blockchain. You've got API/PaaS conservatism and SaaS freedom in one company!
Show this thread -
I have this conspiracy theory that a team of productive junior devs with ~1 year of experience might be better for early stage startup iteration than a team of grizzled senior devs, at least for SaaS. It is easier to follow 80/20 rule when you're not good enough to do 100/0.
Show this thread -
"How aware is your team of the corners they're cutting?" is important. If you're cutting corners, your bet should likely be something like "we're going to have to clean this up in a year if this is the product that takes off." Calculating incorrectly can screw you next month.
Show this thread -
You also mainly want to optimize for moving quickly enough that you miss little things, not big things. If there is a hole that takes a day to patch in the product then thats way worse. Big things mean you have to rollback and fix so that your app isn't just broken for a day.
Show this thread -
Also, I specifically framed the original question as "how much deliberate tech debt should a highly skilled team aim for" because it isn't a strategy to have an unskilled team role out product tech debt because they *can't not*. Thats just gambling
Show this thread -
If some of your team members just want to build high quality software then you're not just trading in tech debt, you're spending employee morale. Ideally you get them more aligned with the startup's mission so that they appreciate the process.
Show this thread -
Similarly though, some people love shipping things out once the happy path works and they don't want to sit around and discuss details. Great early on but can explode when you need to slow down and improve stability. This person will likely own a lot of code so losing them sucks
Show this thread -
The question of "how far off are we from product market fit" is fundamental because it determines all of these considerations and also captures many sensitive questions. How much do current vs. future customers matter? Is all of this work likely for nothing, in a way?
Show this thread -
Fundamentally, the questions are: • How much does a bug actually matter? • How likely is it that this product/feature is around in a year? Two? Your job as CTO is to decide what the answers are, convince your team of that, motivate them, monitor, and adjust as needed.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.