Interview: Technical Due Diligence with Santtu Elsinen and Juha Rämälä

Santtu (00:05):

We are typically buying or acquiring businesses which might have from 2-3 to 100 employees or so. And if there is a big rewrite looming in the future, it will eat up the energy of the whole organization and the developers will be tight with the rewrite, they are not able to do the new features that the clients, the end-users, customers request. They are not able to create something that delights the customers and the rewrites might take two years and then you lose market position, so it's really important to manage the debt and understand amount of it.

Lauri (00:43):

Hello and welcome to DevOps Sauna.

Lauri (00:46):

Financial due diligence is a defacto assessment carried out when purchasing or investing into any software company. But what about the technical due diligence? We at Eficode have seen a multiple cases where business critical solutions have been in such a state that the most suitable way forward, is to start over. Imagine that this application was part of the acquisition that your company was considering and imagine that rebuilding would be such a big expensive effort that the business income is not able to cover the required additional investment in any reasonable time.

Lauri (01:23):

This is why technical or technology due diligence exist. We invited Santtu Elsinen, Chief Digital Officer at Alma Media and Juha Rämälä, and Agile Coach and a Project Manager at Eficode. We discuss with Santtu and Juha about the reasons to doing a technical due diligence. How does the process look like and spice the theory up with their experience from the field.

Lauri (01:49):

So, Santtu and Juha, welcome to the DevOps Sauna Podcast.

Santtu (02:06):

Thank you.

Juha (02:06):

Thank you.

Lauri (02:06):

Nice to have you here, and this is a topic that I need to start by admitting that I know very little. I have been part of the acquisitions as part of the Eficode executive team, but I have not had an opportunity to participate in a technology due diligence, more into the business due diligence type. And that's the topic of today. So we are going to talk about technology due diligence and why should somebody do it and how it's done and we'll take it from there.

Lauri (02:42):

So let's start by just putting a definition into the technology due diligence audit and give floor Juha to basically introduce the concept and what does it mean.

Juha (02:55):

Okay, thank you. Well, companies invest in other companies and their software. The due diligence process ensures that everybody knows what is being purchased and the technology due diligence audit concentrates on the software. The development team, the process being used and the overall quality of the software. As you know, not everything is visible to the surface. If you think for example, a WEB UI of some application or solution, you really can't see beyond the surface, whether there is something good or bad beyond the surface, but with technology due diligence audit, it helps you to find the possible development items and as well as the good, the valuable parts of the software.

Juha (03:46):

In time, the software gets outdated or it has been originally written in poor quality or some shortcuts had been taken during development. The technology due diligent audit gives you a ballpark of investment that is required to get it back on track. What you get is a technical debt analysis and recommendations how to fix it.

Lauri (04:11):

So, is it fair to say that this is relevant for the kind of acquisitions and considerations of acquisitions when you're buying software? But if you are buying let's say consulting business, then it would be less of an issue.

Santtu (04:31):

Well, I guess it falls a bit to the semantics, so some people talk about IT DDs and then some people will talk about technology DDs and this probably get mixed in conversation. Generally I would say that you need to look into the IT part obviously, so are there adequate licenses, what kind of systems does the company use, et cetera. This applies to basically every company as everybody uses technology nowadays. You look into their agreements with their vendors, et cetera. But then technology due diligence is important when you are acquiring software or when you are acquiring teams that produce software, whether they have done it already or are planning to that in the future.

Santtu (05:16):

So, I would make that distinction.

Juha (05:22):

Yeah, so if consulting business is using some particular tools, then of course it might be interesting also to look at those if they have for example, built them earlier phase and then they are using ones as tools in their consulting business, of course then we can apply the technology audit also to those as Santtu said.

Lauri (05:46):

Right, okay. So it doesn't have to be source code. So long as there is technology involved that is part of the package so to say.

Juha (05:54):

Well, source code is easy to start with so that you can look at the code that's there, but of course we can look at the processes and how they are working as a team and how they use those tools.

Santtu (06:10):

Yeah, but obviously I would say that it's fairly important to look into the code as well because the code does imply, it doesn't give a false picture of itself. Of course, you need to understand what's behind certain design decisions that have been made with that part. It doesn't rely on personal opinions, you use automated tools to analyze it and then of course, expert opinions and I think it gives a fairly truthful picture of the situation.

Lauri (06:43):

So when you start to thinking why and when you should do technology due diligence audit and there's naturally this, let's think of it this way, if you were to say this is why and when you should do it, but also this is why and when it is probably not necessary, what do you think?

Santtu (07:03):

No well, first and foremost, one needs to understand what you are acquiring. If you are acquiring a software company or a company where the software plays a significant part of the business, you need to understand what you are getting. I mean, if you were to buy factories, you would look into the quality of those factories, the processes there, et cetera. So the same applies for software. The quality of the product is important, but perhaps even more important is the understanding of the capabilities of the people behind the software.

Santtu (07:35):

So whether they work together well as a team, how they are able to perform and deliver code, updates, et cetera. So I think the understanding of the cohesion of the teams and the ways of working are really important. You are basically often buying also people, and that, if you are buying a startup, that is pretty much the only thing that you are buying. So it's important to understand what the people are capable to do.

Santtu (08:05):

And just like Juha said earlier, I think it's the traditional way of looking into these things as perhaps being having a few interviews looking into the interface, checking few architectural diagrams, et cetera. But you don't tend to get a deep insight into the product by just looking into those matters, so you actually need to go to the code, look at the developer, DevOps pipelines, CICD things and how the people actually working, so that's really important.

Santtu (08:41):

I would say that you should consider doing a technology due diligence when you are acquiring a company that has software products or does software development. It might not have products yet, but it has such an intention. And I would think that it's important whether the software is developed internally or via an external partner. So if it's a combination where you have one or two or a multitude of people and partners, you would need to audit those companies in order to understand what you are getting.

Santtu (09:15):

And I would say that this should be done always, regardless of the companies. So our company, we do around from five to 10 acquisitions per year and typically some of these acquisitions are fairly small. They might be two-, three-, four-person companies, but it's still very important. Perhaps even more important, because the end product resides of the capabilities of one or two persons, so it's very important to understand what they have developed over the years.

Santtu (09:48):

The good thing is obviously that if you are acquiring something small, the process is fairly straightforward. Then again, if you are buying an ERP that has been developed for 20 years, the analysis is a bit more complicated.

Lauri (10:03):

Yeah, I can imagine it, especially in the smaller companies. They might have preferred the time to market which means that a lot of documentation and a lot of information, in general, are not explicated anywhere, but they are more in the people's minds.

Santtu (10:22):

Yeah, that is the thing and typically things like disaster recovery for example. It resides on the capabilities of one single person. So you need to understand that what actually will happen if something goes wrong and the services cease to exist. How do you fix those, especially if the one person is not available at a later stage anymore.

Lauri (10:44):

Yeah. You both have experience from technology due diligence, but I understand that your point of view I rather different. So Santtu, you have been on that side of the table where you are considering to acquire a company and you are performing a technology due diligence to make an informed decision, whereas Juha, I understand that maybe I don't have a full picture of your history, but you are more in the other side of the table where you are providing services for the kind of companies that Santtu represents.

Santtu (11:18):

Yeah, true so. Well, over the years during my career, I think I have been participating in 40 or 50 different M&A processes, so I have been also doing other things besides just technology DDs. But nowadays I am mostly the kind of person who acquires services for the DD purposes and manages the whole process and of course, then thinks of the issues like agreements and valuations and such. But yeah, I have been buying and selling over the past 25 years.

Lauri (11:55):

So now, technology due diligence sounds like a black box for an uneducated or uninformed like me. So maybe it is worthwhile to just open the books and look what's inside and look at how does one do an audit. So if I turn the table and give for to Juha to give a breakdown. What is included in that audit?

Juha (12:23):

Well, first of all, would be produce their SV creator report that, what is the status of the software that is being audited. But before that, first we start with kickoffs. The first kickoff we do is most often with the customer who is ordering the audit. In that meeting is probably one or two hours. It's been summoned quite rapidly, because normally due diligence processes are quite quick and the technology part is something that is done very often a bit in the late phase of that process anyhow.

Juha (13:03):

So we have a quite tight schedule. Anyhow, we started the kickoff at the customer where we set the target. We also manage a bit of the expectation so that we need to know why the audit is needed, what's the reason behind of course, the company's investing into another company, but we need to know a bit more. So we need to know whether the customer has any known concerns about software or do they want to know the value of some part of that so that we can go with deeper into the software and see that it has real value in things.

Juha (13:43):

In that kickoff, we also need to discuss a bit about the security and for example the inside information policies. Is it something that might apply restrictions to our auditors so that they can't really go to the stock market for the next six months because of that audit, but it's something that we agree in the kickoff. And then we also agree to the schedule. Normally the audit takes around two calendar weeks, starting from the point where we get the access to the source code.

Juha (14:24):

Then we also agree with the customer what kind of meetings we have before our report is done. Do we need to have some intermediate checkups? If they are in rush, we might want to discuss a bit things pretty early in the phase of the audit. Once we have understood what the customer wants, then we connect to the target team. With the customer we have already set up the stage, so we know that is the target friendly or hostile, meaning that how much they know. Do they know that they been audited for an investment or thing or not and how well they have been communicated about the details of the audit.

Juha (15:21):

Then when in the kickoff with the target, of course, we need to know where we are coming from and we describe why we are there. We might have agreed with the customer that there is a background story while we are doing the audit and then we discuss about things on a delicate manner so that if the target is not supposed to know all the things, we are not telling those things to them.

Juha (15:51):

We create a circle of information with the target so that we, for example, very often the CTO of the company is the spokesman for the kickoff, and with him or her, we create this kind of circle of info and said who knows what and who can we connect directly, and who do we need to connect through the CTO for example. The contact person.

Juha (16:17):

If the target requires NDAs with Eficode, of course we will set up those and very often if we are talking about the inside information cases, we need to create personal NDAs with everybody there so that the data is not distributed to the wrong places. In the target kickoff, the target normally introduces the product and gives a demo of the application, they run through their processes, they run through their source code and they introduce the team. And from that meeting onwards, we really need to establish trust with the target and of course with the customer from the customer kickoff. But it's really important that the target is not skeptical with Eficode. We are not going to steal their software, we are just auditing it and giving also them valuable information about the application and software.

Juha (17:18):

During the kickoff, other things that are important is that of course, we need to get access to the source code. We either get it through the version control directly. Sometimes we need to set up VPNs, we need to create secure data rooms in order to share the code or the data or the documentation. Sometimes it's even required by the target that they set up this kind of virtual isolated environment where their software is and they are locking all the work that we are doing in there. But of course, for us, the easiest way is that we create the trust and we can get the access directly through their version control and use that for the source code.

Juha (18:01):

Also, we get access normally to the ticketing system, to the pipelines of DevOps and also other documentation is really important to get our hands on. In that target kickoff, we start setting up the interviews with the key personnel or agree on how to do it later phase onwards. And then of course, we can agree on this kind of separate communication channels, sometimes we can use Slack in order to get, or some other chat platform to discuss with the team if we have any questions regarding the code. This is the best possible case that we can ask questions from the target team any time and then get verification that the things that we have found.

Juha (18:52):

Once we get the source code, we do an expert review on the code base, meaning that there will be one to three developers, architects, UX experts, looking at the code or the actual application and they review it and see how it's been built. They check the architecture and so on, all the details. And then we run static analysis tools on the software so that we get the standardized metrics of the overall quality of the software which are then shared to the target and to the customer so that they can see what we have found through the tools.

Juha (19:32):

And if the customer has requested some deep dives into business-critical items, then we look at those in more details and trying to find real value behind perhaps the promise that the target has given. Once we have started the code analysis, we know a bit more about the code and we know a bit about the developers, then we decide that who do we want to interview. Normally we interview the CTO, for example, who is the lead, who should know the most of the application on a high level. Then we go deeper, architect who has designed the application is really interesting person to talk to, and then developers who have created most comments into the application. Those are really interesting people to get the understanding of the application and what's good and what's bad in the application.

Juha (20:29):

And it's surprisingly easy to get answers from the developers that what is good for, what they are proud of and what they would really want to improve in the application. They give answers if you ask. Sometimes they give answers if you don't ask, and that's a nice case. You get lots of information from the interviews. You also interview very often the customer service people, support team members or testing people, just to get really good overall look on the application. And then in the end, as I said, we create an audit report. There we concentrate on the tools being used, the environment, the application architect, the scalability, quality, security issues.

Juha (21:23):

We look at the sustainability and after that we also give an analysis of the technical capital and technical debt. How much there's value and how much there is debt there. And also because people are important and processes are important, once you have figured out what's the software, then we start asking questions about processes and the team and we try to analyze and find any, for example, personal risks so that are there any bottlenecks or really that important people in the team that once they take their finger out of glass of water, there's a hole there and try to find those people.

Juha (22:18):

After we have created the report, we send that to the target to be commented and also they can point out things that we may have misunderstood, because we don't have the whole picture. We are looking at the code, we are doing interviews, so we may have something that we didn't understand and then they have the opportunity to fix those issues. Of course, we keep our veto right on things that we find, so that the target can't really explain them out of bad habits if they do have those.

Juha (22:58):

Once we have gotten the confirmation from the target that the report is okay, or they have been able to comment it, then we share the report to the customer and there we will then discuss the findings and the recommendations with the customer and go a bit deeper into the findings that we've found. And after that, the customer should be much more wiser regarding the software and the team processes and the value of the software.

Lauri (23:34):

Thank you for that. Well, maybe at this point Santtu is thinking, "Okay, that's how it looks like in paper for somebody who's providing those services", and then there's this experience that whoever is buying that analysis, what that experience looks like, and we'll go back into that very soon. But I want to make one observation and probably hear from you, I have been under the impression that when you do acquisitions then there is inevitably some sort of information asymmetry between the company who is been acquired and then the company who's acquiring it.

Lauri (24:15):

And that's part of the deal-making that not both parties know everything. But when you come to the... and I was listening to your kickoff code analysis and interviews, and I was very much following that mind of thinking that, "Okay, the buyer is gathering information and making conclusions that bring them an advantage in that conversation based on all the other information that they have available", but then you come to the last part, which is the audit report. And that's where it all, I changed my... I didn't know what to think of it anymore, because you basically said you are playing back the report to the target company.

Lauri (24:53):

So essentially the organization who was audited has the same information than the company who ordered auditing.

Juha (25:06):

Yes. And we have to be open regarding the things, because of course, whatever we find and whatever are the recommendations, they are really valuable for that team anyhow. And regardless whether they get the investment or not, it's something that they should look at. If we find something that we recommend to fix, then they should look at that one. For just getting things right, in my mind, it's really important that we let the target company comment on the things that we find because if we have understood something wrong, we haven't found something, it's possible to happen. We can't really know everything, so it's also in a way valuable for the customer so that we get things right so that we don't say anything that is obviously wrong.

Juha (26:08):

Of course, as I said, we keep the veto right, because we might know better, we might have seen something that can't be explained and those ones will be in the report, so they can't really hide. The target can't hide those things that have been found in the audit.

Santtu (26:28):

Perhaps to continue from there, I would think that there are two sides to the coin. So obviously the technical finding itself saying that you have a flaw here or there is a security problem with that implementation, those you need to share with the target. The other side of the coin is obviously the financial implications of such findings which then belong to the company doing, or having purchased the diligence from somebody, because that is something that you require for negotiations and from there you can, even though I don't see this as a process where you want to create the negotiation advantage. This is a more often understanding process, but still that kind of information obviously only belongs to the company intending to do the acquisition, that we then use the negotiation.

Lauri (27:20):

Hi again. Santtu and Juha discuss about the software teams and relate to DevOps. Our teams at Eficode have written a hugely popular guide, DevOps for Executives. I am adding a link to the show notes and I encourage you to read it at your leisure. Also, there are a few more links to the related podcast about technical agile coaching and technical due diligence. Take a look.

Lauri (27:46):

Now, let's get back to the discussion.

Juha (27:50):

When we are sharing the report with the target, we go through the technical details and then try to get confirmation to the things that we have found and reasons why they have chosen to do something in a certain way. And once we go through the report with the customer who ordered the audit, we go a bit beyond that and I've also discuss feelings that how did we felt about the team and how do they work together and is there something that we may see questionable and then also bring our doubts into the discussion when we are talking to the customer.

Juha (28:35):

So we want to get the things and the facts right with the target by reviewing the audit report with them and when we are talking to customer, we go a bit further and talk about the bigger picture, the overall picture of the application, the software team and how do we see the overall development process and team, how they work together.

Lauri (29:08):

So Santtu, if you listen to all that, and think it from your experience perspective, what would you highlight from your experiences from doing tech due diligences?

Santtu (29:22):

Yeah, I think that there are a few perhaps not so surprising points, but I'll nevertheless share them. Very seldomly you encounter a target which you want to acquire whether there is nothing to fix. So when doing software, obviously you can almost always do something better, so you will find issues and then you need to understand the implications of those issues. Are they big? Have they large financial impact or is it mostly insignificant impact? And unfortunately, especially when acquiring, let's say companies with a bit of a long history, you come across major issues, because when you have coded something for 10 or 20 years, it's very rare that everything is done with modern technologies and tools, uses cloud to a full extent, et cetera.

Santtu (30:14):

And there is amicable and excellent dev culture and efficient team. So there are always issues, and you need to understand that you will face these. When you find a product or a target where there are no major issues, it's always a source of great delight, at least for my colleagues who are running the technology leadership function, then there is one less problem on your table in the future.

Santtu (30:41):

But this also happens and like I said, I've been once on the sale side where there was an audit done and the reviewer rolled that this code is really elegant. I couldn't have written it better myself, which was a rare price from such a project.

Santtu (31:03):

The other thing being that M&A processes are acquisitions investments. They are typically big processes. There is a lot of people involved, both from the target side. Their advisors, their lawyers, their auditors, investment bankers, what have you's. And the same from your side, so there is easily 20, 30, 40 people that you need to keep on a par what is happening, because what you find in technical DD, will or might have an effect on legal issues. You need to renegotiate some parts of the share purchase agreements. You need to look into the reps and warranties part of such papers.

Santtu (31:46):

So if you find for example a security hole, then the seller must give you some guarantees that if there is a data breach, it's not entirely up to you to cover the cost from such breach, et cetera, et cetera. So you need to really engage a lot in the communication between different parties, and unfortunately people doing technical DDs, they always don't think to share the same capabilities as let's say lawyers or auditors from a big five company.

Santtu (32:21):

So you need to also translate the messages between the different parties and highlight that this is really important or not. There are lawyers who are experts also on technical matters and it's good to have one or two or even three on board in these cases, but sometimes it's not in their expertise to understand the implications of let's say copyright licenses on the future of software development, and this is a big IPR issue obviously. So what of communication, yeah.

Santtu (32:53):

The third part, Juha already covered this a bit, so what is valuable in this kind of audit is that typically the target also receives something that's valuable for them. They receive a list of issues that they probably would need to look into. If not instantly, in the next few years. I have been in part in multiple projects where big security issues have been found and obviously then they have been fixed in a very fast manner. This is important for the target's business continuity and their risk position whether the acquisition happens or not.

Santtu (33:29):

So whereas you might say that, let's say financial audit necessarily doesn't provide that much additional value to the target, I would say that the technical audit typically does. That is a good thing when discussing the M&A process with the target that we would like to do this and it will also be beneficial for you whether the deal happens or not.

Lauri (33:58):

Yeah, we really needed this topic earlier which was start in the companies that haven't existed such as long time. They probably have focused on getting their features right and then by way of that, they have accrued some technical debt. And we have discussed about technical debt earlier in the podcast and basically one way of describing technical debt is that it's something that you think you would be doing next when you leave behind whatever you were doing. It's like okay, I'm going to fix it, but I don't have time to do it now. And that's what you leave behind, is the technical debt.

Lauri (34:38):

Why does it matter? Especially now in this tech DD context. Why is technical debts such an important thing?

Juha (34:45):

I would describe it in this kind of practical manner, so if you are buying a house or an apartment, you really want to know how much there is to repair, how well the house is being built, and is the plumbing still okay? Any issues with water isolation in the bathroom, because you were doing it in a hurry. The same applies to the software. You need to look at architecture and are the libraries. Are they up to date,? convince us what the team is using. How is the documentation? And as you said, how many shortcuts have been taken during the process?

Juha (35:30):

It's really easy to say that, "Well, I'll do that tomorrow. I will write this again, I will refactor this code next week." And then you forgot or you don't have the time and you have to prioritize something over that refactoring where you would actually meant the things that you did too quickly and hasty. The feature will work, you get the money. Money with that feature, but it might be really badly written, and that's causing the technical debt.

Juha (35:59):

And when you have a lot of technical debt in the software, in the application, it's really difficult to scale the application. Doesn't really scale if you have problems with code and even continuing with the current code base, it might be difficult to continue with the codebase. And definitely, if you have done the worst possible thing and did a lot of copy, pasting in the software, so that you have the same code in many projects, then they should be in one common place, then you have this really bad situation where continuation from there is going to be hard and what do you get out of the technical debt is that the more debt you have, the less the software is worth and the more difficult it is to continue building on that software with debt.

Juha (37:01):

And all these things they go hand-in-hand with the course that you will face in the future of that application and developing that further. And what do you need to know is, technical debt is anyway there. It's today there and you will create technical debt basically every time you touch the code. But you have to manage the debt so that you know when you are creating it and you have to know and write down the way how you fix it. And once you have done that, it's okay actually to have it if you know how to fix it and you have a plan and you know when you are going to fix it.

Lauri (37:45):

Yeah, what about you, Santtu?

Santtu (37:47):

Yeah. I mean, Juha put it well. And obviously technical debt is like any other debt. The bad thing about technical debt is that it cannot be wiped away by interest rate. Changes by the European Central Bank, it will always be there. There is no inflation, so eventually, it needs to be paid, or then you will be bankrupt if you cannot face the amount of debt.

Santtu (38:09):

It is also important to think that if you typically obviously when doing an investment, you look into the, let's say, cash flows from the next five or 10 years and hopefully the company show some kind of a profit or at least is on a growth trajectory so that you acquiring something worthwhile. But let's say for the sake of convenience an easy example that you think that company's going to make 100,000 of profit each year from the next 10 years, of it should be rising, but just for the sake of convenience, a very easy calculation.

Santtu (38:43):

If then, during year 10, you need to do a one million Euro investment in order to get rid of the debt, because the software has become unmanageable. The amount of time of the personnel is totally used with managing the software, the maintenance of it. They are not able to develop new features, et cetera, et cetera. And you need to pay this one million Euros in 10 years. It has a very significant impact on what you should be willing to pay for such a thing because obviously or generally, you tend to buy something that goes on at infinitum.

Santtu (39:24):

You're not buying something that exist only for two or three years. It might have a huge impact on the evaluation and sometimes the analysis shows that you actually it makes no sense to invest in it or the price is so low that the target is then not willing to engage in the discussion anymore.

Santtu (39:44):

And on the other hand again, continuing from Juha's thought is that it is important to have the process of managing the technical debt. So, it is perhaps worthwhile to do small-scale, medium-scale improvement over the years, than to let the debt accumulate over 10 or 15 years and then you are at the situation where you need to start everything from scratch, recode everything or refactor everything. At least in our case we are typically buying or acquiring business which might have from 2 to 3 to 100 employees or so. And if there is a big rewrite looming in the future, it will eat up the energy of whole organization, then the developers will be tight with the rewrite. They are not able to do the new features that the clients, end users, customers request, they are not able to create something that delights the customers and the rewrites might take two years and then you lose market position.

Santtu (40:45):

So it's really important to manage the debt and understand the amount of it. Obviously, at some stage, it makes sense perhaps to accumulate the debt. It's not always wise to keep the debt at minimum level, but you should understand the implications of such decisions.

Lauri (41:09):

Yeah, and maybe there are very different technical debts, like if the problem is about let's say, availability and scalability, then it's quite a different kind of an animal than let's say that you are user interface library, or the UI framework is basically going extinct and there's not going to be a support for that and you have to migrate to a completely new  UI framework.

Lauri (41:34):

And of course, the first one can be solved in a very different and maybe more affordable way than refactoring the entire user experience for your end-users. But let me put it the other way for you Santtu. How does technical differ between startups and between more mature companies? Because we have been talking about those two dimensions also.

Santtu (41:59):

Yeah. When thinking about startups, especially of startups where the founders have previous expertise, they have had a long carrier or a track record, you typically find a very modern tech stack. They have hired a CT or developers who are experts on modern ways of working. They use a cloud infrastructure in a modern way, so they are serverless solutions. You are using containers, et cetera, instead of the good old local hosting facilities somewhere.

Santtu (42:30):

And as the development history is typically not that long, there probably isn't a large amount of technical debt available. Then again, obviously they are startups, I mean, I have set up a few companies over the years myself and typically the best tools are the ones that you know how to use and not those who are best on the paper. Not everybody is using the, let's say, industry-standard libraries and solutions. So obviously there are also cases with startups where let's say, the setup is perhaps not enticing a large appetite for the particular tech work, but you still live to manage with it though.

Santtu (43:15):

Then more established companies and especially those who have a long history and are doing something which is inherently complex, like an ERP solution, so there typically is some legacy in the code and infrastructure, especially since when the companies are small, they tend to do a client-specific modifications, and then you end up in a situation where you have actually 37 versions of the same software running for 37 different clients, and this is unmanageable on a long run.

Santtu (43:50):

And there are also sometimes issues with dependences, so you have used a version of the language that existed eight years ago and you're unable to update it because there are so many dependences, and you don't have the time to fix all of those over the years and you might then end up in a situation where you actually have a fairly big security risk posture. There are a lot of attack vectors that could be used against your software, because it's so old and you haven't been managing the debt well.

Santtu (44:26):

That being said, there are good cases of startups, there are good cases of established companies and there are bad cases of both of these, but if you want some kind of overall view, I would say that typically the startup cases are a bit more easier and especially if they are experienced founders there.

Juha (44:46):

What I've seen with the startups that, for example, we have worked together is that they normally tend to prioritize the features that make money. They don't prioritize the features that are nice to have and they normally forget the documentation for example which is part of technical debt that you don't know how it's been built.

Juha (45:08):

But that for sure, it's very often they use modern technologies and then for example, when we do the audit, one of the things that we look at the application and the solution, is that how easy is for us to set up the environment and do we get the application working on our side. And then in a way the less you have technical debt, the more you have modern stuff, the easier that they sell. You don't really have to figure out that how this is actually being built. You just press the button basically and get it done.

Lauri (45:50):

So, you built it, we run it and then see if you can make it work. And if not, then there's something wonky going on.

Juha (45:58):

Yeah. Yeah.

Lauri (45:59):

Good advice.

Juha (46:00):

Sometimes you need some deep centric if it's not stand out, but if everything is really nice and well done, then if you get the source code out of the git and run it, there you have it, you could start developing it, if everything is in place.

Lauri (46:23):

Yeah.

Juha (46:24):

And if you look at the legacy stuff, it might be that well, it's something that I have never written as a language and it might be really cryptical so that you just have to know that there is an API somewhere and you call it somehow and then you get something. And this the nightmare of the cases, that you have to trust purely on the target developers to tell how it works. But of course, that's something that we then try to analyze also.

Lauri (47:01):

Yeah. We are rounding up, but there're two short topics that I want you to touch upon because we have been so well. The name says it's a technology due diligence audit, but there are two topics that were coming up. One is the value of the team and processes, and then the other one is value of the trust.

Lauri (47:22):

So maybe we spend a little while talking about team and processes first, and then round up to the trust part of the technology due diligence.

Juha (47:34):

Sure. From an auditor point of view, the team is the thing that does the trick so that the code is as good as a team. So, people are the valuables and then you really need to appreciate their part in the audit. And in our technology due diligences we evaluate the team, we try to figure out if there are any personal risks. Are there any individuals who are with high importance and if they leave the team, what happens? Do they have enough documentation? How difficult is to bring in someone new into the team who would take over that work. And we try to analyze that. Is it even possible.

Juha (48:21):

And then of course we, on the feeling side, we are trying to also establish some kind of evaluation on the team spirit. That how well they work together. Are they a bunch of individuals who do whatever they want and don't really talk to each other, or are they a team that is really working together and creating together value to the software.

Juha (48:48):

And of course we want to know how well everybody knows what's the way forward. Do they have road map and is that shared with everybody, and also who owns that? Is it chaos or is there some kind of way forward and it's been managed in a good way.

Santtu (49:13):

Yeah. So continuing from that, if one needs to make a choice between the product and the team, obviously would say that the team is more important, but there is some fluctuation with this obviously as if the product is failing you, then you are purchasing something especially for the future. And then the team and its capabilities are the crucial, the paramount thing.

Santtu (49:39):

If you are acquiring something that has been existing for 20 years, then there is a value in what has already been produced. There are client relations, there might be enormous amount of code, great algorithms, et cetera, et cetera. You can't neglect either parts of these, but like I said earlier, you are acquiring people to do the job that they are good at, and hopefully basting about, so you need to look into the capabilities of the team.

Lauri (50:09):

Yeah. And probably a big difference is whether you are consolidating the market, so you are buying a competitor, you are buying somebody who is coming up with basically overlapping offering and merging them together. Or if you are building a proposition where you are basically collecting together different functionality, to stitch them to a proposition. But there's barely no overlap between those parts. So naturally they also play a big role there.

Lauri (50:39):

What about the trust? That was something that we discussed in the beginning. And I'd like to hear your both views on that one before we wrap up, or before we close.

Juha (50:52):

Yeah. From the auditor point of view, we need to be trusted by the target otherwise we can't really get anything out of the software. So they need to trust us and once they establish the trust towards us, they are also learning things. They are given some pointers, they are given some valuable feedback so that this goes in both ways. So when they trust us, they get information and pointers and also when the customer trusts us, then we provide valuable information to them that where they are putting their money in.

Juha (51:38):

So there needs to be a trust in this whole triangle, both ways, so that we are together at this phase and we need to trust each other to get the value out of this process.

Santtu (51:53):

Yeah, I fully agree. So obviously from the client perspective, you wouldn't want to hire a bad lawyer, so why would you want to hire a bad auditor or tech DD auditor. So you need to have the trust on the persons or company you are working with. The important thing here is also that like Juha said, it's typically a two-week process, sometimes one, but it's never a very long process. And the auditor cannot look into everything, so you need to have also trust on the auditor's processes, that what they are doing will provide a good enough picture of the truth what there is and what there isn't.

Santtu (52:36):

So in that sense, trust obviously plays a major part in this. And again, continuing from Juha's thoughts, if the auditor and the target, there isn't any rapport between them, they don't trust each other, it will end up in playing games, and sometimes it might be difficult to take. I mean, you have coded something for the past six years. It's your baby. You think it's great. Then an external party comes in and say that it's not so great. You have done this wrong and that should have been done better, et cetera. It demands a lot of soft skills from the auditors as well to manage the processing in the correct way and not go into the playing game part that this was done bad and then the target company says but hey, you don't understand anything about how we work, et cetera. So that the audit starts to be pretty close to where it wants to be if you go into that one.

Lauri (53:36):

Yeah, you had a great...Sorry Juha, go ahead.

Juha (53:36):

Yeah, yeah. Going back to the thing that we also share our report to the target. This is, I think, part of the trust so that we don't want to write anything down unless they also see it. They know what is being written down about their software and their processes.

Lauri (53:55):

Yeah, and Santtu, you have this example about not hiring an untrustworthy lawyer and I could imagine that when, let's say that a company who is doing acquisitions, and when they find some company who have successfully performed tech DD audits, then there's a value in sticking with that auditor, because basically, it reinforces the relationship time after time.

Santtu (54:25):

Absolutely. And like I said, it's also about the processes and the reporting, because the reporting that has been created, it goes to multiple parties. It goes to the lawyers, it goes to the financial auditors, tax auditors, your own team, perhaps your own board. You need to understand that what's going to come out from the audit, how are you going to use that information in your own decision-making and negotiation processes.

Santtu (54:51):

Obviously, here working with somebody on more than one project is helpful, because then you can convey the ideas and requirements that you have for such a process and you can start to develop efficient ways of working together. I mean, I guess any talented individual would do a code audit, but it's not about the code audit itself, it's about the soft skills, it's about the processes, et cetera. And again, you wouldn't perhaps go to a lawyer who has never handled a single M&A case prior your particular project. So stick with the experts, I would say.

Lauri (55:32):

Thank you. And thank you both for joining the podcast. It was a very enlightening conversation.

Juha (55:40):

Yeah, thanks for the invitation.

Lauri (55:43):

Thank you for listening. You can find links to the social media profiles of Santtu and Juha in the show notes alongside some related materials that I believe could be of interest to you. If you haven't already, please subscribe to our podcast and give us a rating on our platform. It means the world to us. Also, check out our other episodes for interesting and exciting talks.

Lauri (56:05):

Before I let you go, I want to offer a floor to Santtu and Juha to introduce them properly. All I say now, is take care of yourself and remember that the technical debt cannot be wiped away.

Santtu (56:19):

Hi, I'm Santtu Elsinen, I'm the Chief Digital Officer at Alma Media which is a Finish mid-sized, or large-sized by Finish standard media company. We have pretty much digitalized our sales, almost 80% of our revenue nowadays comes from digital properties. So we have close to 100 different services in Finland, Sweden, Baltics and then Eastern Central Europe. What I do here is I handle technology-related matters and part of the management team and typically, I'm very much involved with the M&A work. We do that quite a lot. So it is a significant part of my job here.

Santtu (57:04):

My background is entrepreneur. I have founded five different software companies myself and sold all of them away over the years and then I decided to try the cooperate life and that's why I'm currently working here.

Juha (57:20):

My name is Juha Rämälä, and as a title, I have a title of Agile Coach and Project Manager at Eficode. I have about around 20 years of experience on the IT side and various sides of it, so I've been in a huge corporation for 10 years and then some startup experience in my background also. And then the later years, for some reason, I've been brought up with problems with processes and change management and those are the things that I've done also in the past.

Juha (58:07):

And now that I've been working for Eficode, mainly I've been working on the project management side, but during the last year, I've participated more or less in around 10 different due diligence audits, either helping the actual doers or being part of the audits. And it's been pretty interesting, right in a way that you can see what have been built in the world and how they have done the job.

Juha (58:47):

And also, going further, because we are further developing the due diligence audit offering of Eficode, I'm going to be developing it further and trying to get it more standardized format so that you can rely that our standards and our processes on the due diligence audit process are something that you can trust and you know what you're buying when you're buying a due diligence audit.