Show Notes
Mon-Chaio summarizes some common red flags that surface during a company’s technical due diligence investigation.
References
Transcript
Mon-Chaio: Thank you, everyone for joining me for this VacationCast episode of The TTL Podcast. For those new to the show, we do VacationCasts when one or both of Andy and myself are on vacation and unable to record a regular episode. Uh, hence the name VacationCast. VacationCasts are also shorter than normal episodes and cover smaller topics that don’t benefit as much from exploring and debating between two people.
For today’s VacationCast, I’m going to be talking about common issues I find when conducting technical due diligence investigations. This does sound kind of dry, and while this isn’t exactly a leadership topic, it is a topic that many leaders of technical organizations will encounter when they’re closing around a funding or doing an acquisition deal. And more often than not a lot of these issues that I find and talk about in these technical due diligences could have been minimized or alleviated entirely by having applied different leadership tactics. Which I think actually makes it a good topic to cover briefly on this podcast since we do talk a lot about leadership tactics.
As we often do, I’d like to start by making sure we’re all operating with the same vocabulary. So when I talk about technical due diligence investigations, I’m talking about a process where either an individual or a team looks into the details of a company’s technical organization in order to assess areas of risk and exposure. Now, this is almost always done as a precursor to an investment or acquisition event, but really there’s nothing stopping a company from conducting its own technical due diligences outside of these funding activities.
A common misconception that I do here about technical due diligences is people thinking that it’s just about examining source code and engineering processes. That is, the technical assets and work product of a company. While those aspects are important, and I do look into them thoroughly during these investigations, equally important are the technical people and people processes, including assessing strengths and gaps in leadership skills. As always with these investigations, the goal is not only to make sure that the product contains minimal risk, but also the team that is building the product and supporting the product has minimal risk as well.
So with all that in mind, as I mentioned at the beginning, there are some common issues that I find myself calling out as risks over and over again in almost all of my technical due diligence reports. And these issues span companies stages, product types, and industries. As I thought about it, I realized that these recurring issues can be categorized into two risk buckets. Number one, fragility. And number two, scale.
The fragility bucket in my mind can be thought of as how resilient your people, processes and software are to bumps and shakes. So, can a single tiny nudge break down your entire technical operation. Or is it resilient to even the most violent of earthquakes?
On the other hand scale is about how well your people, processes and product are set up to grow as the company grows. The most common use of additional investment capital is to scale of the company more quickly than it could otherwise. So often that means hiring more people, building more product, or expanding to more territories at a pace that’s often an order of magnitude or more than it was previously. So scale risks are when the foundations that your company is built upon are unable to support this type of explosive growth, or worse, end up retarding the very growth the investment dollars are meant to accelerate.
So going back to the fragility side, some common things that I see in the fragility bucket are things like lack of automated tests and too many engineering silos. Another very common and equally important issue that is often overlooked is what I call optimistic processes. I see many companies with irresponsibly lightweight, or even worse, wishfully happy path processes that don’t stand up to risk scrutiny. A commonality between these types of processes is that they are generally trying to pretend the things that are likely to happen and have happened often for other companies just won’t happen to you and your company. And that is a big fragility red flag.
In the scale risk bucket, some common red flags include not-invented-here syndrome and lack of leadership experience. One more that I see a lot is an imbalance between tactics and strategy. Because as an organization grows, their leaders necessarily move further and further away from the frontline work. So their future impact depends on how well they transitioned from pulling all the levers on the shop floor to moving to cleaning grease traps and sharpening knives … that is, the proactive removal of execution impediments. Now the latter job requires foresight, patience, and a less-is-more mindset, skillsets that are not often present or even required during the early helter-skelter days of a startup. Now that doesn’t mean those leaders during those early days, do not possess or cannot learn those skills. But if their work to date shows little evidence of that strategic mindset, it’s really difficult to recommend that those same leaders will be able to effectively helm a rapidly scaling organization. And that makes it a risk that falls into the scaling bucket.
So, this is just intended to be a quick summary of a few things that I find when I’m doing these technical due diligence investigations. If you’d like to learn more and read about it more in detail. I did recently write an article that I’ll link to in the show notes. But the reason why I think it’s an important topic for a podcast like The TTL Podcast is that even outside of technical due diligence investigations, fragility and risk are two areas, which I think it is super important that all leaders of technical organizations should keep a close eye on. Many, many core problems of technical organizations can easily fall into these two risk buckets, and having a model which thinks about problems in this way can really help you to categorize and problem solve.
That’s all I have for this episode. We’ll resume regularly scheduled programming next week as Andy and I explore how technical the leaders of technical organizations need to be. But until next time, be kind and stay curious.
Leave a Reply