In recent years, ProSiebenSat.1 followed a consequent diversification strategy with the result that today half of our revenues are no longer coming from our core TV business but from other – mainly digital – areas of business. We acquired for example some well-known companies like Verivox, Parship or Jochen Schweizer. Our business development teams are constantly screening the market for potential ventures. Once we have found an interesting target and agreed on the general business terms (prices, shares to be traded, etc.) it is time for us to take a closer look at the company - the so called due diligence.
During this process, all areas of a company are thoroughly screened in order to find potential issues but also to find extraordinary chances that are not immediately obvious. This includes but is not limited to business plans, financials, legal obligations, HR, tax topics and of course tech.
With this article, we want to share our insights and experiences and provide help either in case you need to conduct a due diligence on your own or you are a start-up awaiting a due diligence from a potential investor.
The scope of a due diligence
With many of the companies in our portfolio being digital, tech is a crucial part of their daily operations and basically every area of the company is relying on tech – and a great team behind this tech. This is why we keep the scope of our IT due diligences rather broad: We not only look at technology, architecture and infrastructure but also at team structure and skills, project management, and metrics. And of course, since a good understanding of security is becoming more and more important, we take a look at this as well.
The downside of such a broad approach is that you either have to spend a lot of time on a due diligence (and force the target's team to do the same) or you have to compromise on the depth of things you can check. The approach we identified to be the best trade-off here is very comparable to a car inspection: With our screwdriver, we poke in many areas and if we find a rusty part we take a closer look. Transferred to IT due diligence this means we check all areas of interest. Once a document or an answer raises our suspicion we will dig deeper here. While this naturally bears the risk of missing very specific issues very deep down, it gives us the best overview with a reduced risk of missing something big.
And this is also how due diligences often differ from audits: An audit usually wants to identify all potential issues in a certain area: A security audit should ideally surface all security related problems from legacy systems without security patches to unnecessarily open ports or weak passwords, the security part of a due diligence will show if the team has a good security understanding or if there is a deal relevant risk here.
A due diligence is a due diligence is a due diligence – NOT
One of the most important things we learned very early on in our process is that no two IT due diligences are the same – because no two companies are - and that we always have to tailor the process to the target. Of course, in order to maintain a comparability between companies and take care not to miss out anything during the process, you should define the previously discussed common scope and also have a playbook or framework for your due diligences. But all this should be flexible enough to be fitted to the deal.
Some circumstances that could for example influence the scope are:
Your plans with the business: What are the growth plans? Do you see potential synergy effects with other companies from your portfolio? This means we will have to take an even closer look at topics like scalability and flexibility of the systems to be adapted to other use cases.
The target's business: A company that is dealing with sensitive data, e.g. a dating company needs a comparably higher awareness of data privacy whereas a physical goods company should have a deep integration in their production and logistics systems.
The target's maturity: For a start-up with 5 people you would naturally expect a lot less strict processes for their daily work compared to a well-established 250 employees company, whereas their employees probably need to be a lot more flexible when it comes to their responsibilities.
OK, let's finally get to it: How we do due diligences
Before we get in touch with the asset, we start with a long chat with the business unit at ProSiebenSat.1 that plans to do the investment to understand their plans and needs. For most of the companies we are acquiring we plan to grow them by providing TV commercial air time. If that is the case we need to make sure they can handle the extra traffic. Imagine we air an awesome TV spot during primetime that causes millions of people to visit their website and their servers cannot handle the load. Another big topic is always synergy effects when you buy a company because you plan to (re)-use their technology in a couple of other ventures. Are the systems meant to be shared? What would it cost and take to make them tenant-ready? Does this cause any license issues because of used software?
Now let's see how big this baby is
Once we collected all the needs, we get in touch with the target to introduce ourselves and the process and also to get a first understanding of their systems, the complexity, the tech stack and of course the size of the company. This is also usually the point where we decide if we need to get other people into the process, e.g. external advisors or specialists from inside ProSiebenSat.1. This might be because of specialties in the tech stack (e.g. uncommon languages or services) or the mere size of the deal. Questions we typically ask here are regarding the tech stack, a quick(!) architecture overview, number of servers/instances/employees, etc.
Once we developed a proper understanding of what is awaiting us we introduce the further process to the target. The process itself is not rocket science and basically industry standard: Send a document request list with a couple of documents that the target can/should provide beforehand and schedule an onsite visit. The reason why we say "can/should" is that we ask the target to only provide us with documents that are either readily available or easily creatable. The main purpose of the requested documents is to give us a better first understanding of the whole setup before we go onsite. Every bit of information we can read beforehand is one thing we don't need to ask during the onsite meeting. In case we identify that we really need a specific document we request it from the target throughout the process. The reason why we usually stress this point multiple times during the call is that we missed to do it during a due diligence a couple years back which resulted in a de facto shutdown of a complete engineering department for two weeks as they switched from engineering to "document production."
Now we are finally able to tailor the scope, hire an advisor if needed or gather resources otherwise and start reviewing the documents as they trickle in.
Life of a jet setter
As mentioned before the most important step in our process is the onsite meeting. The reason why we do this meeting onsite is because from our experience you develop a lot better relationship when you are sitting in one room and many misunderstandings don't happen if you meet face to face. Additionally, the office environment tells a lot about how you work and how you work together. And last but not least it is easier to drag in experts from the team if you are sitting in a meeting room next to them. Of course, there are sometimes situations where it is not feasible to take a trip, either because the teams are working fully remotely or because of the expected complexity there is just nothing to see.
We try to keep the onsite meeting as informal as possible. This should be considered a free advisory session for the target where at best they just learn a bit about their systems and where we see room for development.
Over time we developed an agenda for onsite meetings that helps us to stay focused and cover all necessary topics: We first start with a live demo of the product. We really recommend this, because no matter how often you have read the briefing documents or watched presentations, getting a firsthand introduction to the product is invaluable to really understand the business. Then we move through the back-office (the target shows us the processes and software needed behind the curtain to fulfill their business), get a quick introduction into the business and IT plans before we finally go into the technical details. Here we go through the architecture, used services and libraries to see if they match the product needs. Infrastructure, hosting, costs and office IT is the next stop where we also take a deep look at things like scalability, high availability and redundancy. In "operations and security" we look at their deployment processes, disaster recovery mechanisms in place, their understanding of security and data privacy and the SLAs they are promising to their customers.
The next item deals more with the human part of their organization: How do they develop their product, how do they perform project management, which KPIs are they collecting and why, which tools are they using and how is their team structured and trained.
And finally, basically as the proverbial “icing on the cake” for the day, we dive into code. Yes, we do code reviews during our process, on the one hand because we are technicians and are just blatantly curious how their code looks like, on the other hand because the code gives us another good idea on the quality of the systems and the maturity of the team.
The very last agenda item is a feedback session. We mentioned initially that we see this whole process as a free advisory meeting and as of this the target should gain something out of it, so we will tell them what we found and where we think they can improve.
Let's produce some paper
Once we are done with the whole process, maybe circled through a couple of Q&As in order to get everything right, it is time to write a report. If you are in the comfortable situation of having an external advisor, we recommend letting her write the report – that is the reason you are paying her money, right? ;-) If you have to write the report yourself, we would suggest to not writing it too extensively. In our experience, a report that focusses on the findings (positive and negative) and a couple of observations is more likely to be read than a couple hundred pages of texts and images. Store it together with your notes so in case there is a follow-up question during the further process or after the deal has been signed, you or your co-workers are able to answer this question based on your notes.
Hey, we’ve signed, now what?
Once the deal has been signed it is time to think about the Post Merger Integration (PMI). As the PMI process is complex enough to fill another blog post or two, we are not going into detail here. Just one thing: Make sure you hand over your findings and measurements to someone responsible for the PMI. At ProSiebenSat.1we have – additionally to the PMI process – an IT performance management team that dedicatedly advises the portfolio companies in all technical questions. If you have something like this, too, it would be also wise to handover the information to them.
And now is probably also a good time to work on your request lists, onsite agendas, etc. because as always you should have learned something from this due diligence and can improve yourself.
Help, help, I'm part of a ProSiebenSat.1 due diligence? What shall I do?
At first: Congratulations, you obviously managed to convince us that your company is awesome!
Now, don't panic! We will give you a few hints on how to be successful at a ProSiebenSat.1 due diligence.
Let us guide you through the process! Chances are high that we outnumber you on the number of due diligences we have seen and done and we're willing to guide you. We will let you know when we need something, we will let you know what we need and we will help you work out all questions you may be having.
Be open, don't try to hide things, because we will find them!For many people a due diligence feels a bit like an unannounced school exam and they are afraid to fail. This often leads to situations where they try to hide things or cheat on questions. And as it was in school (or with your mom, when she asked if you did your homework), there is a very high chance we find out. And when we do, we will take an even deeper look. We strongly suggest to be open and honest on all topics. Of course, this doesn't mean you need to present every skeleton in your closet. ;-)
Be prepared – have specialists ready to answer questions!We understand if you as a CTO don't know all nitty-gritty details of the system. Still we might have questions about those details and in that case please make sure someone is available who could answer those questions. You don't want everybody to know about the deal? No problem, just let us know beforehand and we will make up a plausible story for your team – trust us, we have some experience with this.
Never take feedback personally! As has been said before, take the tech due diligence process as a chance for free training or advisory. Like we mentioned, part of the process is that we will give you some feedback. Keep in mind, this feedback is never meant to be taken personally and we are also well aware that we might be criticizing your hard work which is why we focus on our observations. As always in life, your mileage may vary and there is more than one solution to a problem, but we ask you to take the feedback just as what it is meant to be: Our opinion.
Enough of theory, you must know a whole lot of war stories
Sure, we conducted quite some due diligences in the past and yes, some of them caused funny memories. Understandably we cannot tell you anything that would allow you to conclude on the target but for starters here are two funny campfire war stories:
The onsite visit of one (admittedly rather low-tech) target took place in a meeting room on the ground floor. On the opposite side of the street facing window was a sheet of paper pinned to the wall with the guest Wi-Fi credentials written on it. Well, not the best place to place it but if you want everyone to use your guest Wi-Fi, why not, what could possibly go wrong. During the setup, we realized there was no company Wi-Fi so we asked the CTO about this. He proudly told us that they set up their company Wi-Fi to not broadcast the SSID (that is what you call security through obscurity) and instead set up a second access point as guest Wi-Fi. During a break later on, we did a port scan of the "guest" network to see if we can find out how many people were using this. During the port scan, we discovered a couple of hosts with a running remote desktop server (VNC) on them. We started a local client and found that those were unprotected. The hosts we found were internal test servers with all source code files deployed on them in cleartext. Upon investigating we found out that instead of setting up a separate guest network the access point was on the same network and subnet as the hidden company Wi-Fi.
The next story happened also during an onsite of a slightly more mature start-up and is another very good example of a false sense of security. Due to the size and complexity, this onsite was planned to take place on two days. During the first day, we discovered there was a site to site VPN between the office location and the data center and there were no security measurements in place to prevent people from plugging own devices into the company's network. Still the CTO felt pretty confident because "we have a janitor at the entrance of the building who knows everyone so nobody can enter the building unknowingly." The first issue with this is of course that this doesn't prevent internal people to do harm. The next day we switched our business shirts with hoodies, waited outside until a group of people came from public transportation and entered the building with them - past the janitor. Coincidently they had to go to the same story as we, so we could just tailgate with them through the ID card protected door, went to our meeting room and waited for the CTO. When he entered the room 20 minutes later, wondering why nobody had called him that we were already there, we wished we would have taken a picture of his facial impression.
René Bruns - Senior Manager IT Due Diligence & Data @ProSiebenSat.1 Media SE
Alois Rühling - Software Architect @ProSiebenSat.1 Media SE