[jasode]

>Use WordPress and P2, use Slack, use G+ Hangouts, use Skype, use any of the amazing technology that allows us to collaborate as effectively online as previous generations of company did offline.

I've been a 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace. Yes, they do help mitigate many issues of isolation and they do help collaboration but there's still some "bandwidth loss" when people are not in the same room or even down the hall from each other.

I'm not advocating an open floor plan with noise and distractions. Even a set of private offices that share a common corridor to facilitate spontaneous conversation with a side conference room for group brainstorming, is superior to keeping Skype windows open.

Yes, there are the common examples of virtual remote workers at basecamp, Automattic, github etc. Those are not billion dollar companies. 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. Small scale modest businesses, yes, but not big ones.

Maybe you can hire a 5-person 100% remote team to launch a new web magazine. Journalists and editors by their nature seem to fit the remote work paradigm quite nicely. At first glance, it seems programming also fits, but only for modest projects.

Yes, the remote workers themselves will insist "I'm 100% just as effective offsite as onsite -- in fact, I'm more productive because I'm not interrupted by office nonsense." No doubt they feel that way but the whole team isn't more effective.

Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent.

[falcolas]

As another veteran of working remotely, I disagree. Conscious use of collaboration tools offsets not being in the same office together nicely. Real time communication via Hangouts or Skype are at a level where you can hold a good conversation without having to be in the same physical location.

Also, most offices (and businesses) are not really built to support proper collaboration and working conditions. As an example, due to a recent job move, I'm stuck in an office 80% of the time right now, and it's pretty miserable. It's an open office plan so there's constant noise and visual distractions, my boss can (and does) come over and interrupt me constantly on issues completely unrelated to my work, and in a former life the office was a welding garage, so I'm pretty cold most days this winter.

I hear of the unicorn offices, where they were built to support collaboration and focused development work, but I've always found reality has more in common with Dilbert than Valve.

[timr]

Thing I've learned through hard experience: programmers (and yes, I am one) generally over-value individual productivity and under-value communication. So yeah, you can "hold a good conversation" via Skype, but you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.

Programmers tend to want to squirrel themselves away and work on stuff to maximize their own personal productivity, whereas organizations want to get a bunch of people working at a group optimum. That means that every individual takes a productivity hit for communication purposes, but that the organizational output is much higher than any individual could achieve. Hence, we get the fruitless debates about working conditions: what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

There's definitely a fine line between communication and distraction and it's hard to hit the balance (I've worked in some horrible "open-plan" environments too), but in my experience, programmers nearly always err on the side of too little communication, especially early in their career.

[mgkimsal]

Companies that want that sort of environment need to structure the entire business process around spontaneous collaboration, not just pay lip service to it.

The reason I didn't hit deadline X? 5 "spontaneous collaborations" happened at my desk in 3 days. Wait... I don't get my bonus because we missed the deadline? But... my collaborations helped the marketing dept hit their goal ahead of time, and they did it by coming to my desk and asking me questions. Oh... that'a a different budget?

If you want to foster that sort of behavior, make sure all of the aspects of the business line up in support of it, not just the facilities budget because "open plan" is cheaper than private offices with doors.

[manto]

This seems fairly anecdotal. Do you believe this is a larger issue that the spontaneous collaboration is causing you to miss deadlines? Ultimately if the marketing goals are met through your efforts why not use this as leverage?

[falcolas]

I feel that TheOtherHobbs covered most of the points really well, but I feel that this point needs a bit more direct discussion:

> you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.

If you value developer productivity at all, that little bit of friction is a _good_ thing. It means that you have to think for a second about the most appropriate forum for that discussion. And if you decide that you do need to talk to someone, the friction isn't really that high. Click on a user, click on the green button with the camera on it, and you're talking.

In-person spontaneous collaboration is, in my experience as both a developer and a development manager, highly overrated, and the value is very rarely worth the costs. Those costs include lost productivity, developer stress, bikeshedding, and an implicit culture of hostility to anything that doesn't _look_ like productivity (like thinking).

Taking a moment to put on my development manager hat, one of the things I never want to do to my developer employees is interrupt their flow. I go to meetings, so I can give them a brief summary which contains only the information they need to do their job. I work with the customers and listen to 50 minutes of rambling so I can glean the 5 minutes of information my employees need to do their work.

I've hired them, and I'm paying them ludicrous amounts of money, to create programs; to create value for the customer. Anything that gets in that way is up to me to address and remove. And based on my experience as both a developer and a manager, those "spontaneous collaboration" interruptions are usually something that needs to be addressed and removed.

[nostrademons]

This still doesn't refute the point timr was making: sometimes the most productive thing you can do is stop a programmer from writing code. As a programmer (and an employee), what you're ultimately responsible for is happy customers and solved problems. If your code solves the wrong problem, it has negative value to the organization, as it's just something that all the other programmers will have to trip over later.

The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem. Whether that outweighs the increased individual productivity from eliminating distractions is very much case-specific, which is perhaps why there's so much heat and so little light on this issue. You'll never capture all the complexities on a web forum.

[falcolas]

> sometimes the most productive thing you can do is stop a programmer from writing code.

I have little to dispute about this statement, but I disagree that being colocated has any effect on this (unless stopping them 4-5 times a day will truly make the team more productive; at which point a manager needs to step in and fire that person ASAP).

> The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem.

How does colocation solve this where remote does not? Do you expect that your co-workers would somehow notice this from looking over someone's shoulder, as opposed to when you pull in a branch of code from your VCS?

Once you've pulled in the code and notice the problem, you can bring it up in the next scheduled standup or hit the little green button next to their name in Hangouts/Skype/...

I can not see how being colocated would do anything to help speed the discovery of this particular class of problem in a way which is not practical using modern telecommunication software. As a point of reference, I have personally pair coded (with anywhere from 2 to 5 people) with folks in England with great success.

[nostrademons]

From personal experience, the most common way this comes up is that you have a casual hallway conversation with a colleague, they ask "So what are you working on these days?", you tell them, and they respond with "You should talk to so-and-so, he worked on that a year ago and may have some insights" or "Have you heard about technology Foo that's designed just for that problem?" And then you follow up on that lead and realize that the project you just budgeted a week for (and will end up spending a month on, given all the unexpected problems that come up) can be solved in a couple days if you approach it slightly differently.

These are not hypotheticals - there have been numerous points in my career, ranging from being a sole technical cofounder to working in a 50K+ employee company, where a chance meeting has saved me weeks-to-months of implementation effort. And in each of those cases, the solution they suggested was not something I would've thought to look for on my own, because my starting assumption was that it needed code to solve. And similarly, it probably would not have been spotted until the feature was done and the time spent, because usually your coworkers' assumption when you embark on writing a solution is that the solution is necessary.

[TheOtherHobbes]

>whereas organizations want to get a bunch of people working at a group optimum.

It's an exceptional and rare organisation where this is even remotely realistic as a goal.

The appearance of productivity is usually far more important than the reality - especially in mid/late corporations, where the most significant outputs are primate status plays and politics.

>what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity.

No sane manager is going to want to do that without a really good reason.

>programmers nearly always err on the side of too little communication

That's because programmers like to be left in peace to work on small, relatively well-defined problems. Communication can be limited to progress and code reviews and goal-setting by team leaders. Everything else is noise.

The real problem with remote working is that too few corps understand it, and too many managers believe employees aren't functional adults who can work without constant supervision.

It's a management issue, not a programmer issue.

I think at some point we're going to see some faddy Harvard Review type write a faddy Harvard Review type book about remote, and it's suddenly going to become the new outsourcing. Because cheap.

But meanwhile - Paul Graham's problem is that he has a nostalgic hankering for a vision of SV and start-up culture that's already well on its way to being disrupted by the global talent he wants to move to the US.

If you're a world-class five percenter, why on earth would you want to move somewhere with insane living expenses and in-bred VC culture of the Valley when you can bootstrap and innovate around it elsewhere?

Does he really believe all that funding and schmoozing and presentation is essential to getting a business up and running on a planet with an Internet?

Graham maybe needs to consider the possibility that those five percenters aren't his future employees - they're his future direct competitors.

[timr]

Pretty much nothing you've written here refutes what I'm saying. You're a programmer, so naturally, you assume that your optimal use is programming, and you draw conclusions starting from that assumption. But if you moderate that assumption a bit (you're also well-used as a planner, an organizer and as a communicator, among other things), you arrive at a different set of conclusions.

"The appearance of productivity is usually far more important than the reality"

No, that's just cynicism talking. Larger organizations care about your personal productivity, but they care less than small organizations. Part of the brilliance of modern corporations is that you don't always have to be at peak productivity as an individual in order for the company to profit. Which means, in turn, that you can do things like get sick or have a family without having to give up your job. The flip side of feeling less efficient is that you have some cushion when you actually are less efficient.

"I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity."

You obviously don't want to interrupt someone gratuitously, but the point is that your perspective on what's important can differ wildly from your employer's perspective. Keeping someone in "The Zone" is not the only goal. An employee in "The Zone" who is churning out "The Wrong Thing" is worse than no employee at all. So you need communication. And as soon as you need communication overhead, people are going to be interrupted. It's a cost of doing business.

[discreteevent]

The 5% thing in the original article doesn't add up for me at all. The top 5% of the programmers that I have come across are able to do things that the typical YC company doesn't need at all. He talks about someone who would hire 30 of them if they could. Really? What kind of team would that be? Could you keep them motivated doing all the bits and pieces a startup needs to do? Maybe they are building a new OS. (I doubt it)

It sounds a bit like people shooting the shit about great footballers or something where you up the ante to large it up ;)

[davidw]

> Real time communication

That implies a time zone with a lot of overlap. Rome/Berlin time is 9 hours ahead of San Francisco, meaning there really isn't a lot of overlap.

Real time communication also means that you need to consciously set up the call and pay attention to it. Sometimes I overhear something at work, or we talk about something interesting at lunch, or there's an "oh shit" moment (not often:-) when it's really convenient to have everyone jump in.

I've been doing open source and IRC and 'the internet' for more or less 20 years, so I'm pretty comfortable with the whole thing, and happy with it, but when there is a sense of urgency, it can sometimes be less efficient.

[zanny]

Run a mumble server and give each developer their own "office" as a chat room.

If you chose not to talk casually when remote that is really up to you.

[falcolas]

Yeah, time zones are easily the biggest problem. Even then, however, it's not that hard to find an overlap.

I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.

[davidw]

> Even then, however, it's not that hard to find an overlap

0900 my time is 2400 west coast time. No overlap there. 1700 here is 0800 west coast time. Granted, I don't leave that early from work, but not all programmers are "in the office by 9" people either. There's not a lot of overlap.

> I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.

I don't doubt it's possible, and even the best solution for some people in some situations. But not for everyone.

[drumdance]

> Conscious use of collaboration tools

The key word being "conscious." Finding good developers is hard, and finding good ones that communicate well remotely is even harder.

Shameless self-promotion: we (nearly 100% remote) explain some of soft skills we look for in an engineer here: http://www.staunchrobots.com/blog/staunch/

There's probably a training business opportunity in this sector.

[cgh]

Harder problems than the Linux kernel?

I've been remote for eight years now and I work on a codebase so huge that no one person understands it all beneath the 10,000 foot level. Nearly all of us are remote (only the managers are "local" to San Jose). Once a quarter we get together and meet up, coming from Vancouver, Toronto, Bangalore, Colorado and northern California.

[gaius]

Yes, kernels are not difficult because most of the problems are purely technical problems, that programmers can just decide for themselves any ambiguities, and many of the parts can be worked on separately. Software with users is 10-100x more difficult.

http://c2.com/cgi/wiki?WhyIsPayrollHard

[cgh]

Sorry if I was unclear. I was just using Linux as an example. The product I work on has plenty of users. I don't agree that it's orders of magnitude more difficult but that's beside the point.

[diydsp]

> the Linux kernel?

Although it's insanely technically challenging, many computer science projects are more difficult than the Linux kernel to do remotely. For example, watching users interact with the software, anything that involves expensive test equipment, anything that runs on embedded/custom hardware.

[soperj]

Because no one has ever run the linux kernel on embedded/custom hardware?

[kareemm]

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

[jasode]

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

[zedpm]

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.

[jasode]

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

[YuriNiyazov]

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.

[zedpm]

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.

[gclaramunt]

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.

[JoeAltmaier]

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!

[photomatt]

Not that valuations are the end-all be-all, but Automattic was valued above a billion earlier in the year, and has risen since then: http://www.techmeme.com/140505/p14#a140505p14

[rumcajz]

Having experienced different setups, it seems that collaboration is OK if everyone is at the same place. It's also OK is everyone is remote. Where it gets troublesome is when part of the team is collocated and part is remote. What you get is two unequal classes of employees which leads to all kinds of problems.

[jkmcf]

I work part time remotely, and we have other devs full time remote. I definitely feel like I'm "missing out" just being OOO part time, be it the hoc discussions or just going out for beers.

Of course, it only matters if you let it matter. Some people don't care or need that stuff. They worry about their own work and leave work at work, which I'm working on doing :)

[fsloth]

I think you might be falling into the trap of overt generalization.

I agree that remote removes critical bandwidth for cross team communications.

On the other hand, lots of programming projects are parallizable to n crafty individuals who need colocate only once in a while to " totally sync their mindstate" and can communicate effectively enough in the mean time using other ways without loss of critical bandwidth if the need for that bandwidth is not needed.

Not all teams need the same kind of cross individual bandwidth. Of course loss of colocation leads to loss of serendiptuous talks to create novel insights but if the insividuals working together were located far apart in the first place then they might not be working together at all if not remote.

Personal anecdote to give a practical example:

I recently moved to another team within the same organization working on the same product but on a different level. The team from where I moved developed the stuff that got CI:d to customer builds and it would have been really difficult for me to imagine working remotely there as the work required often going around the floor asking about stuff (lots of undocumented legacy).

My new team focuses on tech and middleware and creates libraries for downstream to consume. Programmers work on their own libraries and I can go on for days without requiring input from anyone. On this team I could easily work remotely.

Based on my experience I would claim it depends on the designed team duties wether remote works or not. And I think this means that team organization must be tightly coupled with the software architecture design. I have no idea which should drive which but I'm pretty sure any changes in one should also be consciously reflected in another.

[mgkimsal]

"A lot of startups have ambitious goals and very hard technical challenges"

And those companies aren't billion dollar companies either.

"All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace"

But they're more effective than those people not working together at all.

"Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent."

You have to define 'best'. If the definition of 'best' has to include "people who are willing to uproot their entire life to spend a portion of it in someone else's office", then yes, you're correct.

"I see no evidence that this has ever been successfully done. Small scale modest businesses, yes, but not big ones."

I see little evidence that co-located teams are all that much more successful at becoming billion dollar behemoths than virtual teams.

You get access to a wider breadth of experience of worker when you embrace remote. Just because management hasn't had enough experience with the model yet to be able to grow a billion dollar company doesn't mean a) it's bad or that b) it may not happen in the future.

[hckr1292]

Videoconferencing sucks -- it's not as effective as having your coworker come over to your screen for pair programming, or talking face-to-face with your UXer. Anyone who has done any amount of remote work will realize that the OP is dramatically overstating the value of teleconferencing solutions compared to working in house.

[mgkimsal]

You know what else sucks? Driving in to an office for pointless meetings to take up half your day. Getting sucked in to office politics whether you like it or not. All those things suck.

I think you're underestimating the degree to which day to day office crap weighs on people and makes them far less effective than they might otherwise be, even if they get to have someone come over and "pair" with them.

Remote working is an approach that really needs to be embraced by the entire company, and refined over time to match the needs and skills of the team as they change. Some people need more one on one time, some need more group time, maybe you do some face to face meetings quarterly instead of annually. It's not a one-size fits all, but nothing (including f2f office work) is.

[ci5er]

I agree with your first paragraph 1000%.

One of my old start-ups had white boards everywhere (when we ran out, there were windows...) and ad-hoc bi-lateral marker-of-death struggles would spring up anywhere all day long. That was super handy.

I've mostly been an independent lone-ranger type for a long time now, and have rarely met most of my clients face-to-face -- but I do miss at-the-drop-of-a-hat white board sessions.

[mgkimsal]

Did you mean "disagree"? Can't tell what your point is.

I like f2f problem solving too - whiteboarding, high energy, etc - it has its place.

[ci5er]

I mean "agree". My point is that the hassle is a hassle -- the f2f problem solving sometimes makes it worth it. Not often enough to make the decision cut-and-dried.

[falcolas]

Videoconferencing _used_ to suck. Four years ago, having a voice conversation while sharing a screen was neigh on impossible. Now, however, it's dirt simple and works really well.

[tracker1]

I'm kind of split... I think it depends on your home environment. Spouse, kids, other distractions? Sometimes the workplace has fewer distractions than home.

[Vendan]

Meh, that's an easy fix. I've got an actual office outside of my house that takes 30 seconds to get to. (AC and hardwired ethernet, of course)

[drawkbox]

So as a remote worker, you would be more productive in the office 5 days a week?

If everyone on the team has a 2 hour commute, that is a guarantee that there will be less time available to the individual and thus the team. Commutes are a big problem aside from the communication.

I have also found that companies that do remote or allow it, just communicate better, to all parties, even clients or stakeholders. They are more external focused companies without internal blinders, they take an external view of the company instead of internal. Lots of employees time is commuting and dealing with office politics which become a bigger part of your job than working at some places.

Personally I think companies that are remote or allow remote are much better at communication overall and have a saner external view of themselves coupled with the internal view, rather than just an internal view of what matters. I have seen this across many companies I have worked for or with. Some internal places I have worked that didn't allow remote made it very hard to get information because they expect people to barge into offices to ask.

Overall I feel remote companies have the benefit here and make for more robust teams if they do it right, not to mention the benefit of attracting great developers all over the country or world.

Today, virtual communication is how we communicate to most of our clients, customers and stakeholders. Companies that allow remote just do this better because they also communicate that way. Remote companies value external views of the company and communication much higher than non remote capable companies.

Two more benefits of remote capable: When you setup another office upon growth the new office will not have the virtual communication problem (office to office within the same company is typically virtual communication and non remote companies do this badly), also remote companies root out non-contributors more quickly as you can't just hide behind being there physically as work you must contribute and build.

VCs are so against remote that it seems like they almost have some tax hookups and own lots of real estate in SF as some of the logic makes no sense, ultimately labor costs would be cheaper and the companies would be more robust to changes.

[learnstats2]

"If everyone on the team has a 2 hour commute, that is a guarantee that there will be less time available to the individual and thus the team."

I am willing to sacrifice 2-4 hours of personal time per day commuting => I am willing to sacrifice myself to the company's wishes => I am a 'good employee'

A portion of the advantage of office work comes down to employer control of employee. The differing communication systems with clients, customers and stakeholders illustrate the different balances of power accurately.

As such, I agree that remote companies make for more robust teams if they do it right - but it's much harder to do it right.

Remote companies lose some advantage of easy communication (in order to survive as a remote, you have to be better at communication), and you lose some advantage of having a clearly indicated power structure.

[zippergz]

I feel the same way. I have lived in a tech hub city and worked on-site for major tech companies. I now live in a non-tech hub, with very few technology jobs to choose from, but I live here for personal quality of life reasons. Since I've lived here, I've worked both remotely and on-site for a few different companies. Selfishly, I'd like to see far more companies allow remote workers, because it would give me so many more job opportunities. But I also have to admit that my experience is that overall team/company productivity is markedly better when the people are all in the same location. I know that there are exceptions, but I really don't think they're the norm.

[henrik_w]

Yes, it's a matter of how much the team gets done, not only how much you personally get done. I used exactly this example in "Programmer Productivity – Interruptions, Meetings and Working Remotely" http://henrikwarne.com/2013/04/02/programmer-productivity-in...

[rebelidealist]

Github was valued at $750mil in 2012, should be worth a whole lot more now.

Basecamp, has not gotten outside valuation for a long time, but they are just as if not popular that Asana who was valued at $280mm back in 2012.

[ryandvm]

Agreed. I don't have a solution, but this frustrates me to no end.

As a software engineer that previously worked in an open floor plan I can testify that they absolutely crush individual productivity. Headphones are no solution. I think I'd need a potato sack on my head too.

But as a software engineer that currently works with geographically distributed teams, there's no way to deny that certain elements of communication can't be reproduced with chats and hangouts. It's not just technical discussions either - it's much harder to build cultural cohesion in distributed teams as well. Which is a bummer because it's a lot easier to engage in blame and scapegoating when the guy that wrote something is just some email address and not a friend.

I wonder if anybody has had success with some sort of 80/20 (remote/on-site) model...

[meanv]

hand raised I have been doing 4 days remote, 1 at the office for 7 years. I live 150 miles from the office. That once a week face time is very helpful.

I haven't read the entire thread of comments, but as I read about the mishmash of remote tools, I'll throw in an endorsement for Microsoft Lync. The full blown integration of email, video, audio, screenshare works really well.

[rumcajz]

What you typically do is work remote and meet in person once in a (long) while. This is how lot of open source projects work.

[frostmatthew]

> All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace.

Totally agree. But also feel collaborative periods make up a small amount of our time - remote workers allow having more/better/cheaper developers (whichever of the three you want) which can easily offset the less effective collaborative times.

If software development were a field where we spent most of our time collaborating with others remote work wouldn't make sense. But most developers are spending most of their time alone at their desk coding or communicating with others in a manner that doesn't differ based on location (i.e. you still email people in the same office).

[ergo14]

> 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

Sorry, this just isn't true, the IT team in my old place was 100% remote (there were sales and marketing in local office), and we had very big growth and success solving quite a few technical problems scaling the business for millions of users. It's more of recruiting people with right skills and right mindset. After scrums/whatever we spend 90% of our time solving the problems - being on site doesn't really help unless you do do some specific R&D that requires constant team consultation - which 99.99% of startups here DON'T do.

[the_arun]

I am in bay area & do not work remote, but I often think future is all about working remote to avoid commute & pollution. Software Engineering is one such job where we can get things done remotely. Like open source community :)

[k-mcgrady]

>> I've been 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace.

As someone who worked remote for 6 years (with a few face to face meetings over those years) and now works in an office I think each have their trade offs and it balances out largely. In an office you can get quick questions answered much faster. If you forget to ask something in a meeting you can find the person and quickly get the answer later that day. Discussions are more natural too. However I've found that when working via email or Skype discussions are much more focussed. We ask our questions, get out answers and get back to work. In a face to face discussions people tend to add words to their sentences to make what they're saying seem longer/more important. Discussions deviate from their intended purpose. Sometimes that can be useful but often it's a waste of time. I've been in meetings which I could have wrapped up in under 5 mins - and the people I'm with are there for 30-60 mins. They talk about irrelevant things, repeat themselves with slight variations etc. etc. Sometimes this can be necessary if you're building a relationship with someone but most of the time it's a waste of time.

[jleyank]

Couple of thoughts to throw out: (1) retention, keeping somebody in the family who has or wants to move out of SV/NYC. (2) Getting that 35x rockstar on board who's not interested in SV/NYC. (3) Stretching the $$ (of company or staff), as most parts of the US if not the world are cheaper than these two areas. (4) Customer proximity, in that there are markets that aren't the (western) US, etc.

[larrys]

"are not as effective as everyone sharing the same physical workspace. Yes, they do help mitigate many issues of isolation and they do help collaboration but there's still some "bandwidth loss" when people are not in the same room or even down the hall from each other."

Agree. Which, in fact, was one of the reasons that both Bell Labs and the Manhattan Project achieved what they did. (For sure a different time which lacked many of the advantages we have today.) And you could also argue about the negatives, the distractions etc. [1] But there is no question that in many cases it's an advantage to be located near others working in the same area and not in near isolation.

[1] If you don't like listening to music (I don't) use a set of 3M "tarmac" grade earmuffs which will block out nearly everything.

[jleyank]

"Which, in fact, was one of the reasons that both Bell Labs and the Manhattan Project achieved what they did."

Err, no. The Manhattan Project succeeded because it has most of the available physicists of the world, a blank-check budget, top priority and rather severe real-world pressure. No startup idea will ever have that kind of staff...

[nicktix]

+1

[walshemj]

Yep its buying into the hype of teleconferencing that the Big Telcos sell to the CEO on the Golf course. The REAL point here is to build software you need teams that work well together not a bunch of solo contributors

[fencepost]

Mullenweg is in kind of a unique situation with WordPress/Automattic - they have regular staff meetings all over the world, under the monicker "WordCamp". Sure they don't have all the staff at any of them (except SF, presumably), but a lot of the people working for the company attend various ones regularly, so they can get together in-person for periodic meetings, while at the same time keeping people in touch with what their users are doing.