23 insightful IT due diligence red flags

I’ve managed through numerous DD projects this month, and they prompted me to provide some information on the typical “red flags” that we often observe. This is a long post that I will continue to contribute to. Please reach out if you have any additional ideas.

To put this article in context, previously, I have written about:

• The common mistakes in IT Due Diligence,
• Why storytelling is necessary for both team and technology due diligence,
• A paper on some due diligence questions that non-technical people can utilise before they invest in full diligence.

Red Flags need categorising

Before I begin, it is worth noting that even if people, processes and technology are organically interlinked, it is easier for all parties if red flags are categorised – so that it becomes easier to discuss, drill-down and create a relevant action and budget to address.

If not, you can find yourself bamboozled as senior technicians/CTOs are articulate and can avoid challenging questions if they want to.

Reg flags are often an opportunity

Often red flags flagged during a technology due diligence exercise are usually opportunities for the investor.

• If it’s an operational concern, it may be an opportunity to mature the related processes.
• If it’s a “people” concern, there is develop the in-house team or augment the team with new vital hires to inject more ideas and energy into the group (which doesn’t always work).
• If it’s a technology concern, then there are many angles to take, and is the result or symptom of the people and processes in place to develop the solution. Recommended technology changes need to be realistic, weighed up against the cost and the time to implement.

People

For reference, here’s a brilliant HBR article on hiring concerns. At the core, it reports that firms no longer spend the time developing their staff – expecting to employ “oven-ready” people (thank you, Mr Johnson) to fulfil functions. This lack of personal development is prevalent in the technology industry and very obvious when we assess teams.

The challenge compounds when money is injected into the team because there’s a need to drop-in experienced people to turnaround and develop the tech environment. Adding new people can be the right approach – but remember the in-house staff hold vital information to improve the system more effectively.

As one Partner in a firm recently said – there must be a better way, why do we need to replace staff when there’s already so much talent within firms? I’d argue it’s because there’s a glut of untapped potential talent that needs attention, but those people need time and effort to develop.

1. Strategy misalignment

Probably the most destructive “people” red flag is when the team isn’t aligned. It is obvious to focus on the roadmap and strategy, but when evaluating an organisation, it is also essential to ensure they are aligned.

Real-life examples are numerous, situations where the CTO’s vision opposes the lead technical team’s view. Or more disturbing is when the strategy misalignment is so severe that it’s impossible to work out what the company does – to the point no one can pitch the same story!

Sometimes you can meet an entire team who are all aligned, but one (highly technical) lone ranger can disrupt the delivery – only allowing things to develop if thy match their way of thinking.

In addition to ensuring the tech team are in alignment, it’s also essential to speak to sales and marketing to check whatever is being built by the tech team meets the vision of the business and ultimately the customer need. For example, during one DD project, a ~500 employee business had a more complicated pitch than the leading corporation in their field (who employ hundreds of thousands of employees) – and no one was able to pitch clearly.

2. Avoidance

As mentioned earlier, senior technology staff are articulate and able to run circles around most people as they describe the intricacies of their beloved technology solution. But these presentations could be avoidance – long-winded monologues to keep us from digging deeper into what’s happening.

I recall meeting a CTO in Amsterdam for a leading-edge Fintech product. The one word I could use was “slick”. The CTO had developed some brilliant presentation skills, and by the time they were and acquisition target, he had the pitch down to an art. Full of “founder magic” I don’t think anyone could resist his passion and narrative (remember, tech is all about storytelling).

But, some things didn’t feel right. We felt there was much avoidance. But when ignored the pitch, and got deeper into the product itself, bespoke engineering was uncovered that could be replaced with off-the-shelf solutions, and the hosting costs through a small provider were spiralling. In this example, the investment continued on the basis the engineering and hosting concerns were addressed.

The way to overcome the “avoidance” challenge is to ensure that you add diversity to your due diligence team – you need more than one person to perform the assessment and for the interviewers to have different skills.

3. Poor internal communication

An easy way to judge a teams/business culture is the quality of the input (meetings, written and oral comms) and the output (precisely how much work is being closed-off).

So a simple open-ended question to ask “how does the technology team communicate” can reveal several red flags. If this question throws a tech leader, and they are unable to reel-off the numerous ways people communicate, it’s a red flag that needs more in-depth inspection. Unfortunately, some people think that Slack/Teams messaging is enough, or that due to being in different physical locations, there’s no need to design robust communication processes.

But I challenge that view. One of our customers operates an entirely remote nomadic team has mastered their comms – with software development processes that utilise video conferencing combined with investment in the organisation so that they all trust each other to keep things moving forward. To be clear, their company is a team where most of the software developers don a backpack and are continually moving between countries.

To test the input from the team, you can ask, How often do you have regular meetings, and how would you score them from 1-10? If there are communication issues, this question will often uncover them.

Improving communication is undoubtedly an opportunity to help to improve a technology team’s productivity, but you must balance the communication “overhead” against the current delivery cadence of the organisation.

4. Lack of training

This red-flag is probably so common that it’s more an “orange” flag than a red one.

We often observe technology employees are expected to self-teach, and there is little investment in their skills. Many firms keep costs down by paying for books and exams – but not full training.

As a self-taught software developer (of long ago), I agree to a point, but this approach eventually limits the creativity and innovation of the team. If you look at other areas of the business, say sales and marketing, their day-to-day skills topped-up with some soft skills and project/management training.

Training is down to available resources, and we appreciate we cannot suddenly inject a lot of money into areas previously untouched before investment. But if you are to have a business in your portfolio for 3-6 years, the team you invest in might simply become stagnant, and you may end up spending money on expensive consultants.

5. People in the wrong seats

Sometimes we’ll meet a firm in the middle of a tech transformation, and they are (a) struggling to deliver the new technology products to support it and (b) obtain any meaningful buy-in from their business community. Often there will be Kanban boards galore and many new simultaneous initiatives ongoing, but the management expresses concern with the delivery. Sure, we can spend more on more resource, but is the problem elsewhere?

Often, people are in the wrong seats. Some staff have moved up to more senior positions. Still, their conative profile (their natural way they behave under pressure or stress) does not match the leadership position they currently hold – they’d be more suited to a hands-on job, but this is a step “down”.

If we look at the wider team, a younger person who has a conative leadership profile is more suited to the job. It takes humility and understanding to move the younger person “upwards” into, the more significant role and let them find their voice, but it’s a better solution than poor results.

6. Lone rangers

Sometimes you find the tech mavericks – people who are brilliant at their job, who have a lot of influence in an area but they are not team players- preferring to push forward in their own direction. Not much to explain here as the impact is evident, but it is critical to determine if they are a flight risk – will they leave the business post-investment.

We recommend finding out why they are behaving that way as doing so can unlock a lot more productivity, security and innovation in your technology investment. The usual trigger is when two or more people refer to a specific tech team member as being “difficult” – often those difficult staffs are A-players that could transform your investment.

7. Un-co-operative Staff

By “un-cooperative”, I mean people who prevent access to systems or those that prevent change. Of the two, the obstructive people are probably the most common people we encounter – they don’t want you to look at their systems, they use a lot of delaying tactics to prevent you from getting the information you need. Fine, that sort of behaviour comes with the territory and is easy to spot (and escalate). Do they want investment or not?

The second type is more about staff being uncooperative with each other over long periods of time. A few businesses we’ve worked with have been founder-managed-developer. The real “architect” of the products is the founder. Over time, they’ve all hired additional staff to increase their productivity, but they find it difficult to let go of the technical aspect of their business (for many reasons). Their reluctance to hand over the reins may mean that the founder’s mindset limits the potential of the technology platform.

For example, at one company, the software product was developed in a legacy framework, and the founder won’t allow the #2 to move the product to a modern one. (The #2 had been waiting 14 years to modernise the platform!). As soon as the company was sold, and the founder exited the #2 could finally execute his modernisation plan.

With an un-cooperative leader, you will need to sell the vision to them first before you get buy-in.

8.No mention of the customer.

It would seem natural that a technology team are focused on their end-customer, but we often walk away thinking the technology is developed in a bubble. In one of the most extreme instances, a new software product was launched, and the pilot customer reaction was to (literally) cry – not tears of joy, but those of concern as the new product wasn’t up to scratch. Put the customer in the middle of the team’s strategy/decisions.

9. Unrealistic expectation of the investor.

It’s good to understand what the team expects, once they gain investment or are under new ownership. Sometimes, expectations are unrealistic – such as increased wages (when the business was presented for sale/investment at its most profitable) or that all the quirks and imperfections will be addressed (when the company was perfectly imperfect and profitable).

To balance this judgement, we have to check what was being promised by the investor/buyer – especially during a competitive bid – as some buyers may promise more to stand-out or win the deal.

As people who often run post-deal advisory, we’ve often seen the aftermath. E.g. during one competitive deal the investor who “won”, had promised the board they would look after the existing technology team, training them as needed and working side-by-side with them to run some integration work.

It was challenging, as the internal staff loved the idea of the new opportunities to learn but lacked the base skills to take advantage of the opportunity. Plus, they had never run an integration before and were deeply uncomfortable with the complexity and the pace of the project. Hence the time to integrate and related costs tripled.

So it’s worth checking expectations, from both sides the expectations of both the investor and potential portfolio business, where possible.

Processes

1. Lack of financial control

Financial DD will pick this up, but it is still essential to assess this from a technology leadership perspective. When we dig into the financials, we might see patterns where the company as not controlled their technology spend. This uncontrolled spending can be as fundamental as not having purchase orders in place (even for large mid-sized businesses), finances through spreadsheets (for large corporate) or allowing staff to buy kit and software at will.

There are too many “signals” of poor financial management, and it’s a key area to consider as part of tech DD. It’s also the most significant concern for many Investment Director we’ve spoken to, who have been burnt by expensive post-deal projects.

The post-deal response can sometimes be overkill. For instance, one firm employed some new dedicated procurement and software licensing experts, but in turn, the project delivery slowed-down by a factor of four. There needs to be a balance.

2. Lack of data

Another common aspect that many Investment Professionals will understand well is the lack of general data (finance, forecast, etc.). It usually means that the leadership cannot predict when contracts or customers are due to be renewed, so forecasting and maximising opportunity is impossible. To be able to compete, this data needs to be visible. In many cases, the data is being stored but not available for meaningful consumption.

Typically, there is a plan to turn this problem around.

But note the company managed to build an investment-ready target without the necessary data, so the opportunity to grow the business appears to be positive.

3. Too many new/open initiatives

This refers back to our “input/output” assessment of company culture. Simply put, if projects are not being closed, then it’s a red flag. The challenge is that many firms operate technology projects using both waterfall and agile processes simultaneously. So identifying “closure” can be a challenge, as something that’s continuously updated has no “end”.

It’s a relatively easy thing to assess – either you review waterfall project plans, agile epics, service desk calls, bug/fix ratio and open initiatives in Jira etc. to see what’s happening, OR you sit in on meetings and look for project management artefacts in the office. Learning how teams close their projects is the second “investigative” concern following their use of funding.

So the team is failing to close down projects. What’s next? This is an area where a fresh pair of eyes, from an experienced project/agile professional (whether a programme or project level), will help. It is also worth considering the product/engineering team ratio as often teams organically build new products to compete with their nearest competitors. On small acquisitions, we’ve witnessed 50+ products being managed by < 20 people. No wonder they are unable to modernise the entire platform.

4. Lack of change management

We assess a growing product, and it looks good on the first appearance, but after a day or two, we realise that there are few controls on how software/systems are updated. Often, we don’t learn this from the tech team – we find out from speaking to the users (if internal), or by looking at online responses/support tickets for SAAS.

At first glance, this isn’t a significant concern as the business has managed to grow and generate revenues to attract investment or acquisition. We appreciate that implementing change management can impact the productivity of the team.

But, many firms have a “cloud-first” principle for their technology assets (I personally have a People First principle) and want to deploy robust security and not controlling change will almost certainly break their policies. Lack of change becomes more of a challenge if this is an acquisition that will be integrated into a larger firm – now, we must determine the best change process by comparing both businesses.

5. Joiner-Mover-Leaver Process.

Regardless of the size of the firm, a robust joiner/leaver/mover process is critical. Firms must ensure cyber-security and asset control are in-place when people join a business, leave a company or move to a new department.

For a new joiner, there is a trend for employees to use social media to report their first-day experience so ensuring that computers, user IDs, employee handbooks (or equivalent) and general onboarding are paramount for the company reputation.

For leavers across the entire business, computers and devices need to be returned and wiped if not.  And for leavers In the technology team, ensuring the codebase and the infrastructure hosting any products are both secure. “Removing” an employee is quite easy, but firms often use generic security accounts with high-security access which constitute a significant concern. A disgruntled employee can use these generic accounts to connect back into the business.

For movers, ensuring user’s use of information is restricted down to their role. The problem is that the way people access information and data isn’t granular, and there can be fear of making security changes due to concerns that It will stop the product(s) working. If you cannot push for change post-deal, this security problem will continue to grow.

6. Unable to state the active number of customers

A small but insightful signal is if the team(s) either have no idea how many customers they have or are vastly different numbers they are working towards. The challenge is to determine why this is happening and may be related to the “lack of data “concern highlighted earlier in this article.

Difficult to explain why this happens as it will be unique to every acquisition, but from the technology perspective it is worth understanding if the capacity management and other resources align to the customer growth expectations once the investment has been made.

7. Manual Processes

The typical scenario is for a SAAS product, the customer acquisition and onboarding processes are automated from the front end, but behind the scenes, the work is manual, i.e. manually be a person, in the background. A recent case of this is the Theranos Labs, a firm that was selling hardware to test blood at home, but in reality, the samples were tested manually using traditional tools.

Back to lower-profile businesses, there’ll be a good reason why manual processes are occurring, maybe it’s cheaper for human “resource” to onboard a customer than develop an automated process – or the operations have grown organically without review.

Sometimes, manual labour is preferred because the target business creates healthy revenues from consulting services. The staff on the ground often have better ideas on how to remedy this than a third party.

Technology

1. Roadmap Concerns

The usual project-delivery aspects come into play here -is the plan realistic, do they have enough resource etc.

But during the assessment, are we witnessing “buzzword bingo?” – i.e. reports of high levels of AI, ML, etc. in the roadmap when there’s neither the skill in-house or time to develop it? Most tech entrepreneurs express high-levels of founder magic, so they are great at presenting a positive vision for their platforms, but what is realistic?

2. Product-Market fit is not clear

We’ve been assigned to assess a tech firm, we review the publicly available material, and the product/market seems clear. But then, during the assessment, it becomes evident that this not the case, the company is at its early stages and has developed an Enterprise product, but now they are selling it to SMB.

To those involved, this is a natural progression as it’s re-using the code base and opening to another market. But in short, this is a maintenance concern, and it would be interesting to be a fly-on-the-wall to hear how the Enterprise clients react when they realise their multi-thousand/million investment is now being used by small businesses at a fraction of the cost.

So we relate this to an unclear product-market fit because if there is a fit the pipeline would be growing so fast, there wouldn’t be time to conjure up new ways to re-purpose the current software platform. Instead, they would be focused on sales, marketing, onboarding and customer service.

3. Great SAAS Product – Poor Everything Else

A couple of years ago during a tech transformation pitch, a CTO asked me “What’s the latest trend you’re seeing?”. It was refreshing to be asked something a little different, yet a challenging question which I needed a quick response to, and what crystallised was an amalgamation of all of the observations previously explained in this article. Namely, there’s a ton of investment in time and resources on the publicly facing SAAS products, but less investment on the people, processes and tech that support the platform.

It is understandable to squeeze assets, and reduce costs on internal tech when the focus is on the revenue-generating code within the company, but not updating and patching systems and updating software components will come back and bite the tech leadership. Eventually, things become so far behind that it becomes “scary” to update any system, in fear of breaking either the hosting or the platform itself.

The worst scenario is when the staff simply “give up” on the modernisation of their systems, or assume that their kit will be unreliable. In this situation, productivity is impacted as staff cannot rely on their equipment. Business users may find it challenging to produce any reporting, or the accounts department cannot reconcile their accounts without lengthy bespoke data processing is operated. The cost of fixing these problems can be a significant red flag.

4. Legacy Bespoke components

Some firms are running their software/platforms using home-made components that are no longer viable. For instance, we assessed one company that built proprietary network protocols and encryption methods. There was a good reason why they created these legacy components in the past, but the industry standard products were far superior today.

Other legacy concerns are bespoke scripting often used by platform teams which have taken years to develop. If the platform will be integrated or carved-out, these scripts can be high hidden costs. In some cases, firms have ended up lifting and shifting entire data centres – i.e. moving physical kit – then try and untangle and re-engineer complex scripts as they simply don’t have the time.

Or lastly, bespoke/hidden project management tools that are associated with the platform – they tend to be smart, but what is the cost of managing these online tools to the new investor? And, do these tools add value or is there an off-the-shelf equivalent that would allow a more effective focus of the revenue-generating platforms?

5. The Data Warehouse is overloaded

The product platforms are operating well, but the warehouse that’s processing the data is failing to keep up with the business growth. Information is missing, or the processing isn’t completing in time. The customers may not experience an issue, but it will become evident as the platform grows, and for the new investor – a potentially expensive problem to fix. Getting to this “state” is a good indicator of overall operations and systems management from the team.

6. Technical Debt

Whether it appears in the code review or infrastructure services, tech debt is a major red flag. What will you be responsible for fixing in the future?

Apparent causes of technical debt are the “rush” to market – causing time constraints placed on development, the complexity of the source code, and decisions made by the business that which harmed the product from a maintenance perspective. Also, a lack of planning, coding standards and guides and skills can result in future development remediation concerns.

From a hosting / infrastructure perspective, the most common reason for technical debt is implementing and using new systems without decommissioning the older systems – leading to long periods of co-existence and associated costs.

7. Cloud / Hosting Sprawl

As more systems move to the cloud, and they are maturing, the more “cloud sprawl” will occur.

Cloud sprawl is the uncontrolled proliferation of an organisation’s cloud instances or cloud presence. It happens when an organisation inadequately controls, monitors and manages its different cloud instances, resulting in numerous individual cloud instances which may then be forgotten but continue to use up resources or incur costs since most organisations pay for public cloud services.

When we move from internal data centres to the public cloud, we no longer have the benefit of “sweating” our assets. So careful management is required to keep costs down. A review we did of several digital acquisitions for a firm identified £700k pa of savings. These savings were due to misconfigured cloud environments, lack of internal experience (as contractors built the cloud systems, and left the business) and use of IAAS when PAAS is a better and viable option.

Conclusion.

While developing this list, one question became clear – why don’t we run formal 3rd party technology due diligence for traditional transformation projects? Surely having a holistic review of the business combined with the assessment of the team, processes and technology could allow us to develop far better transformation projects?

Arrange a Conversation