3 ms·
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 d
by akeefer 16y ago
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 are legitimate reasons to co-locate a team.
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.
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.
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 only 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.
- andrewbadera 16y agoAs someone who does and has worked on enterprise-grade software, and someone who now helps client teams facilitate development, both in-person, remote on-shore, and remote off-shore, I can confidently state: it all comes down to communication, and a lack of communication not only dooms telecommuting, but it's a strong indicator of longer term failure in the parent company. If ideas, thoughts and facts cannot be clearly captured and/or communicated in a facile fashion, any complex project is risking higher failure rates. In-person buffering is a crutch at best.
- tswicegood 16y agoNot sure why this got down voted to negative points. This is a good point, but one I guess a lot of startups don't want to hear. :-/
- robobenjie 16y agoI'm really excited to have people in that first situation (the 10 people there and one person far away) try using our robot (anybots.com) That is exactly the problem we are trying to solve.
- gphil 16y ago"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." I totally agree with this. I work in this kind of environment, where I need to collaborate with about a half-dozen (non-software) engineers on the product design, and working with them when they are/I am offsite is much more difficult than when we are all in the office. I inevitably spend most of the day reading and writing e-mails and on conference calls when this is the case, and most of the day working on the product when it is not. Five minutes sitting around a whiteboard in person dissecting a problem can often replace an hour-long conference call or thousands of words of e-mail correspondence.