A Dive into Technical Due Diligence and Common Hurdles Impacting Investment

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.

‍

Fragility

‍

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:

‍

🧠 Silos and lottery number

‍

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.

‍

🔢 Code quality and automated tests

‍

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.

‍

🛠️ Optimistic processes

‍

• “Once requirements are signed off, development will proceed smoothly and we won’t have to waste time revisiting them.”
• “Every team simply documents their disaster recovery plan in the wiki and we’ll be set.”

These are a couple of real-life examples I’ve encountered of overly simplistic processes that are doomed to failure from design.

• Yes, startups should keep processes lightweight but there is such a thing as irresponsibility lightweight.
• Yes, changing requirements is one of the most expensive taxes a software team incurs and, yes, a command-and-control process for disaster recovery is expensive.

But pretending things that are likely to happen just won’t happen isn’t the way forward and leads to markedly increased organizational fragility.

‍

Scale

‍

Can the business continue to function effectively after doubling the number of engineers they employ? After increasing their customer base by 10x? After opening another engineering team offshore? These are all examples of questions around scale that investors frequently ask me to validate during the technical due diligence process.

‍

And red flags around scale often fall into one of these common categories:

‍

🏹 Tactics vs Strategy imbalance

‍

As organizations grow, leaders necessarily move further and further from the front-line work. Their future impact depends on how well they transition from pulling all the levers on the shop floor to cleaning grease traps and sharpening knives, i.e. the proactive removal of execution impediments.

‍

The latter job requires foresight, patience, and a less-is-more mindset, skillsets that are often not present or required during the helter-skelter early days of a startup. This doesn’t mean those leaders do not possess or cannot learn those skills, but when their work to date shows little evidence of that strategic mindset, it’s difficult to recommend that those same leaders will effectively helm a rapidly scaling organization.

‍

💻 Not-Invented-Here (NIH) syndrome

‍

Founder CEOs are often infatuated with the unique value their product brings to the world, as they should be. Founder CTOs are often infatuated with the unique technology they develop to enable the product. This latter mindset is a bit more dangerous. While it is not uncommon to see truly unique technological innovations developed in-house, more common are startups piecing together common existing technology in a unique way to solve the problem at hand.

‍

As companies grow and supported use cases multiply, their technology teams must scale with them by focusing their engineering efforts on their core tech differentiators and away from the more commoditized enablers of their system. Refusing to aggressively utilize off-the-shelf components, often because they fail to meet only the last 5-10% of the needed functionality, is an all-too-common cause of teams slowing to a crawl as they grow.

‍

🧭 Lack of leadership experience

‍

Leadership experience, like schooling, isn’t a magical harbinger of success. That being said, learning on the job is often a much slower way to scale versus having someone who already has the mental model and execution experience to back it up. One area where this commonly manifests is in hiring. Many startups I see start by hiring from their network, with limited or no formal processes to assess candidate skills.

‍

Often hires are made because the technical leader has already successfully worked with someone in the past or a trusted employee can vouch for a candidate’s skillset. This is a fantastic way to bootstrap a company but a poor way to scale as the company exhausts the people in its network.

‍

Furthermore, stumbles and missteps in creating a formal hiring process due to inexperience or incorrect mental models often torpedo an organization’s initial scaled hiring surge: they either hire the wrong people or find that it’s impossible to hire anyone. But beware! Successful past execution is only one part of being experienced - it also needs to be married to a mental model of leadership backed by larger sample sizes to give confidence in likely successful future execution as the company grows.

‍

The concepts of fragility and scale are not exclusive to companies looking for funding or acquisition. Whatever its stage, all companies would do well to keep these core tenets in mind to ensure both current and future success.If you would like to learn more about topics like this, we talk about building model leaders in our weekly episodes of the TTL Podcast. Or simply send me a message, I’d love to hear from you!

‍