
Stop whining and start hiring remote workers - jodosha
http://37signals.com/svn/posts/3064-stop-whining-and-start-hiring-remote-workers
======
edw519
_Everything we do to manage a business consisting mainly of remote employees
is something anyone else could do too._

I would modify "anyone else" to "anyone else enlightened enough". Big
difference.

It's still amazing how many managers/leaders are so bad at managing/leading
that all the tools in the world wouldn't make a bit of difference. You know
who they are, the people for whom:

    
    
      perceived activity = progress
      meetings = progress
      being there = progress
      lines of code = progress
      check marks = completion
      social skills = competence
      perception = reality
      what's on the surface = what's underneath
      # of tasks completed = an acceptable metric
      successful testing = quality software
      smiling customers = satisfaction
      90% complete = only 10% more to go
    

Good managers know better. So they can take advantage of OP's tools.

The technology for managing remotely is clearly ahead of the people who would
most benefit from it. I look forward the the day when managers catch up and
"get it".

~~~
arctangent
I can't agree with you more.

But let me briefly offer an insight about why I think things won't change:
management itself exists to perpetuate the things on the left hand side of
your equations above.

Traditional managers in established (i.e. large) companies are terrified of
letting their staff work from home because they perceive (correctly) that if
those staff are still productive then there isn't really any reason for them
to be employed in their own role.

The things on the left hand side of your equations are a proxy for success
that the manager can use to justify their own usefulness. As soon as you start
measuring "real" progress the need for non-productive members of staff
disappears entirely and most middle management instantly becomes surplus to
requirements.

~~~
troll24601
The idea that management exists to perpetuate the things on the left is as
cynical and generally wrong as the idea that coders exist to increase
complexity and guarantee their own necessity. It is true only of the worst of
either group of people. The best work hard to make themselves unnecessary.

~~~
rbanffy
I've seen the very worst managers a lot more frequently than the very worst
programmers. While some structures may reward bad programmers, structures far
more frequently reward bad managers and very often prvide them with a place to
hide their inadequacies very easily.

~~~
Joeri
That's because if a programmer is bad, work doesn't get done, and people
notice immediately. But if a manager is bad, the subordinates often manage to
get work done despite the manager, and the bad manager is in turn more likely
to have a bad manager who doesn't recognize the on-going failure.

------
DanielBMarkham
Okey dokey. I clicked on this thinking "hell yeah!" and stopped short of
agreeing after reading it. Why? Because although I agree with the author, his
argument is too shallow.

Here's the thing: _delegating to remote workers is going to be the critical
skill of the first part of the 21st century, and it's not as simple as black
and white._

So it's not just "do it all the time" or "only use local help" It's much,
much, much more complicated. I work with a lot of technology companies, and
I've seen them kill perfectly good projects by poorly-configured remote worker
configurations. If you don't know what you're doing, you're better off with 4
guys working in the same room than 40 guys working all over the world. See
"The Mythical Man-Month" (<http://www.hn-books.com/Books/The-Mythical-Man-
Month.htm>) Technology labor is not fungible. The social dynamics of teams
physically co-located can create powerful momentum. Serendipity is about 20
times harder to do over a telephone.

"Get up to speed on remote working practices" contains a lot of nuance. For
instance, I've seen teams fly in remote workers for the first few sprints of a
project, then going "truly remote" once the rhythm and cadence was
established. I've seen teams pair up with each pair working in a different
location. I've seen teams work mirror configurations where they still paired
up, but each pair was separated. Each of these setups (and many more) have
their advantages and disadvantages.

So yes, by all means, leverage the terrific talent and resources available to
you around the world. But don't read a slogan and go running out to shoot your
foot off. Take some time and figure out what kind of company you are, what
kind of culture you have, and what kinds of projects you do. Then grow and
evolve your remote working to fit in with that. Don't be the guy who already
has the solution and is just looking for the problem. Remote working is the
key to the new century, but it's nowhere as simple as flipping a light switch.

~~~
equalarrow
I love the 37Signals guys and opinions, but this is where I greatly differ
with them.

Case in point. I worked at a place where at one point, everyone was remote but
me. I could have been remote, and sometimes I like working from home or a cafe
or wherever. But for team morale and even with phone or video conversations
with the other devs, it became totally demotivating after a while.

I was contracting with that company and joined years later as a ft employee.
Engineering consisted of about half a dozen and we were growing. We started to
notice that it was 'hard' to hire anyone local, so they just gave up (accepted
maybe?) and ended up going with a contracting company and almost doubled the
team with everyone new being offsite. Standups became something that was no
longer fun because there was so much emphasis on looping in the remote people
- screwing around with the video camera, trying out this video service, etc,
etc. Come tomorrow (1/12), everyone at that place will be remote and they'll
have lost pretty much all of the local devs for various reasons, me included.

Building a team can be hard. But I don't buy the "we can't find anyone local"
argument and if I was building a team, I want people local. It's definitely a
programmers market right now, but if you want to hire local, then you have to
go out and get creative - go to user groups, meetings, etc. It can be done and
I've seen it both ways. Local, to me, is just hard to beat. I want people
engaged with each other and don't want to have to Google+ someone on video
every time I have a question for them.

That said, I'm fine with some days a week where local people work remotely,
but to have everyone or some 100% remote is not a good idea in my mind. You
don't develop 'company culture' that way. If everyone's remote, there's no one
to have a beer with after work and talk about the latest coding issue,
problem, point of interest, socialize, or whatever. Guess that's just the
difference with getting the work done vs. enjoying your work and the people
you work with.

~~~
DanielBMarkham
Yes. Agreed.

Too many times we programmers view programming as if it is a transfer of bits
over a wire somewhere. You shove a pizza under the door, email some
requirements, and out pops a solution.

It doesn't work that way at all. Most of the really cool things that happen
with teams can't be predicted ahead of time. You just put some really smart
people together in a room, throw a tough problem at them, get out of the way,
and watch the magic happen.

The magic doesn't happen when nobody has met each other and communication is
limited to telephone, email, and IM. I'd rather have 5 guys who weren't so
smart all working together in an awesome team than 10 guys who were rocket
scientists all plugged in remotely.

Having said that, there are ways to get where everybody wants to go. Hire
locally and then let folks work remotely from time to time. Hire people who
have already worked closely together and have developed a great relationship.
Hire in clusters, etc.

I like 37Signals, but too many times much of their blogging and communication
consists of "look how awesome we are!" I am all for people self-promoting, but
this schtick starts to become annoying to me after a while. It sounds a bit
like pandering and easy sophistry. Things are not that simple. We would not
all be awesome if we worked like 37Signals and things would not be better if
we all suddenly switched to remote workers overnight.

~~~
plinkplonk
"You just put some really smart people together in a room, throw a tough
problem at them, get out of the way, and watch the magic happen.

The magic doesn't happen when nobody has met each other and communication is
limited to telephone, email, and IM."

Someone should tell the Linux Kernel (and other Open Source dev, where a lot
of terrific "as magic as it can get" sw dev happens) guys.

No, I am not saying that OS dev is the same as commercial dev, or even that
what you are saying is essentially wrong.

I am just challenging the absolute nature of "The magic doesn't happen when
nobody has met each other and communication is limited to telephone, email,
and IM." Plenty of "magic" does happen every day when people who know each
other only by their irc handles or email ids work together on a codebase.

Whether such activity can be harnessed to help a commercial dev effort is
certainly debatable (and there are many good points on either side of the
issuel), but the idea of confining "magic" _in software dev_ to only dev teams
working in the same room is somewhat dubious (imho, ymmv etc).

That said, time to party here in Bangalore. Happy New Year, everyone!

~~~
kronusaturn
> Someone should tell the Linux Kernel (and other Open Source dev, where a lot
> of terrific "as magic as it can get" sw dev happens) guys.

Apparently someone did. The express purpose of the Kernel Developers Summit is
to work out problems that couldn't be resolved online.

~~~
plinkplonk
A summit once a year doesn't change the fact that the default mode of working
is still remote and distributed.

An equivalent would be someone working 9 to 5 in an office and doing two days
of "work from home" in a year.

------
moocow01
One thing I've realized about working remotely is that it is actually quite a
big pay raise if you use it correctly. The type of work-related things that
usually cost money/time can be much more easily eliminated like...

\- commuting costs (no need to buy that 2nd car and pay insurance)

\- commuting time (arguably time = $)

\- lunches and food (make your food/drinks at home)

\- ability to take care of little things during non-rush hour (ex. going to
the post office when there are no lines)

All in all, you could probably find ways around these for non-remote jobs
depending on your situation but I've found I save about $1000 a month from
working remotely. This translates to about a ~$1400 dollar bump in salary per
month when you take into consideration that Uncle Sam takes ~30%. Difference
of ~16-17k for me annually but everyone will have their own number. And this
doesn't even take into account the possibility of living in an area with a
lower cost of living.

------
pg
"Stop whining" should really be "stop looking at the empirical evidence,"
because so far all the really big successes have been focused on a single
location, especially at first. 37signals is a successful company certainly,
but I would be surprised if its value is 1% of Google's.

~~~
balloot
I would be surprised if 37signals value is .1% of Google. Google's market cap
is a little over $200B, so .1% makes for a $200M company.

~~~
bigohms
Valuation, sure. If the numbers ever get out, be seated at the time. It's a
very lucrative product.

------
balloot
I don't get what it is about software engineers that make so many of them
think they're entitled to work remotely.

It seems to start with the fact that many engineers think 100% of their job is
coding, and therefore they can get "more" work done when working remotely.
This is absolutely dead wrong. Engineers also should be accomplishing the
following in order to maximize overall productivity:

\- teaching other engineers

\- learning from other engineers

\- coordinating engineering tasks to minimize duplication

\- doing what is necessary to ensure the software is what is needed

\- communicating with others any insights that may be had while developing

\- working with other departments to make sure everything is in place to build
whatever it is you're building.

This is just what I can come up with off the top of my head in 2 minutes, and
each of these things takes a significant hit when the engineer is working
remotely. Any engineer I would want to hire has quite a bit more to offer than
coding skills, and as soon as you require more than a basic automaton blindly
building a product exactly to spec, you need human interaction with that
person to maximize potential. We already learned this lesson a few years ago
with the total failure of "all software can be outsourced to India!" I don't
see why we need to learn this again.

~~~
mkramlich
good sw engineers are rare and in demand plus, we have many tools and
telecommunication technologies which let us communicate and work remotely.
Some people have learned that traditional corporate offices are full of things
that make them less happy or less productive. Distracting sights, noises,
interruptions, makework, politics, inability to say what you really think,
having to act and dress artificially, inability to say take a nap when you
feel you need it, arbitrary arrival times, hampered ability to switch over to
non-employed tasks when needed (family things, a FOSS project, another
contract gig, etc). Some find it patronizing as well. There's also the notion
of maximizing for happiness rather than purely money. Also a smart actor in
any economy will use whatever leverage he has to maximize his own interests.
If the demand/supply balance happens to favor sw engineers right now they
would be wise to take advantage of it. Businesses and governments do it too.
Also, some individuals are broadly talented, beyond just being a programmer,
and it's much easier for those folks to exercise and monetize a broader range
and depth of their skills if they aren't kept in the narrow straigtjacket of a
specific employer's job role, and place and time of business. Being a remote
worker makes it much easier to lead a hybrid life where you spend some time on
entrepreneurial side projects since less time wasted on commutes and you can
handle interrupts from those side projects without political shit from your
"day job". You can make $100k/year as a FT programmer, a good life to be sure,
but the most likely path to making millions is by starting a business. And
that path is easier to try if you're a remote worker or contractor.

And yes, I know there are positives and advantages to office life as well,
please no need to chime in and enlighten me there. been there, have the
t-shirt, but there are lots of other t-shirts. :)

~~~
balloot
I disagree with a fundamental assertion you make here. I think a software
engineer has a very low ceiling when working remotely. Engineers that I
consider "good" or better not only must be on site most of the time, but they
WANT to be on site most of the time. It's the only way to maximally impact
whatever it is you're working on, and any good engineer wants that.

Also, many of the things you are talking about are red flags that would cause
me not to hire an engineer (FWIW I'm a lead engineer). If I'm paying you a
good salary to be on my team, I don't want to structure our work arrangement
around letting you work on various side projects. We pay well, we expect a
lot, and you should deliver as such. And I have consistently found the only
way to make that happen is to enforce physically spending the majority of your
time with the rest of the team.

~~~
mikeash
> Engineers that I consider "good" or better not only must be on site most of
> the time, but they WANT to be on site most of the time. It's the only way to
> maximally impact whatever it is you're working on, and any good engineer
> wants that.

I know a lot of excellent programmers and have never heard anything expressed
other than the precise opposite of this sentiment. None of them want to be on
site if it can be helped, and they pretty much universally believe that
physically transporting one's self to a real office on a daily basis is an
outmoded practice.

I don't doubt that there are good people out there who like coming in to work
in an office, but in my experience there are a _lot_ who do not.

You say that you've been unable to get consistent high output without forcing
people to be on site. I've seen lots of people produce consistently over a
period of years without ever once setting foot in any office (frequently when
there is no office to set foot in at all). Perhaps the problem there is not
with remote work in general....

~~~
balloot
You seem to know a totally different set of engineers than I do. I work in
Silicon Valley, and the vast majority of jobs here require on site presence.
This is the case for a very specific reason - the most productive engineers
work best when they can quickly and easily share ideas with others. You would
be wasting a significant amount of their ability by not having them around in
person.

The proof is in the pudding - every highly successful, well admired web
company you can think of employs the vast majority of its engineers onsite,
and those that are offsite are not core contributors. To claim that working in
an office is "outmoded" is ludicrous when there has yet to be a successful
case that succeeded with a team that is mostly remote. And no, 37signals and
its dozen employees don't count as a successful case of remote teams. I'm
talking about a venture funded company with dozens/hundreds of engineers.

------
ryanackley
I worked remotely for a year and half and later worked from home for my own
business. From my own perspective, I found it unsustainable.

Mainly, there are the psychological benefits of working around other people
that the internet can't replicate. These were the stages I went through when I
landed my remote job back in 2004:

1\. Euphoria. I was finally free of cubicle hell! I couldn't believe my luck
of landing a job working remotely. I could start and stop work whenever I
wanted. I could even take a nap after lunch

2\. Contentment. I was more productive. I was being judged on results only.
All is good.

3\. Isolation. I started to feel a little left out from from the happenings at
the main company office. I would hear stories about company gatherings and
events. When I was at the office, I wouldn't get any of the inside jokes or
stories about the "crazy" night I wasn't there for.

4\. Insanity. Must...get...out...of...the...house...

Also, career development is really hard working remotely. Most people are fine
being an individual contributor early in their career but once you've been in
the industry for 10 years or so, you'll start thinking about what's next.

I'm more satisfied coming into the office at a company that gives me
flexibility to be myself and work the way I want than I was working remotely
from home. YMMV.

~~~
dhh
Two things. We've definitely found that this setup works better with people
who already have strong social ties present. Close by family, friends helps,
but spouse + optionally kids really does it.

Also, at 37signals the career path is not one that leads into management. If
you're looking to climb the ladder at a bigco, then sure, I wouldn't recommend
remote working.

------
tibbon
For people talking about the lack of face time for remote workers, might I
suggest proposing to potential employees that they spend 80-90% of their time
offsite, and 10-20% of their time working onsite?

I live in Ohio for example. At some point I really wouldn't mind working for a
company in NYC, SF or Boston. Actually, I'd enjoy it since it would give me a
chance to escape the midwest with a greater frequency. I'd have _zero_ problem
working a week a month in one of those cities. I just can't move to a new
location fulltime right now. I have good friends in all of those cities and
don't need hotels every time (just pay for my transit costs and I'm set).

Yet, hiring employers view location of workers as being a binary of 0 for
always offsite, and 1 for always onsite. The most reasonable thing appears to
be striking a middleground.

~~~
dhh
It's a great setup. We get remote workers to come into the Chicago every once
in a while for a few days or a week. Good boost of energy, but doesn't need to
happen more often than once every few months.

~~~
tibbon
For cultural and team building, have you experimented at all with having
employees attend an event like SXSW or something even less work-related like
PAX so that people can get to know each other personally better in something
that is at best tangentially related to work? Or, does it seem to generally be
a waste of capital and time that isn't worth it?

I've personally experienced that I can really get to know people when spending
an entire week hanging out with them in this manner, and that it seems to have
very positive impacts on efficiency of my later interaction with them.

~~~
dhh
Yeah, we generally use RailsConf as a team-building exercise. Didn't get much
out of SXSW, though. Liked meeting up somewhere just the team better.

------
kenneth
People who blindly argue for working remotely don't understand that there's a
huge difference between getting shit done and building a company. You can't
develop a company culture without putting people together, physically.

If your goal is simply finish executing on that spec, and if you see workers
simply as a resource to be optimized, then you're right and remote workers are
the cheaper, more efficient way to go.

But if, on the other hand, what you're building is the company itself: a team
of smart, like-minded people who like each other and work well together,
there's no substitute for physical proximity. Happy hours, being able to _see_
what everybody else is working on, and working alongside everybody else with
delivery pizza at 9pm when in crunch mode… these are things that build
camaraderie between team members. It's similar to a group of soldiers in the
trenches: you need to know that your fellow soldiers are your friends, and
that they've got your back.

The whole is more than the sum of its part. But only when you have a great
company culture gluing the parts together—with remote workers, the whole is
just the sum of its parts.

~~~
nirvdrum
The other side of this token is every single person I've seen complain about
getting passed over for a gig because they didn't want to relocate (there's a
lot of them on Twitter) is only interested in putting in their hours and doing
a job. Arguably there's nothing wrong with that. But when building a company,
I want people to care more about than just lines of code. Actually, I want
people to do that in general (I have worked at bigger companies too).

~~~
dhh
I've found this to be completely false for every one of our remote workers.
Nobody at 37signals fits that description and as mentions in the article, the
majority works remotely.

~~~
nirvdrum
That's good to hear. I've really only had success with people willing to work
some time in the office or who would have relocated, but we allowed to work
remotely (this is over several companies). The folks that absolutely demand
working remotely don't carry themselves well in public channels, which is
likely the root of my stereotyping.

------
djb_hackernews
To add an anecdote:

I was recently contacted by a recruiter helping out a company in an area in
the south that wasn't in a very hot market talent wise. So they were expanding
their search for senior level developers for a 6mo contract. A few emails were
sent back and forth, and obviously the recruiter always wanted to know my
rate, but I kept deferring until I had more info...

eventually it seemed like a pretty good fit, so I gave them an hourly rate I'd
expect that was reasonable - It was about market for my area (DC) and below
some of my other contracting rates.

I got a curt response from the recruiter explaining the company was only
offering an amount that was over 30% below my quote (A pretty good tell this
is a recruiter I don't want to work with anyway). The message mentioned my
rate was quite high for someone not on site. (It was very clear this was for a
remote position, and I would not be relocating)

If you are going to hire remote, does it make sense to expect a discount?
Especially when you are reaching in to more expensive markets?

~~~
joshcrews
A complicating factor is the recruiter's take on top of your rate. I'm making
up numbers, but lets say your rate is $100, and the recruiter's % is 40% of
your rate. Now the company sees $140/hr.

The company may not object to your rate if they found you directly, but your
rate + recruiters expense is more than they were expecting. But all you hear
is, "hey bud, that's a little too high of a rate, isn't it? Why don't you come
on down to something a bit more conservative" And your rate isn't too high,
its just too high when he adds in his cut.

------
lrobb
I've telecommuted for over 10 years now... Last year I was given the
"opportunity" to look for a new gig, and was horrified to find that the vast,
vast majority of software companies are still stuck in a manufacturing
mindset: show up at the factory, do your 8 hours (or 10). Even worse are the
"local candidates only" job posts.

------
hkarthik
I work in a completely distributed team and I think it works well if you have
the right demographic in your team. The one problem I see with the model, is
that it does little for junior developers or interns that are just starting
out.

There's a minimum bar that a developer has to reach before I think they can
work in a distributed team. Folks just starting out need a bit more hands on
mentoring and the distributed model makes that difficult.

I wouldn't hire an intern, or fresh college graduate into a distributed team.
I think the issues around the talent crunch have something to do with not
enough people in the field. Going distributed solves the problem of needing
experienced folks, but it does little for newly minted developers.

~~~
devs1010
Agreed. I worked in a remote-ish situation early on where the people were in
town but didn't have an office so I worked from home most of the time. I feel
I've definitely progressed a lot more now since I started working in an
office, but then there is a point again where you can get enough experience to
where working remotely may be the better option, but starting out I agree its
not necessarily the best option.

------
sgdesign
I can't agree enough with this. I help startups find designers through my site
(<http://folyo.me>), and it's been all but impossible to find great designers
available in the bay area.

On the other hand, the rest of the country (and the world) has tons of really
good designers, some of which struggle to find work.

So far the companies who have gone the remote route haven't regretted it, and
they've been able to avoid spending countless hours searching for a local
hire.

~~~
gexla
Great designers having problems finding work...

That's the unfortunate part of freelancing. The most amazing developers might
be horrible with the marketing / business end.

~~~
da02
It might also have to do with how creative people are more likely to feel
dirty fulfilling the wishes of the boss when they are wrong. Which might
explain why your local restaurant would overpay for Flash heavy websites on
eLance rather than hire someone on Folyo.me.

------
gyardley
I've got a question for DHH - or really, anyone with a widely-distributed
team: how do you deal with the administrative overhead of hiring employees in
a lot of different jurisdictions?

I've used Ambrose in the past, and they could handle the administrivia
associated with employees in most American states, but they were no use
internationally. And 'professional employer organizations' like Ambrose often
only work with organizations that are already doing well (or well-funded).

~~~
tibbon
When I've had to handle a large, distributed and international team I mainly
just had almost everyone on as a contractor. This wasn't us trying to deprive
them of benefits or underpay them, but really was what most of them wanted.
They wanted flexibility and the ability to work in a somewhat non-dedicated
way. Worked for everyone involved since the paperwork was really minimal.

~~~
marquis
Be careful doing this, as there are official rules whether someone is a
contractor or not, not just 'because I call myself one'. You can in theory get
hit for payroll taxes.

[http://www.irs.gov/businesses/small/article/0,,id=99921,00.h...](http://www.irs.gov/businesses/small/article/0,,id=99921,00.html)

~~~
christkv
I'm not sure this applies for international contractors though but the same
applies for the european countries and it's harsher. In Spain if you have
worked for more than 6 months on a contract for 1 employer you are considered
an employee.

It comes down to social security payments :). A contractor pays less than a
full-time one and the government looks upon contracting like this as a way of
dodging paying the correct social security for an employee.

Leads to a horrible environment where people get fired every 6 months and then
recontracted under another work title.

~~~
marquis
As an international contractor you are best to set yourself up as a company or
self-trader and invoice appropriately. You should then be subject to normal
international outsourcing behaviour in regards to the paying company's tax.

------
systemizer
I'm going to have to disagree. As a developer, I would highly prefer having my
co-developers in the same building, if not the same room with me. It's about
having that certain "hum" of energy in your environment that you can only
achieve if you are immersed in it yourself. It's also a cultural experience to
be sharing the same environment with your peers.

More importantly, I don't want have to abide by some API to interact with
another developer. Hell, if I want to play toss with a nerf football with one
of the other developers, I should be able to do that (of course, if the want
is mutual). Which technology will allow me to do that?

I worked at a startup last summer. The developers and I would hangout outside
of the "war" room, playing call of duty, grabbing some beers, or whatever
sparked our interest. The times outside the workplace are often the most
memorable in a job.

~~~
shazamjad
I will add to this - I worked for a company last year where the majority of
projects were outsourced to a team setup in Egypt, and I spent more time
debugging their work than it would've taken me to do it myself.

Not to mention how off the spec most of their work was and our clients were
always left dissatisfied. I think that's part of the reason I left within a
few months.

Remote working is amazing provided you can get a solid, self motivated person
or team who are on the same wave length as you - but it's incredibly tough.

~~~
plinkplonk
"I will add to this - I worked for a company last year where the majority of
projects were outsourced to a team setup in Egypt, and I spent more time
debugging their work than it would've taken me to do it myself."

To be fair, DHH isn't talking about outsourcing to dumb but cheaper devs. He
is talking about hiring _really good people_ , who won't or can't move to San
Fransisco (or wherever), and probably cost as much or close as devs in SF. I
doubt 37 Signals hires remote workers who check in code that has to be
debugged before it works.

iow I am saying, respond to what DHH actually said.

~~~
gexla
The original article is talking about hiring A players remotely vs hiring B
players locally. In your Egypt example, you are talking about something
different, hiring C players remotely.

~~~
sgdesign
That's a great way to sum up the issue.

------
lxt
I agree 100% with this blog post.

I have worked remotely for Mozilla for the last four years: first as a senior
dev, now as an engineering manager with a team of currently 7 people. My team
is located in Africa, Europe, and North America, and we work closely with ops
people located in the US and Asia (Singapore, India), as well as people in
other parts of the company in a number of other timezones. I believe more than
half of the Mozilla workforce is remote from an office. This includes places
like Portland OR which has more than 10 Mozillians, but no office.

Some riders: \- We work _hard_ at being remote friendly. We all spend all day
in IRC. We put people's timezones in the phonebook. We make extensive use of
IRC, the phone, Skype, teleconferences, Vidyo, email, Bugzilla, wikis, and
etherpad. We get together throughout the year - sometimes a couple of people,
sometimes just our team, sometimes our group, sometimes the whole company,
sometimes at an office, sometimes at a brewpub or cafe, sometimes at a
conference. \- We actively screen for remote suitability when interviewing
people who want to be remote. \- If people are in a country where we have an
office they are employees, if they are in a country where we don't they are FT
contractors ("geo-contractors") but we treat them like employees in every
other respect. I think it makes life a touch harder for our admin staff, but
they are awesome and take it in stride.

I've been doing this for a while, it's the best thing I've ever done, and my
team kicks butt.

------
Mz
I don't have experience with working remotely but I do have experience with
taking classes online. My experience has been that they expected more out of
you as an online student, that there was no "credit" given for "face time" (ie
"warming a seat"). It's easy to fall out of touch with what employees are
really doing right in the same room, especially with knowledge workers. We
often have no real idea what is going on at the computer screen in the next
cubicle, to a degree I find rather shocking. I kind of feel like people have
their head in the sand if they think simply being in the same room as a
knowledge worker somehow gives them an idea of what they are up to.

Edit: I don't have first hand experience working remotely myself. I do have
coworkers who work remotely.

~~~
kaybe
Instead of surfing the net when I have a low I look around to find someone in
a similar position and make them tell me stuff about what they are doing. It
can help us both. :)

------
ROFISH
I always question the use of Skype. It's great for video chat, but it requires
somebody to call and somebody to host, and it gets real nasty when you need to
get work done and just want to talk for like two minutes. I recommend getting
up a Mumble server. It's voice chat, but anybody can join in at anytime, or go
to a private "room" to talk amongst themselves.

~~~
jebblue
Mumble is in the Ubuntu repositories, client and server that's cool and it's
encrypted. I'll have to keep that one in mind. Thanks.

------
mylons
I also wish current employers were more willing to do this. I've had managers
in the past negotiate their own remote employment, but REFUSE all requests
from their underlings to do something similar.

~~~
nvk
Yes, this is a very common practice.

------
donky_cong
If you are preaching something like this, atleast have the decency to go all
the way.

Why are all the examples of "remote" in US/UK ? There are 7 billion other
people. And I can assure you there are amazing Indian, Japaneese, German,
Russian, Finninsh and Australian devs.

Thats the real big pool of talent. (And you can get some prime developers at
lower than $100K/year).

~~~
dhh
Dude, this whole software business thing at 37signals got started with me in
Denmark.

Also, we just hired someone from Russia.

What makes it harder is that for this to work, you need timezone overlap. I
now live in Spain half the year, but it does require me to work from 1pm to
9pm. I enjoy it like that and it fits well with the Spanish lifestyle, but it
doesn't work for everyone.

~~~
hugs
A few years ago, why did you move from Denmark to the HQ in Chicago? Could you
have just stayed in Denmark?

~~~
dhh
Because I like living in the US better than living in Denmark.

I've recently moved to Spain for part of the year because I like 65F and Sunny
better than the Chicago Winter.

Neither moves had anything to do with work per se. (Except that I'm a better
worker when I live where I want to live)

~~~
JoeDeveloper
Except that I'm a better worker when I live where I want to live.

I can't agree with this enough.

The lack of structural violence is also a huge win, being able to hack at 24+
hour stretches without being told that they are locking up now, or obligations
to go for a Wed, Thurs, Friday beer etc. can also be conducive to high levels
of productivity.

------
gexla
Colo workspaces are a great way to get the best of both worlds. Working
remotely but still being in an office environment with other developers. Not
everyone has this option but I find it's a great way to switch things up when
you need to get out of the home.

I imagine good remote workers could also be difficult to find, simply because
many of them already likely have a ton of work coming in. Running your own
show also gives you a lot more flexibility, so taking on an actual job can be
a bit of a sacrifice.

------
nvk
Me and my Co-Founder decided that since we don't like to be in offices,
everyone that works for us (Ripe Apps Inc.) don't have to either.

We've let go of the the physical space, we collaborate by Skype, IRC, e-Mail,
Google Docs, DropBox, once every week or two over burgers/lunch, and if we
need to convey something that is not coming trough the line with contractors
we meet at a cafe for an afternoon.

We also don't hire manager, we only deal with people who can self manage.

~~~
devs1010
I worked for a company like this, honestly I didn't really like it, at least
the meeting in cafe's part, personally I find the comforts of an office
superior in this regard as a conference room with no distractions and a
projector beats sitting in a noisy cafe huddled around a laptop. I'm not
against the not having an office idea completely but I think that if I were to
be involved in something like this again I would want them to at least have
one of those "shared spaces" offices where you can go in sometimes to work
collaboratively and have access to conference rooms, etc.

~~~
billswift
One thing that can work, if you only need a day here and there, is to get a
motel room to use as a meeting room/conference room. Even fewer distractions
than an office and you don't have to pay for it when you aren't using it. (We
did this a few times in the 1980s/90s when I was working for an architect,
when we needed a meeting place near a job.)

~~~
devs1010
Nowadays I think most cities they have spaces that can be rented on an hourly
basis that are suited for this purpose (beyond hotel rooms)

------
tirrellp
I've mentioned this before, and its interesting to see it being pointed out by
more than just me. <http://news.ycombinator.com/item?id=2813915>

Some options for the talent crunch are: 1\. Grow your own talent from
inexperience 2\. Pay for relocation 3\. Entertain telecommuting. 4\. Build a
satellite office in an area where there seems to be a mass of talent. Bay area
companies take note, San Diego is absolutely crawling with unemployed talent.

~~~
zem
I wish more companies were willing to consider option 1. it does mean a few
months of less-than-ideally-productive time while they ramp up, and a
corresponding time commitment on the part of the senior devs to handhold them
while they learn, but you get some very passionate and dedicated employees out
of it. also, they don't have any bad habits they're attached to (:

------
nate
This post from DHH misses one bit. This hiring remote workers works for them,
(as it's worked for me/us at Inkling and Cityposh) because we also have
another tenant to our hiring practices. We hire people who can manage
themselves. 37signals calls this "managers of one"
<http://37signals.com/svn/posts/1430-hire-managers-of-one>.

I like to think of it as hiring employees to boss me around
[http://blog.inklingmarkets.com/2009/10/hire-employees-to-
bos...](http://blog.inklingmarkets.com/2009/10/hire-employees-to-boss-you-
around.html)

The companies complaining about remote workers not working for them is also
because they are surrounded with people that can't do their work unless they
have constant group think meetings so no one can possibly be blamed for the
work/decisions being made.

------
PanMan
I think remote work can work well for a well defined problem. However, for
small startups often the product is changing while it's being developed. Also
the energy and team feeling are different when working remotely or in the same
office. It is for a reason Y Combinator wants everybody to join them in the
same office.

------
rglover
I'm glad to see this being discussed. As a designer/front-end dev, I find
working remotely to be personally rewarding and immensely productive. Going to
an office all day is not fun and with all of the distractions, it makes work
even more difficult. Being remote removes these barriers. This is great
because when you need to get a project done, you can have hours of
uninterrupted time and knock stuff out.

There is one major caveat, though, in that IT'S NOT FOR EVERYONE. Whether it
be that you thrive in a communal environment, work better in teams, or just
can't get your work done without being babysat, some people just don't cut it.

For companies, it's an excellent way to diversify your team and build an
international presence.

It's 2012. We have the Internet, phones, and airplanes (if an office visit is
truly necessary). Get into it.

------
mechanical_fish
You can write code remotely (probably even better than you would in an office)
and you can deliver and debug and do maintenance remotely, but it's very hard
to do politics remotely. When it comes to convincing people, the person or
team on the scene has a built-in advantage over the disembodied person on the
phone or the net. This is just human nature. Monkeys gotta monkey.

Yes, yes, it used to be that the person on the scene had a much bigger
advantage, and now thanks to our awesome telepresence technology the advantage
is smaller than it used to be. Whatever. The advantage is still there. Blame
time zones, blame the limited field-of-view of cameras, blame subtle sounds
that only locals can hear, blame the fact that it's easier to establish
rapport by talking about the weather when everyone _is experiencing the same
weather_ , blame out-of-band signaling of every sort, from sharing the same
pizza at lunch to sharing the same hallways and parking lots to sharing the
same air.

You can fight this by deliberately leveling the playing field: Force everyone
to be remote most of the time, from day one. 37signals built their company
this way. (And they also attracted and hired excellent writers; that's not a
coincidence.) But if you don't foster that culture from day one it is _hard_
to bolt on after the fact. Particularly because the culture of written
communication and the level of writing skill needed to make remote interaction
work doesn't arise overnight and doesn't grow on trees. You need to _practice_
being an effective distributed organization.

And the problems with being remote won't always be obvious - indeed, as I said
up front, the code may well be better, because offices are such unproductive
workspaces. But the problems will arise when politics arise, as they do in any
group larger than a given size. It will be harder to move up or around in the
organization. It will be harder to sell ideas to co-workers from other
departments, the ones who don't work with you everyday, because the social
grooming is so difficult.

It's not just because of tax law that most remote workers tend to be
contractors, and that so many contractors dream of starting small product
businesses. The culture of business-to-business contracting is better adapted
to working in writing and over distances, because there's several hundred
years of cultural experience to draw upon: We have contracts, we have lawyers,
we put stuff in writing. Selling a product to someone through the mail is even
more formalized: People expect to read brochures, to get the product in a
circumscribed package, to sign a contract and pay by the hour before putting
in a tech support ticket. Contrast all this with the employee-employee
relationship, which tends to be egalitarian and communal and rely a lot on
subtle mutual teambuilding and backscratching that are difficult to
virtualize.

------
conformal
funny enough we are based in chicago and do the same thing: hire people who
work strictly on remote.

almost everyone gets along fine on remote, but sometimes management of remote
employees is a serious pain. it's much easier to shop for talent and get the
best devs and sysadmins vs people in the area.

------
venturebros
I love how Automattic runs <http://automattic.com/work-with-us/>.

I have been sifting through a lot of these posts and I think everyone is
forgetting not everybody is a Software Engineer. There are other components to
a business too. I can say as a front-end developer I certainly do not need to
be tied to a desk 8 hours a day every single day to code up a mockup. Yet when
ever I see a job I would be perfect for I get told they do not do remote work.

------
timedoctor
I'm basing my entire business around this idea of hiring people remotely, and
now have a new startup staff.com which is about hiring people from any
location. LOTS of problems to be solved with remove hiring and remote working:

1\. Are the team actually working each day (many people need the discipline of
coming into the office) 2\. Are they moonlighting with multiple companies at
the same time 3\. How do you get a sense that you are really part of one team,
a feeling of connection 4\. Communication issues related to working remotely
5\. Hiring effectively without actually meeting in person 6\. Maintaining a
sense of team and having people feel like they are part of a team (even when
not meeting in person). This is very important as part of maintaining a sense
of loyalty and connection with team members.

My personal experience in managing over 50 staff members in 9 countries is
that all of these problems CAN be solved, but it takes work. My ideal
situation is to meet 4 times per year in person, but sometimes this is
difficult when staff are really in completely different locations.

------
JoeDeveloper
Apropos:

A few days ago a discussion about just this topic was started at
[http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=...](http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=86567916&gid=2204708)

A recent poll was started at:
[http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_...](http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_panel_id=1&_ch_app_id=1900&_applicationId=1900&_ownerId=0&appParams={%22section%22:%22results%22,%22poll_id%22:159960}&trk=email-
polls-title-results)

Where the vast majority of respondents said that they value work experience
over location - but from my reading it just highlights how there seems to be a
mindset that is blind to the value propositions presented by telecommuting.

Here is a short video on Distributed Agile: 5 DOs and 5 DON'Ts from
assembla.com - having worked there, I find that it works amazingly well.

------
vnchr
"SHUT UP AND USE ALL OUR PRODUCTS"

------
spiredigital
A few takeaways from what I've learned after 4 years of experimentation with
outsourcing / hiring remotely in my own full-time online business:

\- Turnover can be a problem. I went through 3 part-time workers in the course
of 6 months because they moved on to bigger, better projects. The hourly rate
was great, but the re-training and inconvenience was a nightmare. When my
third iterations employee for the position ended up being a rock-star, I
worked HARD to make her feel like part of the team, encourage her, and gave
occasional bonuses even though she was an hourly, outsourced worked. She's
been with me for 2.5 years.

\- Hiring full-time, salaried employees in your time zone is EXPENSIVE, but
eventually necessary in you want to free-up your time, grow the business and
maintain quality. For a while, I really put off hiring a full-time operations
manager, instead trying to work with professional, part-time remotes in a time
zone 7 hours ahead. I saved a little money but dealt with tons of logistical
problems. If your employees are solely building a product, this might not be
an issue. But if they have any time of consistant employee communication, time
zone shifts can get complicated.

I finally bit the bullet and hired a full-time, local operations manager
despite the expense... ...and it has been worth it. I was able to interview
face-to-face, which I think is important for critical positions, and ended up
with a guy who I 100% trust with the operations of my company. I spent 7
months last year traveling internationally, and was often out-of-touch and 12+
hours ahead of my business and customers. Without a local, full-time employee
to manage the business for me that I trusted, there's no way I could have done
that. I possibly could have found someone remotely to do this, but I would
have had to spend a LOT of face time with them for training, and to feel
comfortable at a level where I'd leave for an extended period.

In summary, I've found a combination of remote and local employees really
works best. Remote outsourcing offers a LOT of great talent and potential, but
it's no panacea; there are plenty of logistical issues to be considered. But
with the right planning and local/remote diversification, it can be a great
tool for growing your business.

------
danmaz74
The reality I know is that there is much more work to do than what only the
really talented, self managing, committed developers can do. So we (I mean
"society") also need to be able to put the not-so-talented, and/or not-so-
committed, and/or not-self-managing developers in the conditions to be
productive - which isn't working alone from home.

So, I completely agree that remote work should be leveraged much more often,
especially as remote collaboration technologies are getting better and better,
but this won't be the one-size-fits-all solution. Just like the traditional
9-5 office isn't.

------
hello_moto
But DHH, BigCos aren't 37Signals...

... then he went on a rebuttal saying that BigCos are wrong model and
everybody should be like 37Signals, small, lean, mean, and can declare
bankruptcy in the face of a huge lawsuit.

That's the key. BigCos operate at a different level set of requirements.

Here's one example: scrapping content from websites. When you're RIM, you're a
target of lawsuits if you crawl and scrap people's website for your Blackberry
News Reader. When you're Flipboard, people wouldn't know/care as of now (at
least until they're big enough to milk cash out of them).

~~~
dhh
Plenty of BigCos have teams who work remotely. Often the teams that work on
the most interesting, new stuff (because they tend to be smaller and more
agile than the folks manning the sausage factory).

~~~
jebblue
This describes me for the past several years. It makes it challenging when
dealing with managers who assume all humans must want to climb someone's
ladder but remote work is fulfilling nonetheless.

------
casca
Hiring is hard. Hiring someone you've never met is a whole lot harder. Someone
you know, have worked with before or from a personal recommendation? Sure.
Some guy who you've assessed can pass a coding test? Not so much. As I'm sure
many here have experiences, a great way to destroy a team is to get the wrong
person. Remote workers should certainly be an option. But identifying that
hiring local people is hard as "whining" is just high wankery.

~~~
sgdesign
The big advantage of remote work is that you can easily try out someone as a
freelancer first before bringing them on full-time.

~~~
lrobb
I've asked this of recruiters before... Instead of flying me in to do a full
day of white-board technical interviews, why not just give me a short project
and see what I produce?

It's mind-boggling how broken our hiring practices are, yet how easily it
could all be fixed.

~~~
objclxt
I have done this before, with some success - however, I think you might be
missing the point slightly of a white-board interview. Yes, one purpose is to
assess your coding ability, which you're right to say a short project could
achieve.

Another is to assess your ability to brainstorm and talk people through your
ideas. If it was about coding ability alone you wouldn't need the whiteboard -
you could just be sat in front of a computer. I can think of several people
I've interviewed who have produced very good code, but have lacked the social
skills required to integrate with a large team - even working remotely. So I
don't think the solution is quite as easy as you think.

~~~
jebblue
I do really badly when placed in front of a white board and am asked to code.
This is a ridiculous concept, imaging taking Anthony Bourdain into a room and
telling them to use the whiteboard to describe a tough cooking challenge.

------
quesera
As usual, I think 37S is mostly correct here, but they've omitted some
crucially important qualifiers. I often wonder whether this is genuine
myopia/naïveté, or whether they are crafting a subtext that serves their
larger PR and marketing goals (i.e. obviously this can't work everywhere and
in all cases, but look how close our realities are to our idealized case! Oh
and by the way sign up for our services because they will solve your
problems!).

Anyway, I've worked on and managed distributed teams, spread over 14hrs of
timezones. What I've learned is:

You need good people. They need to take absolute responsibility for their
work, and they need to be highly cooperative and reliably honest. They need to
care.

You need the _right_ good people. They need to be professionally fulfilled by
the high quality of their work as well as the team's work. They need enough
adulthood or experience to do all the little things to compensate for the
reduced bandwidth, like spending an extra 30 seconds on commit messages or
ticket updates. They need to make the extra effort, sometimes.

They need to get their human quota of social interaction, status affirmation,
deep bonding, etc elsewhere. They need to want to get stuff done at work and
have another healthy center of life gravity somewhere else. It's probable and
hopeful that the team will all become friends, but there's just too much drama
and/or inefficiency if the team constitutes a member's whole social circle.

You need need a strong and coherent plan, especially around product vision and
strategy. If things are still very fluxy or in-pivot, and you need everyone to
be highly cooperatively creative, then there's no substitute for getting
everyone together and eliminating all of the communications friction and
overhead. Once the plan is internalized, you can disperse. Minor perturbations
can be handled remotely. Major ones suggest reconvention.

You need good leadership. This can be de facto or even cooperative, but
someone needs to take organizational and facilitating roles, and the rest of
the team needs to have a focal point. Obviously if you are a team under some
umbrella of org chart, this needs to be the titular manager, and he or she has
to manage upwardly even more actively than within.

...

The absolute hardest part is hiring those good, right people. The technology
is 100% there (and I think the 37S suite is OK but generally end up falling
back to lighter weight options).

Remote work attracts the highly professional and the highly useless. If you're
hiring people without a trusted recommendation, differentiating between the
two can be difficult. You're looking for people who are talented and
scrupulously honest, especially about weaknesses. People who are lying to you
are often lying to themselves, and people who are lying to themselves are
always lying to you. There's no place for that in a distributed team.

It's very important to cut quickly when you fail with a hire. There's no shame
in not being the right person for a job, but it's the hiring manager's duty to
take improvement very very seriously. The highly professional _will not
tolerate_ bad teammates under these special-needs circumstances, nor the bad
management that permits them.

When remote teams fail, it's because management and hiring have failed. It's
not so much harder as different -- but different is hard, for some styles of
managers.

------
latch
In my experience the real problem is that people are much worse at
hiring/interviewing than they think they are. Their process is broken, their
questions are weird and the amount of time they are willing to dedicate to it
isn't sufficient.

Hiring isn't easy, it does get easier with experience, provided you actually
look at it as a skill you can/need to improve (which the vaste majority of
people don't).

~~~
jt2190
"people are much worse at hiring/interviewing than they think they are."

Yes. What needs to be asked is: "Are you ready to hire remote workers?" with a
laundry list of items, such as:

    
    
      * Do you know how to communicate effectively with remote workers?
      * Do your team members know how to communicate effectively with remote workers?
      * How will you correct things when your team members forget to include the remote 
        members on meeting invitations, emails, etc?
      * Does the remote worker know how to communicate effectively?
      * Does the company have a way of supporting remote workers? (Network, hardware 
        and software support.)
      * etc.
    

My point is that making effective use of remote workers is much easier said
than done.

------
dboyd
What is gained in hiring remote has a cost. A significant percentage of human
communication is non-verbal[1].

When hiring remote, make sure to put "communication skills" near the top of
the requirements, since any hire is going to have to make up for the loss of
presence.

[1] <http://en.wikipedia.org/wiki/Body_language>

------
rob41
I am still amazed with how few design jobs are available remotely. I hope more
companies start using distributed teams.

------
amac
Remote is fine right, if that's your choice in business. Surely though, the
joy is in building something with others - products, services, cultures etc
regardless of success or failure.

If your business is your life's work, I can't see any greater pleasure than
sharing it with others.

------
Badkangar00
funny, I use IM with someone that sits next to me.

------
unfletch
Does anyone have pointers to good resources for workers looking for remote
positions?

~~~
JoeDeveloper
Ditto that. There are sites like freelancer.com, elance.com etc - but there is
considerable overhead involved in vying for short-term gigs and negotiating
terms etc.

I worked those sites for about 2 years and it was actually very gratifying and
instructive - I built everything from twitter spiders to usenet picture google
widgets and customized more e-commerce setups than I care to think about. It
is definitely worth doing to test your mettle against players from all over
the world, but ultimately it becomes a grind and a chore, there is a huge long
tail of "5 pages + contact form" and "penny auction" clones that offers little
opportunity for personal growth - especially at the race to the bottom prices
that is the norm.

unfletch, if you are into Rails then I know that Assembla.com is always
looking for fresh talent.

------
parbo
The only silver bullet is to get a number of people together who are
passionate and skilled. The assignment really doesn't matter, as long as it
spurs an emotion in the team.

------
loceng
It's pushed and promoted as what you need to do in order to get investment
because VCs feel there's less risk that way.

I guess the alternative is you don't get your product built.

------
drcoopster
As a remote worker, I can't agree more with the article.

I've heard this many times: "You're a great candidate for this job, but right
now we're looking for people who are local."

------
ntomkin
> 37signals has people from such distinct tech hubs as Fenwick (Canada)...

I hate strong statements that have the _out_ of being tongue-in-cheek. Fenwick
is not any type of _tech hub_. It's a high rural area with the closest mid-
sized city (St. Catharines) about 50 km away.

~~~
dhh
Dude, that was ironic. None of those places are tech hubs. That's the joke :).

------
JoeDeveloper
I have been working remotely for the past ~4 years and it has proven to be one
of the most productive approaches for me.

I find that meeting many of the "challenges" of managing distributed teams end
up being worth much more than just the ability to hire quicker and from a
broader pool.

Distributed teams and asynchronous communication ( email, wiki, tickets ( and
comments to them )) coupled with knowledge repositories ( such as internal
stackoverflow clones etc ) allow formal, persistant capture and presentation
of best-practices within the team, without a large upfront cost and
'documentation rot'.

Having to verbally explain something to each new member in turn strikes me as
much less efficient than being able to point to written documentation and a
centralized place to request information or clarification.

It also helps ensure that goals and approaches are actually captured clearly,
rather than assumed based on nodding heads.

Tools like assembla.com ( full disclosure, I have done work for them ) and
other team / project management offerings with integrated source control also
serves to capture raw metrics to allow better estimations going forwards and
better pinpointing of areas that need strengthening.

It is often said that adding new members to an existing project can extend the
duration of the project, as experienced developers need to spend time on
getting others up to speed than actually working on the deliverables
themselves, by building this documentation into the process as a whole that
cost can be amortized, shared across the team and contribute to knowledge
transfer even among high-value members.

By embracing ticket based development, it means that people can continue
working on something else if they come across blockers or are waiting on
feedback for whatever they were working with before. It also means that
developers can choose tasks that they find compelling or have otherwise non-
obvious synergies with their background / recent tasks.

While working in that kind of environment I manage 55+ productive hours / week
pretty easily, and with pleasure - as have many of the people that I have
worked with, by virtue of minimal administrative overhead and being able to
'stay in the flow' working on tasks in a self-directed manner within the
context of goals for a particular iteration.

Capturing the value-add of developers via tickets ( though obviously imperfect
), tends to minimize social manipulation of managers in terms of who did what.
The persistent record of ticket comments, code review input, code commits, and
other exchanges works to increase transparency - accountability and value can
have a firmer ground to be evaluated.

The biggest problem that I find with preferring to work as a telecommuter is
how few companies seem to be open to hiring under those conditions. I have had
offers where the only sticking point was that I needed to relocate to New
York, or California, or Amsterdam, or Brisbane, or Singapore .. etc. They are
all great places, or well, fine places at least, but I am pretty content being
surrounded by rice fields and having chanting monks strolling by now and then.

If you could use a telecommuting fullstack / JS Engineer - let me know :)

------
shareme
I have a question...

I was introduced to a multi-disciplined and multi-cultural environment early
in my college studies and on top of it it had a remote component in the mid
1990s.

I found that the skills in communication and people skills to converse with
multiple areas of university study and cultures across many human
languages,etc was the skills I needed to remote effectively both as an
individual worker and as a manager.

Am I missing something or have no one else discover those aspects yet?

------
ultimatewarrior
The social dynamics of teams physically co-located can create powerful
momentum. Serendipity is about 20 times harder to do over a telephone.

