9 ms·

Telecommuting Culture - What it tells me about your company

74 points by tswicegood 16y ago

garyrichardson 16y ago
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.
- hga 16y ago
  I think he addressed that implicitly in his emphasis on hiring the best, e.g. "Hiring someone good is important, but hiring the best you can afford isn’t." When you hire a rookie, you're trying to create the best through mentoring, providing experience, etc. It's a great and very productive thing to do if you can afford it but it's not the sort of position he's talking about.
  - tswicegood 16y ago
    +1 I would add this caveat though. If I'm hiring a rookie and I wouldn't trust them to be able to get up to speed and be able to contribute without constant supervision, I would pass. Yes, when someone's just starting out that person-to-person interaction is great, but that can be accomplished with an open Skype/iChat video window and some desktop sharing. hga hit the nail on the head though - I'm not talking about every hire, I'm talking about bringing someone onto a team that can "hit the ground running" with a "large and evolved codebase" or any other of the number of things tech companies/recruiters talk about. I recently talked to one fairly established company out of Chicago who was looking for a new lead dev for a re-architect they were doing of their system because their in-house guy botched it. The second I said that moving wasn't high on my list of things to do they were gone. They wanted a "rock star", so long as they set the terms.
smitjel 16y ago
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. 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. But this broad brush used to paint companies that simply say they don't telecommute as "not getting it" is a little lame.
- tswicegood 16y ago
  I disagree here (obviously). Hiding behind agile (in any flavor) as a reason to not allow telecommuting is just that, hiding. I've known plenty of teams who have successfully pair programmed trans-continent. It can be done. Maybe it is more challenging, but I don't think "agile" automatically rules it out.
  - technomancy 16y ago
    > It can be done. Maybe it is more challenging [...] The only thing that's challenging about it is that you have to take some time to meet in person so people get a feeling for each others sense of humor, etc. We do this 3-4 times a year--rent a vacation home for a week and work in person for a while just to gel the team. Once you have a team that knows each other it works great.
    - tswicegood 16y ago
      Completely agree. A lot of MBA types (sorry for the overly broad generalization here) seem to have gotten the idea that every day should be a team building exercise and you can obviously only do those on site where you can take foam bats to each other and have the best ideas rise to the top. Seriously though, that's what a lot of these arguments sound like to me.
- brown9-2 16y ago
  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. Did we read different articles? Because I didn't see any arguments based on what language a company uses having anything to do with the ability to telecommute.
  - tswicegood 16y ago
    I made an aside to Django vs Drupal and a few people have seized on it. My bad, I took a cheap shot that detracted from the overall point. :-/
wyclif 16y ago
Posts that are written this poorly do not inspire confidence in the author's conclusions.
- tswicegood 16y ago
  Patches welcome: http://github.com/tswicegood/travisswicegood.com/ http://github.com/tswicegood/travisswicegood.com/
  - mahmud 16y ago
    It's your responsibility to argue your position rationally and eloquently. Your opinions are not a public good that others aught to participate in perfecting.
    - larsberg 16y ago
      s/aught/ought :-)
    - Calamitous 16y ago
      Irony alert: you probably meant "ought"
    - etherael 16y ago
      I agree with the first sentence entirely. The second sentence is not so hot, disabusing people of their misconceptions and reinforcing their logical positions is absolutely something that should be considered a public good. This is the root of the sunlight is the best disinfectant argument; that no matter how offensive or absurd the position presented, at least it has the opportunity to be subject to peer review.
duke_sam 16y ago
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. 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. 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...
sinamdar 16y ago
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". 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. 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.
- rada 16y ago
  One comment I do have is that author shold run spell check on the atricle and correct some of the grammer "grammer" -> "grammar" "everyday" -> "every day" ". Which" -> ", which" (just to name a few)
  - rimantas 16y ago
    Yes also "shold" and "atricle". I am the only one thinking that sentence was written with errors intentionally? No other has that amount of errors.
motters 16y ago
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.
- mkramlich 16y ago
  Agreed. The demand for gasoline and oil and cars themselves should go way down if there's a massive drop in the automobile commuting demographic. And air pollution drops. Wear and tear on roads drops, so less money spent on maintaining that, so less pressure on local government budgets. Less road accidents, so less costs spent on police and ambulance related to that, plus less health care costs and car damage and loss of life. Less traffic/gridlock during the rush hour periods of the day. Many benefits from an increase in telecommuting.
  - motters 16y ago
    With the aging workforce in Japan, Europe and North America telecommuting and telerobotics will mean that people who have physical mobility impairments will still be able to continue in active employment for longer than would previously have been the case.
lee 16y ago
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. My 1 hour daily commute took 3-4 hours total,... the entire team was tired and demoralized from sitting in traffic for so long. 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. It demoralized me, and I had animosity towards the company. My performance suffered and I cared less about my work. Eventually the CEO almost drove the company into the ground, until he quit before he could get sued for not completing his fiduciary duties. He eventually fired me, and it was probably one of the best things to happen to my career. TL;DR: anectdotally I can agree that companies that can't trust their employees to telecommute are toxic places to be avoided.
- strlen 16y ago
  Sorry if this sounds blunt, but a) Why did you join in the first place? b) Why didn't you find another job before getting fired?
  - lee 16y ago
    a) When I joined it seemed like a genuinely interesting and good place to work. I joined leaving somewhere worse; and at first it was a great place to work. I did not even think of asking "does this job offer telecommuting?", as I never telecommuted in the past. I had only been out of school for a year, and the company had a lot of cool things going for it, like beer Friday meetings and an office in the "hip" part of town. b) I was trying to find another job. It just happened that I got fired before I could find one, this was also happening at the height of the recession and in my neck of the woods the opportunities were slim. It worked out really well in the end. We had our first child that year, and I got to spend 3 months with my family before finding a much better paying job that had a healthier environment. Sometimes leaving one job is the only way to get a raise.
kschrader 16y ago
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). I still haven't come across a tool that allows telecommuters to replicate this process.
- tswicegood 16y ago
  Couple of questions for you then: * Do you do this every day? * If so, do you get anything done? I only being slightly facetious. I agree that there's a lot to be said for brainstorming in person. I'd also argue that there's a lot to be said for brainstorming out of your normal environment (i.e., office). But you don't do this every day. You code every day. Why not rent out some office/conference space for an afternoon every few weeks as you ramp up on your next iteration and save the money on the office space all the while allowing your programmers to be more productive?
  - kschrader 16y ago
    Yes, discussions between programmers about how to best implement things happen every day. We work in an open work space, and I can't even count the number of times that someone has jumped into a discussion with a better idea of how to implement something. If that saves the original people a couple of hours (or days, etc) then we've immediately increased productivity. I don't buy into the idea that being "more productive" means sitting by yourself in your home office cranking out code.
    - mattm 16y ago
      It takes at least 15 minutes for people to get back into a productive working state after being interrupted. If you interrupt an office of 8 and one person has an idea that saves 2 hours, you are only breaking even. I worked in an open space before and it drove me nuts until I finally left. It was fine when there was just a few of us but as they started adding more people, the number of interruptions started to go up exponentially until some days it seemed like I was being interrupted all the time.
amanfredi 16y ago
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.
- tswicegood 16y ago
  Might be a cultural thing, but I've worked for multiple companies out of California that did not set up in other states. I know because I had to pay nearly 90% of the normal California income tax, and the income tax of the state I was living in. Agreed it can be an issue, but one that a lot of Valley companies seem to be ignoring.
bitwize 16y ago
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.
- neutronicus 16y ago
  Or said government contractor could be forbidden from using any kind of telecommuting technology because employees are not allowed to remove sensitive data from the premises.
  - rdl 16y ago
    Yes, the author of this post clearly has no idea about enterprise/government security policies -- they exist for security and for contractual compliance. He used the example of Manning in Iraq (who was allegedly inside a SCIF, but consciously violated security policy, whether or not you think what he did was right) -- the purpose of all of that is to make sure your honest and trustworthy employees aren't accidentally compromising sensitive information, and to protect from outsiders. You don't body cavity search your own cleared engineers because that is not generally the threat, and it's highly invasive. There is information protected against willful disclosure by trusted individuals, and that information is kept inside a hardware security module and/or is never accessible to individuals. e.g. nuclear weapons have a "no lone zone" around them, such that if any person (even the commander of the base) is in that space alone, he is presumed to be doing something evil, and is supposed to be stopped (using lethal force if necessary) on sight. That level of security just isn't warranted for most things, but "work on material in a secure room, and the information doesn't leave the room except by defined channels" is a pretty good level of security. DoD has a lot of security vulnerabilities, but security would not be improved by allowing telecommuting!
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 ago
  As 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.
danielrhodes 16y ago
It's not that companies regard it as a technical challenge, telecommuting is a communications challenge. When people are in your office and they are part of your team, decisions get made much faster and everybody feels the energy. We have done both, and our best productivity came from people being in our office.
sama 16y ago
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. 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.

74 points by tswicegood 16y ago

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.

hga 16y ago
I think he addressed that implicitly in his emphasis on hiring the best, e.g. "Hiring someone good is important, but hiring the best you can afford isn’t." When you hire a rookie, you're trying to create the best through mentoring, providing experience, etc. It's a great and very productive thing to do if you can afford it but it's not the sort of position he's talking about.
- tswicegood 16y ago
  +1 I would add this caveat though. If I'm hiring a rookie and I wouldn't trust them to be able to get up to speed and be able to contribute without constant supervision, I would pass. Yes, when someone's just starting out that person-to-person interaction is great, but that can be accomplished with an open Skype/iChat video window and some desktop sharing. hga hit the nail on the head though - I'm not talking about every hire, I'm talking about bringing someone onto a team that can "hit the ground running" with a "large and evolved codebase" or any other of the number of things tech companies/recruiters talk about. I recently talked to one fairly established company out of Chicago who was looking for a new lead dev for a re-architect they were doing of their system because their in-house guy botched it. The second I said that moving wasn't high on my list of things to do they were gone. They wanted a "rock star", so long as they set the terms.

smitjel 16y ago

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. 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. But this broad brush used to paint companies that simply say they don't telecommute as "not getting it" is a little lame.

tswicegood 16y ago
I disagree here (obviously). Hiding behind agile (in any flavor) as a reason to not allow telecommuting is just that, hiding. I've known plenty of teams who have successfully pair programmed trans-continent. It can be done. Maybe it is more challenging, but I don't think "agile" automatically rules it out.
- technomancy 16y ago
  > It can be done. Maybe it is more challenging [...] The only thing that's challenging about it is that you have to take some time to meet in person so people get a feeling for each others sense of humor, etc. We do this 3-4 times a year--rent a vacation home for a week and work in person for a while just to gel the team. Once you have a team that knows each other it works great.
  - tswicegood 16y ago
    Completely agree. A lot of MBA types (sorry for the overly broad generalization here) seem to have gotten the idea that every day should be a team building exercise and you can obviously only do those on site where you can take foam bats to each other and have the best ideas rise to the top. Seriously though, that's what a lot of these arguments sound like to me.
brown9-2 16y ago
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. Did we read different articles? Because I didn't see any arguments based on what language a company uses having anything to do with the ability to telecommute.
- tswicegood 16y ago
  I made an aside to Django vs Drupal and a few people have seized on it. My bad, I took a cheap shot that detracted from the overall point. :-/

wyclif 16y ago

Posts that are written this poorly do not inspire confidence in the author's conclusions.

tswicegood 16y ago
Patches welcome: http://github.com/tswicegood/travisswicegood.com/ http://github.com/tswicegood/travisswicegood.com/
- mahmud 16y ago
  It's your responsibility to argue your position rationally and eloquently. Your opinions are not a public good that others aught to participate in perfecting.
  - larsberg 16y ago
    s/aught/ought :-)
  - Calamitous 16y ago
    Irony alert: you probably meant "ought"
  - etherael 16y ago
    I agree with the first sentence entirely. The second sentence is not so hot, disabusing people of their misconceptions and reinforcing their logical positions is absolutely something that should be considered a public good. This is the root of the sunlight is the best disinfectant argument; that no matter how offensive or absurd the position presented, at least it has the opportunity to be subject to peer review.

duke_sam 16y ago

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

sinamdar 16y ago

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

rada 16y ago
One comment I do have is that author shold run spell check on the atricle and correct some of the grammer "grammer" -> "grammar" "everyday" -> "every day" ". Which" -> ", which" (just to name a few)
- rimantas 16y ago
  Yes also "shold" and "atricle". I am the only one thinking that sentence was written with errors intentionally? No other has that amount of errors.

motters 16y ago

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.

mkramlich 16y ago
Agreed. The demand for gasoline and oil and cars themselves should go way down if there's a massive drop in the automobile commuting demographic. And air pollution drops. Wear and tear on roads drops, so less money spent on maintaining that, so less pressure on local government budgets. Less road accidents, so less costs spent on police and ambulance related to that, plus less health care costs and car damage and loss of life. Less traffic/gridlock during the rush hour periods of the day. Many benefits from an increase in telecommuting.
- motters 16y ago
  With the aging workforce in Japan, Europe and North America telecommuting and telerobotics will mean that people who have physical mobility impairments will still be able to continue in active employment for longer than would previously have been the case.

lee 16y ago

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. My 1 hour daily commute took 3-4 hours total,... the entire team was tired and demoralized from sitting in traffic for so long. 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. It demoralized me, and I had animosity towards the company. My performance suffered and I cared less about my work. Eventually the CEO almost drove the company into the ground, until he quit before he could get sued for not completing his fiduciary duties. He eventually fired me, and it was probably one of the best things to happen to my career. TL;DR: anectdotally I can agree that companies that can't trust their employees to telecommute are toxic places to be avoided.

strlen 16y ago
Sorry if this sounds blunt, but a) Why did you join in the first place? b) Why didn't you find another job before getting fired?
- lee 16y ago
  a) When I joined it seemed like a genuinely interesting and good place to work. I joined leaving somewhere worse; and at first it was a great place to work. I did not even think of asking "does this job offer telecommuting?", as I never telecommuted in the past. I had only been out of school for a year, and the company had a lot of cool things going for it, like beer Friday meetings and an office in the "hip" part of town. b) I was trying to find another job. It just happened that I got fired before I could find one, this was also happening at the height of the recession and in my neck of the woods the opportunities were slim. It worked out really well in the end. We had our first child that year, and I got to spend 3 months with my family before finding a much better paying job that had a healthier environment. Sometimes leaving one job is the only way to get a raise.

kschrader 16y ago

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). I still haven't come across a tool that allows telecommuters to replicate this process.

tswicegood 16y ago
Couple of questions for you then: * Do you do this every day? * If so, do you get anything done? I only being slightly facetious. I agree that there's a lot to be said for brainstorming in person. I'd also argue that there's a lot to be said for brainstorming out of your normal environment (i.e., office). But you don't do this every day. You code every day. Why not rent out some office/conference space for an afternoon every few weeks as you ramp up on your next iteration and save the money on the office space all the while allowing your programmers to be more productive?
- kschrader 16y ago
  Yes, discussions between programmers about how to best implement things happen every day. We work in an open work space, and I can't even count the number of times that someone has jumped into a discussion with a better idea of how to implement something. If that saves the original people a couple of hours (or days, etc) then we've immediately increased productivity. I don't buy into the idea that being "more productive" means sitting by yourself in your home office cranking out code.
  - mattm 16y ago
    It takes at least 15 minutes for people to get back into a productive working state after being interrupted. If you interrupt an office of 8 and one person has an idea that saves 2 hours, you are only breaking even. I worked in an open space before and it drove me nuts until I finally left. It was fine when there was just a few of us but as they started adding more people, the number of interruptions started to go up exponentially until some days it seemed like I was being interrupted all the time.

amanfredi 16y ago

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.

tswicegood 16y ago
Might be a cultural thing, but I've worked for multiple companies out of California that did not set up in other states. I know because I had to pay nearly 90% of the normal California income tax, and the income tax of the state I was living in. Agreed it can be an issue, but one that a lot of Valley companies seem to be ignoring.

bitwize 16y ago

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.

neutronicus 16y ago
Or said government contractor could be forbidden from using any kind of telecommuting technology because employees are not allowed to remove sensitive data from the premises.
- rdl 16y ago
  Yes, the author of this post clearly has no idea about enterprise/government security policies -- they exist for security and for contractual compliance. He used the example of Manning in Iraq (who was allegedly inside a SCIF, but consciously violated security policy, whether or not you think what he did was right) -- the purpose of all of that is to make sure your honest and trustworthy employees aren't accidentally compromising sensitive information, and to protect from outsiders. You don't body cavity search your own cleared engineers because that is not generally the threat, and it's highly invasive. There is information protected against willful disclosure by trusted individuals, and that information is kept inside a hardware security module and/or is never accessible to individuals. e.g. nuclear weapons have a "no lone zone" around them, such that if any person (even the commander of the base) is in that space alone, he is presumed to be doing something evil, and is supposed to be stopped (using lethal force if necessary) on sight. That level of security just isn't warranted for most things, but "work on material in a secure room, and the information doesn't leave the room except by defined channels" is a pretty good level of security. DoD has a lot of security vulnerabilities, but security would not be improved by allowing telecommuting!

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

danielrhodes 16y ago

It's not that companies regard it as a technical challenge, telecommuting is a communications challenge. When people are in your office and they are part of your team, decisions get made much faster and everybody feels the energy. We have done both, and our best productivity came from people being in our office.

sama 16y ago

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