Hacker News new | past | comments | ask | show | jobs | submit login

> A lot of startups have ambitious goals and very hard technical challenges and you can't compete with a team made up of 99% remote workers. I see no evidence that this has ever been successfully done.

MySQL was a 1B company and built with a remote team:

http://developers.slashdot.org/story/13/03/07/1826212/former...




If you're bringing up MySQL as a counterexample, I think we've lost sight of the original conversation.

The original Paul Graham essay[1] had a lot of focus on "startups". The companies in the early days scratching and clawing trying to make things work. I thought that was the context.

MySQL was started by 3 guys in Sweden working in the same office. Even if they wanted to have everyone working remotely in 1995, there was no technology (high speed internet) at the time to do it. Sure, as a company becomes bigger, and also as technologies improve, there are possibilities for organizing remote work.

Anyways, back to the context and constraints of startups: If you're a startup, it would be great to recruit the "exceptional" talent in South Africa, Ukraine, China, New Zealand, etc (because 95% of the best programmers are not in the USA).

The MA.TT says remote work is the answer. I don't see how because I've not seen any evidence of any billion-dollar American startup that was built by a 100% virtual team from multiple timezones of Europe/Africa/Asia.

If you're creating a 24/7 tech support department that "follows the sun", having staff in far off timezones is awesome and necessary. If you're trying to build a product with hard challenges for the team to solve, MA.TT's "answer" of international remote workers is not an answer.

[1]http://paulgraham.com/95.html


Remote does not necessarily imply international. There are over 300 million Americans who don't live in the Bay Area, so there are plenty of potential remote devs that are still in the US. Domestic remote devs are in the same or nearly the same time zone and can easily travel for regular, in-person meetings.

A startup I helped build over the last nine years was acquired earlier this year. Our entire company was distributed, and we thrived with email, persistent chat, weekly meetings via phone, and occasional in-person meetings.


>Remote does not necessarily imply international.

It does in Paul Graham's essay and OP's response to it. Again, we're losing sight of the thread's discussion. (Please read PG's essay that started this.)

PG's essay was about H1-B visas (recruiting foreign talent into the USA) and the OP (MA.TT) said the answer was remote workers. This means international remote workers that are 6+ to 12+ hours ahead in timezones.

We're not talking about hiring remote workers in Maine and Rhode Island to work as a distributed team for California companies. We're talking about remote workers in far off timezones like France, Japan, Australia, etc. I know of zero examples where the type of company that Y-Combinator likes to fund (e.g. billion-dollar ideas) was built with remote workers to the extent that the H1-B conversation can be rendered a moot point.


Actually, we are talking about both. YC and PG are very strongly pro "everyone in the same office", so it's not that those workers could come to US and then live in Maine. No, they will come to US and live in SF or NYC areas.


I read PG's original essay and ma.tt's, and while I agree that PG is talking explicitly about international, I disagree that ma.tt is doing the same, to the exclusion of domestic remote workers. He writes "If 95% of great programmers aren’t in the US, and an even higher percentage not in the Bay Area, set up your company to take advantage of that fact as a strength, not a weakness." That comment about "not in the Bay Area" is indeed explicitly pointing to US developers outside SF.


While I concede that's not the "billion-dollar American startup that was built by a 100% virtual team", I've worked for a startup where half of the team was distributed across america and europe. It was an amazing team, highly collaborative and flexible, successfully tackling a hard problem. (I used to joke that the code base was CS funland: all the interesting problems in one place)

We failed mostly because our product was overly ambitious, solving a broad problem.

Yes, is just an anecdote, but my point is that distributed team can run circles around most of colocated teams and we wouldn't have been able to assemble that team if we insisted that everybody had to be on the same place.


Here at Sococo we hope to be that team! We're in several time zones, 6 states and three countries. Not to a billion yet; not hardly. But growing!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: