Gitlab’s Startup Acquisition Process(about.gitlab.com)
about.gitlab.com
Gitlab’s Startup Acquisition Process
https://about.gitlab.com/handbook/acquisitions/acquisition-process/
111 comments
It's a lot of time, but it's probably more important that it's psychologically destructive. As soon as you've invested any meaningful time into an acquisition discussion, it becomes very difficult to manage the company as a going concern and to make good long-term decisions about it. You're explicitly contemplating ending the company.
You mostly don't need the "don't talk to corpdev" advice once you've found product/market fit, unit profitability, whatever; it's more obvious whether the discussion is a waste of time or not. But early on, it's an especially hazardous thing to do, because you're not anchored to a specific conception of how your business is going to operate.
You mostly don't need the "don't talk to corpdev" advice once you've found product/market fit, unit profitability, whatever; it's more obvious whether the discussion is a waste of time or not. But early on, it's an especially hazardous thing to do, because you're not anchored to a specific conception of how your business is going to operate.
That's a super interesting point... even if you're fine financially and the acquirer doesn't sabotage you, you've fundamentally damaged the company by exploring acquisition.
Like if somebody goes from working hard on a marriage to seriously investigating divorce. Even if they decide divorce was too expensive or whatever, they're never getting back to even the problematic state they were in before they called a lawyer.
Like if somebody goes from working hard on a marriage to seriously investigating divorce. Even if they decide divorce was too expensive or whatever, they're never getting back to even the problematic state they were in before they called a lawyer.
To make matters worse, corp dev people are absolutely aware of the dynamics --- they're more aware of them than you are, because this is their entire job, where you might engage with it once or twice in a whole career --- and are selected for their expertise at manipulating the dynamic. They will, if they're seriously targeting you, deliberately bait a hook and keep you on the line long enough for walking away from a deal to be especially painful.
I think Paul Graham pretty much has this topic locked up and can't see how you'd express it better.
I think Paul Graham pretty much has this topic locked up and can't see how you'd express it better.
I investigated divorce months before marrying and we made sure that if it had to happen, like to 55% of mariages around us, we d make it as painless as possible rather than total chaotic surprise. I suppose there must be a corporate equivalent ?
Your team will also pick up on the fact that you entertained exiting, then didn’t.
I was a lead at a startup that was acquired and the acquisition process would have probably sunk us if the acquisition had not gone through.
We were in the middle of raising our next round when the offer came through. The founders and the board decided to accept the offer but it was still contingent on due diligence. While going through the due diligence process all funding conversations had to stop. Luckily we were small so the due diligence process only took 2 months but we had to tighten our belts. If the acquisition had fallen through, we would’ve been in real trouble because we burned 2 months of cash and would have needed to line up funding quickly.
We were in the middle of raising our next round when the offer came through. The founders and the board decided to accept the offer but it was still contingent on due diligence. While going through the due diligence process all funding conversations had to stop. Luckily we were small so the due diligence process only took 2 months but we had to tighten our belts. If the acquisition had fallen through, we would’ve been in real trouble because we burned 2 months of cash and would have needed to line up funding quickly.
Having gone through an acquisition by a different company, I can say that this process almost exactly matches the process I went through. It was definitely a lot of work that ate up tons of time. It also wasn't something that could be discussed with most of the company, so now you add a few months of "acting funny" to the mix and it's a challenge and a half.
Yes there is a risk of this. But, with modern tooling, you don't need to do this to accomplish the same goals. It's not hard to figure out the high level approach of what someone else is doing. It's not hard to figure out a significant number of their customers. There are entire companies that exist to answer these questions for you. Ultimately, if you're looking to sell your company, you will have to trust the acquirer. This isn't a GitLab thing, it's just the name of the game. I wrote a bit about selling my company a year ago [1] and it was similar, except a lot of the diligence happened post LOI / Term Sheet. In hindsight, I kind of wish it had happened earlier.
[1] https://www.nothingeasyaboutthis.com/lessons-from-selling-a-...
[1] https://www.nothingeasyaboutthis.com/lessons-from-selling-a-...
100% true. So people are aware, even if you get to an LOI, then there is usually an established close period (right now it's usually 30-90 days). That close period is intense and can absolutely derail the energy of the company.
Rob Ferretti, who runs a luxury and high performance car rental service has a podcast where he talked about this. He said a major US brand spent several months in talks to acquire the company then just walked away. He said they disclosed pretty much everything, since they had to prove they had revenue and were actually making money. A few months later they launched their own premium service.
I don't know if this is still a common thing, but this definitely used to happen.
It seems that Amazon did something similar under the guise of becoming an investor: https://news.ycombinator.com/item?id=23929044
The Billion Dollar Code on Netflix is a dramatized story about this.
Since this documentation heavily refers to Technical Due Diligence processes, I thought I'd offer an "AmA" since this is what I do for a living (personally have conducted 400+ Tech DD projects).
Disclaimer - I'm not a GitLab employee and they are not a client of mine, but their documented processes are very synonymous with what I do.
Disclaimer - I'm not a GitLab employee and they are not a client of mine, but their documented processes are very synonymous with what I do.
I’m curious about your career path. Did you start by doing it in-house and then go into consulting? Are you at a big consultancy or do you run your own specialty DD consultancy?
I love this question since my career path is so irregular. It'll take some time so lemme write a more detailed response in a bit.
Also interested on your answer. I'd love to work on this full-time!
Thirding. I've done a little of this as part of a job a while back and I think I'd really like doing more of it. Curious what kind of demand-volume there is for it, and especially if there are any adjacent services that people are willing to pay for (e.g. more social, looking into the management & process side of a tech org). Avenues for breaking in with sales for this, that kind of thing, would be greatly appreciated.
I'll answer this in two parts:
Me:
I personally have a very atypical career so please take this with a grain of salt. That being said, I think my weird background helped me to excel in this space
Here is my professional background
I started as a consultant in SAP's support group. Oddly, at a young age this gave me exposure to the technical/operational challenges of M&A as I sat in on a high profile customer who bought SAP and BOBJ integrated products before the company merged, and then had to deal with the companies/tech talk to each other post close. This was more "in the trenches" than it was strategic, but it help formulate how I thought about the strategy of M&A for companies. I then taught myself to code when I tried doing a web design agency and a startup. Failed miserably, but gave me a ton of empathy about what its like to be a (1) a founder (2) an engineer and (3) a business operator. After my last startup failed, I called an old friend of mine and luckily they were hiring. Their IT DD practice was small (it was 1-2 people) but growing. I came on and basically acted as a junior partner with one of the partners who led the practice. We quickly grew that to supporting ~100 deals/year. The company wasn't strategic about the work (they wanted large scale IT strategy gigs), so we split off and I start my own firm that focused solely in on IT/Tech DD. I then sold that company to my biggest competitor. I'm now an MD/Executive at that firm. My experience with hands on development, owning/operating a business, M&A, mix of enterprise software + implementation, and consulting (this can't be understated, there is a ton of value in knowing "how to be a consultant") is probably what really helped me excel in this space. Oh and now that I've sold a company myself, I have even more perspective :)
Typical person:
There are usually two types of personas that fit well: career consultants in tech M&A (think E&Y, West Monroe, KPMG, etc.) and operational leaders (e.g. seasoned CTOs, VP of Engineering, Head of Product, etc.). People who have done both are IDEAL. Personally I look for "athletes" or T-Shaped people. You need to be able to get very technical and then translate this to a financial person who doesn't know the difference between Java and JavaScript, which is a very unique skill in itself.
P.S. I have a huge demand Product people (market + technical) who want to help do Product Due Diligence + Product Strategy consulting. Please reach out if you're interested.
Me:
I personally have a very atypical career so please take this with a grain of salt. That being said, I think my weird background helped me to excel in this space
Here is my professional background
- SAP Consultant working for SAP (Data Analytics & Reporting)
- (Entrepreneur) Web Design Agency (failed)
- SAP Consulting (3rd Party Partner)
- (Entrepreneur) Startup (failed)
- Management Consulting (we were doing about ~15 IT Due Diligence projects a year when I joined)
- Left previous firm and started my own firm (Renna Partners), which exclusively focused on IT/Tech DDs (previous firm did IT strategy + DD was a small part of the overall biz)
- Sold my firm to my competitor (Crosslake), which is who I work for now
I started as a consultant in SAP's support group. Oddly, at a young age this gave me exposure to the technical/operational challenges of M&A as I sat in on a high profile customer who bought SAP and BOBJ integrated products before the company merged, and then had to deal with the companies/tech talk to each other post close. This was more "in the trenches" than it was strategic, but it help formulate how I thought about the strategy of M&A for companies. I then taught myself to code when I tried doing a web design agency and a startup. Failed miserably, but gave me a ton of empathy about what its like to be a (1) a founder (2) an engineer and (3) a business operator. After my last startup failed, I called an old friend of mine and luckily they were hiring. Their IT DD practice was small (it was 1-2 people) but growing. I came on and basically acted as a junior partner with one of the partners who led the practice. We quickly grew that to supporting ~100 deals/year. The company wasn't strategic about the work (they wanted large scale IT strategy gigs), so we split off and I start my own firm that focused solely in on IT/Tech DD. I then sold that company to my biggest competitor. I'm now an MD/Executive at that firm. My experience with hands on development, owning/operating a business, M&A, mix of enterprise software + implementation, and consulting (this can't be understated, there is a ton of value in knowing "how to be a consultant") is probably what really helped me excel in this space. Oh and now that I've sold a company myself, I have even more perspective :)
Typical person:
There are usually two types of personas that fit well: career consultants in tech M&A (think E&Y, West Monroe, KPMG, etc.) and operational leaders (e.g. seasoned CTOs, VP of Engineering, Head of Product, etc.). People who have done both are IDEAL. Personally I look for "athletes" or T-Shaped people. You need to be able to get very technical and then translate this to a financial person who doesn't know the difference between Java and JavaScript, which is a very unique skill in itself.
P.S. I have a huge demand Product people (market + technical) who want to help do Product Due Diligence + Product Strategy consulting. Please reach out if you're interested.
Here is a link if you want to apply: https://jobs.lever.co/crosslaketech/7b2e42ec-d873-443f-b30f-...
I love the idea of doing independent technical due diligence work after enjoying doing software auditing and investigations in my current job. Looking at Gitlab's processes it seems like company structure, finances and legal checks make up a lot of the investigation. The software/infra/tech side seems quite short (Gitlab suggest their early technical diligence should be turned around in 2-3 days).
Do you think there's enough demand out there to have a company that does just technical (e.g. software quality, security) due diligence?
Do you think there's enough demand out there to have a company that does just technical (e.g. software quality, security) due diligence?
> Do you think there's enough demand out there to have a company that does just technical (e.g. software quality, security) due diligence?
My company (used to, we've grown to do other things) only do Tech DD and we've done really well, so the answer is yes. According to Pitchbook there are about ~3,000 software company acquisitions every year - so that might tell you how much potential business there is.
My company (used to, we've grown to do other things) only do Tech DD and we've done really well, so the answer is yes. According to Pitchbook there are about ~3,000 software company acquisitions every year - so that might tell you how much potential business there is.
[deleted]
There are consultancies who provide these DD services certainly as a line of business, if not their entire business. Like any other professional services enterprise, a lot of it depends on your network and ability to generate new business, especially in the early days. If you're not in the position to do it yourself, perhaps there are opportunities to get involved on a contractor basis with firms that do.
AMA Question - Does a process like this help you make better acquisitions, or is there still an art in picking the right startup at the right time for a business?
My firm doesn't acquire the companies themselves, we work with companies (like Gitlab) or private equity firms who acquire businesses to help them understand the technology. So our clients pick the startup and they usually have a thesis for acquisition. During diligence it's their opportunity to confirm or deny that thesis, and as an objective, third party set of expert eyes we can help them do that.
What's the rate of your reject rate, and what are the most common deal breakers, bad signs? It'd be helpful.
So we just advise on things that might constitute as "red flags", however ultimately our clients make the decision to break a deal. I would say its about 5%~10% rejection rate (some clients are more risky than others), and it's very rare that tech alone is the deal breaker. When tech is an issue, it's usually combined with some business issue (example - it takes 3 months to onboard a new client and the company has little automation for data migration, so they won't scale well)
Thanks!
* What are the most common gotchas?
* What tools do you use to do the technical due diligence?
* What would you suggest to prepare for it?
* What would acing it look like?
* What are the most common gotchas?
* What tools do you use to do the technical due diligence?
* What would you suggest to prepare for it?
* What would acing it look like?
* What are the most common gotchas?
Surprises! We don't like surprises, and nor do our clients. From a tech perspective - dated tech, unmanageable (or no clarity of) tech debt, NIH syndrom
* What tools do you use to do the technical due diligence?
OSS scanning and security scans mostly
* What would you suggest to prepare for it?
I'l try to answer this simply, which is - read GitLabs documentation and if you have similar and more importantly - actually operate this way, then you'll be more than prepared.
* What would acing it look like?
As I mentioned below, there is no pass/fail. Acing it is - be honest, be prepared, and have a plan (not for the tech dd itself, but rather a plan for your business).
Surprises! We don't like surprises, and nor do our clients. From a tech perspective - dated tech, unmanageable (or no clarity of) tech debt, NIH syndrom
* What tools do you use to do the technical due diligence?
OSS scanning and security scans mostly
* What would you suggest to prepare for it?
I'l try to answer this simply, which is - read GitLabs documentation and if you have similar and more importantly - actually operate this way, then you'll be more than prepared.
* What would acing it look like?
As I mentioned below, there is no pass/fail. Acing it is - be honest, be prepared, and have a plan (not for the tech dd itself, but rather a plan for your business).
What makes something like outdated tech a "surprise", rather than just "reality"? As in it was actively hidden from you, or just not something anyone thought worth mentioning until it came time to plow through the code?
"Surprise" could be interpreted a few different ways. Here's an example to elaborate:
- Company being acquired ("Target") built a web based application in the mid-2000's using VB.NET and each client installed the software. It requires a desktop widget to be installed at their clients locations to talk back to the VB.NET web backend. In 2016 they switched their licensing model from perpetual license to subscription and now the web application is hosted by the target and not the clients.
- Target tells acquirer they have a "SaaS" application.
So, now its a VB. NET web app with single tenants hosted on the Target's data centers. Not untenable, but the acquirer was probably expecting a multi-tenant SaaS web app in a more generally supported web framework.
And, yes I've absolutely seen this case (or something very similar) in the wild.
- Company being acquired ("Target") built a web based application in the mid-2000's using VB.NET and each client installed the software. It requires a desktop widget to be installed at their clients locations to talk back to the VB.NET web backend. In 2016 they switched their licensing model from perpetual license to subscription and now the web application is hosted by the target and not the clients.
- Target tells acquirer they have a "SaaS" application.
So, now its a VB. NET web app with single tenants hosted on the Target's data centers. Not untenable, but the acquirer was probably expecting a multi-tenant SaaS web app in a more generally supported web framework.
And, yes I've absolutely seen this case (or something very similar) in the wild.
I'm not OP, but when I experienced due dilligence the thing I found counter-intuitive was that 'looking really good at everything' isn't actually the best approach.
As an example - it might be better that the company doing Due Dilligence finds you awful at sales during the DD phase, because they will see that you got revenue despite poor sales technique and they will see it as an easy target for improvement / 'to generate value'. Companies want to identify ways that they would be able to help the company they are aquiring.
Not sure if this applies to Technical DD, but thought it was interesting enough to share!
As an example - it might be better that the company doing Due Dilligence finds you awful at sales during the DD phase, because they will see that you got revenue despite poor sales technique and they will see it as an easy target for improvement / 'to generate value'. Companies want to identify ways that they would be able to help the company they are aquiring.
Not sure if this applies to Technical DD, but thought it was interesting enough to share!
Yes, that's called 'hidden upside'. You can of course also disclose this before DD. As a rule, surprises during the DD process are to be avoided if you can, even positive ones (because you may lose out on a bid from a party that would have bid if they had been aware of it).
source: yaddp.
source: yaddp.
Exactly this. You don't pass or fail Tech DD...it's more to provide comfort to the buyer.
OP is specifically talking about tech due diligence which is specific within due diligence in general.
One thing that appear in tech due diligence is quality of the technical architecture and implementation, and security risks associated.
One thing that appear in tech due diligence is quality of the technical architecture and implementation, and security risks associated.
And: quality of the people... if there is one distinguishing factor it is that one. Bad tech can be fixed, and if there is a competent team that got put in charge of a pile of tech debt then there is hope.
Excellent topic, my company also does technical due diligence. Even so, beyond acquisition, regarding investments we see that founders networking and promises take over technical capabilities. Not the same for pure acquisitions. Shameless plug: [1]
It would he great if the HN community could comment more about this topic beyong the Gitlab's article.
[1] Fundamental Analysis of Web3 Technologies: https://blog.coinfabrik.com/fundamental-analysis-of-web3-tec...
It would he great if the HN community could comment more about this topic beyong the Gitlab's article.
[1] Fundamental Analysis of Web3 Technologies: https://blog.coinfabrik.com/fundamental-analysis-of-web3-tec...
[deleted]
> Customer list with name, monthly revenue, contract termination date and any other fields if relevant.
Could you compare and contrast this analysis for companies with a small number of large customers, vs a large number of small customers? What are you looking for? What are examples of good or bad surprises?
Could you compare and contrast this analysis for companies with a small number of large customers, vs a large number of small customers? What are you looking for? What are examples of good or bad surprises?
These are more business/commercial questions, but they typically manifest themselves in Tech DD when it comes to implementation, which is what we might look at.
Do you have an example of your work? I'm curious what a report looks like, having done only a couple of 'code reviews' myself (that is, I got a codebase and three days to write a report on how it could be improved, not very formal at all).
I'd love to share this, but unfortunately our reports belong to our clients so it would be really hard for to disclose an example to the public.
Do you know of any documents similar to what you do that have been disclosed to the public, or is this a sub-industry that us completely opaque to outsiders?
It would be interesting if you did some open source project of sufficient size or something. (Unless it’s not a one-to-one or something)
[deleted]
I've been a part of a few of these, and it really just depends. Overall, though, the report will break down the company into a bunch of different categories (and not just from a code/tech stack standpoint). Sometimes you'll get a point-rating (1-10 or whatever) or a market-based rating (e.g. degrees worse, comparable or better than their competition in a category).
The audit may encompass anything from code quality, technical debt, tech stack, architecture, infrastructure, to the product roadmap, licensing of dependencies, corporate structure, hiring/retention of talent, etc. It really just depends on what the company paying for the DD asks for (which could be either side, and that also matters a lot).
Each category in the final report will have a summary, a score, notes about risks/opportunities, suggestions on how to improve, what things are strengths, etc. It can be really, really long, and often it's broken up and worked on by multiple people based on their area(s) of expertise. Usually you'll see a high-level summary chart at the end of the report that just kind of puts everything in front of you.
The audit may encompass anything from code quality, technical debt, tech stack, architecture, infrastructure, to the product roadmap, licensing of dependencies, corporate structure, hiring/retention of talent, etc. It really just depends on what the company paying for the DD asks for (which could be either side, and that also matters a lot).
Each category in the final report will have a summary, a score, notes about risks/opportunities, suggestions on how to improve, what things are strengths, etc. It can be really, really long, and often it's broken up and worked on by multiple people based on their area(s) of expertise. Usually you'll see a high-level summary chart at the end of the report that just kind of puts everything in front of you.
This is a very good summary of what deliverables look like.
What does your company charge for standard B2B SaaS acquisition technical DD?
Unfortunately, I can't disclose that, but I can tell you what market rates tend to be. I've seen firms in this space charge anything from $10k to $150k per deal. The lower end tends to be the "one man shop" and the larger end tends to be more established advisory firms who work on large and or complex deals.
That sounds… cheap. Like that’s less than the monthly take home for a single non descript engineer.
Yeah I think having an hourly rate would have been more useful, but I appreciate their reply regardless.
I’ve done DD for a small SaaS acquisition. But from the sell side. It was a decent amount of work providing access, diagrams, answering questions, etc. I would think anywhere from $150-$300/hour depending on the deal size.
I’ve done DD for a small SaaS acquisition. But from the sell side. It was a decent amount of work providing access, diagrams, answering questions, etc. I would think anywhere from $150-$300/hour depending on the deal size.
Quite the contrary. The projects last 2~3 weeks.
Where are you making $150k a month and are you hiring?
> the larger end tends to be more established advisory firms who work on large and or complex deals.
I'd assume the higher end includes the auditing company holding a pile of compliance certs. Those can be pretty expensive to pick up.
AMA question: I've never personally been through this process, but I assume go-to-market DD is typically part of the process. Are there specialized firms that handle that side of the equation?
If you want to do an AmA you should probably do some answering... I don't feel like hijacking your thread but really, those are important questions.
More than happy for you to answer as well - I respect your opinion on this topic.
P.S. - don't really appreciate the snarky "you should do some answering"... as a fellow busy professional, I'm answering when I have the time to do so.
P.S. - don't really appreciate the snarky "you should do some answering"... as a fellow busy professional, I'm answering when I have the time to do so.
It wasn't snarky, more that if you're going to do an AmA that kind of puts the ball in your court and you really should use the opportunity because if you don't have time now then it might be better to do this as a separate 'Ask HN' or something to that effect.
This subject is very dear to a lot of the HN crowd and of course you as the initiator of that process should get the first shot at answering these questions, they are all super relevant and very practical. You might even want to do a formal write-up of the answers you get in a blog post.
This subject is very dear to a lot of the HN crowd and of course you as the initiator of that process should get the first shot at answering these questions, they are all super relevant and very practical. You might even want to do a formal write-up of the answers you get in a blog post.
You posted this 1 hour after he originally posted? Yikes, chill out
This is an impressively thorough and quite insightful M&A overview.
However, it is completely one-sided toward the buyer (ie GitLab).
As a seller, I'd be wary of going through even a fraction of the pre-term-sheet diligence and disclosure, without getting to a ballpark on acquisition price (or price methodology) beforehand.
Also, they don't mention, but having escrow set up as an insurance in case the acquirer backs out also seems necessary (ie % of the deal held with third party). Otherwise you are basically giving away all your company secrets and time, and if they back out, you get nothing.
I'd guess YCombinator has something equivalent from the seller side. It would be great if they shared their M&A handbook at some point in the future, although I understand it's probably considered "secret sauce".
However, it is completely one-sided toward the buyer (ie GitLab).
As a seller, I'd be wary of going through even a fraction of the pre-term-sheet diligence and disclosure, without getting to a ballpark on acquisition price (or price methodology) beforehand.
Also, they don't mention, but having escrow set up as an insurance in case the acquirer backs out also seems necessary (ie % of the deal held with third party). Otherwise you are basically giving away all your company secrets and time, and if they back out, you get nothing.
I'd guess YCombinator has something equivalent from the seller side. It would be great if they shared their M&A handbook at some point in the future, although I understand it's probably considered "secret sauce".
It's basically don't waste your time with corp dev. http://www.paulgraham.com/corpdev.html
You hit the nail on the head that it's way too much work when there's not even a contingent offer on the table. A real buyout would come in with either a stated sum, or a methodology for how that sum will be calculated.
You hit the nail on the head that it's way too much work when there's not even a contingent offer on the table. A real buyout would come in with either a stated sum, or a methodology for how that sum will be calculated.
Pretty cool that they shared the process. A couple things that seem interesting to me:
* Giving the acquirer the cap table early on seems to go against the advice I've seen.
* This is a ton of time investment for a company that has no idea if an offer will be forthcoming, or if it would be in a ballpark where a deal would happen?
The acquiree is supposed to go through 12 stages of diligence a code review, detailed financials, employee review, give out their roadmap, customers, vendors, cap table, source code, financial assets all before seeing any hint of what the offer will be or whether there will be one?
Is that right? Wouldn't getting an idea of whether you're in the same neighborhood be sensible before demanding so much?
* Giving the acquirer the cap table early on seems to go against the advice I've seen.
* This is a ton of time investment for a company that has no idea if an offer will be forthcoming, or if it would be in a ballpark where a deal would happen?
The acquiree is supposed to go through 12 stages of diligence a code review, detailed financials, employee review, give out their roadmap, customers, vendors, cap table, source code, financial assets all before seeing any hint of what the offer will be or whether there will be one?
Is that right? Wouldn't getting an idea of whether you're in the same neighborhood be sensible before demanding so much?
> Giving the acquirer the cap table early on seems to go against the advice I've seen
The cap table tells a story about the company. For starters it identifies the decisionmakers. More importantly, a hairy complex cap table says an acquisition process may be difficult and unpredictable. A straightforward cap table is like a well maintained roof on a house. It doesn't prove that the rest of the company is in order, but its highly correlated
Start by sending a summary cap table of major holders with the breakdown among classes of stock
The cap table tells a story about the company. For starters it identifies the decisionmakers. More importantly, a hairy complex cap table says an acquisition process may be difficult and unpredictable. A straightforward cap table is like a well maintained roof on a house. It doesn't prove that the rest of the company is in order, but its highly correlated
Start by sending a summary cap table of major holders with the breakdown among classes of stock
> This is a ton of time investment for a company that has no idea if an offer will be forthcoming, or if it would be in a ballpark where a deal would happen?
But the work can be reused for other candidates, and... this is about multi-million deals, the work will pay itself off.
I heard about a financial guy working his ass off (nights, weekends) for weeks if not months on end on getting part of the company acquired or sold off; in the end the deal was worth €100M, and I'm confident he owned a significant chunk of the part sold. I wouldn't mind working weekends / evenings for a while if it was for a "you can retire" sum of money.
But the work can be reused for other candidates, and... this is about multi-million deals, the work will pay itself off.
I heard about a financial guy working his ass off (nights, weekends) for weeks if not months on end on getting part of the company acquired or sold off; in the end the deal was worth €100M, and I'm confident he owned a significant chunk of the part sold. I wouldn't mind working weekends / evenings for a while if it was for a "you can retire" sum of money.
> Giving the acquirer the cap table early on seems to go against the advice I've seen.
Why?
Captables are for the most part just process documents, you need to know who has which quantity of shares to be able to put a proposal for a deal on the table. If you don't know who holds the shares you may not even be able to make a proposal at all, and you may not be able to verify that the person that makes the offer to sell has the right to do so.
Why?
Captables are for the most part just process documents, you need to know who has which quantity of shares to be able to put a proposal for a deal on the table. If you don't know who holds the shares you may not even be able to make a proposal at all, and you may not be able to verify that the person that makes the offer to sell has the right to do so.
I think the reasoning is something like, when I buy a car, I don't base the price I'll pay on the cost of the raw materials.
It also lets them craft a minimal price deal, and do things like split out different shareholders based on what they'll likely accept.
Not particular to the cap table, but the same with the financials here. If gitlab sees they have only one month's runway, why wouldn't they lowball?
Generally speaking, if gitlab sees 40 million in revenue potential, shouldn't that be how they craft what they offer?
There's probably a distinction here between "selling" your business, and "being acquired."
It also lets them craft a minimal price deal, and do things like split out different shareholders based on what they'll likely accept.
Not particular to the cap table, but the same with the financials here. If gitlab sees they have only one month's runway, why wouldn't they lowball?
Generally speaking, if gitlab sees 40 million in revenue potential, shouldn't that be how they craft what they offer?
There's probably a distinction here between "selling" your business, and "being acquired."
Sure, but it helps if you can show who actually owns the car. And a captable is pretty much just that: a division of who owns which chunk of the company. No need to disclose what they paid for it, that's not the acquirers' business anyway.
Seems like they could just steal a lot of info and then build their own version through this process
Does seem odd to expect to share code early and a risk to share it with any interested party.
I mean, it's someone else's code, your engineers are going to say it's rubbish, it needs a full rewrite and throwing away, warn us up front before you even think about acquiring such terrible code, etc. But if it's a built a company to the point of raising sufficient revenue/profit it's surely good enough.
I mean, it's someone else's code, your engineers are going to say it's rubbish, it needs a full rewrite and throwing away, warn us up front before you even think about acquiring such terrible code, etc. But if it's a built a company to the point of raising sufficient revenue/profit it's surely good enough.
It is. Normally you only do that after you agree on the terms and that means there is a deal unless something horrible is found during DD. And if your code is terrible simply disclose it then likely the requirement will go away. But if you claim it is super good but you only have juniors on staff you can expect to be quizzed.
Yes, this happens. So be very much on your guard about this and make sure that you trust whoever you talk to and if you can't trust them then you can ask a trusted party to do the review for you and pass that to whoever claims to be interested.
There are many variations to this kind of 'vendor dd', you can prepare it beforehand or you can push to have the process modified until it is to your liking depending on how desirable you are.
There are many variations to this kind of 'vendor dd', you can prepare it beforehand or you can push to have the process modified until it is to your liking depending on how desirable you are.
Not that that never happens, but engineering time is not cheap even at Gitlab scale. Even if you manage to recreate the product based on the insider info it's still a risky process; new products fail all the time, especially if they are new entries in an already filled market.
It's much quicker and often not that much more expensive (after you tally up all the engineering and marketing costs and adjust for the risk of failure) to acquire a company that already has a working product, customers, marketing, documentation and usually you get a team of domain experts included in the purchase.
It's much quicker and often not that much more expensive (after you tally up all the engineering and marketing costs and adjust for the risk of failure) to acquire a company that already has a working product, customers, marketing, documentation and usually you get a team of domain experts included in the purchase.
If there’s one thing you learn quickly about doing M&A it’s everyone does a lot of work that might not result in a transaction.
That gets expensive. A typical VC that does a bunch of these without being able to follow through will rapidly find their management fees exhausted (because that's where quite a few of them fund failed DDs from, a typical DD budget is anywhere from 150K to 500K depending on the deal size, that includes legal, financial, technical, commercial, possibly an evaluation of the founders and whatever else is deemed necessary).
I think this is more of a technical/operational process, and less about the financial/legal one. Typically there is a "LOI" (Letter of Intent) that kicks off the DD process. That stipulates the acquisition price, any key terms (cash vs stock), etc.
I agree. It seems like they are trying to be transparent and detailed, though, and I don't see that in their list, and the negotiations only appear around step 13?
Gitlab's Handbook [0] (which this article is part of) is an invaluable resource for any first time founders. This is one of the best contribution of Gitlab to the community in my opinion.
[0] https://about.gitlab.com/handbook
[0] https://about.gitlab.com/handbook
Why does everything need to be acquired these days? Why do we consolidate everything into a few big companies? Why can’t we just have technology spread out across multiple players.
[deleted]
This is awesome. Kudos to Gitlab for open sourcing this.
> The call must include the Product champion and may also include Stage Leaders
I was not familiar with these roles before this article. Are they more colloquially known in the M&A world ?
I was not familiar with these roles before this article. Are they more colloquially known in the M&A world ?
They’re roles (intentionally flexible in the who) ascribed for the particular acquisition target. In M&A you have 2 main stages, the (1) find interesting targets and confirm they’re interesting, and (2) the purchase and integration.
The champion will often lead (1) but if they’re too busy may have a defined stage leader to make sure the trains keep moving well. In the later stage of (2) the stage leader will typically be someone with experience integrating companies. It’s an art.
I wouldn’t say they’re agreed on definitions, but I got what they meant from my exposure to M&A.
The champion will often lead (1) but if they’re too busy may have a defined stage leader to make sure the trains keep moving well. In the later stage of (2) the stage leader will typically be someone with experience integrating companies. It’s an art.
I wouldn’t say they’re agreed on definitions, but I got what they meant from my exposure to M&A.
GitLab team member here.
"Stage leaders" is specific to GitLab, referring to the stages of the DevOps lifecycle [1]. Stages are part of the product hierarchy definition [2], with sections, stages, groups, categories, features. Maybe the term is similar to "product group leader" in other areas.
FYI, created a merge request to link the product handbook from the acquisitions handbook, providing more context on stage leaders. [3]
[1] https://about.gitlab.com/handbook/product/categories/#devops...
[2] https://about.gitlab.com/handbook/product/categories/#hierar...
[3] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
"Stage leaders" is specific to GitLab, referring to the stages of the DevOps lifecycle [1]. Stages are part of the product hierarchy definition [2], with sections, stages, groups, categories, features. Maybe the term is similar to "product group leader" in other areas.
FYI, created a merge request to link the product handbook from the acquisitions handbook, providing more context on stage leaders. [3]
[1] https://about.gitlab.com/handbook/product/categories/#devops...
[2] https://about.gitlab.com/handbook/product/categories/#hierar...
[3] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
From the context Product Champion would seem to be using "champion" as in the B2B sales world - usually someone advocating the purchase of a particular vendor's solutions, here someone inside GitLab advocating to buy a particular company.
One interesting tidbit from the handbook:
A good acquisition target company should be "willing to sunset old customers within 90 days or less, with an option to transition to GitLab" [1]
Given the pattern of startups being acquired, announcing "nothing will change", then sunsetting their original product [2], it's interesting to see this spelled out so plainly.
[1] https://about.gitlab.com/handbook/acquisitions/#acquisition-...
[2] https://ourincrediblejourney.tumblr.com/ is the canonical repository of these emails
A good acquisition target company should be "willing to sunset old customers within 90 days or less, with an option to transition to GitLab" [1]
Given the pattern of startups being acquired, announcing "nothing will change", then sunsetting their original product [2], it's interesting to see this spelled out so plainly.
[1] https://about.gitlab.com/handbook/acquisitions/#acquisition-...
[2] https://ourincrediblejourney.tumblr.com/ is the canonical repository of these emails
That tumblr site is great. Twitter has been busy.
This is a great process write up, but I was surprised how little was addressed about existing target company customer support and communication. There is ample support for internal stakeholders, but what about customers of the target company?
I have found that as a customer of products acquired by larger companies, the customers of products being acquired and integrated into a larger product are often forgotten and sidelined.
I have found that as a customer of products acquired by larger companies, the customers of products being acquired and integrated into a larger product are often forgotten and sidelined.
Forgot step 6, layoffs.
Can anyone expand “MVC” as used in this guide? It appears as
“Outline a simple integration timeline for those features, considering an MVC release on the first month …”
I’m only familiar with this meaning Model-View-Controller. In this context I’d probably expect “POC”.
“Outline a simple integration timeline for those features, considering an MVC release on the first month …”
I’m only familiar with this meaning Model-View-Controller. In this context I’d probably expect “POC”.
"Minimal Viable Change"
https://about.gitlab.com/handbook/product/product-principles...
https://about.gitlab.com/handbook/product/product-principles...
Thanks a lot for helping :-)
I've created an MR to link MVC in the handbook: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
(GitLab team member here)
I've created an MR to link MVC in the handbook: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
(GitLab team member here)
Thank you! This might be a useful term of art to bandy about my current work situation.
Feels like created on Workflowy/RoamResearch with nested bullets. Great!
I know there would be non-disclosures in place, but it's easy to imagine a company less scrupulous than Gitlab basically cratering a potential competitor without the resources to go after them in court.