By Mon-Chaio Lo
My name is Mon-Chaio Lo and I help leaders build exceptional and differentiated engineering organizations. I’ve honed my craft through 20+ years of building teams at startups (seed to series E) and the largest tech companies in the world (Microsoft, Uber, Meta). These days, I’m coaching engineering leaders through my podcast (https://thettlpodcast.com/) and my consulting work.
When investors look to fund or companies look to acquire a technical startup, they often partner with people like me to do what’s called a technical due diligence investigation. The goal is to ensure that there are no red flags in the technology component of the startup, both in the technical people and in the technical product.
The most common issues I’ve encountered that lead to either non-funding or less than full funding from investors and M&A activities can be broken down into two categories: fragility and scale.
People, processes, and software may be working now, but what are the odds that they will continue to work into the future? This is the essence of fragility. Can one single nudge break down your entire technical operation or is it resilient to even the most violent of earthquakes?
Here are some of the most common components I’ve cited in my reports as being too fragile:
Engineering organizations, especially ones that run lean, often think that assigning different components to different engineers and having them work in parallel is the way to increase efficiency. While there is a small nugget of truth there (though less than you might think), a major downside to this is knowledge silos.
The more core information that is locked up in a single person, the lower the lottery number (i.e. the number of people that have to quit after winning the lottery for your organization to be in dire straits), and the larger the fragility risk. And don’t think that documentation is the answer. Less than 10% of the documentation I see meets the up-to-date and quality bar for me to consider it suitable to prevent lottery number fragility.
Startups often take shortcuts to move fast, and one of the most common that I see is writing fragile code. This manifests itself as code that only works in the most basic of use cases, code that is written in a way that makes it difficult to change, and code that has no or insufficiently rigorous automated tests.
I am a big proponent of YAGNI (ya’ ain’t gonna need it), so I’m not advising startups to write lunar lander-style mission-critical code, with all possible scenarios covered rigorously. However, many startups I see are too far down the other end of the spectrum. I agree that shortcuts should be taken to move fast, but there are far, far better shortcuts to take than the time saved through writing fragile code.
These are a couple of real-life examples I’ve encountered of overly simplistic processes that are doomed to failure from design.