
Telecommuting Culture - What it tells me about your company - tswicegood
http://www.travisswicegood.com/2010/08/09/telecommuting-culture/
======
akeefer
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
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.

~~~
tswicegood
Not 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. :-/

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

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

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

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

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

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

~~~
mattm
I solve hard problems better when I have quiet time where I can think through
the problem. Some people do think by talking but I imagine most engineers do
not fall into this category.

~~~
kschrader
Many companies, software (Facebook) and otherwise (Toyota) have open layouts
to encourage problem solving in groups.

Most of the good engineers I know are just as adept at hashing out a solution
on a whiteboard as they are doing it quietly by themselves, and, given the
sample set that I've seen over the years, I've found that the collaborative
solutions tends to be better.

~~~
andrewbadera
Effectiveness of group brainstorming was disproven years ago.

~~~
lonestar
Do you have a reference for this? I'd be interested in reading it.

~~~
regularfry
If you can find a copy of 59 Seconds, by Richard Wiseman, it's mentioned in
there (with references, if I remember correctly). I don't have my copy handy.

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

~~~
tswicegood
Patches welcome: <http://github.com/tswicegood/travisswicegood.com/>

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

~~~
Calamitous
Irony alert: you probably meant "ought"

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

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

------
bitwize
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
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
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!

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

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

~~~
jtheory
Pair programming is worth discussing.

I've tried pair programming in person, and it's almost impossible for me. I
have vision problems, and I just really need my own monitor, configured how I
want it, with me sitting squarely in front of it. But even beyond that issue,
I'm enough of an introvert that I have a whole set up thoughts running through
my head when I'm in a social situation, monitoring myself for the image I'm
presenting, and the other person for how they're reacting. I can still work,
but it definitely takes up some bandwidth, kind of like if I'm working while
speaking a foreign language.

But the experience of remote paired work has been surprisingly good, for more
than just the vision reason. I'm started recently on a completely-remote
development job, with the team spread across multiple continents. No pair
programming yet, but I just got off a call a few hours ago where I worked with
another developer for more than an hour, troubleshooting build issues.

\- Whoever is driving shares their screen, but we both still have access to
our own computers, so there's no "hang on, lemme run back to my PC to double-
check my notes there...".

\- You're never forced to code with someone else's
computer/keyboard/monitor/mouse/system setup/chair/etc.

\- No awkwardly bumping knees or elbows, no worries about the other programmer
having overpowering coffee breath or odd physical tics, being distractingly
unattractive or attractive, etc..

So YMMV, but personally I'd rather do pair programming this way even if I was
_at_ the office.

Side note: I am simply unavailable for jobs that don't allow telecommuting;
that's been the case for years now.

~~~
technomancy
> So YMMV, but personally I'd rather do pair programming this way even if I
> was at the office.

After a year or so of remote pairing I strongly agree. Among other things, no
more dvorak/qwerty conflict is great.

