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.
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.
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.
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.
> 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.
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.
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.
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.
These behaviors are simply not constrained by the environment, not anymore.
I've seen many examples that exactly the same problem as you've written happens even in co-located team, so it's a problem of lack of communication, not of being co-located (or not).
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.
"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.
It sounds a bit like people shooting the shit about great footballers or something where you up the ante to large it up ;)
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.
If you chose not to talk casually when remote that is really up to you.
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.
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.
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.
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.
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.
MySQL was a 1B company and built with a remote team:
The original Paul Graham essay 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.
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.
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.
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.
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 :)
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.
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.
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.
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.
I like f2f problem solving too - whiteboarding, high energy, etc - it has its place.
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.
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.
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.
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...
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.
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).
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.
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.
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.  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.
 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.
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...