Hacker News new | comments | show | ask | jobs | submit login
A Short Rant About Working Remotely (ericfarkas.com)
528 points by speric on Jan 31, 2013 | hide | past | web | favorite | 326 comments



Having worked in both environments before, one thing that I observed is that working remotely can indeed be highly productive, but it's very difficult, perhaps even impossible, to do it successfully if only a few employees are working remotely.

Otherwise what happens is that the people who can see each other face to face and in the hallway will of course do it, leaving the odd remote person out of many conversations. So either the remote person won't be as in the loop as the others (bad for them, and bad for the overall team dynamic because someone needs to be treated specially), or else everyone on the team needs change their otherwise perfectly normal and perfectly productive patterns of communication (leading to frustration with the artificial constraint).

So there's nothing inherently wrong with remote workers, but it's probably better to go "all in" like some companies are starting to do, or try to avoid it at all, except in very special circumstances.

I bet many of the "99%" of companies the author was referring to that said "no" to his working remotely simply fell into the category where the majority of existing employees weren't remote, so they they chose not to introduce the new and arguably difficult to manage dynamic.


This is a huge factor. When most people are in the office, the means of communication becomes different, in tons of little ways.

For example, brainstorming sessions end with scribbles on whiteboards, and a fleet of Post-Its that say "Do Not Erase!" It's perfectly adequate documentation because the same team comes in the following afternoon and keeps going. But the one or two people that work remotely are never going to see it. And no matter how much Skype you do, it's just not the same as being in the room as it happens.


Great point, and I suspect you are right. Either remote is a deep part of your startup culture from day one, or don't even try.


Perhaps a better way to put it is that it is difficult to retrofit an office to allow a few telecommuters.

In my experience, I was working remotely in the company's early days. The in-office employes really started to grow after me. While I remain the only one that really works outside of the office, the culture of remote workers was instilled from nearly the beginning and don't really find any of the problems you suggest to be true in my case.


You are absolutely right IMHO.

Same problem (seems off-topic but i am not so sure it is) is for someone who doesn't smoke. I don't and I thought about starting (or at least getting myself chocolate cigarettes) to join the colleagues outside during the break to stay in the information loop.


> else everyone on the team needs change their otherwise perfectly normal and perfectly productive patterns of communication (leading to frustration with the artificial constraint).

I have yet to work in any place, remote or local, that doesn't have a large portion of the executive team (which is always a double-digit percentage of the total headcount of the company) on the road for various reasons a substantial chunk of the time.

I think companies that rely on this face-to-face dynamic (of which there are many) are doomed because the normal operation of their company will necessarily disconnect people on a regular basis. If you're not putting all the critical information somewhere reachable by everyone, all the time, you're shooting yourself in the foot, even if (in the usual case) everyone shows up to the same room every day.


This parent post is what I came in to say. I'm a sole remote employee at my current company and I think I miss out on like 75% of discussions that go on.


In my experience, "hallway discussions" can be equally as unproductive as they are productive. The benefit is cancelled out by the detriment.


Who are you to say they don't understand their own business process and culture well enough to determine that remote employees aren't a fit for them? I've worked with several remote team members, and it's always been frustrating. Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello???

Communication is extremely important when working in teams, and you'd have to be pretty ignorant to claim remote workers are able to communicate as well as on-site workers. If I need to ask a teammate a question, I turn my head slightly to the left and ask them. They respond immediately. Sure, you can set up some sort of always-on video or teleconferencing, but do all new, growing companies have the know-how and resources to implement that for multiple remote workers? Or are you just so special that you deserve all that extra effort?

Small, early stage companies also seem to be focusing a lot on developing a company culture these days. Remote workers don't fit into that strategy very well, if at all.

I'd welcome a remote employee under one condition: They're required to be on a constant video call so their on-site team members can see and talk to them at any time.


> If I need to ask a teammate a question, I turn my head slightly to the left and ask them. They respond immediately.

And then they stand the chance of losing anywhere from 20 minutes to an hour of productivity thanks to your interruption.

Part of the reason remote work appeals to so many of us is because we don't deal well with the constant stream of interruptions that occur in many office environments.

I don't believe this is the case for everyone. There are some individuals capable of working productively in a noisy environment all day while sleeping only 3-4 hours per day. But I think such individuals are rare, and you're doing yourself and your organization a disservice if you think all developers can work this way effectively.


My main drivers for working remotely are what you just described and eliminating commuting time. I find I'm much more productive and happy without those inconveniences in my life.


Yeah, I get that. You are more productive. You are interrupted less. You can focus more easily. You are happier at home.

Now, where's the consideration for everyone else on your team? That seems to be the one thing missing from all these counter arguments, yet it's the crux of the matter.


They can reach me via IM, phone, webex, etc. Initiating communication this way (maybe excluding IM) is somewhat more formal than face to face chatting. This gives the initiator more incentive try to work out their own problems first without bugging me (and that's great). If they truly need me for something, I'm happy to oblige. The casual face-to-face "do you have a minute" interruptions are the ones that really kill productivity.

I'd like to respond to some of your other comments:

If I had to endure a culture where this was acceptable:

> Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello???

I wouldn't work there for very long. This mentality of "butts must be in chairs" flies against the notion that software engineers are professionals and should be treated as such. This nagging is a great way to lead to a broken, angry engineer.

That said, I agree with your premise:

> Team productiviy > your individual productivity. It's that simple. Do you think your team members interrupt you just for the fun of it? No, they interrupt you because they need your help to accomplish something.

But there is a fine line between nagging and actual necessary interruptions that is deepened by remote work. Asking a professional why haven't they responded to the email you sent 5 minutes ago, to me, is crossing the line and if everyone on the team has to endure that kind of behavior then individual and team productivity will both suffer. I've experienced being micromanaged and it's terrible and it's definitely not conducive to my productivity. The rest of the team seemed the same way and thus the team productivity suffered as well. Creative thinkers need uninterrupted time to plan, think, and execute.


If you can't deal with interruptions, maybe teamwork is not for you.

I agree that it's distracting and irritating at times, but that's the nature of working with other people.


Most people believe they are able to deal with interruptions. Very few people are actually able to do so in an even remotely efficient manner.


Still teams of gifted individuals tend to achieve more than sum of gifted individuals working alone, distractions notwithstanding.

Anyway I'm reserved about the very thesis that office life is particularly full of distractions. At home office you might have spouse and kids who are even less understanding of your "zone" than your coworkers. If you are single it might be neighbors driving their renovation project with hammer drills at work hours. You probably have a TV, game console, your guitar, your pet, and basically have to rely on self-discipline with that.


Remember there is a distinction between remote working and working from home.


I can usually deal with interruptions in a gracious and friendly manner. I'm a nice guy, usually laid back, and capable of rapid context switching.

I have discovered, however, that since I do not work for an emergency room, my context-switching-skills are rather undervalued by the free market. The value I generate for clients and employers is very much correlated to my ability to train clients & colleagues to let me focus on solving one problem completely before moving on to the next problem.

I find when you describe the effect of interruptions in terms employers understand — "working this way costs you money, both directly, because I charge a not-insignificant amount per hour, and indirectly, because there are opportunity costs to my working on emergencies instead of farther-reaching goals" — they will become your allies in fighting off interruptions. If you just complain that interruptions are distracting and irritating, well, you're just gonna get a prima-donna label for yourself.

I love working as a team. My creatives can make something look more visually appealing in a few hours that I could in a few months. I can develop the functionality in a few days when they wouldn't know where to start. We all have our strengths. But creative work is inherently a selfish, individual act requiring concentration, and interruptions, in most instances, don't help the team meet their goals.


Absolutely agree - anyone wandering into one of these opinion articles/discussions would think that developers are a self-centred bunch of arseholes whose productivity is the most important thing in the entire universe, and isolation/concentration is critical. Even brain surgeons need to collaborate and operate - literally - in conjunction with other people.


I'm a software engineer married to brain surgeon. She will be the first to tell you that the actual procedures, while technical, are essentially arts and crafts; they require care, but not extreme mental focus.

However, when she's reviewing patient charts and imaging to prepare for a procedure, that requires absolute focus, and she will isolate herself completely for hours and not talk to anyone no matter what. So, there is a time for collaboration, but there is also a time for focusing on one task to the exclusion of everything else.


So when brain surgeons are operating, do their bosses pop in and ask them inane questions they could get answers to via email?

Developers don't need to continuously collaborate. Even brain surgeons spend a lot of time reading up on papers and research and interruptions do not help them.


Absolutely - anyone wandering into one of these opinion articles/discussions would think that developers are a self-centred bunch of arseholes whose productivity is the most important thing in the entire universe, and isolation/concentration is critical. Even brain surgeons need to collaborate and operate - literally - in conjunction with other people.


Oh, really? Because researchers disagree with you:

> Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006). Close proximity improves productivity in all cases." -- http://conway.isri.cmu.edu/~jdh/VRC-2008

From adrianhoward's post above.


Have you even read the study, or are you just quoting it blindly? Your link provides a very brief summary but mentions no details about what tools and workflows remote workers were using. It also doesn't mention anything about the type of project that was being delivered and the various constraints that it had. Maybe you're just taking this stuff on faith.


The referenced study answers all of that: http://pages.cpsc.ucalgary.ca/~sillito/cpsc-601.23/readings/...


So reading through that study it appears as though that the remote test group ("Team Solo"):

- was actually working in cubicles in the same room and could overhear each others conversations.

- used email and a very basic text-based chatroom built in 2002 as their primary means of communication, as well as the telephone. Doesn't sound like a sophisticated setup to me.

- did not use any screen sharing software or VOIP software like google hangouts or skype and no mention was made about version control software, wikis, project management software ala Asana or Basecamp, or any other of the modern tools we developers use today.

They mention that "Team Pair" benefited greatly from pair programming, which any remote worker (including myself) can tell you is more than just possible using the tools of today, but perhaps even better than hovering over someone's shoulder in the instances where the software allows you to take control of the other person's screen.

From the study:

"On Team Solo, by contrast, intrusions were both functional and social in nature. Intrusions were longer and generally involved movement – team members physically visited another team member’s cubicle."

Again, their "remote" team is actually just a team in the same room but separated by cubicles. They state that the reason the interruptions were lengthier for Team Solo was because of the physical distance between the team members. In my experience, when team members are truly remote, the interruptions drop significantly in both length and frequency.

You have linked to a very old study that determined that working in an open-plan office is better than working in a cubicle-based office. You either didn't read the study, or are not understanding how this clearly does not apply to truly remote workers and the topic at hand.

The tools people have today to collaborate remotely are much better than they were in 2002, and getting better every year. Unless you can point to a recent study that actually compares truly remote workers using modern tools to co-located employees I'm going to go ahead and say that the evidence is weak at best.


This... x10. Having worked remotely from 2000-2002 and also 2010 to the present, I don't know how anyone can make an accurate statement about remote working in 2013 based on a study from 2006.


Do you require that local employees be physically visible at all times? What if they need to take a walk to clear their head and focus on the problem at hand? What if they need to go to the bathroom?

Do you require that local employees drop the task they're working on to respond immediately to any question from anyone and completely lose focus on real work just to save you from a minute of reading some documentation?

Either this is an absurd double standard, or your office is a terrible environment for doing any sort of independent focused work (which may well be just fine, if your office doesn't do that sort of thing, but that's what most people who work remotely are going to be doing).


> Do you require that local employees be physically visible at all times? What if they need to take a walk to clear their head and focus on the problem at hand? What if they need to go to the bathroom?

Yes, remote and physical team members must have a mobile webcam that they bring with them on all breaks. The webcam must have RFID tags built into it, and their homes and frequent break locations must be equipped with RFID scanners to verify the location of the camera and prevent any funny business. No exceptions, ever.

Also, when people ask questions they never EVER preface them with "Let me know when you have a second".

Seriously, are you in third grade? Can you read something and not interpret it literally? The Greek knew reduction to absurdity was a shitty argument more than 2,000 years ago... how come you still haven't figured it out?

From adrianhoward above:

> Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006). Close proximity improves productivity in all cases." -- http://conway.isri.cmu.edu/~jdh/VRC-2008


I think after reading the tone of your response I can determine that I would have a difficult time working with this type of personality. As a developer interruptions are a huge productivity drag. I have to stop whatever I'm doing, answer your question, and figure out where I left off and get back into the right mode to program which can take a while.

Right now I have a few work-from-home days a week and I find I'm enormously productive on those days due to lack of interruptions. If the company cannot sacrifice face time and trust for higher developer productivity (even in the name of teambuilding) then I wouldn't want to work there.


Like a few others who have responded, you're not seeing the forest through the trees. That's somewhat alarming for a group of people who are supposed to be creative problem solvers.

Team productiviy > your individual productivity. It's that simple. Do you think your team members interrupt you just for the fun of it? No, they interrupt you because they need your help to accomplish something. As a resource to the team, you hurt it's overall performance by making yourself less availble.


> Team productiviy > your individual productivity. It's that simple. Do you think your team members interrupt you just for the fun of it? No, they interrupt you because they need your help to accomplish something.

Team productivity is the sum of individual productivity though. Having all of the individual productivity disrupted is going to lead to lower team productivity.

I think Joel said it best 13 years ago: http://www.joelonsoftware.com/articles/fog0000000068.html

===

"Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff. "


Team productivity is the sum of individual productivity though. Having all of the individual productivity disrupted is going to lead to lower team productivity.

This is generally untrue in my experience. Team productivity is usually limited by a bottlenecks and silos where progress stops. It seems counter-intuitive but you really can go faster as a whole by slowing some folks down. You don't get faster as a whole until you get your critical bottlenecks in the process faster.


Are we really talking about "the team" here, or are we talking about a PM who interrupts developers multiple times during a day, in order to re-prioritize tasks, get status reports, etc?


I completely agree. Dealing with remote team members has always been difficult with teams I've been on, and I would guess they have been only half as productive.

This isn't through any fault of their own, but they just can't be "in the loop" as much. Most communication takes way too long to type out in e-mail or IM, so you need to get them on the phone -- but calling and getting transferred, and then they're not at their desk, etc., is just too much of a pain. There's a HUGE difference between waiting until you see that someone is at their desk, and repeatedly remembering to keep trying to call them -- or sending them an e-mail to call you, and then you're out.

They can't see when someone on your team is having a little difficulty and instantly help out, turning someone's hour task into 5 min. They're not involved in the informal meetings behind someone's screen where a feature is changed slightly. They're just missing out on a lot of "informal" information that is crucial for productive development.

And even over the phone, I find it's much more difficult to explain things and make sure they're understood crystal-clear. Sometimes you need to see the understanding in their face. Sometimes you need to draw, sometimes you need visual aids, sometimes you need to pull up a web page, but it's too much work to pull up videoconferencing or something.

In the end, all these problems are "technically" surmountable, sure, but I've never seen it work. Maybe remote work would be fine in a waterfall-type development model, but with modern-day "agile" development, it just doesn't work as well for collaborative teams.


> Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello???

You're confusing people who are bad at communication with working remotely being bad.

Maybe you've never worked in an office environment with someone who has the same issues, but they're by no means alleviated merely by having their ass in a particular chair.

> Or are you just so special that you deserve all that extra effort?

From the employee point of view: Is your business so special I should sell my house, pull my kids out of school, and move so I can work for it? Do you really want to pay me the 50% pay differential I'd need in order to live in your higher-cost-of-living and lower-quality-of-life area? Is your (presumably internet-focused) company so incompetent it can't manage to use the same systems that we use in our day to day work and life to communicate?

> I'd welcome a remote employee under one condition: They're required to be on a constant video call so their on-site team members can see and talk to them at any time.

Completely laughable. Do you have closed circuit TV recordings of everywhere in the office?


>> I'd welcome a remote employee under one condition: They're required to be on a constant video call so their on-site team members can see and talk to them at any time. > Completely laughable. Do you have closed circuit TV recordings of everywhere in the office?

I'm actually working with a distributed team that does this. Everyone is on a shared video conference eight hours a day. If you want to talk to someone you look at your video conference team to see if they are at their desk, on the phone, or talking to someone else. If two people need to talk without disturbing others, they mute their video conference mic and jump on Skype. You can still see them, get their attention, etc. but you don't have everyone talking over each other on the main video conference channel.

It actually works a lot better than I expected.


That actually sounds pretty effective, and would get around a lot of the inefficiencies I've had in the past with remote workers.

Curious, is it just a window with all the other video feeds that you keep in the background? Or a thumbnail version of to the side? Or a second monitor? I'm curious as to the difference between it being always visible, or something you have to pull up.


Most of the people from home have it on a second monitor. There are about four team rooms on the call as well. They usually have one or two 30 to 50 inch televisions showing the other members.


What technology are you using for the shared video conference? I'm looking for something like this. It needs to restore connections when they die (something like Skype will reliably crap out after an hour or so, and doesn't re-establish the connection).


Cisco Movi/Jabber. But it was down once and we used Google Hangouts pretty effectively. If a connection dies, you just fire it back up again.


> From the employee point of view: Is your business so special I should sell my house, pull my kids out of school, and move so I can work for it? Do you really want to pay me the 50% pay differential I'd need in order to live in your higher-cost-of-living and lower-quality-of-life area? Is your (presumably internet-focused) company so incompetent it can't manage to use the same systems that we use in our day to day work and life to communicate?

People make those choices knowing it limits their career options. Since when are companies expected to accomodate every lifestyle and location employees might desire? That's pretty self-centered.

> Completely laughable. Do you have closed circuit TV recordings of everywhere in the office?

Why would you need closed circuit TV for team members who are all sitting in an office together? Is there something difficult to understand about tying to create an on-site presence for a remote employee? There are companies that already do it.


> People make those choices knowing it limits their career options. Since when are companies expected to accomodate every lifestyle and location employees might desire? That's pretty self-centered.

Companies make the choice not to hire remote workers knowing it limits their hiring options. Since when are workers expected to accomodate every workplace and management decision an employer might desire? That's pretty myopic.

> Why would you need closed circuit TV for team members who are all sitting in an office together? Is there something difficult to understand about tying to create an on-site presence for a remote employee? There are companies that already do it.

My point is that it's beyond the pale for anything reasonable. You don't record your offices 24/7 or install keyloggers on your computers, I hope, why would you expect anything different remotely? Can you really not measure effectiveness and communications skills except via panopticon?


It has nothing to do with measuring productivity or making sure they're at their desk instead of watching TV. It's about creating a virtual presence in the office to reduce communication barriers. I don't see anything ridiculous about that -- several people on HN have mentioned that their company does it.


Having worked nearly half my career as a remote employee, I find Skype mostly eliminates this problem...

Onsite Employee: "Hey, got a second?" Me: "Yep" Video chat commences

It's a horrible work habit to get into to interrupt someone like that, but sometimes it's necessary. Plus, sometimes it's nice to just chitchat with your coworkers, just like you would in an office setting.

The bottom line is, I'm good at my job and if you're not willing to let me work remotely, you are welcome to discriminate based on geographic presence and eliminate 90% of qualified employees and I'll just go work for the increasing number of enlightened companies that have figured that they can get better talent by making telecommuting a reasonable option. Not all awesome engineers live within a commutable distance to a major metropolitan hub.


> Why haven't you responded to that email I sent you 5 minutes ago?

WTF? What kind of person checks their email every 5 minutes and gets any work done?

> If I need to ask a teammate a question, I turn my head slightly to the left and ask them.

How is that a sign of productiveness? If anything this is an argument for working remotely. Read PG's essay on Maker's Schedule: http://www.paulgraham.com/makersschedule.html


Sorry, but I disagree with this:

"you'd have to be pretty ignorant to claim remote workers are able to communicate as well as on-site workers. If I need to ask a teammate a question, I turn my head slightly to the left and ask them. They respond immediately."

And here's why, Skype overcomes this problem... I've worked remotely in plenty of team situations where I've sent a chat message, and got instant response, consistently.

When I get a Skype message in these situations, the only reason I wouldn't respond is if I wasn't at my desk for the same reasons someone wouldn't be at their desk in a face-to-face office situation.

I think, as a business community, we just need to get more and more comfortable with remote working arrangements, and implement policies that could cover the various productivity issues (if you don't respond to a message within 'X'... this happens etc...).

I also think we have to remember there are productivity issues in the face-to-face office scenario as well, when people get together they tend to "talk around the water cooler," they tend to "go out for drinks, then call in sick the next day" etc... and other social-oriented productivity issues.

Not all productivity issues are bad either, if someone working remotely doesn't answer a chat message in 7 seconds, they might be improving themselves in some manner. ;)


That's exactly the kind of interruptive behavior that worsens productive. Communication should be batch, considered, and efficient.

The "Hello???" kind of attitude toward peer engineer communication is akin to a mobile phone notification or a blinking chat icon, all enemies of organized thought that leeds to maximum quality output in minimum time.


> Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello???

That sounds like an incredibly frustrating work environment.

I mean for them, not for you.


> If I need to ask a teammate a question, I turn my head slightly to the left and ask them.

Avoiding this is the primary reason I like working at home. Getting distracted by things like that are a productivity killer for me.


Because team work is all about you, right? Quite a myopic view. How dare anyone try to increase the productivity of the team by stealing precious seconds from you!

Teams are more productive when they're in the same location. That is a fact. Your individual productivity may suffer at times, but the team will do better overall if you all work together in one location.


I've noticed quite a few responses in this vein. It may be worth considering that indeed, personal productivity is part of the benefit people get out of this kind of work.

I, too, am much more productive working at home. So much so that I started working from home 3 days a week and eventually just switched to remote work. I understand the need for team productivity but there are ways to solve it that don't require constant face time. When I, as a remote worker, had to hire employees to work for me at the office, I made sure to hire people who were good enough not to require constant supervision and did not need to ask a question every 5 minutes. After the initial orientation, I made sure to be available by email, IM, phone (in that order) which worked out just fine.

I think part of the reason for the strong differences of opinion is that both can be right. The right team, colocated, can be very productive. However, I have seen many colocated teams fail, sometimes horribly. Conversely, I've seen remote teams do extremely well also. In fact, all remote teams I've worked with have done quite well. Obviously some of that may be due to their motivation, skills, experience, etc. But the fact remains. As I say to everyone who asks, remote work is not for everyone. We're used to the norm of working on location, but that, too, isn't for everyone.


That same comment could be turned around just as easily though. If your team mates have no concept of just how much of a distraction they are, or worse they don't care, then they'll interrupt you all the time for random reasons. Some times that's fine, some times it really does speed up what ever we're working on, but the `vast` majority of the time it's things that would have been 100% ok getting typed into a 2 sentence email for me to look at when I next opened my email. By slightly increasing the "cost" of communicating it makes people think a little more about the way they do it, and if a response is truly needed "right now".


Another "me too". The past 8 years, about 80% of the projects I have done have been remote. I get contacted often from recruiters, as well as HR in big name companies, and they nearly always indicate that telecommute is a deal-breaker, so that ends the discussion right there. I live where I live, and I'm not moving. Even if a client/company is local, a balance of local/remote is the right way to go. Dealing with traffic / commute, ergonomics, distraction-free are all important.

This is really pretty simple. If the local talent pool is exhausted, and you want good people, the smart move is to hire good, remote people. Bring them in periodically as needed.


The really smart move is to have smart guys on retainer, ensuring they keep up to date on your code base and deployment practises. Then they can be pulled in periodically.

The really really smart move is to let them bid on some of the tasks - a sort of granular level development contracting.


The irony I keep seeing is that at a small startup, everyone's output is severely visible.. regardless of where you're at. I was the first technical hire at the startup I'm with now (details in profile), working remotely from San Diego while the cofounders were based in SF. There's definitely never been any question about what's getting done and by whom. In a lot of ways I understand the challenge that being a larger shop who's grown locally and is considering adding remote working might face much more than the "We're so small we have to be in the same room" argument.

The benefits of hiring remote workers early on are numerous. The fact that it leads to working more asynchronously, and makes you available to talent anywhere are worth the price of admission alone, IMHO.

[EDIT: oh also: we're hiring]


Would you consider moving when the team gets larger? If you don't do you think you'll get 'left behind' as the local culture develops?

We're also in SD, but trying to build a team here and not finding as many local applicants as we'd like.


We've considered moving, sure. For us though the cost of moving houses in this market, and my wife's local reputation-based business (wedding photographer) would make it an extremely expensive proposition in the short term. I think getting left behind is definitely a risk. So far I'm the only employee outside of the bay, but the culture has remained pretty asynchronous and conducive. If we continue to find talent local to SF I imagine there's a solid chance that'll change, if we happen upon more awesome remote talent it might not. I think it'll just depend on who we end up hiring over time.

Early on though, getting big enough to have that issue sounded like a very high class problem so we decided not to care much where people were and focus on getting things built.

[Aside: That's awesome that you're in SD! Drop me a line and I'd be happy to pass your details along to some of my SD developer friends]


In general, I totally agree. Being able to hire the best person, anywhere, and allow them to work super-effectively is a strong moat. I share this opinion and hire accordingly.

I think the "these companies are wrong" posts, though, are not attempting to see it from the other side.

Try to put yourself in the shoes of these startups. In super-super early startups (e.g. pre-profitability or definitely pre-revenue) one of the goals (aside from staying afloat) is to build a sustainable culture (company etc.). It's very difficult to build a company culture AND product AND hit profitability AND 1,000 other things from scratch before going out of business.

When most are co-located and a few are distributed it just adds one more thing to the pile. I've done it before, so I know how hard it is, even when we were all 'on board' with it.

It's just harder; you need to start from scratch with the assumption that any one can be remote at any time, and so you build your tools/processes accordingly (if you have a physical kanban board then it'll be a real hard thing to support remote devs).

For just one non-top 1% of all software-developer persons? The overhead is probably not worth it if you have a ready talent pool in your city (especially if you now have nexus in another state, which is a very real risk as states are looking to increase their revenue. ugh).

For Joe Average, or Jane Above Average, these companies would prefer to hire a local person than remote. That makes sense to me.

As a big part of getting from 'startup' to 'sustainable business' involves managing risk. So, understand where most of these businesses are coming from. Having one or two remote people in a company full of on-site people is a risk (not from a technical perspective, but from a culture and focus one), and not one they're willing to take.

It's a trade-off, and one that can make sense if viewed in context and done for the right reasons (note: "We can't control them/see their work/trust them/need to see their faces/need them from 9-5/etc." are WRONG REASONS).

Ranting about a system problem isn't very useful; I'd like to see more posts about how to convert a primarily on-site team to support 'work anywhere'. What processes and tools need to change to do this?


I have done and tried to do that very thing.

1. Continuous Integration (and or delivery) This is the sine qua non. Everyone should be able to check out and build a complete working eco system and run all tests on their local laptop or Rackspace cluster you rent just for them

2. Really, get the continuous integration working. Stop now and do nothing else till you have. Tell the dev's remote working is only possible after one month of a CI process that is never broken itself (although build can break). Spurred on, everyone will suddenly get that CI build working.

3. The CEO must build a complete off site copy of the entire company on his remote laptop. Is it getting boring yet.

4. Agree on one place to store all documents, all meeting notes, everything. Do not split comms over IRC and Skype and gmail and ... It will mean no one can reliably contact anyone else because "oh I left you a message on Skype", "but I live on IRC"

5. Get different people to work together on different areas. Pair programming is not ideal IMO, but having Fred write the code for task A and Bob principlaly write the first tests, means they have to talk and decide a solution, and Bob keeps a friendly competitive eye on progess. Move these pairs around a bit.

6. Stop trying to get updates for management - its either working code or not.

7. talk to people a lot. Watch thier checkin velocity - it will speak volumes. Talk if it changes.

8. Assume, perhaps commit visibly, to people as being safe in their jobs for a long time (2 years minimum). This to me seems the biggest - people need to feel safe. Maybve thats just me


"4. Agree on one place to store all documents, all meeting notes, everything."

This can't be understated. When I ask the founder where the company logo is and they say "it's on one of the external harddrives sitting around the office somewhere", it's incredibly frustrating. The most well-oiled startup I worked for had a perfectly organized central-storage of digital resources, which greatly contributed to the smooth workings of the company.


A scary amount of my life and all my business is now on private repos at github.

That's getting scary.


If you're looking for a self-hosted solution to keep you from becoming overly dependent on Github, take a look at Gitlab [1].

Since you're using Git, all those repos are presumably backed up on individual development machines. Or you could easily write a cron job to mirror them every day or so.

The real problem is other content like issue tracking, wikis, and pull requests. If keeping these is important, you may be locked into the platform, at least as far as existing projects are concerned.

[1] http://gitlab.org/


FWIW, I also agree with a lot of your points, Matt.


We switched from almost always in the office to a ROWE (Results Only Work Evironment) and now 90%+ of the time we all work from home. According to a company survey of the people in the ROWE, devs feel more productive, and managers feel there has been no change in productivity. I think this is because we are measuring productivity in different ways. Managers measure productivity over a week or month, which has stayed static, whereas devs measure productivity in amount of time they have to spend to get stuff done. When you don't have to spend 1-2 hours commuting, you spend less time "at work" and get the same amount done.

Personally, I like it, but we also already had a culture of doing a lot of talking via IM. In this day and age, there's no excuse for not being able to get ahold of people. But by the same token, you can't always assume someone is going to respond in 30 seconds. I hope no one is so dependent on other people that someone taking 20 minutes to respond is a complete blocker.

We use Google hangouts extensively for meetings and often open them up just to chat and connect with fellow devs.

We have lost a little bit of a sense of belonging to the team. I think extensive use of google hangouts helps a lot with this. With most laptops having a camera, there's little excuse not to fire one up whenever anyone wants to talk.


> We switched from almost always in the office to a ROWE (Results Only Work Evironment)

That's awesome terminology. I work from home now, but I had a test run in my previous job that was almost always in the office. I ruptured my Achilles and was unable to move about. I felt more pressure (in a good way) to get stuff done, because I felt that i could delay my return to the office longer if it was crystal clear that I was being productive.

I found the same odd productivity boost working a week out of 2 week vacation on the beach in NC. Surprisingly, I was able to focus a lot better since i wanted to have lunch with the family and go for a swim and also because I knew I wanted to stop at 5PM for some beach time. I should clarify that I wanted to stop and feel good about myself that I accomplished a day of work.


"...But I don't see a reason why, in 2013, given the tools we have, a developer has to be on-site at a desk every day, as the normal operating procedure..."

I am struggling with this same question, but from the other side. I help teams become more Agile, and I'm a startup junkie, so all I care about is performance here. I want to know what works best in terms of product quality and pivot ability.

And guess what? So far it's co-located teams that kick ass over distributed teams. I wish it wasn't so, and I'd love to hang back in my home office and work, but that's not the way the numbers are looking.

To be more precise, yes, you can become a "commodity" programmer, that is, somebody that people slide a list under the door to and who delivers code on a regular basis. In this case you are competing with commodity programmers around the world who are willing to work for peanuts. If that's your thing, hop on over to one of the programming job sites and have fun with it.

Now I can already hear the objections. With all these tools, why can't I be just as plugged in as if I were in the office? Aren't you making a false dichotomy, asking us to either be on-site or completely on our own?

Yes, I am generalizing. Look, I don't know why the tools don't work to do the things they are supposed to do. Certainly we have chat, VOIP, and all kinds of awesome communication tools. You'd think that would be enough. But it's not. Instead of powerfully performing teams we get mediocrity.

I suspect that software development has a powerful social and human aspect that is not replaced by tools. Working in a team isn't just trading streams of data across a wire. It's going out to lunch, having a beer while talking about work, or making an oddball suggestion one Wednesday afternoon that turns out to change how everybody thinks of the problem they're working on.

So sign me up for remote work too. Just show me how it's going to be as effective as co-located teams. I see a lot of fluff from places like 37Signals who make a marketing strategy out of being so aweseome, but I'm not seeing results in the real world. I hope to learn more -- and I hope this problem gets solved.


An important factor is team cohesion and trust. In a fully distributed team, trust is immensely important because you can't just look out at the warroom and see who is "crushing it".

You have to have a team that can come together in ways other than having a beer every Friday. Sometimes this is accomplished by having a once per quarter, or twice per year, or even once per year gathering. Those are generally good times for team building activities, not just commits.

Having non-work interactions with your other co-workers can also be helpful. Something as silly as firing up a Quake server or playing Halo together can make a difference.

Also, you cannot expect to apply standard management approaches in a distributed team environment. It can be a struggle because you have to find a new way to evaluate the contributions of your various team members. I think that this is actually where most distributed teams fall apart. Managers simply aren't trained for this environment.


I'd contend that the tools just aren't there.

When I want to chat with someone, I want to do it instantly, like walking up to someone in the office. The Skype concept of "dialing" someone is old, antiquated and feels... laggy.

There was a video chat client promoted on Hacker News a while back that allowed for instantly initiating a video chat session with a colleague.

Sococo, a distributed agile client (with video support) also claims to do the same thing, allows for you to instantly create a video session with anyone in your virtual office.

IM works because it's immediate. Video chatting must be the same in order for a distributed team to work.

The tools aren't there yet.


Just leave the video conference software on. I'm working on an agile project with a distributed team and it works well once people realize that working in front of a live camera isn't any big deal.


I'm generally not interested in hiring remote workers at our company. While it can work in rare cases (where the need for collaboration is low) it is much more the exception than the rule for us. Our company culture and structure is based around trust and collaboration. We allow VPN/remote work, but as a tradeoff. For the most part, our employees are local and have a desk in the office that they spend most of their time in. I agree that in some cases working from home offers a greater opportunity for focus and freedom from distraction. But for that case we have VPN. The rest of the time everyone benefits from closer collaboration.

For what it's worth we have done several experiments. We even tried having a remote worker on a constant skype connection, with a monitor/camera in a shared office with other workers (over a period of several months). Based on our data I would say that there is a measurable decline in value when a person shifts to >50% remote work in our environment. That may not be true for other environments of course.


> For what it's worth we have done several experiments. We even tried having a remote worker on a constant skype connection, with a monitor/camera in a shared office with other workers (over a period of several months).

Did this help things at all?


It was definitely a noticeable improvement over remote with just email / phone communication (and occasional trips to the office), but easily not as good as being there.


> And guess what? So far it's co-located teams that kick ass over distributed teams.

Can you elaborate on this? Do you have any specific data points you can share?


As someone with Aspergers remote work has been a godsend. I am not nearly as agitated as before. My quirks do not annoy people. I am more productive and my wife says I am happier.

When I worked in an office I used head phones (not buds... big ol' ear covering things) to help and was criticized for wearing them (it made me seem unapproachable). In reality it was to help keep me calm and focused.

At home I face neither the noise issue nor the unapproachable issue.

Remote work may not be for every team but in-office work is not for every person either


I've been working remotely for 1 year and 3 months. The company I'm working for checks in once a week for about 20 minutes, other than that all communication is done through basecamp. I have to admit it's really hard for me and I just handed in my two weeks notice. I feel so isolated working from home and not being around other co-workers. I miss seing and interacting with other people. I'll be looking for a new job in New York next month and I'm really excited.

Why do you guys want to work from home? Isn't the isolation during the working hours hard on you?


Because the location of my wife's job is completely non-negotiable (she's a surgical resident), whereas there are no actual impediments to me doing my job from anywhere with an internet connection.

As for the isolation during working hours, it makes me fantastically productive -- no junior coworkers sticking their head into my office to ask questions they could answer themselves if they thought about it for a couple minutes. If they can't figure it out after a couple minutes, they can email me or we chat and I'll help them sort it out. When it comes to feeling isolated, I start work early and take a long lunch break. I go over to the college and have lunch with faculty and grad students whose work I find interesting. I give a seminar talk every now and then. I don't really feel isolated at all.


Why do you guys want to work from home? Isn't the isolation during the working hours hard on you?

I work from home to help keep my family life a priority. That extra 2 hours not lost to a commute (and sometimes another hour for lunch) that is spent with my family has immeasurable value.


I feel the same way. Well stated.


I endorse you too!


In my case, getting paid $110k/year in a country that pays $40k/year as the cap (and the currency is 2:1). I'm at it for six months and I have a huge family around me -- helps with the isolation. I will jump on a plane friday and work 3 weeks from the beach, and once I feel this remote thing has stabilized I will move to the countryside to about half the cost of living, so in one year going from the local national market cap to almost 6 times that, working much less (more focus without the office interruptions and away from the 8 hours sitting=8 hours of work) will be attractive to some people like it is to me, I guess.


That is what appeals to me...the freedom to work from anywhere in the world, especially places with a lower cost of living. But even if I stayed local, it would be nice to just be free from a daily commute and regular hours. Most of the time I'm very productive at 5am-7am and 10pm-2am. My 3 month old daughter is most active between 9am and 5pm, so it would be nice to spend this part of the day with her. I'm still looking for a company that is open to remote work.


I've been doing remote work since college, and I travel all the time while working. That may be the best part of remote work. I even worked for a few weeks on a cruise ship. As long as there's an Internet connection, I can do my job.

As for the isolation thing, my family is usually at home, and I also go out a lot during the day.

I can imagine, if I were simply home alone for most of the day, that it'd get lonely and being able to go to the "office" to be around people would seem like a good trade.


Where is this? Can i join you?


Some people feel the opposite in regards to isolation. Introverts gather energy from spending time alone, and are actually drained by interactions with other people.


Working from home is awesome if you're the type of person where lots of noise/movement disrupts your work (which is most programmers). It's very hard to continually be in focus in an office, while at home it's much easier to be in the flow. Not only is it more productive, but I've noticed over time that I've been able to flesh out ambitious ideas much more often and have personally grown because of it.

Think of all the office drama, personal conflicts from trivial things, etc. A lot of it is gone. There is still conflict, of course, but it's real conflict, not petty about desk space or something.

As other's say, you also waste no time on commuting.

You lose constant communication though, yes, so you have to balance this with tools. We use IRC and are constantly chatting, joking around, sending funny pictures, etc. so I don't feel isolated at all. We also meet up 3 or 4 times a year, and it's fun to travel.

It's not for everybody, but it's optimal for some.


I've been talking to possible employers recently and I have a whole list of reasons not withstanding some family circumstances. Note that I'm talking about partial remote work, not full telecommute.

1. My commute is a drain, doing it five days a week drives me to be less motivated and productive 2. Working remotely has less distractions. 3. I know I work better when I'm not in the same place all the time, I have to mix it up or I end up staring at the wall. 4. A company that can't handle remote work has some major process issues, this is a red flag for me. 5. I have a kid, if I'm at the library or the coffee shop near home, I can come home to him at lunch. If you want to make me hate my job, ask me to spend all my time working in an office without seeing him. 6. If I can work remotely, I'm going to do more work. I'm going to keep working past 5 because I'm on a roll. If not, soon as five comes around, I'm gone.

An office is good, and having the option to come in is great. Forcing me to come in all five days a week says something bad about your culture and process. At least to me.


> Why do you guys want to work from home? Isn't the isolation during the working hours hard on you?

That depends on the person.

As you grow up, you may prefer to stay close to the ones you love, rather than to the ones you work with. Or you work better alone, with less noise and distractions. Or you realize that wasting 2 hours or more a day commuting for warming up a chair and using an Internet connection doesn't cut it. Or you may just like isolation.

Whatever reason, it's up to the person, and there are quite valid ones. You're doing no harm in leaving if remote working is not for you. In fact, you're doing the right thing.


The isolation can definitely get to you. I've been working remotely for just over a year and a month now. I found it was becoming really difficult around the 6 month mark.

I was rarely leaving my apartment and working long hours because it was really difficult to "turn off", especially when I never really left the office. I fixed this by getting a dog, and honestly it was one of the best choices I've made. Working remotely, you're in a unique position to provide a great lifestyle for a pet. My dog gets a couple walks a day, and is rarely home alone.

Getting out of the house for one or two hours a day to get some sunshine and take a break is extremely healthy. Plus, there is a local dog park near by that is always filled with people.

Dog aside, it seems that you had much less conversation with other employees than I've got at my job. There is an unwritten rule to leave Skype on, just to hear about updates with the company. Just being able to easily reach out and send someone a message (not through email, basecamp, etc) is important to me.


> Why do you guys want to work from home? Isn't the isolation during the working hours hard on you?

I think the ideal thing would be an office about a block away from where I live. I am pretty happy being back in an office myself, but hate the commute.


In my case, the company I work for is based in California (I started out from there) but I now live in Connecticut. It's been over a year since I last saw them.


I work remotely not by choice but rather because the people I wanted to start this company with don't live in Seattle, and I love Seattle. So remote it is - and for the last 7 years it's been worth it.

However the issolation is an issue - chat rooms, and Skype/Hangouts have always been a big part of how we hold the company together, and how we solve this issue. But for me coffee shops, are a big deal. I'm in one every day for an hour or 2, and that's where I get all my "water cooler talk" and random socalizing. Which on the whole works out quite well for me.


I had a very similar experience. I know and respect people for whom remote work is a good fit. I'm glad they are able to take advantage of it, and support that option for them. But for me, after about a year of it, I was starting to have real emotional problems, which I've never really had before in my life. The isolation just took a tole on me. Perhaps I wasn't doing it right. Regardless, my new job, a twenty minute bike ride from my house, is, even two years in, still fantastic.


Isn't having to deal with coworkers and people and commuting and workings fixed times hard on you? You say isolation as if that's a bad thing, I say solitude because it's not.


i think it depends on personal taste. i'm lucky - i love working from home and, since i live in s america, that lets me telecommute (which means better pay). but i have always been a "loner". i don't mean i'm a socipath(!), i can get on just fine with people (and enjoy their company), but am happiest by myself. i also find it hugely more productive (although you do have to worry more about compensating for low bandwidth communication - but that gets easier with practice, and easier still when you're working with the same people for a while).

although once a week for 20m sounds a bit low. we do also have a daily email (progress/plans) and i will typically chat or email with co-workers or clients (as necessary) most days.

i'm sorry it didn't work for you - hope you find a more communal job! :)


> Isn't the isolation during the working hours hard on you?

I worked in an office for the last several years, and finally just being around people all day every day just got unbearable.

I've been working from home for the last few months, and having 8 hours completely alone every weekday is wonderful.

And my coworkers skype and chat so I get low-grade social interaction.

So I guess that's the answer: for some people being around others is more stressful than being alone.


I've been working remotely for more than a decade now, and other than the occasional day or two now and again, I don't think I've been completely alone that entire time. Either someone is in and out of my place, or I go to somewhere where others are. I imagine that helps a lot with any feelings of isolation.


A few notes from someone who's worked remotely roughly 60% of the last 10 years -

1) Most investors know that startups are generally at a disadvantage with a remote team and give founders shit for hiring remote people. I've found thats one of the reasons early stage folks don't hire more remote people. And there is some truth to being more creative with a team around you... if the team is awesome. Also communication is infinitely easier when you can walk over to someone and ask them a question rather than wait for them to respond to an email

2) Working remotely when you are self-directed and not under tons of pressure, really does lead to awful productivity. At home there are just so many ways to procrastinate

3) However, you can be more productive from home when on a tight deadline. No coworkers bugging you and the music cranked however loud you want, working whatever hours you want means laser-focus for some people.

4) A good checkin routine is key. I've been most productive and been in productive remote teams when there is a routine like a morning "standup" call, and maybe an afternoon call. A good ticket tracker is crucial. Working for folks who use the phone a lot tends to have the most productive outcome

5) There are a lot more small companies who use all remote workers than you think. But they hide in the shadows, and typically are very unsexy cashflow oriented businesses, not venture backed startups. If you're willing to work for consulting businesses that do boring backend for big corps you can find good remote work. But if sexy startups are your thing, expect to get a lot of hesitation until you really prove yourself...

6) Change environments. Sometimes the house can stagnate - spend part of your day in a coffee shop, lease a desk in a cowork space etc and change up workspace once in a while. It helps me at least


2) Working remotely when you are self-directed and not under tons of pressure, really does lead to awful productivity. At home there are just so many ways to procrastinate

This is not true for everyone. There is a huge variance in how vulnerable people are to procrastination.


Have any good contacts at these "boring consulting businesses"? I am not averse to an unsexy (remote) job.


Saw that you connected on Linkedin if I hear of anything I'll let you know


My IT shop tried working from home for a couple of years and the team fragmented, we lost a sense of teamwork, and we started wondering what each other are doing. A new CIO mandated working from the office and it has made for a much better culture and collaboration environment. There's definitely something you lose when you don't work in the office with your fellow team members.


I think that depends on your process and team culture. My current team is remote and we aren't fragmented. For most remote teams all it seems to take is a daily status meeting and a chat room.


I am beginning to feel even a daily status meeting is too much - I would much prefer to take on tasks of around a couple of days, and when done, demo.

Otherwise just skype and chat keeps one in touch

(I would be tempted to mandate a person to person chat for each team member to each)


I am beginning to feel even a daily status meeting is too much - I would much prefer to take on tasks of around a couple of days, and when done, demo.

I feel the same way. Often times I really have nothing meaningful or relevant to share with the team on a daily basis.

"So yeah, that feature we all agreed would take about 3 days to complete? Welp, it's day 2 and I'm still working on it. Progress is good."

Any other details further than that are not of any significant interest to anyone else in the meeting because they all have their own tasks that they're focused on that week. People argue that these daily status meetings help identify problems early on but whenever I run into an issue, big or small, I don't wait for tomorrow's status meeting to rectify it I just immediately start a discussion in the chat room. Obviously this requires trusting your co-workers to not hide potential issues/blockers but if you're not trusting your team than there's bigger issues to deal with that daily status meetings aren't going to help you with.

That said, the benefits of a daily status meeting is all very dependent on the type of project and the amount of collaboration the tasks require.


I find status meetings become:

1. The managers way of finding out what is going on instead of seeing git, running latest code.

2. A way of giving developers bi-polar disorder as they either happen to have just checked in a working piece of code (up) or are still ploughing through on what they said they would do yesterday (down).

It can be good - but only when it requires execution not thought.

My solutions:

1. A selenium / CLI recorder. We make changes to a piece of code - which is covered by ten tests. You fill in the bug report and the recorder does video grab of the selenium web broswer doing the ten tests. Then anyone who is non technical can see what the actually results are - on Youtube!

I heard of some "developer lead development" in a job ad - I think it was Sky. The idea was github like I suppose - devs think "what we really need is" and go do it.

The boss effectively has a veto not a driver. The boss becomes a government.


Agreed. I can definitely see how a team that's used to working in physical proximity would need time and good direction to get used to such a drastic change in methods and environment, but that's simply a matter of acclimation, not an indictment of remote engagement.


We've been experimenting with remote workers for the last two years or so. Our team was used to work in the same place (in Paris), so it took a little bit of time to get used to, as we tried different ideas. Now it works really well with phone/video conferences, trello boards, github, remote pairing, and a (few) permanent chat rooms (thank you Freenode <3), etc.

I think the biggest complaint is that the offices sometimes feel empty to those who chose to work "on site". My take on this is "let's get smaller office space". Plus it costs less. :)


You know, one more thing I've been thinking on this all day. A thought I had years ago. I work from home.

Whenever someone says to me "coworking space" I just marvel. Boggle, really. Why? I cannot imagine ever wanting to be in a room full of other people in order to motivate me to get work done. I call that the tyranny of a room full of people.

If I am done for the day, I'm done. If I want to crank through then night, I crank. If you cannot motivate yourself to work hard when away from a crowd of people, I just feel like yer some sort of pack animal. I agree, being near a boss makes you work more, but mostly, it just makes you look busy. You spend more time trying to find something stupid and mindless to do, during those down hours when yer brain is dead, than you do doing actual work. Whereas, when I'm home, I just hammer through everything I have to do immediately.

If my inbox is full, I don't leave the computer. But when it's empty, fuck ya'll, I'm going to the park.

I'd much rather clean the house and cook a steak when I am log jammed than feel like I have to sit quietly at my desk, looking busy. I think our education system trains people to be too dependent on others for work ethic.


An interesting thing is when your company truly is special, remote may be a much better option. I work for Ksplice (which is now part of Oracle). Ksplice needed people with Linux kernel knowledge, and there is no central tech pool for that. The company had to build itself in a way that supported remote workers.

I think many people use a crutch that it will be too hard to build a company that way, but that is because they think in terms of "average" developers. With average developers, it will be hard, but once you realize your talent pool becomes much richer and will often include people who are already familiar with working remotely, it becomes much, much easier.


I've been working at home (developer) two days a week for the past eight years. This has helped keep me sane, as the round-trip commute time (foot and train) is three hours.

It does require commitment and effort, especially if most employees are office-based. I find I have to make more effort to make sure what I'm doing is visible to the rest of the team, and to communicate. Its easy to think you're communicating enough when others don't see it that way.

When I'm in the office I schedule tasks that need face-to-face time, and when I'm at home my only interruption all day is usually the morning standup. I consider myself really lucky to be able to work like this.

The practicalities are simple and inexpensive too. From home I can vpn onto our office network via a cheap soho router and bundled vpn software. I can use the office phone system with a cheap headset and sip application. Google apps is £2/person/month. Google talk, G+ hangouts and trello are free.


(lightly edited copy of my usual plea for evidence on this topic ;-)

Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal.

(And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - personal preference, getting access to people who cannot co-locate, etc. But for business productivity I'm not seeing much, if any, evidence).

I am not saying:

* That working alone in an office is bad / will cause projects to fail

* Telecommuting is bad (I do it - I like it)

* Telecommuting projects will fail (D'oh - of course not)

* You shouldn't telecommute (of course you should if you want to - but bear in mind that the business may have good reasons to disagree with that decision)

* That telecommuting makes you individually less productive (I'm personally unsure about this. I feel more productive when working by myself, but I know that personal perceptions of productivity can be false. Measuring personal vs team/company productivity becomes hard in anything less than the short term)

* That co-location is always the best solution (it isn't - other factors like team location and skills come into play)

What I am saying is that there is a lot of research showing that co-located teams in team-room like settings are much more productive. This runs counter to many developers preferences (mine too ;-) so it tends to get ignored.

So much more productive that solutions like 'Let's fly everybody to the same place and pay their room and board for a month' can be cost effective.

Here are some references to the research (If anybody has any research that contradicts this I'd love to hear about it. Especially if it talks about actual measured metrics of productivity - rather that self-reported 'I felt just as productive at home' ones.)

----

"It doesn't take much distance before a team feels the negative effects of distribution - the effectiveness of collaboration degrades rapidly with physical distance. People located closer in a building are more likely to collaborate (Kraut, Egido & Galegher 1990). Even at short distances, 3 feet vs. 20 feet, there is an effect (Sensenig & Reed 1972). A distance of 100 feet may be no better than several miles (Allen 1977). A field study of radically collocated software development teams,[...], showed significantly higher productivity and satisfaction than industry benchmarks and past projects within the firm (Teasley et al., 2002). Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006). Close proximity improves productivity in all cases." -- http://conway.isri.cmu.edu/~jdh/VRC-2008

"Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact requirements gathering, negotiations and specifications. Findings reveal that aspects such as a lack of a common understanding of requirements, together with a reduced awareness of a working local context, a trust level and an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers" -- http://link.springer.com/article/10.1007%2Fs00766-003-0173-1

"Our results show that, compared to same-site work, cross-site work takes much longer and requires more people for work of equal size and complexity. We also report a strong relationship between delay in cross-site work and the degree to which remote colleagues are perceived to help out when workloads are heavy" -- http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&#...

"Our findings reveal that: software developers have different types of coordination needs; coordination across sites is more challenging than within a site; team knowledge helps members coordinate, but more so when they are separated by geographic distance; and the effect of different types of team knowledge on coordination effectiveness differs between co-located and geographically dispersed collaborators." -- http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...

"One key finding is that distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is colocated" -- http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/...

"Our study of six teams that experienced radical collocation showed that in this setting they produced remarkable productivity improvements. Although the teammates were not looking forward to working in close quarters, over time they realized the benefits of having people at hand, both for coordination, problem solving and learning.Teams in these warrooms showed a doubling of productivity" -- http://possibility.com/Misc/p339-teasley.pdf

"Despite the positive impact of emerging communication technologies on scientific research, our results provide striking evidence for the role of physical proximity as a predictor of the impact of collaborations." -- http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

"Groups with high common ground and loosely coupled work, with readiness both for collaboration and collaboration technology, have a chance at succeeding with remote work. Deviations from each of these create strain on the relationships among teammates and require changes in the work or processes of collaboration to succeed. Often they do not succeed because distance still matters" -- http://dl.acm.org/citation.cfm?id=1463019


co-located teams in team-room like settings are much more productive

Whenever I've seen this done, the very best employees leave. I am a firm believer that you can train yourself to hop in and out of a reasonable facsimile to the "zone" in much less than 20-30 minutes (I do it all the time)[1]; but the level of distraction of the warroom type environment massively favors your more extroverted engineers. My experience has been the engineers I really want to keep, the ones who solve the really hard problems, are much less likely to be in that group.

In short, you may double your productivity for building that CRUD application, but when you have to solve that really hard problem, you may find you don't even have an engineer who is capable.

1. There is a level of concentration, the "real zone" below it that most development doesn't require. However, when it does, the interruptions become catastrophic.


It depends entirely on the kind of work being done.

If you've got a super-top engineer who can solve the hard problems, then they're probably working on something of their own, and can be off in their own room / at home / whatever.

But in my experience, that kind of "hard", mentally intense, non-collaborative work makes up only a tiny, tiny fraction of commercial software development (although it contributes a great deal to the value). So it's not something to base general development practices around; it's the exception.

As you say -- "double your productivity for building that CRUD application" -- that's exactly the point, that's what most companies need, and why most companies aren't interest in remote working.

When they suddenly need a top-level engineer to solve a hard problem, they hire one who consults for three months, works remotely, and visits once or twice.


When they suddenly need a top-level engineer to solve a hard problem, they hire one who consults for three months, works remotely, and visits once or twice.

You've essentially described every job I've had since college. That's exactly my experience of how companies actually work in practice.


How does one acquire the connections to be called in as this type of engineer?


I'm constantly learning, and seeing when things become "possible" with the current state of knowledge. Whenever I see that, on my own, I'll sketch out how the solution would work.

Then, I look around for companies that need a problem I already have a solution for solved, and I pitch my solution to them. Sometimes, I'll take jobs to solve problems I haven't considered before, but that's rarer.

If they like my solution, I set up a contract to implement it for them.

I'd say about 50% of the time I pitch a pre-existing solution, I get work. What's great is I'm essentially picking my own work and I get paid well (because the problems are hard).

The downside is you pretty much always have to be coming up with new solutions to things, and stay very current on technology.

I'm generally into something long before the "early adopters" get there, and I'm gone by the time it hits the mainstream. For example, I was working on a Google Spanner-like database while Google was doing the same.

At the time, no-one thought something like that was possible (outside of Google -- and they didn't tell anyone). I implemented different parts of the solution with three different clients over a two year period, none of whom hired me to create something like Google Spanner, but all of whom needed one part of the whole package solved.


So, in the best interview tradition, what do you read to keep up to date with the state of the art?

I have a couple of times found myself inventing solutions to problems I had in the business, only to see them appear as cutting edge open source at the same or a little later (ie Python deployment tools)

I have always assumed one needs to be working in an area, pushing hard and then finding that "what no-one has an answer to this!?" moment.

I would have trouble believing I could find a solution at the cutting edge, and find the people who needed it, without being knee-deep myself.


As you suspected, I'm developing solutions in the areas I work in specifically (stuff I'm "knee-deep" in).

I read the usual CS papers, plus lots of PhDs thesis. I follow the references in the bibliographies like crazy, and I also look up the writer's on the 'Net and see what other stuff they've done/written.

It feels like detective work, actually: the most-cited papers are frequently not the best. There's tons of researchers working in obscurity but who nevertheless have useful results.

I see my role as taking advances from research and bringing them into practical use.


It feels like detective work, actually: the most-cited papers are frequently not the best. There's tons of researchers working in obscurity but who nevertheless have useful results.

What are some examples of the best research that is obscure?


Sven Havemann's PhD on "Generative Mesh Modelling"[0] is brilliant. At this point, it could be implemented on top of Blender 3Ds newest modelling kernel.

In general, stack languages are great for graphics in both 2 dimensions (PostScript) and 3 dimensions (GML)[1].

[0] http://digisrv-1.biblio.etc.tu-bs.de:8080/docportal/receive/...

[1] http://en.wikipedia.org/wiki/Generative_Modelling_Language


This is fascinating. Can you give some more examples?


1. Time

2. Networking, Networking, Networking

3. Be willing to talk about yourself a lot.

4. Act Confident in the face of uncertainty.


If you have experience solving hard problems that helps. I had the good fortune of doing so in graduate school. That lead to a job solving another totally unrelated hard problem, with a technology stack totally unrelated to my graduate work. Once I had two gigs like that, the only people who responded to my resume's were people looking for someone to work with immature technology, or had a very hard problem to solve.

Also once you decide that you want to have a professional career jumping on technology grenades, do not work as an employee. I made that mistake. The nature of grenade jumping is that your are asked to solve a hard problem that needs to be solved in a short time, if you are an employee this amounts to massive hours, (70-90 hour work weeks), of unpaid overtime. Work as a contractor and be sure to bill for every hour. Or be sure to get a very healthy option grant if it is a promising start up. My life has been much happier once I started doing that.

Also be sure to work out, this sort of work takes a severe toll on your health if you do it for 20-30 years.


I could not help but misread #3 as "be willing to talk to yourself a lot".


That would be part of 4a. talk to the smartest person in the room, even if it is you.


produce a development library or product they can't live without. you then become an integration specialist.


I've been in more or less the same situation, but for longer periods of time.

I'm curious given your experience. My biggest issue is that I don't know what a 'hard problem' is, I know what comes naturally to me, and what takes me some time to grok, but my experience is that those problems that come natural to me seem to be extremely obtuse to others.

So what types of problems do you solve that allow you to market yourself in such a manor?

I assume you have NDA type structures in place so I expect very general responses.


Most importantly, not every project (nor startup, nor business) needs "the very best" engineers. Not every startup is changing the world, and even among the ones that are I'm sure you can pick out a few that aren't solving massively complex technical challenges that will be discussed in lecture halls for decades. The majority of good startups are just making money (sometimes not even that) until they get acquired.

Secondly, you're assuming that the best developers are going to be more introverted than the developer culture/profession as a whole, which I don't think is accurate.


> Most importantly, not every project (nor startup, nor business) needs "the very best" engineers.

This is highly underrated wisdom.

If you focus on always hiring "Rockstar developers," you'll find yourself in a miserable situation of competition and egotistical conflict. Hire your team, not your developers. Get your team working like clockwork with good systems and good relationships, and your company will be rockstar with whatever people you throw at it. Look at github, stripe, twitter, facebook—you think they only hire the absolute best developers? No, they have a top 2% just like you will—your goal should be to increase the competence of your entire company, not just ignorantly hire the best and fire the worst and hope for the best.

Spot on.

You're right about the other assumptions too (though the parent may not have been that serious about them). IMHO stereotyping introverts or extroverts as being better or worse at certain tasks is a huge --ism to avoid, especially in our field. I see 'extrovertists' and 'introvertists' battle it out all the time with their propaganda and ignorant beliefs about people, and no one wins.

It's far better and more productive to be a humanist and find a good balance. Both extroverts and introverts can be valuable to your team; both extroverts and introverts can be great programmers and workers. You should strive to hire a mix, or stop using it as a metric and naturally get a mix, since these traits like many others generally fall on a normal distribution.

Don't trust your assumptions about yourself, and don't apply them to others. They're probably wrong.


Totally agree - imagine you could hire Linux Torvalds. He is a great programmer but his best work was sending emails to others for 12 years.

This leads to an interesting thought - if you hired Linus and he started spending all his time emailing sarcastic notes to the other developers, how quickly would he get fired for "not focusing on developing code"?

Perhaps the key for CEOs is not to grow culture but to hire people who will grow it for you. You dont get to choose the culture, or even direct it. The funny Finnish bloke will. You just pay him.


And then he goes and creates a version control system when you just wanted a kernel....


... and also he created the kernel, and a way to manage its development better.

I don't see the problem. People who make cool stuff and solve problems in their spare time are the ones you want working for you. Even if they waste time sometimes going off on tangents, it's probably honing their skills and improving something relevant to your company or their own work abilities. No problem, you want that. Trust them to do the right thing.


Exactly. This is where having good engineering leadership can come in. A "mediocre"* developer can often be coaxed into producing great product with a little support from things like paired programing and code reviews. You'll probably increase his/her value and abilities in the process.

So you need your lead to be awesome. But the rest can just be good people who know how to code.

* this would be someone who may not fully grasp all the concepts and sometimes writes bad code, but is open to learn and listen. There are developers who write bad code and are arrogant/confrontational about their abilities. Those should be identified and fired as quickly as possible. They will sink your ship.


The problem here is that the awesome lead will not stay long in a company where all other people are mediocre. Awesome people want to work with other awesome people. There should be a critical mass of them to keep them from leaving.


Or if you're a startup you give your awesome lead enough equity to have skin in the game, and the authority actually to lead and shape the team.


This is relatively true, but at a small company (< 5 programmers) some people do like the role of "lead" and will stay with it as long as the people they work with aren't total idiots.


> Secondly, you're assuming that the best developers are going to be more introverted than the developer culture/profession as a whole, which I don't think is accurate.

I don't think that's the assumption at all. My personal experience is, unless you happen to be located where one of the "best" developers is, they simply won't move. So you have your choice of them working remotely, being lucky, or not hiring them.


> Whenever I've seen this done, the very best employees leave.

I took this to mean (a) be relative to the office specifically, not the industry generally, and (b) that those very best will get sick of the required face time, quit, and get a better job (the insinuation being that that better job will likely be majority or entirely telecommuting. I may have misunderstood the intent as I commented pretty much immediately after reading it.


I believe the point was that people detest that working environment, and those with a choice will pull the ripcord, whereas people who can't get another job will stay. I've seen that happen.

I just generalized it to my experience, which is less about introvert/extravert and more about "bad conditions force good people out/prevent good people from being hired"


> ... favors your more extroverted engineers. My experience has been the engineers I really want to keep, the ones who solve the really hard problems, are much less likely to be in that group.

I, too, read "group" as "extroverted engineers," and I don't really see alternative readings.


I don't think extroverted helps in a disruptive team war room. Most "collaboration" is someone interrupting to ask a question they could have asked in email and waited for an answer.


This sort of thing is the thing I'd love to see more evidence about.

Getting interrupted kills my flow. I'm less productive as I get back into flow (although I have techniques now that let me get into flow much quicker - but that's a separate post).

However - is that drop in productivity outweighed by the increase in productivity of the interuptee not having to wait / switch tasks / fumble on and make a mistake / build the wrong thing / etc.


Times when I've been put in a war room were absolutely infuriating for me, but the tighter loops in bringing people in on what you're doing got the "why not just do X" questions answered much faster. As much as I disliked the interruption, I'm more thankful for all the code that didn't get written because we talked it over first.

If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.


This pretty much matches my experiences. I went from a sceptic to a believer in co-located team rooms after seeing this a few times.

Did you also see the incidence of "bad" interruptions drop as the team got more experienced? That's what I've seen pretty much every time I've worked in this sort of environment.


> If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.

I really like this. I consider myself an intermediate developer, and can't even count the times a 5-10 minute conversation would have saved me an entire day - or week! - of wasted effort. I think this is easily overlooked because its not totally obvious that interrupting a highly productive, highly skilled developer could result in higher team productivity.


I'd be interested to know what your 'getting back into the flow' techniques are?


Generally I think about flow in terms of setting up intermittent reward cycles where I need to put in a little bit of effort, but not too much, to get the reward.

So I think about ways I get get back into those cycles quickly. To do that I try and cut up my work into the right size chunks, have a plan, and leave work with an "easy win" so I can get back into the loop again quickly.

Some examples. Hopefully I'm not descending too far into life-hacker wankery here ;-)

* I TDD code, and always try and leave myself with a failing test. If I'm interrupted and don't have a failing test I will deliberately break something or hit undo enough times to get a fail so I have an easy win when I get back.

* I don't track time on task. I do block out time for tasks - and track non-relevant interruptions during that time and see if there are ways to stop 'em happening.

* I run a personal kanban board for stuff so I can keep that continual ping of reward happening during the day.

* I breakdown tasks as they come in so they I can get little reward pings on a regular basis.

* When I have real problems getting into flow I give myself automatic rewards (do 20m on X then you can do 5m of fun on Y). Similar to http://en.wikipedia.org/wiki/Pomodoro_Technique. Once I get started the normal task-achievements often mean I don't actually end up doing Y - it's just a personal hack to get me started.

Basically - fake the reward cycle until the real one takes hold.

Make vague sense?


The reward technique never works with me. Because, to me, there is not 5m doing something fun. I cannot have something really fun in 5m. So I rather finish all the things in limit time and enjoy the rest of the day, it's the biggest motivation. My only work solution to get back to the flow quickly is leaving something undone. Depend on which task, it will have different ways. Btw, I really love the idea of leaving failing test :D


Your use of "the really hard problems" is revealing. Those of us who went to engineering school know exactly what you mean by that, because it's the way we describe the most challenging exam questions, projects, or open questions in the field. We can usually figure out those really hard problems if we put our minds to it.

But for most tech startups, I'm not sure "the really hard problems" are the technical ones, because we are good at technical problems. Perhaps the really hard problems are how to get early traction, how to build something people love, and how to make the business profitable. Some of those hard problems might be easier to solve as a face-to-face team.


Whenever I've seen this done, the very best employees leave

I've seen that happen (which brings up the separate question of does it matter if the team is N x more productive because of co-location)

I've also seen them stay.

I've also seen them start out very sceptical and then grow to like it (I was in this category - assuming I'm vaguely competent of course ;-)

I've also seen folk I hugely respect advocate and instigate this sort of environment.

.... so which anecdotes win... dunno... hence call for any folks who have found research on the topic.


I think it depends on how you run the war room. The way I prefer it is no off-topic conversation, no distractions, inside voices, and a lot of respect for your co-workers. Also, you need to provide convenient nearby meeting and lounge spaces so that people who want to do those things can easily do it elsewhere. I think that's a great environment for focus.

It takes some commitment to make it happen. Without everybody committing to a low-distraction workplace, volume is definitely the default. But I think the benefits of a team environment make it worth the effort.


When it comes down to research vs. your subjective experience influenced by your personal preference and opinion, why would I put more stock in the later?


I don't think that's being fair to the parent post's point. They're implying that the research, by focussing only on a productivity metric, may miss out on job satisfaction issues that cause top performers to leave. They're not contradicting the research, just pointing out that the issue is complex.


If that's the point, then I'll agree that the issues is indeed complex. This all highlights the need for more research in an age of better tools for videoconferencing and cloud project/file management.

As a management major (do regret) I was taught that it only works when there are clear definitions and metrics for success, especially routine tasks that require less creativity. I don't see that backed well by modern research, and I wish we had better research.

I also feel the anger people (especially programmers, it seems) feel about not being able to work remotely is misplaced. If it upsets you that they want people to work face-to-face, you're probably not a good fit for the company culture that requires it anyway.


I think the "war room" solution is often a symptom of generalized poor management. And bad project management drives away experienced staff.

The open office plan is a nightmare for tech work IMO.


Then how do you explain the many happy teams I see working in exactly that environment, and how do you explain the research?

(Part of the confusion may be that "war room" and "open plan" are not synonyms. The former only includes people actively working on the project. This is not the environment where you have the sales guy yapping on the phone.)


I've worked in the "war-room" style environment, it's okay as long as it's only for work, and not play, because when you have the "game-room" the "work-env" in the same place, productivity goes way way down. It's hard to work when you see your co-workers playing table tennis or foosball, especially at how loud foosball is or tennis is when they laugh etc. I'm not against these things, I just think that companies might consider spending a little more money on an office or atleast put their game-rooms in separate areas, and require a library policy in open-warroom offices.


I said it is often a symptom, not always. Of course it is possible to have a happy team in almost any environment.


War room is a form of open plan in my view. I agree not all open office plans are war rooms.


Introvert programmer here. I find the opposite to be true. In an office situation, I'm much less likely to intrude on someone I need to communicate with, and they are much less likely to intrude on me. In an open environment, I get to overhear conversations that then demand my input. Yes, on occasion, I have been interrupted while attempting to formulate a very complex solution in my head, and yes this was frustrating. However, the benefit of all those overheard misconceptions and subsequent explanations vastly outweighed them.

That is why I firmly believe that given any team, it is best to have them collocated in a large but private room.

However, we are not talking here about the optimal location for any given group of programmers. We are talking about finding an optimal group of programmers without having to exclude those outside a 20 mile radius of your geographical location.


I've seen the opposite. When the team is that close it is difficult to hide your ineptitude. Team members that don't contribute get outed pretty quickly and tend to leave. This is generally viewed positively by those that are core contributors.


Sometimes solving the hard problem means jumping into a teamroom in front of a whiteboard and doing some serious brainstorming / design. That is the one thing that is very hard to do effectively over say skype. Often with remote developers this type of problem is solved by a single person without the input of others. Resulting in a less then optimal solution that only one person is knowledgeable in.

As far as really getting into the "zone". What I do is put my headphones on, pipe some white-noise in and in a minute or two it's no different then working by myself in my home office.


I think the hardest part of product development is deciding which hard problem to solve. A team can often be better than a single very smart person at doing that, by virtue of bringing different perspectives to the conversation.

IMO the best working environment places the team in conversational proximity, but provides an option for individuals to find isolation (either in a dedicated room or at home) when it is necessary to solve a hard "real zone" type problem.


The most productive team I worked with, and one of the most senior teams within an organization of several tens of thousands with a very significant development staff, was approximately 50% remote, depending upon how one measured and when one included some remote developers and operations people (also very senior) who were intermittently present depending upon project needs. (Some of the operations people were often on site but located far enough away that much communication was as if they were remote.)

And its trend was increasingly remote. Members sought this once and as they could, because it increased their effectiveness so much. (And lowered costs and total time demands -- e.g. commuting -- in positions that were already delivering far more than 40 hours / week.)

This team outperformed the other teams by a fair margin. And some of the truly remote members were among the most efficient and effective I've seen.

Throughout my career, I've seen very little evidence that physical presence -- colocation -- makes a significant positive contribution in software development. I am biased, I will say, in that I both prefer and need a quiet work environment. I feel validated or "justified" in this need, for me at least, in that I've consistently been one of the most effective employees in the organizations within which I've worked. (And I've had numerous people in all sorts of roles tell me this.)

I don't mind colocation, if quiet offices are provided. However, cubes or worse are largely de rigueur, these days, and even in such open space environments, I've witnessed not just the destructive nature of noise and interruptions, but depending upon the staff member enormous amounts of time wasted on "socializing" of various (very off-topic and sometimes inane) sorts. Doubly bad in that context, in that it invariably distracts surrounding employees who are trying to work. And it builds a conflict between not betraying teammates and one's own need to have them quiet down or take it elsewhere.

As for who tends to "thrive" in such environments? Those who "multi-task", juggling lots of things shallowly to the point of making many mistakes and oversights. Those who are constantly "interacting", meaning most often that they are interrupting someone else to solicit knowledge that they should have or be able to look up themselves. Those who use the concept of "team" to disperse and deflect individual responsibility.

Granted, I and the people I've described may be a minority. But in my observation and perhaps in staid corporate environments, those who benefit from colocation tend to be those who need to be herded and hand-held. Those who want and are really able to get shit down, don't mind face to face but are greatly frustrated with pointless and distracting face to face.

(As an example of this latter, we got many of our meetings down to 15 to 30 minutes, when they were necessary. People knew and held themselves responsible for knowing what was up, and the meeting could quickly focus on problem solving and setting a specific course.)


Granted, I and the people I've described may be a minority. But in my observation and perhaps in staid corporate environments, those who benefit from colocation tend to be those who need to be herded and hand-held. Those who want and are really able to get shit down, don't mind face to face but are greatly frustrated with pointless and distracting face to face.

I too don't know what the numbers are like. I've seen great teams do great things remotely. I've seen great teams do great things co-located. Some of the very best teams I've seen have been co-located. I've also seen some distributed teams fail miserably. I've seen teams co-locate, try remote working, found it didn't work, and co-locate again. And so on.

I wish I knew the relative spread of how these things work out for people in different contexts and on different projects. I just find it suspicious that remote work is often presented as all upside since:

a) In my experience things are rarely all upside - I always start looking for the downside ;-)

b) For whatever reasons a chunk of the dev world tends to be a tad asocial. I know I can be like that. So when something comes up that supports that tendency I wonder if I may be overlooking problems because I would like something to be true.


I think that some in the development world may be less indiscriminately social.

I'm plenty social. And I'm not a snob -- I can talk with most anyone, about genuine interests (interests on either party's part, not just my own). Or just sit around drawing spirals in the pancake syrup, for a while.

I don't particularly enjoy discussing the latest Hollywood movies and actors ad nauseum, whose existence and which conversation seems to serve significantly to reinforce established, simplistic stereotypes. Especially when the conversation ranges in exactly that direction.

I don't enjoy conversations that "get personal", looking for ways to pick apart those not present (behind their back). Or that look for ways to pick apart those present, in active, emotionally manipulative pursuit of a pecking order.

On the team I described, we socialized, although people were on average fairly reserved. A good part of that socialization reflected people actually paying attention to and remembering what each other were interested in and doing, and what was going on in their lives.

Again, this is just an opinion, but I think some of the "anti-social" attributed to "nerds" and "geeks" is rather an active dis-interest in much of the lowest common denominator of what we consider "social".

(Some, not all. I've met plenty of intellectual assholes, too.)

Another, personal example: I rather enjoy playing sports. I couldn't care less about watching paid professionals doing it. (This does vary somewhat by sport and event. Also, if anything, I tend to find amateur games more interesting; they bear a closer relationship to my life than the over-produced, over-medicated thing that professional sports has become. Upon reflection, maybe this is a somewhat arrogant or avoidant attitude on my part; I received a lot of abuse as a kid for not being "sports-wise" -- something my father wasn't and never passed on to me.)

I've spend too much time and energy on self-doubt, as it is. A lot of places and people have told me that I'm the one who needs to change. They love my work, and how do I do that? But, you know, "We all work in cubes."

If you are outperforming your peers (and, not infrequently, management) and otherwise succeeding, then, well, who has the problem?

The following may take the interpretation a bit far, but: The bully will always insist that it's "your problem".


Not saying that you are wrong, but none of the studies you quote was done in the last five years, and most of them are actually more than a decade old.

The technologies we use to communicate evolve fast, and I would bet money on the fact that (probably because of mindset evolution and tooling) developers are now more efficient when working remotely than they were ten years ago. Moreover, as we are on HN, we are not necessarily talking about average developers, but more about the ones that are used to Git, IRC, Trello, and other tools which make remote work more doable.

Startup environments are not average, and this must be why companies like Github and 37signals can be successful while having remote workers.


Not saying that you are wrong, but none of the studies you quote was done in the last five years, and most of them are actually more than a decade old.

Actually - several of them are. For example:

"Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006)"

This is one of the things I find fascinating. You see the same kind of thing over thirty years as technology changes radically. This makes me think that there's something quite interesting happening in meat-space.

Startup environments are not average, and this must be why companies like Github and 37signals can be successful while having remote workers.

Just to repeat. I am not saying that you cannot be successful being distributed. There are lots of good and sane reasons to be distributed.

I'm saying that there is a bunch of evidence that being co-located is more effective.


2006 happened 7 years ago. Time flies.


Software changes in 7 years - people don't. [I mean the average person; individuals age and get more experienced, but new ones come in.]

Today's homo sapiens brains function the same way as in 2006. Productivity of mental workers responds to disruptions in the same way as in 2006. A large majority of programmers and other people working now in IT are the very same people that were analyzed in 2006.


Brain function is not the only variable at play here. Software and culture change constantly.


Yes, but haven't the tools for working remotely improved a lot since 2006?


Not really - no. I can't think of anything off the top of my head that I couldn't do six years ago.

There are a few more options maybe - but nothing fundamentally different.


They have, but if you look at it in terms of fundamental change, then of course not.

For example, a cell phone from today isn't fundamentally different than a cell phone from a decade ago. They're both computers and can be used to make phone calls. But with the cellphone of today, I can have a virtual meeting with anyone from anywhere, face-to-face. That alone is a huge improvement for distributed teams.


It's not every day you get to use the phrase "technologies we use to communicate evolve fast" and IRC in the same paragraph.


Oops, I was sure I was going to get caught on that one, but couldn't really help myself.


A lot has changed in the last few years-- with modern tools (Skype, Google Hangouts, IRC, GotoMeeting), it is possible to not only almost entirely replicate being co-located, but to even enhance productivity by spinning out ad-hoc co-located teams to solve individual problems.

Need to have a concentrated task force from 5 various departments? No problem, it's a click away-- no need to book a meeting room, take all your gear (disrupting your workspace) and try to collaborate away from your desk in a mutual location.

Currently I sit beside people working that I previously worked on the same project with, but have now slightly diverged from. Trying to come up with a perfectly co-located office plan wouldn't work, because some number of people couldn't help but be misplaced. Not to mention we'd have to do it every few days!


This. There's free technology to solve most of the remote workers' problems.


A lot has changed in the last few years-- with modern tools (Skype, Google Hangouts, IRC, GotoMeeting), it is possible to not only almost entirely replicate being co-located, but to even enhance productivity by spinning out ad-hoc co-located teams to solve individual problems.

The evidence from folk who study this seems to differ from this.

The world is full of anecdotes about how much better things are with the newer technologies - yet I can very little evidence that this is true. I know I'm really good at fooling myself about my own productivity. I don't imagine I'm unique there ;-)

And my personal anecdotal experiences over the years (including recent ones ;-) is that you can really ramp up productivity by getting everybody on a distributed team in one place. Even when everybody is normally skyping / IMing / whatever.


This really is the most important facet to this discussion. Virtually all arguments against remote work seem as if they come from the archaic past. If people being physically separated actually hurts communications, you are doing communications wrong.

Not to mention that most productivity studies are bunk.

The real reason many so many managers resist remote work is because, effectively, they want a fiefdom, and the exercise is often about empire building. An empire of a bunch of Google Talk connections isn't as impressive as a bunch of huddled seat warmers.


Is it churlish to suggest that the most clear counter-example to "all in same room" is http://git.kernel.org/

However with a cursory glance over the references, they seem heavily biased towards a "crunch time, in a war-room" scenario.

This can lead to large productivity gains for reasons unconnected with physical location

(Clear short term goals, only the best get invited into the war-room, daily distractions and resposibilites are lifted, a fostering of elitism compared to the outsiders)

However I cannot see a long term study on this (I may be wrong).

My "gut feeling" is that regular funded sprint meetings plus remote working is an area of research that may well yield best long term trends.

But wheres the proof :-)


"Is it churlish to suggest that the most clear counter-example to "all in same room" is http://git.kernel.org/ "

Not churlish - maybe misguided ;-) I'm really not trying to suggest that distributed work is bad / evil / fails. Just that - all things being equal - colocated teams win. That there is a substantial body of evidence that not being colocated carries a substantial productivity hit.

My "gut feeling" is that regular funded sprint meetings plus remote working is an area of research that may well yield best long term trends. But wheres the proof :-)

Indeed! It's the complete absence of "distributed teams do X and Y better" research that I find fascinating. Unless it's hiding in a corner that I've not been able to find.


I'd be curious to know if any of the quoted research looked at open source projects. In addition, I'd be curious to know if it included organizations such as GitHub and 37signals, especially given how old it is.


Very few pieces of the kernel were actually developed by teams. One guy writes this subsystem, another writes a driver. The interactions between components are well established. Approximately 0% of the linux kernel consists of interdependent components simultaneously developed by different people.


I think he's implying the kernel as a whole. Clearly, the whole kernel is developed by a very distributed "team".

That said, you get right to the heart of the matter: the interactions between kernel components are well established. Sufficiently so that one person can work independently on a subsystem and another on a driver.

In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first. They are very fluid and so it's necessary to be able to lean back and yell at the guy working on the driver or subsystem and say "yo, I need this additional parameter". On a distributed team you need to write that in an email and that extra effort is often seen (rightly or wrongly) as a major bottleneck.

Where I have seen companies fail to work successfully with geographically distributed teams, it has generally been because their "all in one room" culture has allowed them to establish an adequate process/culture around designing quality component interfaces in an efficient manner. This inability to define quality "contracts" is typically what leads to slipped projects and missed expectation. Often times, it is what plagues teams that are co-located.

If you can do a good job at defining system components and their interfaces, doing the development independently and distributed is easy. You can write test harnesses and stubs around those APIs. The question is: can you work on that design process in a distributed manner as well?

In my experience, it doesn't matter, local or remote. Designing component interfaces is hard work and hard to get right. But it is essential.


perfect perfect perfect

  In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first.


Whether or not there are some measurable benefits to the company for telecommuting does not matter.

What matters is this:

(1) The software company needs your software skills more than you need the company.

(2) You decided and plan your life around telecommuting.

(3) So telecommuting is non-negotiable.

Non-telecommuters tend to be wary of remote workers, not because they are any more or less productive. There's an underlying fear and a need to control risk. A manager who is not used to this want to reassure himself that things are going smoothly. You address that, then things fall into place.

In other words, the managers, speaking for the company say they want more "productivity". What they really need is more control and reduction of risk. They feel a certain level of assurance when they can see people walking into the office on time, every day. It assures themselves of their own continued employment. Give the manager what he needs (the assurance), and this conflict goes away.

As for recruiters, at the end of the day, they are salespeople trying to close a commission. There are only a few exceptions where a recruiter acts more like an agent, rather than trading you like a commodity. Obviously, such people are worth keeping contact with.


Whether or not there are some measurable benefits to the company for telecommuting does not matter.

I don't think that it's always this clear cut.

In other words, the managers, speaking for the company say they want more "productivity". What they really need is more control and reduction of risk. They feel a certain level of assurance when they can see people walking into the office on time, every day. It assures themselves of their own continued employment. Give the manager what he needs (the assurance), and this conflict goes away.

This isn't always true - or necessarily often true. Most managers I've deal with over the years are much more focussed on productivity than control. Some maybe think that control is the best route to productivity - but that's a different problem to solve.

For a start - everybody here who's building a startup. As soon as you get employee #1 - congratulations. You're a manager. Are you suddenly unconcerned about productivity ;-)

As somebody who is considering non-founder hires in the next year I'm thinking about ways that I can have them be local and co-located. Despite the fact that this may involve getting an office for the first time, possibly moving locations, hiring newbies and training up rather than hiring for skills, etc. Because, in my experience, the productivity gains could well be worth it. I'm going to experiment at the very least.


Productivity is what employees generally want. For every want, there is an underlying need that may or may not match that want.

If you only address that want, then you are not addressing the underlying need.

Lots of people say they need to get stuff done, but that is not the true underlying need. These are usually driven by deeper motives, generally relating to need for parental approval (fame, glory, success, achievement, etc.), need for security, and need to eat.

Why do you really want to build a startup? If you're honest with yourself, you'll generally find that your want and need don't match. (And if you are impeccable, and your want and need matches, things tend to go smoother).


While I agree that it's not as cut-and-dry "driving to an office in an anachronism!" as most on HN would like it to be, you're not going to win any converts by quoting studies from 1972 and 1977.


I think its a measure of the paucity of Software Engineering as a discipline that a intelligent and motivated person as the parent, is unable to find any research later than the 1970's

(It seems to me that most software research stopped as the PC revolution took off)


It seems to me that software research moved out of the Hallowed Halls of Academia and into the nasty pizzabox-laden basements of geeks' parent houses, where thousands of people hacked (no chicken involved) on massively capable inexpensive hardware.


Clearly you didn't read his post, because several of the links were published since 2003.


The fact that there are studies ranging from the 1970s to the 2000s is actually one of the reasons I find this so interesting.

Communications technology keeps getting better - yet co-location still seems to carry a major advantage. That is interesting to me.


Yeah the biggest difference here is that this is about software development. A room full of people is great when you all need to talk a lot and discuss things and plans and exchange info really quickly and casually.

But for programming, I find the best environment is an empty room, no distractions, headphones on, and NO ONE bothering you. That's not gonna happen at an office. Programming requires intense concentration, hard to get in a room full of people.


That's not gonna happen at an office. Programming requires intense concentration, hard to get in a room full of people

I'm willing to believe that, for some people, this is true. That they cannot work outside of environments like this.

There are also people who believe that they cannot work well outside of environments like this - but are incorrect (I used to be one of these).

There are also people and organisations who are very successful great developers who love and promote team room environments.

a) I'm not sure of the relative numbers of those groups

b) If the team room environments are a lot more productive then developers of the first sort are going to have long term problems getting work on projects that involve teams of developers


One thing this does not account for is that your potential developer pool increases by orders of magnitude with remoting. So, while a team might be more productive co-located, your ability to get much higher quality individuals working for you increases dramatically with remoting.


It appears that the gains from team dynamics (packs) outweigh the average individual quality (lone wolves) for most tasks. The optimal solution in finance, at least, is having the bulk of work done with co-located teams with telecommuting being an option when recruiting niche geniuses for specific tasks.


Point taken. I imagine much depends on the domain and deliverable, as to what that ratio might look like. As someone stated above, not every company is doing ground breaking work which needs the "best and brightest". But some companies might, at least in niche areas as you mentioned.

However, I know from attempting to hire even entry level engineers in sub-250k population areas, it can be very tough to even find a bare minimum candidate. I would jump at the chance to hire a rock-solid developer in a nearby city, state, or even country.


Agreed completely. I'm sorry - I thought I had expressed this in the original post when i said

"Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal."

If you can think of a way I can express that opinion better I'd appreciate it (This isn't sarcasm - it's a genuine request. Judging by many of the replies here I'm expressing myself badly ;-)


You potentially drive prices down, too, by exploiting cost of living outside your location.

There are plenty of good programmers living in relatively cheap places (Like the Midwest, for example). Pay someone in Minneapolis $10-15k less per year than what that same person would make in Palo Alto and that person could still end up above market for Minneapolis.


It's my experience that most people are simply terrible at communicating remotely. So this is what gets reflected in studies done on co-location.

After all, traditional interviews bias for those who are good at face-to-face communication. There is basically no filter for those who suck at remote communication.

It's exacerbated by the fact that it takes more than one to communicate. If you work remotely, it's not sufficient that you are capable of writing an intelligible email. Everyone you interact with also needs this ability, which tends to be rare in companies that are not purely remote workers.


I've worked on two fully distributed teams, and I can assure that it is was a part of the interview process to determine how well the individual could communicate remotely.

If scheduling our call was difficult, or if you were hard to understand on the phone, or if there was excessive background noise, I'd hold that against a candidate. If your emails were not clear and intelligible, that counted as well.

People who communicate well remotely stick out like a sore thumb when you are interviewing for those types of roles and if you value it. If you are just looking for warm bodies, I can definitely see how it would be problematic.


After all, traditional interviews bias for those who are good at face-to-face communication. There is basically no filter for those who suck at remote communication.

That's a really nice point that I'd not considered before.

It's exacerbated by the fact that it takes more than one to communicate. If you work remotely, it's not sufficient that you are capable of writing an intelligible email. Everyone you interact with also needs this ability, which tends to be rare in companies that are not purely remote workers.

The problem is that, from what I've read, the productivity advantage that folk get isn't through the sort of good communication you get from writing effective emails. It's the more ambient communication you get from noticing your coworker has been staring at the screen without typing for a few minutes, or from hearing and correcting a mistake automatically.


Here's a study that showed an increase in productivity with telecommuting employees: http://www.marketplace.org/topics/business/freakonomics-radi...

A reduction in health risks and distractions are two of the noted benefits. If productivity depends highly on teamwork, telecommuting may not be ideal, but it should improve individual productivity for the right employees.


Thank you. Not come across that one before. Anybody got any references to the original paper?

I'd be interested on whether the comparison is to general open plan offices vs team rooms.

A reduction in health risks and distractions are two of the noted benefits

Health risks? I wonder why. Most accidents happen in the home and all that ;-)


1. How do you define group productivity? 2. I'm willing to bet that most of those studies looked at what happens when you take some "on-site" positions and simply hand them to remote team members. Why? Because that's what usually happens. Companies do not want to alter any processes, team structures or responsibilities to explicitly deal with remoteness. Naturally, if you pretend that someone from another state is sitting in the next cubicle, bad things will happen. Companies that embrace remoteness from the start (like GitHub) seem to be doing fine, precisely because they treat remoteness as an asses, not a minor concession someone had to make to workers.


* I'm willing to bet that most of those studies looked at what happens when you take some "on-site" positions and simply hand them to remote team members.*

You'd lose that bet. There are a variety of different methodologies and areas studied.

Companies that embrace remoteness from the start (like GitHub) seem to be doing fine, precisely because they treat remoteness as an asses, not a minor concession someone had to make to workers.

Again - not trying to argue at all that people cannot be fantastically successful as a distributed team.

What I am saying is that every single piece of research I can find says that colocated teams are more effective. This is... interesting... to me.


How much of that research includes open source projects and companies like GitHub and 37signals?

How much of it was looking at teams that are "super distributed", for example, between the US and India, where major differences in time and culture can play a huge role compared to say, a team distributed between Chicago and New York?


These two seem to fall into the category I described:

http://possibility.com/Misc/p339-teasley.pdf

http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...

This one does not seem to involve developing software:

http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

Remaining two articles are not publicly accessible.


What about this case study on the development of Windows Vista? -- http://macbeth.cs.ucdavis.edu/distributed.pdf

Granted, it doesn't study efficiency but defect rates, but having development distributed geographically was shown to have little negative effect.


Thank you! Somebody had pointed me to that before but it hadn't made it into my reading pile yet. Added to the list.


"interruptions were greater in number but shorter in duration and more on-task"

Given recent studies on multitasking, and the time it takes to get back on task, this does not sound like a positive thing.

"an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders"

Most "work artefacts' in software development are digital (and easily shared with the modern internet), and thus distance doesn't matter. This is obviously different from when this study was published in 2002.

The delay mentioned in the 2001 ieee article is virtually non-existant in modern work-from-home settings, where people are constantly connected by DVCS, screen sharing, skype, google hangouts, etc.

Yes, I'm cherry-picking problem quotes from your cherry-picked quotes, and don't have any studies to back up my beliefs (other than my own experience, which is frankly enough for me). That said, most of your citations are old, don't take into account research into human multi-tasking on complex projects, and don't take into account the tremendous advancements in remote communication that didn't exist as little as 5 years ago (github, google+, skype group calls, Trello, Bitbucket, Facetime, etc.)

Yet another anecdote: the last open office I applied to was definitely a war room... Warmachines, that is. I can't imagine getting anything of value done in that kind of environment.


Given recent studies on multitasking, and the time it takes to get back on task, this does not sound like a positive thing.

The question is when does an on-task interruption stop being something that switches modes. Also while the cost of task switching for an individuals productivity may be bad - it may be a net good for the team as a whole.

(BTW which recent studies? Interested in this since most of the multitasking research I'm aware of is pretty old and has the same general message of "it sucks". Would be interested in newer angles on this. Been away from academic cog-pych libraries for a while ;-)

Yes, I'm cherry-picking problem quotes from your cherry-picked quotes, and don't have any studies to back up my beliefs (other than my own experience, which is frankly enough for me).

My experiences have been mixed, but much more positive for co-located team rooms as I've seen folk try different alternatives.

Personally I'd say that the most productive teams I've seen have been co-located - and I've seen several teams who have deliberately moved (temporarily in some instances) to co-locate because they find it works better for them.

That said, most of your citations are old, don't take into account research into human multi-tasking on complex projects, and don't take into account the tremendous advancements in remote communication that didn't exist as little as 5 years ago (github, google+, skype group calls, Trello, Bitbucket, Facetime, etc.)

Most are old - but not all. I also think we tend to overestimate how much things have changed technology wise. I was using video chats, distributed source control, etc. five years ago. What we have now seems to be incremental improvements not game changers.

When I first started looking at this sort of thing six or seven years ago people applied the same arguments about email / internet / web....

Yet another anecdote: the last open office I applied to was definitely a war room... Warmachines, that is. I can't imagine getting anything of value done in that kind of environment.

My experiences have been different. An anecdote battle would probably be pointless - but some other folk in the thread seem to have had similar experiences.

I find it interesting that there's been no newer work showing clear benefits - which is why I'm looking.


This has been very true in my experience. Even having the team in the same room and the same space, but with individual cubicles can be insufficient. It is really hard for people, especially developers, to let go of their personal space. I know it was for me during the transition.

Working on many different teams in numerous cities over the last few years, the bullpen and shared space is one of the best ways to remove silos and promote organic conversation (kill meetings). Pairing instead of code reviews (or gated checkins), talking instead of team meetings, one on ones instead of political games and going out for coffee to think through a hard problem. With the right team, you show up at 9am and leave work at 10am (really it is 5pm, but it feels like 10am).


If the alternative is not having a person at all isn't a competent remote person preferable?


Yes it is.

I tried quite hard in my post to say that I thought there were valid reasons for doing remote work. Just that the balance of evidence that I can find is saying that co-located teams are more productive.

I'd appreciate it if you could let me know if I've expressed myself badly - and any suggestions on expressing myself better are would genuinely be appreciated.

As I said in my post - I telecommute a great deal myself. For pretty much exactly that reason you outline. I am really not trying to say that telecommuting is bad ;-)


I telecommute full time and have for upwards of 8 years, so I'm wildly in favor of it.

My comment was not a poke at you, just the absurdity of not allowing it at all.. if the alternative is worse.


Very relevant video from Gabe Newell about this topic. http://www.youtube.com/watch?v=t8QEOBgLBQU&t=22m30s


Thanks for that. The experiences he talks about of people naturally seeking co-working spaces is something I've seen too.


Indeed - thanks.


I really like the "all things equal" part. Usually all other things are far from equal. You have companies having the entire culture of remote work, availability of skills that's not willing/able to relocate to wherever your company is located etc. etc.


If you're doing software development without an asynchronous work pipeline in 2013 then you have a problem. Regardless of remote or local work, long periods of uninterrupted concentration is exactly when the vast majority of productive work is performed in any given software project. That being the case it makes perfect sense to optimise the pipeline around this very basic fact.

Once that is out of the way, whether you're local or remote is basically irrelevant. All the disadvantages to remote work have always centered around an insufficiently asynchronous work pipeline. I say this as someone who presently travels the world and works on a large array of projects and would never even consider a role that attempts to change that part of my life, simultaneously in the past having worked extensively in async and non async environments both local only and remote.


> long periods of uninterrupted concentration is exactly when the vast majority of productive work is performed in any given software project.

That's only true in some projects, and perhaps not even the majority.

It seems like a very developer-centric perspective. But there are a lot of projects where the real value comes not from the actual programming, but in how everything is tied together, in the prioritizing, in consistency, in common understanding, with continuous improvements that deliver what's actually needed. The programming may be relatively trivial, but good management and teamwork is highly complex, and you need smart employees who are all able to see the big picture and keep on top of it.

This is a very common scenario (more common, in my experience), and whether you're local or remote makes a huge difference.


100% agree. I'm in a similar position. I will not move from where I live; I like the friends and hobbies I have here way too much. There is absolutely no reason in this day and age why the type of work we do has to be done onsite. The hundreds (probably more) companies working this way are a testament to this fact, and there would probably be even more companies doing it this way if it wasn't for inertia, tradition or just plain old CYA ("but if we do something different and fail, the shareholders will hold me accountable!"). To add insult to injury, I am easily measurably more productive when telecommuting, and I'm sure I'm not alone.

Conjure up any wishy-washy "reasons" or anecdotes why you have to be onsite, but I've yet to see any facts to back up the position that onsite all the time is better.


That is the best part of a remote team, your deliverables are the main way you are reviewed. Superficial things are less emphasized such as if you went to lunch with the right group, were in 8-6 on the dot or work on the right team, have the right office for visibility etc etc. So many levels of extra unneeded layers of fluff in an office when it should be on product development.

I do think it is good to work on site periodically and sometimes at least a day or two per week if you can, not because it is needed to produce good work and products, but because it helps kick off, complete + integration days and earns some office points in the not so fun office game.

Many places that have offices and require 8-6, their engineers end up getting interrupted all day and then do all their work at night. So in that case telecommuting would be a huge benefit to the individual but maybe not as much the company since they get so much extra time out. Maybe it is more a salary thing, getting lots of work out of you. I'd argue it looks like more work is being done at an office but remote teams HAVE to get actual work done, there is no other metric to be measured on.


I have worked both on a hybrid team (colo + remote) & a completely remote team (no office) and I can emphatically say that the hybrid team is one of the worst experiences in my career. Decisions were made in some other parts of the world, really really early morning calls and a general sense of frustration for all.

In a completely remote team, you are forced to optimize for coordination and communication. Obviously you suffer the downsides because there is no water cooler, no joint information dissemination sessions, no war room accountability though you can achieve some kind of co-creation using skype, join.me, git and trello. However you gain some big advantages in terms of finding the right resource at the best cost, undivided focus if remote team members are given work packages and ability to exploit the timezone difference for a 24hour work cycle. Not to mention the humongous personal flexibility which it affords at an individual level.

A point to note is that this remote vs. colo experience really can come down to the individual members and their personalities. There is no one size fits all.

TL;DR Go completely colo or completely remote, half-colo + half-remote = half-ass. Team personality is a very strong variable in this equation.


I don't agree. Programming remotely is obviously possible. If your day to day job is receiving programming tasks and hack them as quickly as possible, sure, remote is a perfect alternative.

However, in early stage startups, first employees usually have a much wider role. Like founders, they have a bigger say in where the company should move forward, priorize what should be built, hell, even clean the office and make coffee.

Also, never underestimate a good discussion over a coffee, beer or lunch to talk about problems. There's a reason why most of the best ideas are written on a napkin!

Lastly, I might add that when working on a very early stage startup, founders and employees build such a strong relationship and it's hard to achieve that level over remote working.

Again, I'm not saying it's impossible. For instance, founders who already know each others before starting the company may feel comfortable working hard remotely together. And I'm sure there are other cases when it totally makes sense.


I work 90% remotely. When I started this job, I came into the office everyday, a 40 minute commute. After about a month, my boss came up to me and said "Are you meeting someone here today? If not, what are you doing here?"

I actually like to go into the office from time to time, but there isn't any point when no one is there. I spend a lot of time at various clients' offices, and I notice a correlation: the more opposed to remote work a company is, the more meeting-driven it is. It is as if management feels like it needs to do something with all these bodies taking up space in the office. I see small to mid-size companies sucking up productivity with endless meetings.

That said, I think my company has lost a little bit of interactivity with the remote work force. I'm putting together a Google+ Hangout I call "Engineers' Office Hours". The idea is that if you aren't doing something billable, you hop in and offer help to someone stuck on a problem.


That must be an awesome boss!

On the Google Hangout thing, I sometimes find myself thinking(for the day I get a remote job again), why couldn't people be on a Hangout the whole day(In my case almost all of the dev team were full-remote)? When I did there was a techies chat always open on Skype and we used to chit-chat just like we would IRL, commenting on the Hacker-News-like-stuff, talk about semi-work-related stuff like the our most productive setup, crack jokes at each other and etc and there was definitely a "camaraderie vibe" even though we never met...

Now take a virtual environment like this, add more virtual face-to-face, Planetside 2 afterhours gaming sessions.. I don't see it lacking much, if anything, compared to a in-place tight-knit startup team


I agree entirely -- I've been telecommuting for ten years now, and this is easily the #1 reason the recruitment process fails with me (with small companies as well as large).


we love the fact that we can recruit folks from anywhere in the world and not disrupt their lives, since we are completely remote. it opens up a much wider talent pool and allows you to benefit from local economies as well, without actually being there.


Companies seem to forget (or not put much emphasis on) another aspect of having telecommuters: you don't get tunnel vision due to locality. I've worked for offices around the globe, and one thing that's always struck me about remote vs local is that remote can bring in a new way of thinking that you don't always get locally due to local cultural thought processes.


@BudVVeezer you mean, you are trying to get into a physical office and the recruiters won't consider your 10y of telecommuting as real experience ?


Nope, I mean recruiters contact me about positions but then find out that I cannot relocate and that ends the discussion because the company they are recruiting for disallows telecommuting for one reason or another.


I started to telecommute three days each week (office is ~ 2hrs from where I live) right after Thanksgiving in 2012 and am still adjusting to the lifestyle.

The biggest takeaway - so far - is that successful telecommuting is determined just as much by the given task as the person. I serve as a mixture of business analyst/developer/test coordinator/project lead/cat herder for my project team. Some tasks are easy to coordinate via e-mail/IM, screen sharing and conference calls (like scheduling, status updates, walkthroughs of protoypes). Being able to power through functional and technical specifications is a tremendous bonus of working from home. When it comes to gathering requirements, acquiring feedback and dealing with politics, however, it's really much better (for me) to be in the office.


I meet a lot of people that work in "tech" that describe their jobs similarly to the way you just did. Just as an aside, I think it's a disturbing trend. It's very easy to reach the point where you're being underpaid and stretched to your limits simultaneously.


I think a big part of this boils down to communication style, and how comfortable people are communicating via the written word.

I've worked places where remote working was discouraged, and the reason given was along the usual lines of "well, it just works better to have everyone in the same room". But these were also places where I noticed an aversion to and an avoidance of writing in general.


Totally agree. Where I work, the loudest person wins and gets promoted. It's hard to be loud in email, not to mention, talk over a quiet persons ideas.


I work in our office in Palo Alto and we have a small, 4 person office in Argentina. While I've worked with remote persons and teams in the past, a few changes to our office and their office has helped the working experience for both sides.

1) Both offices have a TV in the main office area with a web cam. We can see what they're up to, if someone is at their desk, etc. and they can do the same. This has been great for quick questions that are harder to explain over IRC and even for a simple waving good morning when I walk in.

2) We have a handful of "remote presence devices" in our office. This allows them or anyone else working remotely to attend meetings without having to ask someone to Skype in or conference call. Once again, it's the simple things like being able to wave or gesture to someone as they're rolling by. (Full disclosure, I work for a sister company of Suitable Technologies, who make the Beam).

3) Like others have mentioned, centralized, collaborative document control (Google Docs that are actually kept up and maintained), source control (GitHub with pull requests), and chat (IRC) help a lot.

4) A trip every 3 - 6 months from some of the Argentina team to the Palo Alto office. While technology has helped, there's still something to be said about being physically present.


Maybe the problem is that the VERY FIRST question you ask is, "Are you open to remote workers?"

I've always found that to be kind of a turn-off when I've interviewed people for software engineering positions. It's NOT that it's not an important question - it's that it shows a bit of social cluelessness. It's the same if the first question someone asks me is "How much vacation time do I get?" or "How much money do you pay?" Of course those questions should be discussed eventually! But I'd like to get to know the other person a little, first.

Ya, I know. It's a seller's market, you're busy, you don't want to waste your time with unproductive job possibilities, etc.

BUT EVEN IF non-telecommuting is a deal-breaker, maybe you should start off asking about the project, the company, the other people you'd be working with. If the work looks promising at first glance, start off by selling yourself first, rather than immediately focussing on the "OK, tell me what's in this for me, before I waste any more time on you and your company" side of things.

Simply as a matter of strategy, you might do better to postpone that question after a round or two. If they like you, then even if they don't have universal telecommuting, they may want you enough to be happy to have you as a telecommuter.


I have got chance to work both in 9-5 environment as well as working in isolation.

Working for home was my own choice so that I can give time to my infant kid which is most important for me. Working from home gave me relaxation. I could work on my chair or on my bed, nobody was going to ask me how I sit. Second most important thing which helped me a lot was to have a feeling of helplessness. When you work in an office, you often ask some of your peer to write a part of your code or look into it. When you work alone you have to do everything on your own, finding solution and implement it in your own code. In the era of Stackoverflow finding a solution of your problem is not difficult at all.

It's been a year I am working individually and I am enjoying it. Instead of wasting time in gossips about Boss or management, I prefer to play with my kid, his smile gives me enough oxygen to keep me motivated for rest of the day.


This is why most people don't get to work from home. Spending time with your kid and being constantly relaxed, working from bed, is counter to the serious business culture of most companies. Don't take this the wrong way, and it's not a dig, but from the way that you wrote that, it sounds like you only work a few hours a day casually.

I can see why Big Bank X would not allow their employees to do that.


On the other hand, hourly-paid remote workers can be a tremendous value, since their pay is limited to the time they actually work and they usually don't receive many benefits.


When we started LogNormal, my partner and I lived in the same geographic region. We both worked out of our own apartments, and met at Red Rock or a Thai/Vietnamese restaurant once a week or so. Then I moved to Cambridge, and we continued working remotely as if nothing had changed. We'd still meet up once a month to go over pen and paper stuff, but we still did all our work remotely from our own apartments.

In all, I think it worked out well. We build a useful product and pulled in several customers. Since we covered the East and West coasts of the US, we were closer (geographically as well as time-zone wise) to many of our customers than we would have been if we were both in the same office.

I don't think there was ever a time when we thought we'd be better off sitting in the same room.


I'm personally not a big fan of remote workers. Not because I don't think the tools are adequate or that I trust they are actually working. I think there's something special that can't be reproduced when a small team that's just starting out is physically together. I've been at a few startups and I can't count how many times a good idea or breakthrough came while we were out getting lunch, a beer or playing pool in the office. Sure, your remote workers are a phone call away, but it's just not the same as being able to turn to the guy next to you and start talking or white boarding. It's definitely possible to make remote teams work and the tools have come a long way. By there's something special about working together in person.


Is it really that difficult to type your question into skype or campfire group chat? We're all remote and we have daily 20 minute video conferences, and everyone is always logged into campfire. It's the most productive team I've ever worked with, and if someone isn't pulling their weight, you can tell from their git commits. Every argument I've heard against remote working boils down to that "something special" you mention, which is pretty darn vague. We have had a few new hires lose it and go AWOL, but those people wouldn't have been a good fit in a co-located team either.


It's not the day to day interactions. Hell, most of the companies I work with that aren't remote chat over IM and group chat while we sit next to each other. As I said, I don't think it's a breakdown of the tools. It's not that people aren't productive either. It's the "other" stuff that doesn't fit into those categories. There's no technology to replace sitting around with a group of guys having a beer. While its vague, it's just a different experience that Skype or group chat. It's a different setting and a different mindset. The things that are special are the things that don't fit into the normal daily workflow. For many companies remote teams might make sense and even strive, this is just my personal opinion of what I think is missing. So much of it depends on the company, the culture and the people.


Point taken; in fact we recently rented a couple of houses in Belize just so we could spend some time together. Funny thing is, I found the entire experience to be extremely draining and couldn't wait for everyone to leave. I had a really difficult time getting anything done in a house full of people, but I think it's just one of those things that varies between individuals. I think the great thing about the rise of distributed companies is they give an opportunity for introverts to come together and thrive in an environment that suits their working style, instead of trying to fit a square peg into a round hole, so to speak.


I currently work remotely, and I agree with you that there is something special about working physically together. There isn't a good remote substitute for standing in front of a white board with another coder. We tended to get excited when we thought of a cool new feature or solved a problem. I fed off of their excitement and they fed off mine.

More

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

Search: