In episode 5 of High Leverage, host Joe Ruscio and special guest Eliran Mesika of GitLab pull back the curtain on company acquisitions, build vs. buy considerations, and the complex inner workings of merger agreements.
About the Guests
Joe Ruscio: OK. Welcome back. We've got another episode of High Leverage, thanks for joining us. Today I've got in the studio a very interesting guest, Eliran Mesika. Great to have you here.
Eliran Mesika: Hi, I'm happy to be here. I'm excited to talk about our topic today.
Joe: Yeah. It's one that's very, in some ways, near and dear to my heart. Your current role, you're at GitLab and you're director of partnerships.
Eliran: Yeah. I've been in GitLab for three years now next month. I've started building basically all of our partnership activities, and now transitioned just a couple months ago into focusing solely on acquisitions.
Joe: Right. More of a corporate development style role?
Joe: Excellent. That's really what we're here to talk about today. I'm very interested in some of our audience to pull the curtain back a little bit on how MNA works, or corporate development works.
From both a startup founder like a dev tool startup founder, or on your side of the table now, on the acquiring company's side.
I think it would be helpful though before we jump right into that, and I've got a bunch of things I want to talk about, but could you give just a quick overview--
I'm super familiar with it, but for any of the audience who is not, what specifically does GitLab do? I'm going to guess it has something to do with git?
Eliran: Yes. It all started with code repo, or source code management, but GitLab is your entire dev ops tool.
Joe: Right. It's gone much further than that now.
Eliran: Yes. We started with repo, as I said before, so you'd have everything basically that you need for your dev ops lifecycle.
Everything from planning your code and your work that you want to be working on, so issue tracker, to code review and code management, to leading into CICD monitoring that's built into the product.
Making sure your code is secure with scanning and everything that happens when you build code, and then when you push your application, and going back to active remediation for enhanced security.
And back to the overall analytics of how your team works and operates as a team and as a group, how efficient are you at building and releasing software?
Joe: We're covering, like you said, the full dev ops spectrum and the feedback loop . From code, to test, to production, to security.
Joe: It's been fascinating, having watched Sid and company create it and watch it come up, and it's become really a huge force.
It's very cool to have someone here on the podcast to talk about it, so let's just dig in.
Corporate development, MNA, what does that mean to you? What is the goal of a company, typically? I think that would be helpful for some of our listeners.
Why do companies buy other companies?
Eliran: There are a number of reasons why companies would focus or try to target acquisitions.
It could be everything from trying to capture more market share or try to limit market exposure in terms of threat protection.
It could be adopting or expanding into different industries or adopting a new business model that they could then leverage to existing products, it could be an acqua-hire.
It could be a whole slew of different reasons why you would want to acquire an asset or actual company in terms of a stock equity purchase that you'd want to facilitate.
Joe: Yeah, there's a range of different outcomes like you said. Just to maybe restate, you'd buy a company, like you said, if you were looking to move into a big new market and there's an established player there and it's a very big a deal.
It's a call to creative, where you're expected to pretty quickly start generating revenue back into your your bottom line revenue and then you move down into potentially more, and I think especially for a lot of startups because I think more acquisitions tend to get done.
There's a distribution. You have the headline monster exits and back 10 years ago $250 million or whatever was a monster creative exit, and now the numbers are a lot bigger.
Although those grab most of the headlines and certainly have a bunch of whatever people are striving for, there's this long tail of strategic exits where you're buying a company-- That's more of a build versus buy, right?
Joe: Because the strategic exit is not going to immediately start delivering revenue.
Eliran: Yes. When you look at that specific type of acquisition, you have two.
The build versus buy, or you or have maybe also a private equity purchase to buy a business that you believe or they believe they can build to a better more successful business in a very short time frame.
We're talking about a year to three years to then spin off again. When you really focus on that you have these two types of of deals that we're talking about.
Our approach is also very much along those lines as well.
Joe: An interesting side note left as an exercise to the listener, private equity has become in the last three to four years, a pretty interesting force in software as a service.
Eliran: They identified the growth potential in that industry and of course they want to capitalize on that with the funds that they have.
Also, I think that the appetite that founders have as well when they're approached with that perhaps bigger offering compared to other software or service companies when they're going head to head.
Joe: If you put yourself more in the founder's shoes-- so you have founders who started a company, they've probably raised some amount of funding and they've made certainly significant progress of some kind on revenue or traction, or whatever.
How do you see founders typically decide-- What causes them start thinking about potentially exiting through an acquisition versus going on to the next round of financing?
Eliran: From my experience and having talked to a lot of founders, it could be a number of reasons.
The first one, if we're talking about perhaps a smaller company, it'll be some maybe fatigue that the founding team has around maintaining that company. And of course scaling it.
They may have been doing this for a number of years and they realized that's not exactly what they had in mind or envisioned what founding a company and growing a company would be like.
They maybe enjoy something else, maybe writing code or spending more time on that as opposed to hiring people and scaling a team and managing an executive team.
They realize if they want or need to be sustainable to go to the next stage, which was what you said, to do another round--
That means going bigger, that means more of probably the same things that they perhaps do not enjoy as much. That is probably one of the main reasons to go into that.
The second reason that I've found popular or more frequent is that the company-- Maybe not touched upon much really in the talk around this topic is the companies are growing but not growing fast enough to to raise a fund or another round.
They may be growing, which we're talking about a double-digit range of growth, but that's not good enough for investors these days.
So they're stuck in that position, "Do you want to be a "small business" and maintain as a small office, small business setting? Selling our software to a select group or a small audience?
Or do we sell it off and join to be part of something bigger, try to get more distribution or get our product into more hands via that channel?"
Joe: That's an interesting observation, especially for venture-backed companies where with each subsequent round of financing there's two things.
One is, as you've mentioned, the set of metrics that are typically applied at that next round or next level, you have to meet those.
There's always exceptions, but generally speaking you can be growing at a rate that most private or bootstrap companies would be ecstatic about, but that the venture community out of necessity of the crazy math that drives that, can't make work for them.
Then I think compounding things, even if you've just scraped through to that level or you're meeting the bare minimums, if you go on and do that and close the round then at the next level you've got to be confident that-- it's this compounding problem.
Joe: I don't know what you've found, but certainly I think the series B is always a very interesting question point.
The other thing, how do you feel about the number of acquirers at each increasing level of valuation? I have an opinion here, but--
Eliran: What do you mean, exactly?
Joe: Companies generally have a range of price points they're willing to pay.
Joe: A deal size that works for one company will not work for a company that's dramatically smaller than it, right?
The other thing is with each next round of financing you go on you reduce the number of potential companies who could acquire yours.
Eliran: Yes, correct.
Joe: I think it's always healthy for a founder alongside of one staying at their next fund raise strategy, you just have a gut check and say "Is this a local maximum that we're at right now?"
I'm a big fan from a founder perspective of exiting at a local maximum.
Eliran: I think it's a healthy approach, also. Before you go into the next decision point of doing another round it's always good to try and validate "Where are we today? What's our alternative to doing this round?
Is it going to be a better outcome if we try to fast forward the next year or two? How did things play out? Maybe this is a better route for us in terms of what we want to achieve together."
Joe: Say I'm a founder who's decided "I'm not sure about this--"a lot of times people talk about dual-track process, which means I'm both going to talk to some investors as well as talk to some corp dev people.
We could have a whole discussion over how well that works in practice, but say I'm a founder who is like "I'm gonna run dual-track, or I'm just going to talk to a few companies."
What what do you recommend? How should they start thinking about MNA? How is it different from raising financing, how is it the same from raising financing?
Eliran: I think it's very different.
If you want to build to a successful acquisition that's going to be more than just your exit point and completing the deal, the way I think founders should be looking at this is--
When you look to start a conversation with an acquiring company you need to understand what you bring to the table and what value you can deliver.
Both from the six to twelve months period, which will typically be your integration period or phase, and then the next point which is probably more interesting is what value you can add to that company from that point onward.
After that 12 months, the first 12 months of integration, that's where the key to the answer is.
If you believe you can provide a lot of value, that's something you also need to invest time into analyzing the acquiring company.
How do you fit into that, and trying to think about different value you can bring to that company.
So that's more of an exercise in not an impromptu "I'll just start a conversation with an acquiring company and see what--"
You're not going to the supermarket and trying to get a better deal for whatever auction you want to raise for a simple product. It's more a conversation to lead into.
Joe: Yeah, the output of that exercise may be wildly different for different potential acquirers.
Depending on-- Some companies may find themselves looking at potential acquirers in two different spaces, for instance, and their value to those two different spaces is-- How you present it and how you frame it, how you calculate it could be totally different.
Eliran: One of the main principles of the whole concept of negotiations is what value you can add to the deal.
It's not just the basis of a deal that we both see, it's what value we can add to that deal.
That's more, as I said, it's more of a complex situation where you need to put time and effort into it.
As you said, it will vary drastically between one company to the next, require a whole different set of focuses compared to running a funding round.
Joe: Right. Where it's actually, it's in some ways much more abstract.
Eliran: Yes. Also I think probably at that point you'll be post one or two rounds so you'll be more exercised in that, and you'll probably have more accessible resources to build to the next round.
Your level of fitness for that exercise is higher probably than engaging in an acquisition conversation.
Joe: Yeah. The other thing that I found fascinating, having both sold a company and having spent a bunch of time on corp dev in a more strategic role at the company that acquired us, is how much--
Unlike venture financing where venture capitalists typically are always looking to deploy capital, and "Can they do 10 deals in one week? No.
But can they string those together in a fairly tight succession? Can they do a couple of things at once?" The majority of corp dev teams, however, outside of a few exceptions-- Timing's really critical.
Because you could have something where everything makes sense, everything's lined up, but the company is actually acquiring something else right now.
Eliran: Yeah. I think typically when you look at corp dev teams, and those are probably usually in a bigger company setting, timing is very critical and it depends on what type of deal they're trying to structure.
Those will probably also open up to a competition where if I'm the company being acquired, I'll likely try to open that conversation with multiple companies.
That timing is getting even more sensitive to "Who's coming first? Who will have the better offer for me? Who will structure a better deal for me and the team?"
I think the timing is also a factor in that competition setting as well.
Joe: Yeah, I think in that way it's probably somewhat similar to any process where you're selling something. The more concurrent demand you can foment, the higher the likely price to clear the market.
I think there's definitely an art to what you said earlier, going through the exercise of identifying who are the different acquirers and why would it make sense to them, and then trying to get discussions going with them as close to the same time as possible.
How do you think through this rough process? You've gone through that exercise, you've talked to some potential companies to have an acquisition, the stars have aligned and you've got an offer.
What's the standard form that that offer takes? What's the process run like from the first informal handshake to closing the deal?
Eliran: You're talking about the actual--?
Joe: The actual acquisition.
Eliran: The final part of the acquisition?
Joe: Yeah. Once you've run a really good process, you've talked a lot different companies, you've accurately portrayed the integrated value 12 months out.
Again, there's a lot of "ifs" here. All these "ifs" line up and you have come to informal terms, just talk through what the process-- People may not be familiar with what happens next.
Eliran: Once you've identified your key focus company, or acquiring company, or it could be more. An LOI will be in place, or a letter of intent.
Joe: A letter of intent, right. This is similar to a term sheet.
Eliran: Basically, yeah. It's a legal document that's not necessarily needed, but it's become the standard today to any conversation that is showing more commitment from both sides to the deal outlining the rough terms of what we're talking about.
In terms of what will be given to what party, assets are not, cash or any other capital, at least putting in a range of that.
So it's not gonna be the final terms, it could be the range of terms that we're talking about.
It could be, if we're talking about a cash acquisition, it could be somewhere that will indicate the range of what we're discussing. We haven't reached the final terms, but--
Joe: Typically those are issued prior to the full diligence that you would need to--
Joe: Hone in on an actual price.
Eliran: As we said, this talks about the commitment from both sides to engaging into the next level of conversation.
Once the diligence starts or completes after that point, we outline the final details of the agreement, which we'll talk about the transition of goods or not, equity or not between the two companies.
The timeline for the deal to happen--so if there are prerequisites or conditionals that need to happen in terms of a product being built or an integration being completed, or anything around those two likely scenarios, and then how soon the company will transition.
Many times, of course pretty much in all cases, the deal will consist of milestones for the funding team or the whole team to be accountable to.
If we have a value, monetary or financial value attached to the deal, the acquiring company would like to attach that to a milestone of what they'll be getting in return.
If we said they would be or the company would be integrating or implementing or re-implementing products or features into the acquiring team, or running a business, they would have different targets to growing that business.
The milestones will be attached similarly and outlined in the agreement itself. I think beyond that point once everything is signed it's just a matter of executing what you've outlined in that agreement and then transitioning the team.
We're talking about also, it could be a whole stage of the HR process of interviewing different team members and trying to identify if they are not sticking together as a whole.
Where they would go, who will be joining and who won't, what's that going to be for the people not joining?
Is there going to be a soft landing for them to look for other jobs? That's another aspect of the deal to look into, the whole people side of it will be another step of the deal.
Joe: First of all, I think it's interesting that you're right, a lot of times attaching conditions to "These are the milestones,"and then there's often incentives to hit those.
Typically all negotiable and going back to the more leverage you have from other offers on the table, the easier it is from a founder's perspective to get some of those relaxed, or lacking that the easier it is to stack those up.
It's always a delicate balance. We talked about the spectrum of types of exits and certainly like the giant creative ones, typically--
In some cases it takes months upon months to just integrate HR systems with very large companies.
Whereas you go all the way down the scale particularly at smaller strategic exits where we're still interested in integrating the product, oftentimes the teams aren't that big and you'll take them along.
You get more into the PE style ones and it gets tougher because part of the transaction is actually taking something that's maybe not profitable, because it was built for a venture model that's not the model it's going to be in anymore, it has to be made profitable.
That usually revolves around unfortunately reducing the size of the team that's actually generating the revenue, alongside with a smaller growth target usually.
Grow slightly slower, but more profitably. Has GitLab had anyone dedicated in corp dev before, or are you blazing new ground here?
Eliran: Yeah. Blazing new ground. No one really has been fully dedicated, I've been involved and other people have been involved in the acquisitions that we had in the past.
We had two, three acquisitions really. Two major ones to talk about, Getter which is an online Slack-like environment for communication for open source projects, and Gemnasium which is dependency management and license management for developers.
Those were the two acquisitions that we had, but now the companies reach the point that we decided to put that in a specific focus.
Obviously I'm leading behind that, so there is a dedicated person to this. There's a whole acquisition plan that's going to be also part of our move to make everything public.
We'll probably in the next days will become public as well, so we have an acquisition offer page but that's made-- I've actually yesterday transitioned that into a handbook.
We have an acquisition handbook that will outline exactly what our focus is, what our approach is, what the target companies were after, what that profile looks like and what they can expect in terms of what they would be getting and why it's even relevant for them to join, what's great about it.
Also if they really want to go into it they can then drill down into our process, to the nitty gritty and the highest resolution of who does what next, and what that looks like.
They can have a full picture of what we're doing and how we're doing things.
Joe: That is fascinating to me, and I want to dig in there a bit because historically and certainly any of the efforts on either side of the table have been involved in, this is probably one of the more--
I don't want to say "guarded" or "closely guarded," but certainly one of the more clandestine activities that companies engage in.
Part of that is, what would you estimate is the average number of conversations that a traditional motion has, or you expect your motion have versus actual outcomes? Like, ratio.
Eliran: You're talking about the number of conversations to deals?
Joe: Yeah. If you end up doing two acquisitions, let's just keep the math simple, how many different companies do you think you'd typically talk to get to two acquisitions? Super ballpark.
Eliran: Probably like 10 to 20.
Joe: Yeah. So, tens. Order of magnitude, maybe we just keep it like that, like an order of magnitude.
I think often some of it comes from "Most of these discussions aren't going to go anywhere, and rumors about the discussions or news of the discussion that doesn't go anywhere is damaging."
So the two acquisitions to date were somewhat opportunistic, then?
Joe: OK. Now there's becoming a very public shift towards a more systemic focus on that, for GitLab?
Joe: It's an evolution of the company?
Eliran: Yeah. GitLab as a whole, we've been growing very rapidly over the last few years, and for instance I'll give an example, ballpark.
I joined three years ago, we were at 50 people.
Eliran: 50, and now we're over 550.
Eliran: In those three years, and in April today our goal is to get to maybe double that by the end of this year. End of 2019, get to 1,000 people.
Joe: That's aggressive.
Eliran: It's aggressive. I think also if you look at the product side of it, three years ago we didn't have most of what we have today.
We didn't have the security, the defense side. We just started on CI, and now we're the market leader in terms of offering and strategy.
Most of what we have today we didn't have three years ago, so the product is also being expanded broadly and very fast.
What we wanted to do is, and part of what I was doing with the acquisition plan and putting an acquisition plan in place is we needed to identify what are the priorities of--
Why are we bringing acquisitions to the table and how are they relevant to what we're trying to do as a company?
Which is move fast and build a lot, and fast. We've identified, let's say, three top priorities of how we look at an acquisition.
If you're not aligned to those priorities you're probably not a good target or a good fit for what we're trying to do.
So the first priority number one is we're trying to hire talent with specific expertise into one of the product categories that we have today.
We have a good number of product categories in GitLab today, and that would be number one priority.
If we can acquire talent with specific expertise that we don't currently have or don't have enough of in GitLab.
Joe: This is what we would classically call an acqua-hire.
Joe: You acquire an integrated, cohesive team.
Joe: They know each other and know how to work, has some proven history as opposed to going off one by one recruiting a similar number of people.
Eliran: Exactly. The perfect example for that in GitLab would be the acquisition of Gemnasium.
They joined as a team and essentially was the first team to build our secure stage, so that was our security team building our offering.
Joe: Was that separate from the Gemnasium original product?
Eliran: No. That product was integrated into GitLab, parts of it, and that was essentially our first offering around security. That was an example of that acqua-hire at GitLab.
The second priority is adding functionality that we deem critical to, you could say, build or buy.
"Can we add that functionality faster by making an acquisition, then trying to recruit new people and having them focus on building that product feature or a specific set of features?"
That will be second priority, a typical case of build then buy.
The third priority, and it's I think very interesting now in the specific time that we're at with dev ops, is building or acquiring companies that will allow us to generate profit in the longer term in product areas that are not necessarily being the most attractive or the heart of the market today.
I'll give an example for dev ops, if you look at dev ops today the whole source code management has now become a commodity.
Everyone has source code management, and no one's deciding on what developer tool they are going going to go with based on just the source code management.
The differentiating factor today is what else you have, and what else do you bring to the table.
With GitLab it's a lot more, it's the CI security and everything around that monitoring.
If you go back in time two or three years ago, everyone was focusing on source code management and the issue tracker, and what functionalities you have within that.
That's become commoditized, so we want to go into the next step of trying to forecast the growth opportunities or growth areas for products and make acquisitions based on that.
Together these three top priorities are relevant ones that dictate our approach to judging and evaluating targets.
Joe: Yeah. Especially with that last one, part of that is when you've made the decision as it seems like GitLab has to bring a product or rather a suite of products to market.
You build up an efficient marketing and sales channel that's able to multiplex across a set of--
I'm sure integrated at the right places, but once you have that working you can take an existing product that maybe hit the right product note but as many of these teams is struggling to build a go-to market.
Eliran: Exactly. Get the distribution.
Joe: Get the distribution, and you have built effectively a very efficient distribution machine and so you can integrate products and then the end result is better off than where either of the individual parties were. That's the theory?
Eliran: I think that's one of the appeals to joining GitLab as part of an acquired company, is to get that distribution to millions of users instantly.
We have over 100,000 organizations that are using GitLab today, so you will immediately get that exposure that you wanted and put your product into people's hands.
That's again one of the things that are appealing to people.
Joe: The model you have is, I think, a great way from a corporate perspective be thinking about it.
What's interesting, you made a passing reference earlier, let's talk about this handbook and/or application. Because that's a new wrinkle, right??
Eliran: Yes. You are talking about our acquisition handbook and how that's become--?
Joe: Yeah, but to the extent that historically for this thing if I think there's a company that my company would be a good acquisition target for, it would make sense, I historically or traditionally have to--
First of all, it's like "Do I know anybody who knows anybody in that company?"
If I happen to be lucky enough to be connected to someone who's connected to some VP of something at that company, I can wrangle some warm intro hopefully up to the corp dev team.
If that's not the case, then my next best option is I go LinkedIn stalking people and try to find someone at the company with some title like corporate development, business development, director of partnerships.
Then I literally send them a terrible LinkedIn message, and that can be really challenging in some ways to even just get access to people. But you're putting that totally on it's head.
Eliran: Yes. We are trying to build more of a well-oiled machine to handle and process acquisitions.
Joe: To handle inbound, like direct inbound.
Eliran: Inbound, and also the way we internally handle acquisitions. It's not just surfacing the whole point an approach of acquisitions at GitLab, it's also surfacing the whole entirety of how we handle acquisitions.
So like you said, I don't think there's anyone out there that's really put it publicly available what their outlook is on acquisitions.
We are doing that because I think the whole approach and what I've seen and learned with my time and GitLab is when you are completely visible to to other people in how you work and what your goals are.
I think that's also one of the key lessons in negotiations is you want to be clear what your goals are and you want the other side to be clear what their goals are as well.
Because that will be the best approach to generate the most value for both sides, is when people both know the goals that each side has and we can maximize for everything.
So, that goes in line with our approach to really publicize everything that we do around how we look at acquisitions, what the profile is, what we'll be offering you as a team that will be acquired, how that's going to look like in terms of that transition into GitLab.
And I think that's unique and a point that we want to make it easier for you to process the idea of an acquisition, easier for you to handle or envision what that's going to look like as an acquired team or even a team member that's looking at this.
You will have more confidence in what we do in the whole process of it when you know a lot more about it, than having a black box like it typically is today where you start a conversation and you don't really know how to start it.
You don't really know what's the middle point, what's the endpoint going to be like, you just want to get to a deal.
We tried to dis-ambiguous that and get to a more outlying public view of that for everyone to consume.
Joe: One thing that's interesting to me, especially working with companies who go through these conversations and my own experience, I do think one thing that will be really valuable about that to entrepreneurs is the wide variance of experience you have with companies.
I think it generally tends to, at least in my experience, align with how much of this activity they've done.
Because especially I think the more acquisitive you get and the more that becomes part of your overall strategy, the more you are incentivized to become good at it and get to know quickly.
Maybe that's because I've seen some companies that are super good and they can get to a "No" pretty quickly, or at least a "Not right now."
Then when the time is right they can turn the crank and run a process.
I've seen other companies where it takes a ludicrous number of meetings on what is theoretically a very small deal to decide not to do it, and you say it just doesn't even make sense that you spent 40 hours of your VPs time on this tiny deal you ended up not doing.
How are you and your team thinking about the key--? What are the most important parts of the process for you to focus on, and what meetings--?
Do you have a schedule where you escalate from your team into the product area leaders?
Eliran: Yeah, I can talk about the process, definitely. I think it's also maybe a good lesson to other founders that are curious about what's the best way for them to pitch and position their offering to an acquiring team.
So when you start a conversation, the typical-- We have a template for that, there'll be typical intake for the first conversation exploratory to get the current state of the company.
That will be the first step in the process, typically done by me. Just getting to know the team, the whole structure of the team, what products are available out there today and the funding and everything.
The whole history about the company and where they are today in terms of business, in terms of customers, growth and the size of the team itself. I think that's number one.
The next step is to-- That's really the point to put emphasis on is, "What is the joint messaging and the joint offering that we are able to build together?" That goes to the point I was making before with founders.
So you have an offering in typical corporate process, you'd have the offering memorandum that you'll prepare, and in larger deals maybe of what you bring to the table and how that could benefit the acquiring company if you were to seek out acquirers.
I think that's critical in any conversation that you have around acquisitions, is you want to start outlining what that could look like.
If we're, at GitLab specifically, talking to a company that will be the second call, it would be a product call with some of our product team members that will dive into their product acquired company, target product, what features are most interesting for us to integrate.
Start outlining right off the bat a quick integration roadmap, so if we were to take all these features, how quickly can we integrate them into GitLab and what is that going to look like?
The second stage for that conversation would be to start outlining what other new functionality that company or that team would like to focus on and build within GitLab, now that you have so many other parts of the dev ops piece or the dev ops pie that you could leverage being part of that one cohesive tool.
So, that would be the second part of it. At that point after that conversation, the product conversation, and we have an internal review where we do an evaluation and make a quick decision.
This is the second point in time where we make a decision. The first one will be after the current state conversation, the first intro call if you will, and the second one is after that product dive in trying to scope out an integration roadmap.
That would be a more critical junction to a decision of "Yes" "No" or "Not now." Basically if we move past that, we will start the diligence process into the engineering side and the finance and legal side to move to a quick acquisition.
The overall goal is to complete an acquisition, let's say, within four weeks or a month.
Joe: Four weeks, is that from the first call? Or is that from--?
Eliran: We're just starting, so everything is fresh with us. The process that I'm talking about, it's a new process and like everything else with GitLab, we iterate.
This will change over time. When you go visit the handbook, if you go today and if you go a month or two from now, it will process and--
Joe: It will evolve.
Eliran: It's a living organism, like everything else.
Joe: No, that makes sense. I think one thing that's interesting, from what you just described, and I'd expect this.
For people thinking about going through this process, to your point, putting the plan together there is this two stage decision where one is --
"OK. We see these 10 deals and we're trying to figure out which maybe two to really look at." That first stage or two is pretty important.
It's getting past that first hurdle, then to get into the real diligence, right?
Eliran: Yes, correct.
Joe: It's hard to over invest upfront on that.
Eliran: Yes. It's hard because you need to start getting more technical people involved to start doing the evaluation, so the better it is--
If you want to maximize the value of the conversation, it would be to start simulating and putting time and thought into what the joint value proposition could look like.
That will make it easier for both people on both sides, because you're going through this exercise as well as the founder.
For me as someone that's doing corp dev, it would be easier to digest and try to understand what's the potential that we have here instead of trying to reverse engineer and bring people in to start doing the diligence and have them think about the integration plan.
Joe: This has been a lot to think about. I'm so glad you came by today. I think we're at time now, but I definitely look forward to checking out the handbook and look forward to hearing back maybe in the future as to how it's going. I think we definitely want to chat about that at some future point.
Eliran: Definitely. Hopefully we'll get some good news in the next few weeks and then we can check in a little bit of time from now.
Joe: All right, great.