- 9 min read
April 12, 2024
Technology companies encounter various specific risks that can have real impact on their operations, ranging from cost inefficiencies and productivity problems to susceptibility to security breaches. A Technology Due Diligence (Tech DD) is crucial for identifying these individual risks and devising strategies to mitigate their impact
These are the risks that are seen most often, that are covered as part of a Tech DD:
Effective yet efficient communication keeps teams aligned and aware without constantly interrupting them with details. Unnecessarily complex collaboration models and organizational structures result in procedural resource waste, which ultimately demotivates and lead to talent churn.
Efficient processes typically rely on goal definitions and road mapping, explicit models of collaboration between the teams and a clear organizational structure that is tailored to the company’s goals. The multitude of different options when it comes to structuring “Product and Development” departments makes finding the sweet spot of optimal team size, collaboration model, and reporting hierarchy anything but trivial.
In very early company stages, when the team is mostly the founders, there is no need for sophisticated structure. However when business picks up, this changes fairly quickly. Experience shows that more than 8 members per team come with significant drawbacks, which would also be the typical limit for direct reports a team lead or manager can handle (this “rule of thumb” limit is higher for a team of very homogenous roles of course).
At scale, this means that some level of distribution (we’re deliberately not saying “hierarchy” here) of staff into groups of contributors is required. Larger organizations often struggle with strong dependencies between teams, regularly blocking each other’s work. Often, this is caused by teams who are assembled around skill sets, not domains, which ultimately leads to significant improvement potential in collaboration efficiency.
As teams grow, knowledge tends to accumulate among the most active, ambitious or experienced engineers, resulting in knowledge silos. If knowledgeable engineers leave the organization at a later stage, progress on building the product will likely slow down, while service stability and availability may be affected as well.
The effect is unfortunately self-reinforcing: poorly distributed knowledge in the heads of a small number of senior tech staff makes it increasingly hard to mitigate that risk itself, as significant dedicated efforts will have to made (instead of a constant, manageable effort built into the processes). Even in early stages of a company, a structured, minimal documentation allows for quick understanding of key concepts, components, and algorithms - but is often neglected in favor of creating a product.
While that may be a valid trade-off, the price normally becomes evident once trying to scale development teams, when documentation needs to be created to get new staff up to speed as quickly as possible. So documentation should not be seen as a pure accountability obligation, but rather as a productivity lever that is used to not block experienced engineering staff too much once growth kicks in.
Later-stage businesses often face the same problem, it just manifests differently: over time, a lot of documentation on various topics is created, sometimes even using multiple different systems (e.g. Wiki systems, email lists, personal notes). In absence of a clearly defined structure that applies for all teams and a constant review of the key pieces being up to date, it becomes virtually impossible to distinguish important pieces of knowledge from “noise”. The effect is ultimately the same: new hires have a hard time figuring out how things work and rely on resident staff to get help, ultimately leading to two (or even more) blocked engineers.
To avoid this knowledge access trap, it is vital to choose a documentation systems and set a clear structure on how to use them. It helps a lot to establish a clear culture of documenting what’s important in the right type of system e.g.
To support the companies we assess, we provide an example structure, containing bare minimum items we consider essential to every tech company’s documentation.
TechMiners can support your Tech Due Diligence process.
We are happy to provide further references from your industry or sector upon request
