GitLab being all remote has been a problem during fundraises. We mentioned it since we're transparent and inevitably investors will want to visit your office.
During our latest D round it was a smaller problem since later rounds are more based on financial metrics and comparables (GitHub, Atlassian, Jfrog). But I wouldn't say that it is no longer a problem with VCs, many still have scaling concerns.
As one of the best investors said that passed on us: we're in the pattern matching business and all remote doesn't match the pattern. It might very well work but we will invest only in a handful of businesses anyway, we might as well pick ones that are a complete match.
Indeed, I hope that one day you have to defend why you're spending money on an office, hiring only the 1% of people that live or can move to a certain place, and waste two hours of their day with a commute.
I think you can raise a comparable amount of funds for a distributed team, it will just be with fewer investors and at a lower valuation.
The valuation will be lower since an acquisition is less likely. Most acquirers of companies under $100m want the acquired employees to join their office. Since this is unlikely with a distributed team there will be a discount on the acquisition price of up to 50%.
There was an upside to this. Since distributed companies make for a less valuable acquisition target our investors are aligned with our plan to become a public company https://about.gitlab.com/strategy/#sequence-
For public companies being remote is less of an issue since financial metrics are much more important and in the case of an acquisition they would likely stay as a separate entity.
This will be a challenge for me as my investors already feel the company has the potential to be an acquisition target for one of the big guys and feels we should be building it that way. We’re also based in the U.K. and am not sure how many Saas platform tech companies become public.
You will have to get to a liquidity event, 99% of the time this is an acquisition or going public.
It is not very motivating for you and the team to build for an acquisition. If you want to go that route be careful how much you raise, every pounds has to paid back 3 to 10 times.
> That’s sad to hear given as I’m looking to raise funds but also hoping to build a distributed team given the abundance of worldwide talent.
Are you looking for VC funding or angel funding?
If you have the ability to use foreign teams, you are probably better off taking angel funding and bootstrapping.
Remember, VC's want "up or out". "Cheap remote workers" isn't really relevant to that to a first approximation.
In fact, some VC's will look at it as a detriment. They wanted you to spend that couple million and succeed or go up in smoke. With cheap remote workers, you look at that couple million as 3+ years of runway for really solid organic growth.
"cheap remote workers" isn't quite the point, it's more access to talent that's not geographically next to you. I know it's not your main point but I just wanted to add this note. :) Most companies who do remote and are successful at it, don't pay a discount on employees. In fact in many cases the pay is very competitive with SF/NY standards.
Exactly why we want to do remote. I find our concept is hard to parse amongst the talent in our geographic area whereas I’ve found folks across the world who completely get it and would like to help.
At the moment, embedded myself into an incubator. Haven’t really found any angel investors who would be willing to give us some runway as I don’t think many here get what we do. But it is a good thought and something to consider if things don’t pan out.
That’s disappointing to hear. Hopefully with the Elastic IPO and other public successes, the pattern matching algorithm will change. If you don’t mind the question, how many people is Gitlab now?
Yeah, having a way to rapidly say no to a lot of otherwise-interesting opportunities is probably valuable to him. And honestly -- getting a 'no' and a clear reason for it is awesome investor behavior compared to the norm. :)
Indeed I was grateful that he passed fast and with a clear explanation. We asked him again when we raised our D-round but that came together to fast to make it work.
In the one conversation I had with him he coined 'the emergent benefits' of a single application https://about.gitlab.com/handbook/product/single-application... and he said we should call it a Development Operating System (OS). What do other people think of calling it that?
So, full disclosure, I helped create and ran the developer tools group at a large, well-known tech company. This is a space I'm intimately familiar with.
The idea seems pretty straightforward to me and not particularly insightful. Calling it an OS is different from calling it a platform, but effectively it's the same thing. Perhaps more interesting are the implications of that analogy -- do you ship APIs and have a lot of third party people building on top of you like in the Github model or do you go more in the direction of Atlassian? I know that's a bit of a false dichotomy, Atlassian has APIs and Github is clearly trying to extend their toolchain, but in general you have one with a rich ecosystem and the other where you mostly ship what they provide.
For myself, I see GitLab trying to be more of a Github alternative than an Atlassian alternative. I don't know if that's your strategic intent, but that's how it comes across to me. In either case, I think the industry in this space is pretty unexciting in terms of the kinds of innovation that are happening right now. Google still has a toolchain that is a decade ahead of most of us, and I don't see anyone really tackling that head on.
In my view everyone has open APIs and the difference is:
1. GitHub focusses on a marketplace ecosystem (although I hear they will be adding CI soon)
2. Atlassian has a suite of applications that work well together and you can buy as a bundle
3. GitLab is a single application for the whole DevOps lifecycle, one codebase with everything from planning to monitoring, one UI, reliable upgrades, everyone on the same page
You could try on Linux for size, but I don't think it fits.
So either as an analogy it doesn't work, or this idea doesn't scale. :) BeOS is the only OS I've used that I both liked and that had a single design vision behind it. I think that this is most likely an artifact of it not being successful, though. If it had been widely adopted, it would have gone the way of MacOS or Windows.
For me, it’s an interesting thought. Would your audience understand what it means? Are you trying to position GitLab into something more than what it is today.
It would also be equally interesting to test what the term would mean to different people.
For me, I still find it difficult to wrap my head around the original concept of what an OS is. And Development Operating System would mean an OS that is in development. At least based on first impressions.
I am likely to try something similar with saying “DevOps for ML” or “CI for ML”. Will see how that goes.
Let me get it straight: You are increasing potential hires pool tenfolds, save a fortune by not playing the real-estate bubble game, effectively double your work day to almost 24 hours by spreading over timezones, and likely enjoy a 6-days work week - and VCs are worried about your ability to scale? This is just astonishing to hear.
You know how we think about all remote, we think it is a no-brainer. I want to leave some notes on your points:
1. "Increasing potential hires pool tenfold" => In the view of many VCs the most talented and experienced people will live in the bay area.
2. "effectively double your work day to almost 24 hours by spreading over timezones" => although it is great that our support and site reliability engineers don't have a night shift it is very hard to work across timezones, it makes most part of our company less effective and harder to coordinate, we have to push ourselves to work asynchronous (issues instead of chat)
3. "enjoy a 6-days work week" => we think the benefits of not having a commute belong to the team member, not the company
4. "VCs are worried about your ability to scale" => they are very worried about having the executive team on the same page, not very worried about individual contributors
> save a fortune by not playing the real-estate bubble game
I always thought that the real estate game was intentionally part of the deal. The idea would be for a group of VCs to pick a target location (say, San Francisco), buy up the local infrastructure (housing, office space, coffee shops, etc), and turn around and rent / sell to the startups that you just funded. This would pad the ROI, so even a company that crashes and burns after 5 years would still be profitable on the basis of the rents paid.
This cycle wouldn't come into play with a remote team. And in that lens, the onerous zoning laws of the bay area make perfect sense
> buy up the local infrastructure (housing, office space, coffee shops, etc), and turn around and rent / sell to the startups that you just funded. This would pad the ROI, so even a company that crashes and burns after 5 years would still be profitable on the basis of the rents paid.
You can never turn a profit on rent paid out of money you gave to someone, just like it's impossible to turn a profit on purchases your employees make from you with the wages you pay them. You're always better off just keeping the money.
That does not "pad the ROI". It lowers the ROI of the fund. It may launder some money from the fund into a VC's personal pockets, but that's not the same thing.
During our latest D round it was a smaller problem since later rounds are more based on financial metrics and comparables (GitHub, Atlassian, Jfrog). But I wouldn't say that it is no longer a problem with VCs, many still have scaling concerns.
As one of the best investors said that passed on us: we're in the pattern matching business and all remote doesn't match the pattern. It might very well work but we will invest only in a handful of businesses anyway, we might as well pick ones that are a complete match.