I don't think it's as simple as saying, essentially, "people who forbid telecommuting are idiots" or "there's no legitimate reason why telecommuting should be difficult." There <i>are</i> legitimate reasons to co-locate a team.<p>We allow working remotely one or two days a week, but our experiments with full telecommuting have not gone so well (though we'll probably keep trying). The level of success probably depends pretty heavily on the type of product you're trying to build and the resulting level of communication that's required. For enterprise software (or perhaps I should say "domain-specific apps" or something), you really need a customer proxy/subject matter expert on hand that you're talking to on a fairly constant basis, because the developers themselves aren't really experts in the domain; as a result, you want your development setup optimized for high-bandwidth communication. When 10 people are onsite but 1 team member is offsite, that communication just doesn't happen, and that 1 person ends up out of the loop and much less productive (at least that's what's happened with us). For other types of software, that's less of an issue.<p>I think it's also much less of an issue if the entire company telecommutes, or if at least a large percentage do: in that case, communication channels are optimized for that. If 5% of the staff telecommutes, the communication channels are optimized for face-to-face communication, and the people telecommuting are left out.<p>And on top of that, there are just different ways to go about developing: they're not necessarily better or worse, but they make different demands on physical presence. A lot of agile/XP practices work best when people are co-located in small cross-functional teams that are in constant dialog, pair-programming, etc. That doesn't mean it's the <i>only</i> way to develop, but it can be an effective way to develop (more so for certain domains than for others), and it doesn't mesh very well with full-time telecommuting. Other development strategies and methodologies make different trade-offs and will be more accommodating of telecommuting.
I've been bitten by the lack of progress measurement and having "agile" requirements before. In most cases my physical presence is a crutch for a bad process, it allows people to make ad hoc decisions because they can grab me and talk in the hall for 10 minutes.<p>If people being physically present is no longer a given then some level of structure has to be put around decision making and disseminating the results of that to the rest of the company. Too many times I've lost days of work because X was changed to Y and I wasn't at my desk when people were herded together to make that decision.<p>Having people geographically distributed forces you to deal with communication up front. People are trained to use mailing lists, IM, bug trackers, commit messages etc. properly rather than assuming that if someone wants to know wtf just happened they can shout at you across a room. You hit problems like Mike being the only keeper of process Z early rather than on day 1 of Mike's 2 week vacation to somewhere with no cell reception...
I once worked for a company that adamantly forbid telecommuting. Our city's transit system shut down due to a strike, in the middle of the cold and dark Canadian Winter. The snow and the flood of cars on the roads, ground the city to a halt.<p>My 1 hour daily commute took 3-4 hours total,... the entire team was tired and demoralized from sitting in traffic for so long.<p>Yet our CEO completely forbid telecommuting. He wanted to see asses in chairs, even if it meant wasting our energy in traffic. We were forced to work in the office, and everyone directed their grumpiness and anger to their job. It made the cultural environment toxic, and people left as soon as they could.<p>It demoralized me, and I had animosity towards the company. My performance suffered and I cared less about my work.<p>Eventually the CEO almost drove the company into the ground, until he quit before he could get sued for not completing his fiduciary duties.<p>He eventually fired me, and it was probably one of the best things to happen to my career.<p>TL;DR: anectdotally I can agree that companies that can't trust their employees to telecommute are toxic places to be avoided.
Ten years from now people who dismiss telecommuters are going to look like flat earthers. There are a range of forces which mean that telecommuting and telerobotic working will become more common, such as rising energy prices, environmental regulations and changes in demographics.
I agree with the author's point. An organization that dismisses telecommute as an option, is closing doors on a whole bunch of "10X" programmers. Which probably means that the current lot is not "10X".<p>I wouldn't want to work for a supervisor (and a team) that needs to "see" the team members everyday to make sure they are doing their job. The military Command and Control management style doesn't work on programmers.<p>One comment I do have is that author shold run spell check on the atricle and correct some of the grammer. But the point is well taken.
Supporting telecommuting workers from out of state can be a big financial hassle as it may be enough to establish nexus in the state, which will force your company to collect sales tax there.
I require all of my programmers to be on site, not because of any need to monitor what they're doing (Pivotal Tracker, source control, IM, and email take care of most of that for us, even while we're in the office) but to have the kind of conversations that can only happen when you have a bunch of engineers around a white board trying to solve a hard problem (no, IRC is not the same thing).<p>I still haven't come across a tool that allows telecommuters to replicate this process.
Requiring someone be in a certain place for a certain amount of time is pretty stupid, but it's worth pointing out that it's very difficult to point to successful startups where the founders were telecommuting in the early days.<p>I only care about output, but I think you get significantly more output in certain situations by being in the same room and informally bouncing ideas around or asking for help.
I think it depends on what level of position you're looking for. I wouldn't hire a rookie for a telecommute job. I want to be able to mentor that person in person.
How about that they are a government contractor and have to comply with federal regulations regarding work schedule? Uncle Sam wants to see asses in seats for at least 40 hours/week, according to some fixed schedule, which schedule must be approved by a certain government agency. If you are such a contractor, your options are to require that all employees be in the office between X o'clock and Y o'clock, or lose the contract.
It's not that companies regard it as a technical challenge, telecommuting is a communications challenge.<p>When people are in your office and they are part of your team, decisions get made much faster and everybody feels the energy.<p>We have done both, and our best productivity came from people being in our office.
The author isn't factoring in HOW the company writes software...it's not just about what language a company uses. That's a small piece of the puzzle.<p>What if the company uses an agile approach to development? Maybe they pair program. That would be a little tough for someone to participate in while telecommuting...sure, technically it can be accomplished but that's not really how pair programming is done.<p>But this broad brush used to paint companies that simply say they don't telecommute as "not getting it" is a little lame.