
Ask HN: If you don't permit telecommuting, why? - ohjeez
I&#x27;m writing a feature story tentatively titled, &quot;Why the Company You Want to Work For Won’t Hire Telecommuters.&quot; I&#x27;d like your input.<p>Plenty of businesses are interested in hiring only onsite staff. I want to explain the viewpoints behind such policies – and then, ideally, address what it would take for those organizations to hire telecommuters or remote workers.<p>So I’d like to hear from two types of respondents:<p>* Someone who has been in a hiring role at an organization where the job requisitions typically say, “Local candidates only, please.” (Whether or not you’re in agreement with the policy.)<p>* Someone who’s applied to a job that says, “on site only” and gotten a remote job despite that requirement.<p>If you applied to an “on-site only” job ad and got the gig anyway, there’s just one question: How’d you make that happen?<p>My questions are primarily for the people on the hiring side:<p>* Why does the person who does this job need to be on-site?
Please be specific. Give me examples of things that can only be done if she were in the office.<p>* Have you been in a position where you personally would be okay with an employee being a telecommuter, but a decision-maker deemed otherwise? How did you handle it?<p>* How has the policy affected your company’s ability to attract candidates?<p>* Have you hired someone for an in-the-office job, and later given permission for the individual to work from home? What happened to make the change okay?<p>* What would it take for the company to change the no-telecommuters policy, even if only for one specific position?
For example, “If a rock star in my field applied for the job, we’d do anything to get him to say Yes – including letting him work remotely.” But there can be many other answers, and I’d very much like to hear yours.
======
stevecalifornia
I am a remote worker and if I ever ran a company I wouldn't allow
telecommuting. Here is why:

When I was at the office for a decade, 90% of the insight and productivity
came from informal conversations in the hallway, lunches and things I
overheard in passing. As a remote worker, nearly all communication is very
deliberate so I am not exposed to those ad-hoc conversations. Everything is
very deliberate: I receive an email, a text or a meeting. The net result is my
personal career becomes very confined and stunted... I become that guy who
does that one thing rather than a team-member who has an awareness of
everything and the ability to jump in as needed.

Being remote also limits my upward mobility. Most of my promotions and moves
were because I would walk back from a meeting with an executive and talk about
what was discussed and express interest in taking ownership. These walk-and-
talks are the only availability in an execs schedule. I tried to get time with
an exec remotely and it was a full two months before I could get any time--
and since it was scheduled it wasn't ad-hoc and overly formal ("What would you
like to discuss?").

So, in my judgement, remote workers are fine for very defined single tasks.
For dynamic workers that move about the company and immerse themselves in lots
of projects and want upward mobility, I can't recommend it.

I feel like my experience of being in office and remote at the same company
gives me some unique perspective versus the people who join a company remotely
and never fully appreciate what they are missing.

~~~
r2dnb
>When I was at the office for a decade, 90% of the insight and productivity
came from informal conversations in the hallway, lunches and things I
overheard in passing

The issue is not remote working, the very thing you wrote is the issue.

Virtually every time, remote working doesn't create new issues but reveals and
- embarassingly - exposes existing ones.

You can no longer take a chance by letting things such as hallway affairs
become a norm and an invisible force. You need to plan everything(and know
what to plan), track everything relevant (and know what's relevant), be in
control of the conditions for career and team progression (and therefore know
precisely what these conditions are), you need to know your stuff. You can no
longer just wait for magic to happen, put people in rooms and cross your
fingers. Or send them to restaurant and expect team communication to have
improved to the benefit of your KPIs.

The truth is 60-80% of today's companies are terribly run. Management of these
companies is playing games without realizing it.

Remote working simply requires real management for it. Real managers quickly
love it as remote working basically is : output-as-a-service : no noise, just
efficiency and result. But the manager more tham ever needs to know what he is
doing, because remote working accelerate the consequences of managerial
weaknesses. What would have tanked a company in 5 years can tank it in 5
weeks.

But the positive is that once a remote setup has been successfully
established, there is an organization insanely streamlined, efficient and
competitive.

~~~
ohjeez
Okay: So how would you advise someone to create that "real management for it"?
Any references or suggestions you would recommend a well-meaning manager to
gain the wisdom and skills necessary? (Because I also will be writing,
separately, about how to do remote work well, and this is exactly the kind of
info I want to impart.)

~~~
DanielBMarkham
I've both hired and advised people hiring.

This is beginning to look like the blind men and the elephant.

The inside joke on remote/distributed work is "You know, if we just had 1)
better managers, 2) better specs, 3) better tools"

We have been trying all of this for 30 years or so. At some point a reasonable
person would look around and see that most all startups are colocated,
physically in the same room having to deal with each other all day long.

There are plenty of theories as to why this is true. Another observation:
people not in the office do best at rote work: fix the bugs, align the images
on the website, and so on.

If your job could be done by robots -- if it required minimal interaction over
electronic tools to get specs and deliver on them in an over-the-wall manner
-- it will be done by robots. Creating technology is about _people_ , not
technology. You sitting in a room and getting into flow-state and cranking out
code is nowhere near as important as you interacting minute-by-minute with
messy humans and trying to determine the nature of the problem you're solving.

Best-case scenario: you work on a tightly-knit team for a few weeks/months on
a fixed-length job. Everybody gets into sync on the customer, specs,
terminology, and solution. The customer's problem is not changing that much.
You deliver some stuff as a team that people like. At that point, and not
before, who cares where people are? Just get the work done.

You can scale that out to working in BigCorp on a fixed domain, but only so
much. And the scary thing is that there are no alarms that go off if you're
doing it wrong.

It's not impossible, or bad. But it works under very limited conditions.
Understanding that is critical. I know there are a ton of folks who want to
work remotely. I am one of them. But wanting something and looking
realistically at what works or not are two different things.

~~~
eeZah7Ux
> You sitting in a room and getting into flow-state and cranking out code is
> nowhere near as important as you interacting minute-by-minute with messy
> humans and trying to determine the nature of the problem you're solving.

Are you implying that "interacting minute-by-minute with messy humans"
requires physical presence?

~~~
dragonwriter
It doesn't require it, but in my experience is vastly more effective;
teleconferencing (even with all the wiz-bang tech aids available) is vastly
lower bandwidth and reduced options for interaction, and a lot more
opportunity for distraction/interruption, either physically at any of the
involved locations or because of tech failures.

------
Throwawayabc123
Throwaway account.

In order to stay price competitive in our industry, we need to use a mix of
junior, intermediate, and senior talent.

We have never found a junior or newly-intermediate candidate successfully work
remote. Part of the point in having senior people is for them to be available
to guide the less learned staff, so it makes no sense for them to all be
remote too.

To be fair, for the right senior staffer, we would be willing to consider 100%
remote. For the right intermediate staffer, we would be similarly be willing
to consider a split onsite and telecommute arrangement, or other flexible
scheduling options.

~~~
aggieben
Have you considered letting your senior people, whom you apparently trust to
be remote, mentor your juniors _remotely_?

~~~
snuxoll
This is what we do, we have 3 senior developers, 2 intermediate level
developers and 3 juniors on our team. Even before we hired the juniors we
_ALWAYS_ had GoToMeeting up and conversed throughout the day and worked
together on projects, it's more imperative with the Jr's so we'll usually pair
someone up 1:1 with them on a separate call to mentor them on a project. We
haven't felt a need for a physical office except as an occasional meeting
space (which is why we are working on getting one built-out in the city where
the majority of our remote team lives).

~~~
mountaineer22
So you do remote pair programming?

I have found this to be quite productive.

Real-time communication with voice, but also the visually shared WIP.

Is this your experience?

~~~
snuxoll
Yes, everyone on our team has a GoToMeeting license, throughout the day most
of our team is pair programming using the screen sharing functionality or
talking with our users about issues or doing UAT before deploying a new build.

Personally I'm not a fan of pair programming, I don't like shoulder surfing,
but it's an invaluable tool for mentoring the juniors so I still participate
when I'm not working on one of my more niche responsibilities I don't share
with the rest of the team as much (DevOps, Salesforce developer, DB developer,
business analyst, etc.)

------
brobinson
How many decision makers are willing to admit that they are subconsciously
using "chair time" as a measure of productivity?

~~~
jdc0589
hilariously, some companies with remote workers have "activity monitors"
installed that tell coworkers you aren't doing anything if your mouse/keyboard
goes inactive for a few minutes.

~~~
dudul
Is that for real?

~~~
ohjeez
It was, at least.

About 15 years ago I got a demo at a Gartner conference from a company doing
just that. The vendor's primary goal, they said, was to measure where the
developer was spending his time (coding vs debugger vs editor... I think it
was a Visual Studio add-in?). But they admitted employers could use it to
track what the developer was/wasn't doing.

...and that was before Facebook.

~~~
dudul
I see. But it was not necessarily just to target remote people. My wife had to
use a time tracker like that a while ago, supposedly for the same reason:
understand where people spend their time.

~~~
ohjeez
This is a tangent... but I haven't run across such tools recently. I wonder
whether they weren't good at what they purported to do, or whether companies
quit paying such careful attention to where workers spent their time.

------
kemiller2002
I will make the opposite statement about telecommuting. I have a rule that my
team must telecommute. Everyone on the team with few exceptions must
telecommute at least one day a week. Here's why. We have the technology for
people to be remote. We've had it for years. I used to do it at larger
companies, and honestly it was a pain at times. This is exactly why I make
people do it. I don't want to lose people or lose out on ones that would be
great, because we don't know how to handle remote employees. I have remote
workers now that are vital to the team, and we all need to know the pain
points they suffer, so we can fix it. It didn't occur to me we had issues
until he brought it up in a weekly meeting to me that he felt left out on side
conversations. Now we all do it, so we all experience the problems and we can
figure out how to fix it. Really this is our approach to everything. Anything
we have issues with we practice until we get it right and anytime we see room
for improvement we make it.

------
RestlessMind
Reasons against remote working: 1\. Timezone issues - this is, imo, the
biggest one. Especially after working with people in China, India, Europe or
even eastern USA (with me in SF bay area). People all over the world _usually_
start working around 9-10, and stop working around 6-7. Meetings, code/design
discussions are very difficult on those schedules, especially when you want a
decision on smaller issues where a quick back n forth would settle the matter
in 30 min if everyone was in the same room. And there are plenty of such
issues, where unavailability of your coworkers seriously affects the
productivity.

2\. Rapport / Camaraderie: Knowing someone in-person, having
lunch/dinner/coffee with them, having watercooler talks about casual stuff etc
builds a rapport, which helps build closer work relationships. I don't think
people in remote locations are any different than my colleagues here, but the
rapport is simply not there if I am going to meet them on video conf or IM
only a few times a week.

3\. Impromptu discussions: These are triggered by spontaneous ideas, and ideas
do not come according to a fixed schedule of meetings. By not having remote
workers in these discussions, both sides lose (by not having more brains, as
well as by missing out).

~~~
doozy
1\. is absolutely true. Real time communication has been crucial to my success
as a remote developer. I'm in South America so it's easy for me to work at the
same time as coworkers in the US. I worked for a some time for a British
company and after a while I just decided to wake up 4 hours earlier so I could
communicate with my coworkers.

2\. and 3. shows your organization has communication problems. One of my
favorite ways to combat that is to do some pair programming. You'll get to
know people quite rapidly if you are talking to one each other 8 hours a day.

~~~
ChemicalWarfare
#1 would be true if everyone HAD to be in the same timezone. Some companies
specifically look for remote employees in different timezones to cover
customer communication/support etc. So that's pretty company-specific.

------
reikonomusha
At a few companies I've worked at, remote wasn't viable due to hardware
development. It was difficult and expensive to replicate test setups for
remote employees when unit costs for some of these devices range from 10 to
100k USD (e.g., VNAs).

~~~
turnip1979
VNA=Vector Network Analyzer?

~~~
aylons
Given the price range, yes. Even though USD 10K sounds a bit too low for a
VNA, even a simple one.

------
dijit
I'm definitely not the person you're targetting, but I was interested in
remote working for a long time- when I asked why I couldn't I was given a few
reasons:

1) Spontaneous meetings become impossible, scribbling something on a
whiteboard becomes much more difficult, the barrier to communication is too
high.

2) We've had bad experiences with people who work in other studios/HQ. They
tend to shirk responsibility, and it's very frustrating to get them to
actually acknowledge your issue as high priority. Managers assume this would
carry into remote work if it were offered.

3) We work in R&D, all internet access is monitored/blocked and we use
internal systems for communications only, so while we can VPN in sometimes
it's discouraged because I have liberties at home that I don't have in my
offices internal network.

They do their best to make a good office environment, but it's still open plan
(much to my dismay, I can't ever focus in that environment for some reason)
but try to strongly discourage remote working.

~~~
SNvD7vEJ
I agree that 1) is a problem, although technical solutions are possible I find
them awkward.

I think 2) has to do with people not feeling they are part of the team.

Our solution to 3) is a separate work machine (laptop) set up so that you can
not access the internet in any other way than through the VPN to the office.
So, to work remotly you need to bring your work computer with you. You can not
connect using your private computer.

------
aurelianito
It is quite weird that we have all these up-votes (including my own) but no
answers.

I think that the real answer might be something quite embarrassing, and
politically incorrect.

~~~
aylons
I'm more prone to believe the answer is dull and not well-defined, on the
likes of:

\- We really don't know how to deal with the differences, and it is scary to
try;

\- There are some company process that we are afraid of changing to
accommodate telecommuting;

\- The risks and costs outweigh the benefits, or the benefits are fuzzy while
the risks and costs are clear;

\- etc

~~~
aurelianito
Those are the excuses. I think the actual reasons are much more sad, visceral
and disgusting.

------
_ix
I admit that I'm not a great manager and more of a technician. I just happen
to have the authority to make hiring and firing decisions for my tiny
engineering team.

I prefer on-site employees to remote for two reasons:

1 - I find that on-site employees are a bit easier to manage. The bar to
communication is lower when they're so accessible. Also, I'm working with
legacy hardware and software, and there is so much to understand in order to
get started on many projects, and it can be a lot easier to sit side saddle
with a junior engineer to help them through the first steps.

2 - I don't have a lot of great confidence in my hiring practices and the
owners of the company are a little more conservative. As such, I make the
safer choice to hire candidates willing to work on-site instead -- I can see
when they come in, I can task and re-task on a whim, and I have a much better
sense of when they begin down rabbit holes.

~~~
bps4484
[note: I work at a company that allows telecommuting and I currently manage 5
engineers in two different locations]

I wanted to expound on "The bar to communication is lower when they're so
accessible."

I think a lot of communication involves understanding the culture (and by this
I mean 'the way someone views the world' and not a more the mainstream sort of
'they are asian' type of definition) of a person. The speed at which you are
able to understand a person's culture (what technologies they like and don't
like and why, what they're previous jobs were like, what type of family did
they grow up in, what jokes do they like, etc, etc, etc) increases drastically
when they are working on site, and it's usually small bits of downtime (lunch,
coffee break, shooting the shit late night) when you learn a lot of this
stuff. Not having this understanding comes with a communication cost, and it's
not just for the managers, it's also for the engineers they work with (and it
goes both ways, the telecommuter is going to have a tougher time understanding
the culture of their coworkers/manger).

Which isn't to say this why my company doesn't allow telecommuting (on the
contrary, we do), but I think this nuance is hard to put a tangible dollar
amount on but is very real. Additionally this does happen eventually with
remotes (I have two great ones that I really think I understand) and there are
things you can do to facilitate it, but it is harder.

------
BadassFractal
Are there any success stories of early stage high growth startups that were
started by a remote team? At least in the startup world, most people are
concerned that you will miss that zeal and watercooler chat magic that is
critical to early stage companies. I don't think anybody cares too much about
your 1000th engineer being remote, the organizational DNA has already been set
a long time ago.

~~~
throwaway1112
As someone who is remote about 90%, I contend the watercooler chat magic is
overrated and a waste of time. I was previously in office full time. I was one
of the first tech hires. I am mostly a programmer, with a good deal of
overlapping ops and analysis thrown in. I'm part of a very small engineering
staff (under 10) in an overall small company (under 30 people). My work output
in our open office drops to around 10% of the output when I work from my
house. This is code, documentation, and meetings attended. People spend more
time at the office because they are constantly interrupted (both by off-topic
conversations as well as for work-related things) and need to stay late (past
40 hours) to finish their tasks. From informal notes, conversations that occur
via Skype or In Person are poorly documented and tend to be rehashed more
often than written communications via Github or Slack. IMO, if the entire team
was remote and utilized more written communications, we'd be spend less time
rehashing old topics and more time delivering value. As to the spontaneity and
ideation of face to face, I've observed this happening over video chat and
slack just as often as in the office. If people are excited about their work,
they will talk about it, in person or not.

~~~
douche
I agree 100%, this matches my experiences pretty closely. I worked 80% remote
for a six months a while back, and it was astonishing how much better
productivity was, as well as the quality, if not necessarily the quantity of
communication. Now I've basically flipped that ratio, and it is depressing how
much of my time is wasted by low-quality communication, interruptions, as well
as the low-grade stress and irritation of _having to be in the office_.

------
abakker
The opposite of what you are asking: As someone who has worked remotely for 5
years, I can say that a big reason that it works for us is the willingness of
everyone to make time for collaboration. For our team (mostly writers,
consultants, analysts), this means picking up the phone and having
conversations with each other constantly. For perspective, I use ~3000
minutes/month on the phone. This is largely made up of 15-30 minute calls.

If your work product doesn't lend itself to spoken discussion too well, or if
that kind of collaboration doesn't suit the team, I can easily see why it
would be very difficult to make it work. It is easy to collaborate remotely on
ideas, but pretty difficult to collaborate on the final product.

If I worked in an field that required a lot of visual collaboration, like
design, I don't think it would work nearly as well. The online, webex style
tools are still too poor to support good collaboration on those kinds of tasks
IMO.

------
jedberg
Not exactly what you are asking for, but I'll throw it in here:

I run a fully remote company, and most of the objections I've heard from
others we've found workaround for.

The biggest unsolved problem is whiteboarding - there is no good collaborative
online whiteboarding solution that doesn't require a lot of expensive
equipment to be deployed to everyone.

~~~
vonmoltke
> The biggest unsolved problem is whiteboarding - there is no good
> collaborative online whiteboarding solution that doesn't require a lot of
> expensive equipment to be deployed to everyone.

Maybe my company is just weird, but we don't use whiteboards all that much. At
least for code our preferred collaboration method is pairing, which isn't as
hard over a network.

We write NLP software, and most of our whiteboard usage is for drawing out
linguistic constructs and often involves only one person doing the drawing,
which seems like an easy subset of whiteboarding to handle remotely.

~~~
jedberg
We don't either, but it comes up occasionally. Sometimes when figuring out a
large architecture, it's just easier to be able to draw it out. So far we've
solved the problem by waiting until we see each other in person every few
months, so it hasn't been a huge issue, just the main issue we can't seem to
solve well.

------
up_and_up
I have worked for a 100% remote team for 4 years. Most of the concerns I see
being posted here, I believe have more to do with the inability to hire well,
the inability to efficiently communicate at the inter and intra team level,
and the inability to operate as a remote-first company.

Below I document how to successfully run a remote company. I work for a
successful startup receiving regular accolades for our product.

Hiring:

Never hire very junior unless the person shows extreme talent combined with
superior communication skills. Generally you are looking for people that are:
highly efficient, organized, responsible, disciplined and able to stay on task
with limited oversight. They should be self-starters with numerous projects
they can point to that they delivered on their own.

Product engineering:

Near all communication happens in Slack/Hipchat/etc. Group meetings, when
including remote people, happen in skype / Hangouts. We use shared google docs
to brainstorm product and document specs. We use Trello to translate those
high level specs into actionable stories. Use github to organize code reviews.
You need a results-driven mentality. What did a developer deliver this week?
This month? Weekly standups on Google Hangouts + monthly 1-on-1's with each
developer can give you a good sense of how well a person is performing.

Culture-building:

Have in-person meetups 2-4 x a year for beneficial face-time and for people to
get to know each other better on a personal level. Have monthly video
conf/hangouts on non-work technical topics where people rotate presenting.
Have a separate monthly book club to discuss technical or nontechnical topics.

Onboarding new people:

First, never hire very junior people. When a new person is hired, have them do
20 min 1-on-1's with all team members to get to know each other and their job
role. Pair them up with a another person to work on a shared project. Have
them paired for several projects before releasing them on the own.

I am happy to answer any specific questions if you have any.

~~~
mountaineer22
What is your team size?

~~~
up_and_up
20 people, but the processes we have in place should be scalable to way
higher.

~~~
mountaineer22
I am not doubting that, I was unsure if this would be too "formal" for a small
team of 5 or less.

~~~
up_and_up
In that case, I would slowing introduce pieces of this, see how it works etc.
If you feel like you need more process or more ways to build team camaraderie
act accordingly.

------
1_800_UNICORN
I work at a company that is strict about not allowing developers to work
remotely except in rare circumstances (i.e. an employee wanted to spend time
in another state to be with their family for a few weeks, and they wanted to
work during most of that time rather than take vacation).

For us, it's about keeping the barriers to communication as low as possible.
We do pair programming, so we're already very much oriented to frequent
communication. While tools like Slack and email get the job done if your team
is working remotely, nothing beats being able to turn around in your chair and
quickly engage another pair of developers (or the entire dev team if
necessary) in a quick discussion about something. This extends to the rest of
the team (designers, product managers, relevant business analysts, etc). At
any point I can walk 30 steps or less and talk to anyone from the product or
business teams about requirements.

Admittedly we keep strict working hours to maximize the amount of time the
team is together (8am to 5pm, everyone takes the same lunch hour). The flip
side of those strict hours is that we are never asked to work overtime or
weekends. We come in, the entire team works for 8 hours together, and then we
go home. People never believe me until they see it in person, but our office
will be buzzing with work at 4:58, and then be a ghost town at 5:02... unless
we decide to play some post-work ping pong or grab a beer!

I'm not saying that I don't think that remote work can be effective, because
I've seen it work. But I think it's disingenuous to say that remote work is
equivalent to colocation. The best argument I've seen for seeking remote
workers is when a company is located in an undesirable city and struggles to
attract talent (i.e. a company in Paducah, Kentucky will struggle to attract
candidates in a way that a company in Denver, Colorado probably will not).

------
edoceo
Our management wants onsite for better control. I think it's all feelings
based. We want to hire in Seattle. We had some remote not work out, therefore
all remote is "bad".

I think BS. We just got a new remote QA team and they are doing great.

We have two remote devs also who are doing good work.

I interpret the evidence to show that remote does work.

I still get push back on it but the rationale is based on words like "better"
and "easier" without quantifiers.

My feelings are that some managers like to interrupt frequently for "urgent
fires" and that is easier when someone is a few metres away.

~~~
ohjeez
In what way did the remote employees not work out?

(I'm looking for examples to include, so details are helpful!)

~~~
edoceo
We called it a quality issue. IMO we didn't provide a good environment. One
remote QA team promised things they didn't deliver. But we found out in two
months

Edit: good environment means clear direction, open communication. Which is
necessary onsite as well

------
dudul
Answering for the hiring side at an organization where remote work is not
allowed.

The reasons given by the founders to only allow local workers are: * we want
everybody in the room to build the culture and for people to learn how to work
together * whiteboard sessions/intense discussions are difficult to do
remotely * for lead positions: face time is important to properly lead the
team

I feel like it's a disastrous policy to find candidates. I'm in MA and we
compete with _a lot_ of companies over a rather small pool of candidates. The
worse is that the "local only" comes with a "please, go easy on the WFH"
policy. Recruiters literally laugh at us, and tell us that we will never be
able to compete if we don't allow flexible hours/locations.

We did manager to hire a couple developers, but we had to lower our standards
(and one could question them, but it's not really the point here).

Interestingly, after a while the "limit the WFH" policy was relaxed. And now
people are still local but can take a couple days to stay home every week. I
think it's just because the team delivered, worked hard and built trust. It's
just sad that it took a long time, and that still has not changed the no full-
remote policy.

I think the candidate would have to be extraordinary and, more important, fill
a position that had been open for a long time to allow remote workers. Enough
time to convince upper management that we had to consider a wider pool or we
would never find anybody.

------
anarchitect
I have a remote member on my team who came to us as part of an acquisition. He
travels to our London office once a fortnight. It works well, but I wouldn't
hire remote workers for new roles.

The key reason for this is that our culture and processes within the company
are not very well equipped to accommodate remote workers. We're spread across
two sites (one of which is a factory), and communication is difficult enough
as it is.

------
anotheryou
I could be more productive remote, because it's less chair-time and more
working when I'm really concentrated, 1.5h less commute, less distractions (i
really love to block out the rest of the world with music and don't like
headphones), real food and a bed for a quick nap at home. We are partly
remote, but I'm sadly not.

What is nice about non remote though:

\- you can see if a college has time for your questions

\- you can scribble stuff easier while explaining complex things

\- less language barrier. I find it really hard to understand non-native
speakers over a bad skype connection (high quality headsets would fix this I
believe)

\- you can sense how the other feels and act accordingly

\- It's easier to guide inexperienced people when they feel more free to ask
questions. Probably fixable through good culture, but an effort to be made.
It's also easier to see when they really got what you mean. (had trouble with
the remote people here, though being forced to write even tighter
specifications or more making more detailed mockups is not necessarily bad)

~~~
gorbachev
The language barrier thin is very real. I'm not a native English speaker and
have very hard time understanding people with heavier accents. It's especially
bad over phone/web conference.

Also it's really amazing how crappy many companies' web conferencing setup is.
They break down regularly, have poor sound quality and are generally really
flaky. I know this is getting better with Hangouts and alike, but still, they
are occasionally going to crap out and always, it seems, at the most
inopportune time.

~~~
doozy
> \- less language barrier. I find it really hard to understand non-native
> speakers over a bad skype connection (high quality headsets would fix this I
> believe)

> The language barrier thin is very real. I'm not a native English speaker and
> have very hard time understanding people with heavier accents. It's
> especially bad over phone/web conference.

Solution: Hire only people who speak good English (yes, you should test them /
interview them before hiring them!)

~~~
anotheryou
Fine english, just with a foreign accent. No problem face to face.

------
Normal_gaussian
Currently we are an "on-site only" workplace.

There are two reasons for this, firstly and most importantly our primary
founder has a law, not a technical, background.

This means he often has to just trust that myself and the other core team
member are doing sensible things. With a large chunk of savings invested and
the project running late (prototype and limited release 1 done, but 'core'
functionality and UI still very much in progress) bums in seats is a very real
metric.

Secondly is a combination of bad experience, low funds, and not the right
time.

The company has had several other in office developers who were supremely sub
par. A lot of my rapid acceptance into the company and (currently thrahing out
the details of) gaining equity came from the removal of predecessors crap and
providing simple and solid guarantees. This makes us edgey about trusting
people to get on and do things without serious oversight.

Its obvious that this can be remedied in two ways- with more funds for the
right developers and spending more time managing them. The funds are being
remedied with our growing sales (yay!) and the time... well I'm primary
developer and learning a hell of a lot about managing people.

Not the right time is a case of everytime we bring someone new in it will
distract me for a fortnight or so... especially considering the current
compensation we can offer. As we are near a wider release it does seem more
sensible just to get on with it and hire with the money and time a wider
release brings (or takes away, as I suspect will be the case with time).

Finally we should note I fully intend to bring remote working into the
company. At first for new hires then a few years in for myself and the other
two (likely rota'ish). This looks like an uphill battle with the founders but
I'm sure when their stress can be lowered it will be a lot easier.

Regardless, life ahead shall be good.

------
doozy
As someone who has worked 10+ years remotely (based in South America) I think
it's a combination of factors:

Supply and demand. Why hire remote when there's plenty of warm bodies locally?
Most companies do not need, and cannot afford, top-tier talent. Labor
shortages are a myth.

Managerial incompetence. How many of the managers have any experience managing
a remote team? Do they know what to do and what not to do?

Remote is frequently seen as synonym with "cheap, sub-par foreign developer"
and there are many good reasons companies avoid that.

IMHO, remote-friendly organizations will prevail. The ability to hire from a
much larger pool of talent and save on office costs gives them the upper hand.

~~~
ohjeez
> Managerial incompetence. How many of the managers have any experience
> managing a remote team? Do they know what to do and what not to do?

What are the skills that someone needs to manage a remote team? How could
someone measure whether he has them?

~~~
doozy
Ability to communicate properly and proficiency with collaboration tools rank
high on the list. It's also crucial to be able to properly identify and
evaluate the contributions of any team member.

Remote is also largely incompatible with micromanaging. If you don't trust the
ability of your remote developers to take decisions on their own the team is
likely to underperform and fall apart. This is one of the main reasons remote
works much better with senior developers.

------
basseq
Broadly, remote workers are only going to be successful in two situations:

1\. Remote workers are task-oriented or don't require collaboration. 2\. The
company is set up to make remote workers equal citizens. ("Remote First")

#1 tend to be the cost play, and leads to outsourcing or offshoring. (Or are
things like in-territory sales managers or something.)

#2 is _hard_ unless you're starting from scratch. On top of implementing
collaborative technology, improving processes, focusing management practices,
and restructuring your organization, you need to change your _culture_.
Employees who sit right next to each other should be chatting in the Slack
channel, not face-to-face.

Most companies have other priorities than to tackle this kind of change, and
quite frankly, don't _need_ to look outside a 30-mile radius to find qualified
candidates.

Hiring remote employees without the organizational foundation to support them
is a recipe for disaster.

Having an existing employee "go remote" is easier because they're already
ingrained in the culture, and "alternate work schedules" (e.g., not 100%
remote) are good in-transition approaches.

------
jldugger
Our last hiring round was for a senior system administrator. We currently have
10 student workers "underneath" this position, and something like 30 percent
of the employees time is spent mentoring students to do the work. We're okay
with occasional work from home days, but a 100 percent remote person is
basically a non-starter.

There's a number of tasks that cannot easily be done remotely:

1\. Recruiting and Interviewing students. 2\. Installing equipment into
datacenters. 3\. Letting customers into the datacenter after hours. 4\. Face-
to-face student mentoring.

Hiring a 100% remote employee essentially means a substantial shift in in the
other employee's (ie me) duties.

We recruited for this position globally, but a number of prospects were only
interested in working remotely. It makes sense for the prospects -- remote
work frees up a family to follow one spouse's career. It makes filling
positions harder obviously. But the only way we'd be able to accommodate that
equitably is by dropping the focus on student employees, and we'd need a lot
more cash flow to make that happen.

------
PaulHoule
I live in a rural area in upstate NY. I can't relocate because I live close to
my wife's family and she teaches kids to ride horses.

A while back I was in a dead end job and working on a side project that was an
image search engine that had nearly perfect relevance in a time when both
Google Image Search and Bing Image Search were both embarrassingly bad -- at
least at the time I started.

It took about a year to get the product really ready populate the database,
and by that time the big guys had come a long way.

This got the attention of a company in LA that had ambitious ideas for an
intelligent social media aggregator and they had explored several dead ends in
terms of building the brains of the product so they brought me in. They were
hoping I would relocate but they had to start getting traction.

It lasted about a year. A prototype of what I built was picked up by the team
and developed into a "MVP" that didn't really get product market fit.

I moved on to another company that was based in Rochester, NY that hired
remotes, but that is another story.

~~~
ohjeez
I want to hear the other story, too! :-)

------
SNvD7vEJ
I find remote collaboration with shared screens and headsets much more
productive than sitting next to each other. You can quickly jump back and
forth between the shared screen and other activities while collaborating.

We also do this even when being in the same room, just because the screen
sharing is so powerful compared to physically sharing a display and a
keyboard.

Also, you can quickly and easily call in any number of people and everyone can
easily read everything on the screen.

I find this perfect for mentoring, pair programming, demonstrations, meetings,
etc.

You don't have to go fetch your coworkers and drag them to your desk to show
them something.

Also, you can quickly see if the coworker is busy in another session, or set
your own status to busy if you need to work uninterrupted for a while. This is
not possible when physically in the same location (unless you have a door you
can close). People will still come up to you and interrupt you with a "quick"
question, derailing your thoughts. A virtual call can simply be ignored.

------
kyriakos
for a purely software based company I think the main reason to require on-site
employees is lack of trust. management really wants to see the people they pay
walk in in the morning and sit at their desks.

personally I am more productive working remotely. I used to work for many
years on-site at the same company and the distractions were unbearable, phones
ringing, people walking by who always felt the need to interrupt me about
anything (work related or not). and many phone calls about unrelated projects
which resulted in context switching.

it turns out working remotely is more efficient because you avoid the random
chit-chat, and unrelated calls transformed themselves into emails which I can
open and respond to at a more convenient time.

------
nfriedly
I know this isn't exactly what the OP is asking for, but I'd like to share my
experiences working remotely for 8 of the last 10 years.

* It's not for everyone. You have to be pretty motivated and driven, and also a good communicator. You additionally need some good non-work relationships. (Although, that's probably true regardless...)

* It's a lot easier when everyone uses phones/email/slack/etc. Being the 1 guy on the phone during a 30-person meeting sucks.

* Those little "water cooler chats" can and do happen on slack and phone calls. It's helped by having met the people in person before, but even that isn't a requirement. I was talking to a co-worker that I've never met in person about pokemon just yesterday...

* I usually shoot for about 10% of my time being spent on-site in 1-2 week chunks, perhaps a little more right after joining a new team. I try to go out for dinner & drinks and whatnot with team members for at least one night on a visit. This can help with those virtual "water cooler chats" later on.

* Mentoring can happen remotely as well. Mentoring and guidance is a large part of my current role, and I've never met the majority of the folks I help out.

* I do occasionally take time out of work for family things. But I also occasionally cut out family time to deal with pressing matters at work. So I think it works out in the company's favor overall.

* I've been told by more than one manager/CTO/CEO that I was fit for a leadership role but wouldn't get it because I worked remote :(

* I joined IBM a year and a half ago partially because of this: I believed that being remote wouldn't hold me back from promotion here but...

* A few months back, the Watson division got a new guy in charge. Everyone was told to either move on-site or find a new job. I managed to get a temporary exception until the end of the year but I'm still not sure which one I'm going to choose when the time comes. Maybe both (I've always wanted to see Europe... ;)

------
maxxxxx
I have worked on remote-only teams which were great because everything was set
up for that workflow. In companies where you have a lot of on-site people the
remote guys add a lot of overhead because now you need processes for on-site
and offsite people.

I am fine if a guy shows up two times a week or so but I am wary of full-time
remote workers unless I know I can trust them to not waste time on irrelevant
tangents. There needs to be some level of maturity.

Time zones are also an issue.I would not work with somebody 12 hours away.

------
aggieben
I once got a remote job with a startup in Dallas, but it was a bit of an
unusual circumstance where I had all the bargaining power. A friend was going
in as the director of engineering and really wanted me, and I basically made
being 80% remote a condition of my employment. It wound up not working out in
the end largely because of that (not because of my friend, but because of
executives who didn't feel like they were obligated to honor their agreement
with me).

------
TrickedOut
Easy - my ex-employer's HR department has an explicit policy of promoting when
your staff grows. Part of it is a spreadsheet exercise at the end of the year
and part of it is optics. The greater the staff I can show the higher the
change of promotion. That was the deciding factor. Period.

I left that place because it was non-sensical, but it was a major employer in
Connecticut, so i wonder how many other major employers have a similar policy.

------
SatvikBeri
On my team we work from home roughly once a week, but don't hire anyone who's
remote full-time. Honestly, I don't have super strong reasons for or against
remote. It does seem like your culture needs to be either fully remote or
fully colocated (to avoid the informal communication problem) but there's no
major reason to pick one or the other. So I go with fully colocated, because
it's the default.

------
mountaineer22
In some instances I really believe it to be an ego or optics thing.

I have noticed some business owners emphasize how many people they employ, how
they are "job creators".

On the opposite end, I have seen entrepreneurs who strive to be as lean as
possible (automate everything), with employing another person seen as a last
resort.

Do you think it depends if the org./dept. is results focused versus process
focused?

------
SNvD7vEJ
What about open source projects where people mostly collaborate remotely?

Are they harder to manage, or less efficient?

------
cheeze
My company generally doesn't hire telecommuters. There are exceptions though.

* Why does the person who does this job need to be on-site? Please be specific. Give me examples of things that can only be done if she were in the office.

Ad hoc meetings are 1000 times easier when everybody is in the office. Standup
and other meetings are hindered by teleconferencing at best. Even with high
quality video and audio, it is often much harder to hear the remote person,
harder to collaborate (I can't just walk to a whiteboard and draw something up
quickly and have them _easily_ see it.)

Having them train a new hire or an intern is much harder. Furthermore, interns
and new hires much prefer somebody being able to sit with them and
collaborate. Sure, you can do screen sharing, but it's not the same at all.

One thing that makes our team 'special' is the culture of the team. We often
do team building exercises (paintballing, curling, etc.), have optional happy
hours, etc. and all of that is physically impossible without flying somebody
out.

It is much harder for the remote person to get support from help-desk. If you
are onsite, you walk down to one of a few different help desks and get help
right away. If your hardware is faulty, you get a new laptop and are up and
running within a few hours. This is not possible with somebody remote, and
we've had major headaches dealing with this.

* Have you been in a position where you personally would be okay with an employee being a telecommuter, but a decision-maker deemed otherwise? How did you handle it?

No.

* How has the policy affected your company’s ability to attract candidates?

I think this one is pretty hard to answer. I'd assume many potential employees
pass on even applying since we don't really support remote work. I don't think
I can give a proper answer here, unfortunately. I can say that we're fine with
this tradeoff. We haven't had any problem attracting talent in the past
(paying boatloads of money helps.)

* Have you hired someone for an in-the-office job, and later given permission for the individual to work from home? What happened to make the change okay?

Yes, we allow this with extenuating circumstances. We've had team/org members
get sick and prefer to work from home for a few months while they recover.
We've had employees leave the country to be with their parents due to illness.
Employees who wanted to work from home a majority of the time while their
child is young, etc. Generally we're pretty okay with short term
telecommuting, but we don't really offer full time (forever) telecommuting.

Note that team members regularly WFH for a week or two while visiting home (if
they don't want to take vacation), and nobody cares if you WFH once a week or
two.

* What would it take for the company to change the no-telecommuters policy, even if only for one specific position? For example, “If a rock star in my field applied for the job, we’d do anything to get him to say Yes – including letting him work remotely.” But there can be many other answers, and I’d very much like to hear yours.

If a known rock-star (guaranteed) applied, we'd let them work remotely. If we
had trouble attracting the talent we needed, we'd let them work remotely.

------
itake
I am someone who got an "on-site only" job and now work full time remote in
the same position on the other side of the country (and sometimes the world).

This happened because I worked on-site for a year and I wasn't happy with the
lifestyle the city I lived in provided (specifically SF/the bay-area, spent
5mo in SF then 5mo in SJ, still wasn't happy, so I moved to VN for 6 weeks).

I told my boss I needed a change of scene-ary and I really enjoyed working for
and doing the things that I do at work, but I really did not like the bay and
I wanted to live other places. He agreed to let me work remotely from Vietnam
for 6 weeks, then Florida indefinitely. I think a few things that drove that
decision were:

1\. After working with me for a year, I am a known quantity that they like.
With every new hire, there is risk and some people think more risk, since
people won't be there.

2\. The company is very small (10 people) and I play an important role in our
platform. It would be expensive to replace me and they don't really want to,
because of 1.

* Why does the person who does this job need to be on-site? Please be specific. Give me examples of things that can only be done if she were in the office.

Having been on site and remote, a couple of things that I feel that I am
missing out are:

1\. I feel like I have less klout in the office. When it comes to product
design and company policy decisions, I am often left sitting on my hands while
everyone else chats about it in the office.

2\. Sometimes I miss spontaneous product discussions that happen within the
office and am not typically told about that. This should be fixable, but it is
about building good habits and keeping the team informed.

* Have you been in a position where you personally would be okay with an employee being a telecommuter, but a decision-maker deemed otherwise? How did you handle it?

No.

* How has the policy affected your company’s ability to attract candidates?

Since the office is in the bay, people fly from all over the world to work in
our office. Has not been an issue.

* Have you hired someone for an in-the-office job, and later given permission for the individual to work from home? What happened to make the change okay?

me! see above.

* What would it take for the company to change the no-telecommuters policy, even if only for one specific position? When I got hired, there was a no-telecommuters policy and they were letting go both of our remote workers. I think I have been able to work remotely because of the points mentioned above.

------
mountaineer22
It seems in most reason given here, it is because the onus is on the junior
developer to seek out the senior developer's help on-site, but it is not
encouraged for a senior developer to reach out to a remote junior dev.

------
Kroniker
I'm not allowed to work offsite, but then again I work in defense, so you can
probably put two and two together...

~~~
aggieben
I used to work defense, and with a few exceptions, I always thought most
people who worked at the company could have been remote without much problem.
It's really not that hard to deal with classified information remotely, and
most things aren't classified (yet).

------
joesmo
I'd like to know how many people here who refuse to hire remotely are willing
and can provide a proper working environment to their engineers: ie-> single,
private offices, 4k monitors, adjustable desks chairs, etc. Or are these
people forcing people to work onsite in substandard conditions simply so that
there can be "spontaneous" conversations, aka pointless distractions like I
read in most of the comments?

~~~
nickff
How can such conditions be 'substandard' if they are the norm, and thus,
presumably, 'standard'?

------
wrong_variable
I think its also a lack of examples of companies that managed to scale up a
remote dev team.

------
ChuckMcM
I've argued both sides of this issue (both for and against) and generally they
come down to situational communication.

Before jumping in though I'd like to create some definitions that I use in my
mind to keep things differentiated. There are three configurations of remote
work that have been called at one time or another, telecommuting.

1) Working from home. This is perhaps the most interesting one and it is
specifically an employee in their own home using their own or company
equipment to connect back to "the office". They participate in teleconference
calls when invited and generally have a VPN type connection to the company
network.

2) Working at a 'commuter' desk. These are people who are working away from
where they normally would and sitting at a desk in a company owned facility
that is not specifically assigned to them but hosted in a company facility.

3) Working at a 'remote site'. These are members of the group who are working
at a company facility that is distant from the primary facility that is
hosting the group they are associated with. It may or may not include other
"remote" members of the group but it is a permanent arrangement unlike #2
above.

I don't think there is a lot of controversy or question around #2. People are
traveling, they can stop in a local office and get some work done and have
access to things like printers and conference rooms. So for those workers it
is a way to work effectively while travelling.

Option 3 (a "local" office for a member of a "remote" group) is generally well
supported by most organizations, especially ones with extended sales presence
in multiple markets. This arrangement benefits the company by allowing them to
hire in places where people don't want to move away, and in my experience, it
makes the sales team (if there is one) at that facility more effective as it
can cut down on communication time between corporate and sales.

So lets agree when we're talking about "telecommuting" as something which can
be argued for or against, we're talking about allowing full time staff to work
out of their homes.

There is lots of material on this with many different angles from team
building to team communication to legal liability.

Most people don't think about the legal question, just like they don't think
about collecting sales tax from people at their garage or yard sale. However,
in some jurisdictions it is illegal to work full time out of your home without
a business license, fire department inspection, and ADA compliant facilities
(for example). In some places you need a zoning allowance. There is a question
about injuries you sustain while at home but "working", is that covered by
workman's compensation? homeowners insurance? (likely both will refuse to
cover it). To the extent that working at home becomes more popular, you will
see municipalities crack down on this just like they do on lemonade stands[1]
from time to time.

Then there are the team dynamics. If you have an office which some people hate
(say a noisy open office plan) but they can't work from home (maybe they are
renting one room out of a 3 bedroom apartment which has two families living in
the other two rooms). They will have negative feelings about the company and
their fellow employees who have the luxury of working from home. If you have a
lot of spontaneous brainstorming sessions, few will remember to "dial in"
someone who is not in the office. This will make the person off site feel "out
of touch" (which can lead to them feeling anger and distrust for the rest of
the team).

But lets answer the 'hiring side' questions, that is easy.

\-- They have to be on site to avoid negative team dynamics and legal
liability.

\-- Yes, and I told the employee they had to work on site at least 4 days a
week.

\-- No.

\-- I've seen that happen (I wasn't personally involved in the decision). The
change was okay because the person's job was essentially a group of 1 (they
had few external dependencies) and they were reliable at meeting the schedule.
They essentially became a "remote office with 1 employee" in it.

\-- I have been in companies where it was pretty absolute (everyone comes into
the office) and companies where it was more flexible. In my experience, groups
within the company without work-at-home people had better group dynamics and
higher productivity. But to really understand why that was you needed to
understand how the company got things done and how groups negotiated
deliverables.

[1] From 2011 -- [http://www.forbes.com/sites/erikkain/2011/08/03/the-
inexplic...](http://www.forbes.com/sites/erikkain/2011/08/03/the-inexplicable-
war-on-lemonade-stands/#476741982264)

