Gitlab’s Startup Acquisition Process

https://about.gitlab.com/handbook/acquisitions/acquisition-process/

by walterbell • 3 years ago

267 104 3 years ago

about.gitlab.com

breck• 3 years ago

This is awesome. Kudos to Gitlab for open sourcing this.

diceduckmonk• 3 years ago

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 ?

jsty• 3 years ago

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.

dnsmichi2• 3 years ago

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...

rubidium• 3 years ago

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.

ankit70• 3 years ago

Feels like created on Workflowy/RoamResearch with nested bullets. Great!

ericb4• 3 years ago

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?

jacquesm12• 3 years ago

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.

ericb4• 3 years ago

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."

bombcar• 3 years ago

Wouldn't a start-up that is considering being acquired (or raising) already have most of this available?

jacquesm12• 3 years ago

Depends on who starts the process. If the acquirer starts it then there may well be nothing at all.

moneywoes• 3 years ago

Seems like they could just steal a lot of info and then build their own version through this process

cs02rm0• 3 years ago

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.

jacquesm12• 3 years ago

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.

WJW• 3 years ago

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.

mbesto21• 3 years ago

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.

ericb4• 3 years ago

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?

paulsutter• 3 years ago

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

formercoder• 3 years ago

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.

jacquesm12• 3 years ago

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).

Cthulhu_2• 3 years ago

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.

mbesto21• 3 years ago

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.

wslh2• 3 years ago

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...

ericb4• 3 years ago

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?

Closi• 3 years ago

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!

mbesto21• 3 years ago

* 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).

paulgb• 3 years ago

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?

mbesto21• 3 years ago

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.

mbesto21• 3 years ago

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

   - 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

Experience that led to this type of work:

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.

DishyDev• 3 years ago

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?

mbesto21• 3 years ago

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.

awad• 3 years ago

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.

kinnth• 3 years ago

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?

mbesto21• 3 years ago

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.

jacquesm12• 3 years ago

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.

mbesto21• 3 years ago

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.

weird-eye-issue2• 3 years ago

You posted this 1 hour after he originally posted? Yikes, chill out

CSDude• 3 years ago

What's the rate of your reject rate, and what are the most common deal breakers, bad signs? It'd be helpful.

mbesto21• 3 years ago

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)

ryanSrich2• 3 years ago

What does your company charge for standard B2B SaaS acquisition technical DD?

mbesto21• 3 years ago

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.

Cthulhu_2• 3 years ago

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).

mbesto21• 3 years ago

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.

twodave• 3 years ago

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.

coreyrab2• 3 years ago

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?

mbesto21• 3 years ago

Can you be more specific? Do you mean like doing a DD on the product and sales strategy of the company that is being acquired?

brugidou• 3 years ago

How do you measure success? Do you follow up on these companies later on (acquired or not).

mbesto21• 3 years ago

Good question - we have a rating system where we compare companies on a variety of dimensions. If we find areas that need help post close, our clients engage us to work with the company.

di456• 3 years ago

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?

mbesto21• 3 years ago

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.

FearlessNebula• 3 years ago

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.

jen20• 3 years ago

Because VCs need returns, and many of these companies wouldn’t even exist without VC money.

jacquesm12• 3 years ago

Or because founders want to diversify. A founder is a non-diversified investor...

datasert• 3 years ago

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

rfrey2• 3 years ago

Wow - I can see why Paul Graham at one point talked about how exploring an acquisition can kill a company. Even at the "preliminary diligence" stage, a small company will have invested at least a month of the founder's time AND basically given away the keys to the kingdom - all their schemas, processes, customer lists, and contracts.

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.

ignite• 3 years ago

I don't know if this is still a common thing, but this definitely used to happen.

iamdamian• 3 years ago

It seems that Amazon did something similar under the guise of becoming an investor: https://news.ycombinator.com/item?id=23929044

bberenberg• 3 years ago

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-...

fatnoah• 3 years ago

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.

akamia• 3 years ago

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.

mbesto21• 3 years ago

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.

tptacek2• 3 years ago

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.

rfrey2• 3 years ago

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.

JumpCrisscross• 3 years ago

Your team will also pick up on the fact that you entertained exiting, then didn’t.

j0hnyl• 3 years ago

The Billion Dollar Code on Netflix is a dramatized story about this.

sidewndr46• 3 years ago

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.

jasonjei• 3 years ago

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.

mkeeter• 3 years ago

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

robertlagrant• 3 years ago

That tumblr site is great. Twitter has been busy.

paultopia• 3 years ago

Forgot step 6, layoffs.

pdq• 3 years ago

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".

fountainofage• 3 years ago

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.

tapotatonumber92• 3 years ago

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”.

sjhewitt• 3 years ago

"Minimal Viable Change"

https://about.gitlab.com/handbook/product/product-principles...

tapotatonumber92• 3 years ago

Thank you! This might be a useful term of art to bandy about my current work situation.

dnsmichi2• 3 years ago

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)

Gitlab’s Startup Acquisition Process

Related Stories