Perhaps more interesting is that Elastic, the company behind Elasticsearch, just IPO'ed on NYSE, and they, too, have a fully distributed team of over 700 -- might even be trending toward 1000 by now. Zapier is another one at multi-hundred-person scale, and is a YC company. A couple other scaled-up ones on this model include Automattic (company behind Wordpress), DataStax (company behind Cassandra).
There is also Wikimedia, Canonical, and Mozilla -- perhaps those 3 are less interesting since they have a non-profit mission tied to the internet-as-community and FOSS.
It's worth mentioning that when I started my startup back in 2009 as a fully distributed team, VCs viewed that as a major -1 strike against the company. So much so that we chose not to mention it during initial pitches. We ended up finding Series A/B financing, and these days, those investors ask us to advise companies on how fully distributed teams work, so new portfolio companies can decide for themselves. They were early believers in the model, but they tell me they have noticed a major change in attitude among fellow VCs toward distributed teams. That is, they understand the tradeoffs (finally), and believe the model can scale.
We now have a fully distributed staff of 70, over 400 customers, and millions in revenue. So 1/10 InVision scale, but it works well (and nicely!) at this scale. These days we also have an NYC office, but we refer to it as "the Internet cafe", about 20 of our 70 people "so happen" to work out of there regularly, with everyone else in home offices or co-working spaces. Our NYC office is also used for team gatherings, client events/visits, and board meetings.
I wrote my initial views on the different scaling models for teams here in 2012:
Also wrote a little about how the fully distributed team needs to be complemented, from time to time, with f2f interaction. This was in 2016 after several years of experience scaling hiring and organizing team retreats -- "Fully Remote, But Here For Each Other":
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.
re: " These days we also have an NYC office, but we refer to it as "the Internet cafe", about 20 of our 70 people "so happen" to work out of there regularly..."
It would be interesting to know:
- How many other distributed companies have a similar arrangement (i.e., a non-distributed "HQ")?
- Does this make employees more productive and/or satisfied?
- When on the journey does it make sense to transition from centralized to distributed?
- Are distributed orgs more (or less) likely to outsource commodity-esque (e.g., bookkeeping) services?
Our onboarding materials explicitly say, "NYC is not HQ". And it's not HQ. It is just an office we leased because we ended up with 10+ staff in NYC and they preferred an office to a co-working space, for security/privacy. (If you've ever lived in NYC, you know it can be challenging to have a home office at any reasonable cost, due to typical square footage of living spaces. That's part of the reason I left NYC.)
We are a Delaware C-Corp. Yes, we have our mail sent to NYC, but that's for the lawyers/accountants.
As for the NYC staff, they find that one "problem" with the office is that it has a "library atmosphere". I personally don't think that's problem, but I am the CTO and an engineer, so I prefer quiet & focus. Some people expect an office to have "energy" and ours is definitely lower on that scale. I try to remind people that "the web is our office and the front door to that office is your internet connection."
Are people happier in our NYC office than on our remote team? Hard to tell, but the NYC folks complain about commuting a whole lot, and often take the occasional work from home day to spare themselves of it. I never hear those complaints from the other staff. I guess one benefit of the NYC staff is that they can have happy hours and dinner/drink outings, which inspires some jealousy on the non-NYC team.
We make up for that by throwing annual and semi-annual team retreats. Our last two were in Upstate NY at a writer's retreat campsite (really fun getting to know everyone over campfires and s'mores) and the one before that was in Reykjavik, Iceland, where we rented out a whole hotel and got to know each other on city and countryside excursions during 23 hours of daylight!
Where on the startup journey does transition to distributed make sense? Well, for us, day one worked! We reversed the typical evolution. We were 100% office-free for a few years. Then, in 2012-2013 or so, we got an NYC office, after a frustrating experience with a sub-leased co-working space for the NY staff. But we refer to it as the NYC internet cafe, not HQ. I think that is healthy for teams like ours.
Are distributed teams more likely to outsource stuff? I dunno, probably. We outsource commodity accounting/legal/payroll/benefits services, but we have an in-house finance/collections team. We also outsource PR, cloud hosting (obviously), and we use a lot of SaaS services.
One such place I worked for had the non-distributed HQ and it housed the execs and some of the local team (being non-specific here on purpose).
I switched from working remotely to working locally, which involved a change of country, and I realised that I couldn't justify my own position after that.
As far as it goes with productivity and satisfaction, I thought the decision to go half-in on remote was a mistake.
My take away was that a startup does not necessarily have the maturity to maintain the balance between local and remote while also focus on making things happen. It was totally a setup that was so advantageous to the staff that the business itself suffered, as I saw it.
In those terms, you get a reprioritisation or a negligence and productivity suffers because you've just resigned to the reality that it's really hard to manage it all. Yet still, you feel entrenched so the best you feel you can do is to just... do nothing.
I would say that a small startup depends on fluid interaction between founders and the various 'makers' on board who help fulfil the vision. If you're 50/50 on how you facilitate that then you get a lot of mediocre when you could have had one solid thing and your foundation is built upon a compromise.
If I found myself in a leadership position in such a scenario again I would hope that I could stomach the firing act and invest in the culture that suited us best. But I don't think that's so easy to do with a small team.
At Mozilla we do have offices. I don't know what the exact office vs home based worker breakdown is, but I think the majority work from home. It's certainly true on my team, which is spread across three countries and nine cities.
> There is also Wikimedia, Canonical, and Mozilla -- perhaps those 3 are less interesting since they have a non-profit mission tied to the internet-as-community and FOSS.
Canonical is a for-profit company. They're also not fully distributed, either; I have a friend who moved to the UK a couple of years ago to work out of Canonical's headquarters.
Canonical is incorporated for-profit but barely pays its bills after 14 years in business, and relied heavily on Mark Shuttleworth wealth and willingness to spend money on things he likes without turning a profit. (Shuttleworth sold his startup Thawte for about $0.5B in 1999 at age 26, and has less than that wealth now.)
That's interesting. My mistake, then. I had cited it from memory of talking to some Canonical staff during my own interview processes, where it seemed to me that it was fully distributed and driven by a non-profit mission (namely: sustaining salaries for F/OSS contributors).
What I meant by that: these three examples might feel, to VCs and founders, like anomalies rather than examples of an alternative scaling model for high-growth software/tech enterprises operating on a startup-to-IPO trajectory. Elastic, Automattic, InVision, Zapier, by contrast, are "traditional high-growth startups" in every respect, but where the founders simply chose fully distributed as the scaling/hiring model.
You pay someone like Trinet [1]. You wire them funds, they distribute to employees in all 50 states and handle payroll, taxation, etc. They act as the employer as record, show up on employee W2s, etc. There are other companies out there that perform the same service, but Trinet is the company I'm familiar with having worked at a fully remote startup.
If you have international employers, there's more complexity besides wiring them funds; you have to ensure you're not violating local labor law as it relates to employee vs contractor classification. Talk to an attorney!
My cofounder and I worked together from cafes on nights and weekends, but also did a whole lot of remote collaboration, in our first couple of years. We did a 3-month summer accelerator where we were f2f every day early on, as well. But when that was over, we switched back to mostly remote collaboration. For the bulk of our first 2 years of operation (which was really a bootstrapping period), we worked mostly over the web. This despite the fact we were both in/around NYC. But, he was based in Manhattan at the time and I was in Astoria, Queens, so we'd save ourselves the trouble of meeting up f2f, though occasionally would co-work together.
I think what you'll find is that in the founding period, f2f can help a whole lot, and, of course, if you are pitching for fundraising or enterprise clients, you almost always need to do some f2f visiting with people. So, don't be religious about it. But for "the work itself" (e.g. code, design, writing) there is no need to be colocated.
Thanks. What’s shaping up to be is that my technical co-founder could be remote while I’ll be dealing with the F2F interactions. While I feel somewhat comfortable having a remote co-founder, I worry if it will come back to bite me.
Also, for your remote employees outside of the US, how do you structure your payroll, determine compensation and pay them? Seems like it would be quite an extensive HR payroll setup, which might not sit well with investors or potential acquirers?
There is also Wikimedia, Canonical, and Mozilla -- perhaps those 3 are less interesting since they have a non-profit mission tied to the internet-as-community and FOSS.
It's worth mentioning that when I started my startup back in 2009 as a fully distributed team, VCs viewed that as a major -1 strike against the company. So much so that we chose not to mention it during initial pitches. We ended up finding Series A/B financing, and these days, those investors ask us to advise companies on how fully distributed teams work, so new portfolio companies can decide for themselves. They were early believers in the model, but they tell me they have noticed a major change in attitude among fellow VCs toward distributed teams. That is, they understand the tradeoffs (finally), and believe the model can scale.
We now have a fully distributed staff of 70, over 400 customers, and millions in revenue. So 1/10 InVision scale, but it works well (and nicely!) at this scale. These days we also have an NYC office, but we refer to it as "the Internet cafe", about 20 of our 70 people "so happen" to work out of there regularly, with everyone else in home offices or co-working spaces. Our NYC office is also used for team gatherings, client events/visits, and board meetings.
I wrote my initial views on the different scaling models for teams here in 2012:
https://amontalenti.com/2012/05/14/distributed-teams
Also wrote a little about how the fully distributed team needs to be complemented, from time to time, with f2f interaction. This was in 2016 after several years of experience scaling hiring and organizing team retreats -- "Fully Remote, But Here For Each Other":
https://blog.parse.ly/post/4736/mission/