Stop whining and start hiring remote workers | Hacker News Reader

Stop whining and start hiring remote workers

37signals.com

481 pointsjodosha234 comments

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

> smiling customers = satisfaction

I think they are right about this one. What's your problem with this?

Often the customers aren't the end users.

I suppose a job can't always be considered to be done well, just because the customer is provided with what they felt they needed. Sometimes the customer is asking for the wrong thing in the first place.

While I can see the reasoning behind this mentality, I have a hard time supporting it unequivocally.

Too many times I've come across what really feels like engineer / developer arrogance vis a vis their end users. The notion that the customer "doesn't know what's good for them" has a bizarrely patronizing air to it.

If the customer is happy, then the product has done it's job. Doesn't mean it can't be improved - but perfection comes after the customer has quit bitching.

Allow me to add to your list.

people who makes incomplete and faulty lists of what good leadership consists of = someone we should take serious

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.

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.

>coders exist to increase complexity and guarantee their own necessity

Holds true in more cases than not, at least in my experience in the enterprise. "Writing your own X" when off-the-shelf solution is available is a dominant example of this.

In many companies the same rigid structures that allow them to operate with average and below-population-average employees reward those who can game them andreduce their own output to the lowest levels toleraed by the structure.

I have freed many good programmers from this trap, but not nearly enough and many remain to be saved.

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.

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.

I don't have much experience with managers because I freelance now and I've never worked at a company with more than about 80 or 100 people.

So this is a real question and not snark... Assuming large companies continue to exist, how do you run one without managers?

If your company is 1000 people do have 10 executives and 990 engineers, customer support, etc. and no managers at all? How does everyone communicate? How do the executives delegate?

Do you need some managers? How many per worker is optimal?

It seems like every large corporation in existence has managers. I can't think of any exceptions. So I'm not sure what an alternative would even look like. Perhaps rotating temporary management structured like jury duty?

I'll probably be downvoted because bashing management is a time honored hacker pastime... But I really am curious. Is it possible to do away with management? Is it desirable?

Oh, you definitely need some managers. I'm not suggesting that we should do away with them completely :-)

In the past (i.e. prior to what we sometimes call "the information age") it was a perfectly reasonable thing to have a very tall pyramid shaped hierarchy within a company. This was because the people at the bottom of the hierarchy needed to be told what to do and how - i.e. the manager was the "expert" at some task.

Nowadays people at the bottom of the hierarchy (especially in technology) tend to know exactly how to do their jobs - in fact they know much more than their manager about their own specialty. This has led (in savvy organisations, at least) to much flatter hierarchies.

> Do you need some managers? How many per worker is optimal?

http://en.wikipedia.org/wiki/Span_of_control

"In the hierarchical business organization of some time in the past it was not uncommon to see average spans of 1 to 4 or even less. That is, one manager supervised four employees on average. In the 1980s corporate leaders flattened many organizational structures causing average spans to move closer to 1 to 10. That was made possible primarily by the development of inexpensive information technology. As information technology was developed capable of easing many middle manager tasks – tasks like collecting, manipulating and presenting operational information – upper managers found they could hire fewer middle managers to do more work managing more subordinates for less money."

Do you really think that managers 80 years ago knew more about task X than the people they managed who did task X every day? I think software/info people like to think our situation is different, but I don't suspect it was all that different in the past. What may be different is that today we have the ability to get a lot more information at our disposal about what's going on in a company than people did 100 years ago.

I think technology has allowed people at the bottom of the pyramid to "own" larger pieces of responsibility within a company, thus allowing them to operate much more independently.

In the past this really wasn't the case. An entire discipline called "Scientific Management" sprung up to explain why workers should be treated almost like animals by management:

http://en.wikipedia.org/wiki/Scientific_management#Taylor.27...

I think this knowledge inversion where the "individual contributors" know more (about the job) than the manager is why many managers do not like agile methodologies like Scrum. Developers are "seizing the means of production". ;)

When developers can work directly with product owners and track their progress, the traditional manager loses. I'm not sure how a developer-driven team might handle HR issues though.

I'm not sure how a developer-driven team might handle HR issues though

There is a nuance here that is being missed, there is management and there is administration, management is authority and administration is coordination among contributors to keep the production line running. Many organizations mistake the two for the same roles as such they give to many administrators authority and make them managers. When many organizations could flatten their management hierarchy and create more administrative roles. HR is a good example of a business function that can be done via administration and not authority. The funny part is when you make people administrators they see themselves more like contributors and become less threatened by efficiency.

Thanks for the clarification. Is the administrator role you describe something like a program manager (PM) or scrum master?

Would you say a "tech lead" is a manager? They have (technical) authority of the product, but not necessarily hiring/firing of other people.

I generally consider leads and architects to be administrators same with project managers, if fact in a good deal of organizations that I have been a part of we did not call them project managers, we called them project coordinators or project liaison which better reflects the role.

You should read some Rands in Repose about the point of the manager job role.

Not every company has this fear. In fact, some large companies are the most progressive with the ability to work remotely and have a huge investment in infrastructure to support this. On the negative side, the employees become more replaceable in the minds of many execs. This includes project and middle managers, so it's not just on the leaf developers.

Agreed : out of sight = out of mind. It's a -lot- easier to think of remote workers as a pure commodity.

Indeed. Some people believe that there's no real productivity gain from all team members being located in the same place. However, one of the (potential) benefits of being located in the same place (as management) is job security. People grow attachments to others.

Plausible if you accept that problems can be broken into separate pieces. Furthermore, measuring/comparing the productivity is non-trivial/impossible.

At my previous employer, a high* level manager (3 levels above me - a leaf node developer), considered it his job to just shield his subordinates from demands/bullshit of those above him.

That's definitely a desirable quality, and leads me to believe he'd have other desirable qualities.

* In reality, middle management, but at the level where strategic decisions are made/strongly influenced.

I look forward the the day when managers catch up and "get it".

So do I, but telling a corporation whose entire culture is built around facetime to "catch up and get it" is, in the general case, like walking up to a flightless bird and waving your arms and shouting "fly, you fool, fly! Don't you realize that the future is in flying? Your cousins that can fly are made of the same parts as you; rearrange them and fly!"

As PG memorably put it:

http://www.paulgraham.com/opensource.html

When I say business can learn from open source, I don't mean any specific business can. I mean business can learn about new conditions the same way a gene pool does. I'm not claiming companies can get smarter, just that dumb ones will die.

I look forward for when techies "get it." IRC and iChat are poor replacements for real human interaction. You can certainly work with them and even be successful with them. But rarely do you approach the same team cohesion you get with in-person facetime.

I think some mix is good. In the office 2-3 days a week and remote the rest of the time. You get a good social balance and then the freedom to work from home.

Incidentally, everyone I've come across that refuses to meet that balance takes on a weird sense of entitlement, illustrating they'd probably be a poor fit anyway. I'm sure there are mitigating circumstances for that, but it is off-putting to the whole idea.

(I don't disagree with this, by the way. The perfect culture that supports the perfect balance of personal and remote interaction is a dream that one aspires to, not a goal one necessarily expects to attain in one's lifetime. ;)

I think the balance really is important. What we've found is that just meeting up 3-5 times a year does the trick for us. We don't need every week.

I have worked for several years on remote teams and have a couple years work experience on a completely local team. In terms of team cohesion I'd say that it has very little to do with colocation, all other things being equal.

Maybe you just haven't worked with a cohesive fully remote team ever?

I certainly haven't. Isn't it incredibly rare?

I wouldn't want to rule that possibility out. But I've worked with people remotely for years and known very little about them. Because our communication is almost solely work-related. Whereas the people I work with locally I know very well. We go out for lunch or for drinks. We chat about random crap in the office. It's not really work, but from it I learn how to work with those people much better.

I'm not doubting you, but can you provide actual examples of how this has resulted in a better work product?

I don't doubt that working together physically has benefits for feeling closer to your coworkers. But I do wonder if that actually has solid bottom line results. And do those results outweigh the benefits of have more talented and productive teammates who are not in the office?

When I'm stepping back to take an objective look at it, "team cohesion" is one of those things that could easily have more value ascribed to it than it actually provides.

Software quality is a notoriously difficult thing to measure. Most studies are conducted over large codebases over several years (IBM & Microsoft have spent a lot of time on this). So, I can't actually prove it.

I have spent a lot of time dealing with it and I know what I'm most comfortable with. And there are always exceptions. I've worked with some really talented remote people -- oddly, they usually end up relocating eventually anyway because they want to. I've also worked with some remote people that really think they're much better than they actually are.

Professionally, the least satisfying jobs for me are the ones where people clock in and clock out. They may be very efficient, but I usually don't learn much from them and there's zero contact after we invariably go onto our next thing.

That's a long-winded way of saying you might be right and objectively team cohesion is overrated -- I really don't know. Subjectively, I found I'm happier that way and I do my best work when satisfied. I do believe it's resulted in higher quality products usually, too. It's often the stuff you don't think about. Like overhearing a couple colleagues discussing something and being able to interject and save them a couple days of frustration. That stuff usually doesn't land in IRC, Basecamp, Skype, or whatever.

But if you've managed to make it work, awesome. It's not my intention to combat the practice if it's working. I just don't like the attitude that anyone opposed to it is some sort of Luddite that sucks at business.

I agree. I've worked for years, sometimes with people that I've never met in person, and had great working relationships while learning very little about their lives. I enjoy having separate work and social lives.

It's funny because this is the antithesis of my experience. A few of my best friends I met through remote teams. One of them I knew for years, and we finally met in person, in Raleigh at the IBM campus. IT was funny because it was a little awkward at first and then we fell into old conversations just like we did on Skype. For every project we have a group chat on Skype and we encourage tech talk and friendly banter. Some of my best friends in the world I have never met in person and I know a good bit of personal detail about them. I have found the experience to be exactly the same as being in a collocated area.

I've actually found IRC can be a helpful addition even when you're physically in the same place. Supports different kinds of discussions that can be useful, especially asynchronous ones, or ones where one or both people find it useful to refer to documentation while chatting.

Agreed. It's a great way to share reddit links.

I have to chuckle at this.

I was an admin in a freenode channel at the time reddit (the one page lisp version) launched.

It initially boomed as it was a great way to share IRC links . . .

I find more the opposite; RL chat is used for fluffy taking-a-break type stuff (take off a few minutes to go the coffee machine and talk about your weekend), while real work starts once everyone gets back to their desk and puts on headphones, using IRC or IM as a unobtrusive backchannel to discuss the stuff we're working on. Works nicely with collaborative document writing in Google Docs as well.

I've tried an "everyone in the same room" approach to collaborative document writing a few times, and that was a disaster for >2 people; online just works much better. Though IRL can sometimes work if it's exactly two people collaborating, who work well together, sharing one keyboard in the style of Extreme Programming (whether on code or prose).

The cohesiveness of a team has little to do with the number of hours they spend in the same room. It's much more related to the composition of the team and how much they share/agree on the purpose of what they are doing.

If you have a bullshit product, no amount of duct tape will hold the team together. On the other hand, a great, world-changing idea is enough to drive the team, keep it cohesive and push its members to levels they wouldn't normally reach.

DHH and his team have a world-changing idea to play with, one that has legs of its own.

If you work with shitty people on a shitty product, you'll have problems locally or remotely, for sure. I'm working on the assumption that people are competent in their job and working on a good product. I still don't buy that a Skype conversation is going to afford more camaraderie than grabbing a beer at lunch or playing a game of ping pong. It's that whole company culture thing. It's the difference between people I work with and those I kick ass with.

You don't need camaraderie - you need a shared purpose and team play. They don't have to be friends - all they need is to respect and trust each other within the limits of their professional activities. Skype conversations have nothing to do with it except, perhaps, helping establish the mutual recognition more easily. Textual communications may become abrasive or be interpreted that way.

I'm happy to agree to disagree. Maybe you're the most successful bastard on the Internet and you have a formula that always works. We're obviously looking for different things and drawing from different experiences.

But as much as it sucks, it almost doesn't matter if you're right. The perception is you're arrogant enough to tell a company or a team how it should be run and if they don't meet your terms, they're doing it wrong and you're going to go do your own thing (this is the royal "you"). I'm exhibiting a mentality you wouldn't want to work for, you're exhibiting a mentality of someone I wouldn't want to work with.

You don't have to agree with any of my rationale, but it may help you and other remoters to understand it. Perhaps it'd help to generate a more compromised view than the "you don't need" responses I usually see. And if it helps with context at all, I've experienced this as a remote employee, a local employee with remote colleagues, and an employer.

Trust me and, more important, trust your team. They are on your side and know what to do. Just encourage them to communicate and they will probably be able to arrange it. They'll do the right thing.

As for me, my current job involves being in the office - the company, the portal branch of a telco, doesn't believe in telecommuting just yet, despite us techies pushing for it. We have lost a couple good people over that issue and it prevented hiring several others I'd love to have on my team. In the past years, I have been involved in several projects that were conducted without physical presence and most of them worked just fine. Keeping everyone on the same page is critical and the least successful ones were when communication was difficult.

I don't know about you but chatting through IRC and Skype is real human interaction to me. The experience is not certainly fake.

With regards to team cohesion, there is no guarantee that you can have achieve that with in-person teams. But the bottom-line here is that do you want to have the best talents working for you or not?

1000% agree.

Taking responsibility is the single hardest quality to find and hire.

    social skills = competence

If you haven't got 'em, I don't care how competent you are. One bad apple can poison an entire team. Developing software is a team sport.

Interestingly I've found this not to be the case, many very good teams of coders (in my experience) have at least one socially awkward person, and still perform very well. (Sometimes it feels like the manager is little more then "socialable" face of the team.)

On the other hand, I find that attitude matters a lot, and one even mildly disgruntled / unmotivated person can really sink a team.

Oh, I agree -- I had taken social skills to mean "plays well with others."

Awkward is just fine. Someone who is mean or lazy is another story.

That's not social skills, that's attitude/decency and work ethic.

Asking coders to increase social skills is asking them to dilute who they are. Like many actors and singers, they lose who they are because they become mixed up with everyone else. Some don't, I don't imagine seeing Johnny Depp schmoozing in a totally social scene, maybe with a few carefully chosen people he trusts and in a quiet location.

Not all programming positions require the same amount of social skills. Some jobs are just fine for the "antisocial software genius" type. Just don't make me work with those guys.

My problem with this is that a lot of programmers/hackers/etc. are pretty good at interacting with each other, but maybe not quite as proficient at interacting with the rest of the populace.

Like for example when you're in the middle of working and someone comes to talk to you, maybe you're just so focused on the problem that you don't realize they're there or you don't want to draw your attention away from the problem, and then that person sees it as disrespect and signs of social awkwardness, while you're just trying to get your job done.

Or if you're in the middle of trying to solve a problem and you ask someone bluntly for something (because you're so focused on the problem) and they take it the wrong way.

I'm not saying that a complete lack of social skills is good either; just maybe that the target of these social skills is the manager, or the sales people, etc. and not the people you're doing all the work with.

One bad apple can poison an entire team.

This is the second time in as many weeks that I've seen these exact words on HN...is it from a specific essay or book?

Not one that I've read.

"One bad apple spoils the bunch" is a common proverb; this is a pretty simple adaptation.

I know. I'm talking about this particular construction as applied to "teams" and in the context of "fit."

This is an unpopular opinion, but I completely disagree.

Great people + perceived activity + being there + lines of code + check marks + social skills = happy customers (usually).

Mediocre people + perceived activity + being there + lines of code + check marks + social skills = waste of time/money (usually).

Great people - (perceived activity + being there + lines of code + check marks + social skills) = happy customers => unicorn scenario (usually).

In an ideal world your great people give you acceptable deadlines and consistently deliver high quality software on time. Then you can ignore subjective metrics like time in office, perceived activity, etc. and everyone is happy. This happens once in a blue moon.

Most of the time when great things happen people happen to be in office, they look like they're working, and they produce a ton of code. Of course correlation is not causation, so forcing people to produce lots of code and be in the office won't necessarily get you good results.

Engineering management is really hard. Please don't trivialize it with feel-good nonsense.

"social skills = competence"

Not to nitpick, but social skills are a form of competence. I know it's not a popular notion in some circles, but communication and the ability to articulate a position is a crucial work skill.

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.

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.

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.

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

Fair point. I over-generalized as well. Just note that I am all in favor of remote work. The trick is reproducing those teams that kick ass. I've seen a lot of configurations, and from what I've seen it usually doesn't work that well. The dream is awesome, and it's the future. It's the damn execution that's tough.

The trick in addressing technology development is to choose the right level of generalization. At some point, you're going to be communicating in leaky abstractions no matter what you say. My overall critique of the article was that the few paragraphs the author provided wasn't deep enough and led to a false impression, not that remote work is somehow unworkable. I could easily post some HN click-bait like "SOPA is the Devil!" and watch the votes climb. What would be tough to do -- and much more useful -- is to provide some kind of analysis where both sides were presented, along with some possible solutions. The first kind of article is a waste of my Saturday morning. The second kind gets me to thinking some. I like that a lot better.

But the Linux community didn't appear overnight. It's grown very slowly over twenty years.

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

Open source projects generally have no deadlines. It's always a work in progress. So, team "magic" isn't really necessary.

Agreed, in fact for non trivial problems almost the opposite is true in my experience. For me at least spontaneous brainstorming meetings are usually a waste of time; I'd much rather take some time alone to think over a problem and put my thoughts on paper or email than coming up with half-baked brainfarts on the spot. Similarly for understanding and evaluating what others have to say, the signal-to-noise ratio of a well thought written paper/email/presentation is more meaningful than a bunch of random ideas thrown around in a meeting.

Once there is a basic plan in place, face time (or phone/IM) are fine to flesh out smaller issues, Q&A, etc.

May I ask what open source products you view as "magic"? Linux is great, but I guess I don't view an OS that has been in development for 20 years and is still mainly constrained to server apps as "magic". And there's very few other open source projects that are used vanilla without some dedicated team sanding down all the rough edges (Unix -> Mac OS, Webkit -> Safari/Chrome, etc)

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

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.

When we developed Basecamp, I had only met Jason and Ryan once. We met zero times during the development phase.

I agree that face-to-face is great, but I also believe that it's vastly overrated as a necessity for "magic" to appear.

Tons of remote teams crank out magic all the time.

For me it's as much about not liking working at home as wanting face to face. I'm too easily distracted at home.

I think that raises the most important point. People are different. I prefer the quiet at home because I can concentrate (I like to talk to people A LOT :) so I spend to much time talking to people at an office). Heading into a 100% remote situation myself I'm still conscious about grabbing a desk in a co-working space for at least 1-2 days a week to socialize a bit and not turn into a hermit.

I do think remote teams can work very well but it has to be built with people who love to work remotely from the start. If you have a mix of people who can't work from home and need social interactions to be productive and combine it with people who want the opposite you are probably going to have problems.

I think it comes down to hiring for one concept or the other.

Then a coworking space could provide you with the separation between home/office that some of us need.

Yes! If I were to be a remote worker, I would make a co-working space a requirement.

I worked 15 months for startup company in California (I am in Toronto Canada) one week on site one week off site so 50% telecommute and that worked exceptionally well product was done and company is highly successful in own field.

Sure you have to make boundaries and it helps if you have office so you can close door and isolate from rest.

Nowdays I try to teach my customers that I will work at least 1-2 days from home. Most times it works but some are not equipped for remote work at all.

It also takes discipline not to slack but that goes for on site worker as well or even more because they get more benefit of doubt being "seen to work"

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

Teams are people, people make really cool things happen regardless where their butt is planted. If cool things aren't happening whether they are in the same room or not might be an indication that you're building the wrong product or service. If you trust them, ask them what they think about what they are supposed to be working on.

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

For how long? Do you come back in 3 hours like Dilbert's boss wondering if the product is built yet?

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

This seems to imply that remote teams don't interact with each other as much. I've found in my experience that pair programming on a remote team is actually a lot more important than locally precisely because it enables this kind of "magic". If you've got the right (free) tools, it's easy to set up an environment where you spend all your time on voip collaborating directly with teammates over SSH and tmux.

Sure you don't see the other guy's face and can't have lunch with him (which is why as dhh mentions below that periodic team summits are also important) but the claim that you can't have the same level of focused communication is silly. There will be less cross-pair communication obviously, but it's easy enough to rotate up the pairs.

I reluctantly have to agree with you. I have worked from home for the last 2+ years, and at first thought it was the greatest thing ever. Next month I'm taking a new job where I will be going to an office again. I'm actually excited about going to an office and interacting with my peers.

IMHO the key is the team and the employer. At my current company software development is a side item that mostly looked on as a necessary evil. In general I don't want to interact with anyone at the office. The new company is a small startup software company with lots of smart software people. The excitement of building cool things feels great, and is something that I think is hard to get across remotely.

I think you're behind the technology curve here. The giveaway was 'even with phone or video conversations"

No remote team need be use phones - there are now headset collaboration tools that are lightyears more effective for erasing the distance bias and making remote teams work almost as if they were in the same office.

In fact, they can be better. In my home office I can take off my headset when I need an hour of concentration.

With devs split between local and remote workers, it depends a lot on the office setup, unfortunately.

A previous office I've worked at had rows of benches (a common setup, at least for us over here in Australia). It wouldn't have been feasible for a local guy to talk to a remote dev with a headset with that setup. We had local guys working on a project pre-book and crowd into conference rooms to talk with the remote guys in India. Definitely a little sub-optimal.

(The place was Yahoo!, which may explain a few things.)

Can't visualize. What situation prevents you from plugging a headset into your laptop? Was it a privacy issue?

Anyway our 'local guys' in Mt View are all in the same room, and are almost always headset-on and available. It takes some discipline, sure.

Less privacy, more not wanting to annoy your neighbours sitting a meter away either side. (No music playing, which amplifies the negative effects of one-sided phone nattering.)

Dang. Sounds pretty crowded. It might actually be better to send the folks home, and provide them all with headsets - at least they could collaborate with one another!

I actually feel that it is pretty simple to set up a good remote structure and is as simple as good old fashion people skills. When I set up a project and on-board remote developers, the first thing I do is tell everyone, no video conferencing for a week. I do this to play a game, I then get the team together after a week and we play a game of describe your coworker. Of course hilarity ensues, as everyone build these crazy visualizations of what their other remote development counterparts look like, sometimes we will have the artists among the team sketch out the visualization on a shared screen. I also open a group chat on Skype for the project, where I kick of casual office conversation, I will usually post some interesting tech articles and kick up a discussion. From there the team dynamics tend to start growing organically. Sure these things may start organically in an office setting with no effort at all, but it does not take that much effort to seed it among an all remote team. Further some of the more introverted members of the team have expressed that they really like it because they feel more comfortable with the introductory exchanges not being face to face. I am a big proponent of remote teams, I can't say that I always was. I used to believe that they would never work because the team dynamic would not form. I was wrong and don't mind admitting that after being part of many teams that have resoundingly proved that my assumptions where wrong. Some of the most efficient teams that I have been on where all remote.

I'd really like to hear more about your experience with the success and failure of remote team configurations.

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.

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

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.

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

and yet it's not necessarily around big successes. companies aim to exit modestly all the time (not every company can be a google)

i run a company that employs "remote workers" but all centered around one city so that there is some in-person interaction and 4-6 big meetings across our two offices. i think the compromise between the talent demand "problem" and finding remote workers scattered across the world is to pick a 2nd/3rd tier city that's reasonable and set up shop there. it's worked for us and i don't think we're any company special.

I am really wondering whether physical proximity of the employees, empirically, has a reasonable relationship to early success?

A pure guess (based on personal preference) is a mix of remote and local working, favoring remote -- would still produce big successes. (Although, this balance should be kept flexible depending of the state of which the project demands.)

This could stem from programming requiring a mix of social and private time, which works naturally with local and remote working.

If your goal is to go from zero to massive IPO in a small number of years, perhaps, but most software teams are not built with that goal in mind.

Size doesn't matter in this context. It's about stability and longevity of the company (and the ability to operate well without localized teams). I'd love to see some data to support the success of local vs. remote teams (especially since the ability to have strong remote teams is fairly young).

The two are not unrelated. If the best distributed companies do 1% as well as the best concentrated ones, then it's reasonable to worry that the same ratio holds all the way down the line, till you get to the point where 100n is on the right side of surviving, and n is on the wrong side.

I agree that it's reasonable to worry, though, the concept of distributed teams is still too young to compete against established, centralized teams. I'd rather look toward statistical data rather than the empirical data that we have on hand now. I'd really like to see an essay where you confute this in detail (there's a lot to dissect here that requires further research).

I think you need to adjust for the fact that many of the tools that make remote employment effective are recent developments.

Are there any notable success stories surrounding companies that began as a geographically distributed team?

Khan Academy

AFAIK DeviantArt's team is all remote.

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.

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

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.

why would I want to be on site most of the time if it is not necessary? So I can be more involved in company politics ? If I deliver all you wanted what is a problem where I was when things were done ?

Your last sentence actually might indicate that your team is maybe not so high quality like you think ? High quality developers are sufficiently self motivated that they don't really need to be forced to produce results.

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

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.

concise: remote/untethered people can deliver great work and as long as you're happy with it thats what matters. also, alot of people find they are happier not being tethered to a Dilbert-like existance. some of those folks are highly and broadly talented who have lots and lots of paying alternative opportunities, so you as an employer will be competing against them whether you like it or not.

I've met an equal number of non-engineers who feel they should work remotely. I watch as my wife works remotely. She gets at least 10 times more done for her employer when she works remotely. 1 reason being is that her work is so much more efficient. No one jumps in her cubicle to bug her about whatever. And there are plenty more. Another thing that happens is that she tends to spend the time she would have spent commuting (at least 2 hours each day) working. And she's not alone. I've seen all her colleagues and bosses do the same thing. What sucks though is she works in a culture that isn't anywhere ready to let go of the control. They are too scared.

While I agree that good engineers should be able to do all of the things on your list, I don't agree that a distributed team is necessarily a huge barrier to all those things.

I work with such a team, and we're in constant contact. I teach, learn, coordinate, discuss design, and communicate insights via IRC and Skype. We're signed in and talking at pretty much all hours. We talk about the piece of code we're working on at the moment, we talk about what we're about to do, we ask for design feedback, we bitch about terrible dependencies, everything.

If you're talking about the kind of remote workers who fire off a couple e-mails and maybe jump on skype for 20 minutes a day, then I agree. That just isn't conducive to good, cohesive work. It also wouldn't fly on our team.

I think it needs to be recognized that (especially with the right team) distributed work and throwing development over the wall to a random offshore company are _nowhere_ near the same thing. If they are, then the team clearly isn't good at remoting and, as you say, probably need to be physically present.

Good engineers should be able to do either well, not just one or the other; and a good team should be able to do everything on your list with either work arrangement.

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.

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.

I worked remotely for two years out of LA as one of two engineers for a tiny startup, and that describes my experience there perfectly.

I've been working remotely for the last three years out of Seattle, and it's totally different. Part of it is the availability of plenty of coffee shops from which to work (http://technomancy.us/156), part of it is having more hacker friends locally with which to co-work, but a lot of it comes down to just having a lot more communication with my remote team. At my last job I spent the majority of the day pair programming over SSH and VoIP. Also, being the one remote guy on a team that's otherwise all in-house is much, much harder to pull off.

You should look into coworking then. This can help bring just the right amount of balance to fight the isolation problem. Even better, it can bring the employed and self-employed together and provide a fresh perspective when you need one.

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.

Funny thing I've found though, a company that will gladly drop $3k to change a few colors and a font on a web form will sometimes throw a fit over reimbursing a $350 plane ticket. Not all dollars are equal.

I think that's a brilliant observation and accurate.

That's the cheapest round trip plane ticket I've ever heard of.

I'm not sure if you're being sarcastic, but I just punched in an arbitrary roundtrip from Columbus, OH to NYC and got several options at $355 including all taxes and fees.

Not being sarcastic, I had just never seen one that low. I've flown only a handful of times (between SF and Missouri, usually booked about a month or two in advance), and the cheapest round trip option I had ever seen is $600.

Understandable, then. Roundtrip fares are so heavily dependent on the individual route and when you travel. I did a quick search from SF to DC and got prices as low as $319, despite being considerably farther than MO. I often do roundtrips from DC to South Florida for under $200. But pick the wrong pair of cities and you can definitely be hurting.

That's even a somewhat uncompetitive route; if you're doing a city pair with a lot of competition, it's more like $200s; e.g. Atlanta<->Houston is typically $200-250 roundtrip.

Average tickets that I see from Columbus to NYC, Boston or SF are between $310 and $375

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.

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.

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.

Do they all come in at once, or one at a time? The former seems a lot harder to coordinate.

Mozilla has all-hands "work weeks" a couple times a year. The location changes each time, so employees can visit different cities and offices.

This is how we do it. Most employees work in the office, but we're fine with people who choose to work remotely, either in part or in full. But sometimes we expect staff to come into the office.

Speaking as a manager, building a team of only remotely people can be more difficult than building a team of employees who see each other face-to-face.

Face time helps us considerably with junior developers, which are much easier to find than senior developers (and, really, the senior programmers and designers are the people who tend to work best remotely, which brings us back to the problem of the difficulty of hiring senior staff). We can pair juniors with seniors at the office and the juniors will come up to speed much more quickly.

It's all about finding a cultural stride in the team. There needs to be a solid core and where they work doesn't matter, so long as that culture permeates. But email and Basecamp and IRC or whatever tools are used aren't necessarily the best place to build that culture--they're merely communication tools. Culture is as much about intangibles like friendship and understanding the company politics beyond the dev team as it is about raw programming ability.

And then there's the fact that when I have a team member standing in front of me talking through a problem or just shooting the shit, they've got my full attention, because they're standing in front of me. When a team member sends me an email, I only have their email to look at. That's probably my personal failing as a manager, but there's something to be said about human interaction, beyond cranking out product.

I've been working with a company now remotely for about 3 years. We've only all met in person with 100% of the team maybe 3 times since I started. Partial team meeting with more than 2 people perhaps 6 times.

I do agree that culturally it can make for a weaker culture. I'm not really "friends" with any of my co-workers like I have been at all my prior companies. I've never worked on side projects with my coworkers after-hours like I have prior. It isn't the same.

Yet, I think its really the culture that we set because of the people we have and/or the tone set by management, not because remote working is a bad idea. We probably could be all a lot closer if management set that as a cultural goal.

I agree, there is certainly a difference between having someone come in your office and sending you an email.

It would seem the solution, as you've identified, is to have some scheduled and semi-frequent in-person interaction in a non-rushed manner.

Interesting aside about coworker friendships. Is that common? In over 20 years of professional employment, I've had a friendship like that develop only once. Not that things weren't friendly and cordial at work, but very rarely did that extend to a personal friendship outside the office.

Hard to say. I'm a very friendly person and I really like getting to know my coworkers. Some environments are better than others I guess. While I wasn't a "coworker" with them, I made a ton of good friends at the betahouse coworking loft in Cambridge.

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.

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

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.

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.

While I can't comment on your personal experience, what you're implying here is really offensive: the idea that only clock-punchers aren't willing to relocate for a job. Most of the best people in any field care about more than just their work and have a whole life outside their job. Relocating means impact on many things, like leaving your community, uprooting your family, impact on spouse's career, pulling kids out of school, moving away from family, etc.

My guess is that most of the people who are willing to easily drop everything and relocate for a job don't have much to drop in the first place, because they're single twenty-somethings.

I see where you're coming from, but I don't really agree that you can't build a company culture remotely. As usual, this all depends on the team.

I'm part of a small company and we generally work remotely with occasional meet-ups. This is, of course, just my anecdote, but I feel that we're building a great company culture. Part of this may be the fact that most of us have been using IRC for 10+ years; we grew up on it. Communicating that way is as natural to us as face-to-face. In fact, we often talk on IRC even if we're in the same building. It's easier to paste links, reference documentation, and avoid constant interruption. We're generally signed in 24/7 and talk at all hours.

If you get those people that sign on to skype 20 minutes a day and you never hear from them otherwise, then yes, I completely agree that it just won't work as well.

I, along with our remote workers, have built a company with a great culture. The first time we met in person was 5 years after we first started working together. We share a lot of non-work 'stuff' - most of us have had kids, so we share photos, send presents, chat about cultures (in the different countries) and when I first met the people who were working for me I knew them really really well. My perception of them in person was exactly as it had been through our remote conversations.

Our company is entirely remote - we got rid of our office in 2002 and we have designers who work locally (but from home) and we have other people in California, two places in Russia and Argentina. We're still a small team, as there's 17 of us, but we have a great culture. I'm just saying that it is possible to do it.

"You can't develop a company culture without putting people together, physically."

I couldn't disagree more.

I've worked at several companies now, and my current company is my first distributed gig. It is by far the best and strongest culture I've been a part of. If you have good people who take the time to skype and chat, being around each other makes little difference.

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?

No it doesn't make any sense. I guess the recruiter can always try though...

only if you will not do same quality work as on site in which case I wouldn't recommend to hire you anyhow

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.

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.

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.

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.

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.

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.

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.

Contact me; email is in profile. My co-founder runs a pretty well known designer meetup in the bay.

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

Contracting instead of hiring is a decent workaround in my opinion. A lot of great people who work from remote are already full-time or part-time freelancers and are totally open to long-term engagements. It's as simple as sending an invoice by the employee/freelancer and sending a check or wire transfer back.

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.

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

I actually really like this set of rules. It keeps nit-wit bosses from calling you a contractor and then micromanaging you like an employee. On the balance they favor those who really do want to be contractors.

If you want to be a contractor and you do the same work as a regular employee and that company is your only client, you're going to have a hard time defending that you're actually a contractor. MA doesn't allow that, for instance. It's not just about how you're treated -- it's very much about the nature of your work.

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.

Right, for us 90% of these people were in europe/south america, and the remainder were definitely working on multiple projects/clients and had businesses setup that they did their contracting through.

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.

We have Paychex handle everyone in the US and everyone outside the US work as contractors. You have to observe the local rules about who can be a contractor, but it works well for people with self-directed work, like programmers, designers, ops people. Less so for, say, assistants.

It's not nearly as hard as it appears.

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.

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.

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

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.

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

Incidentally I am based in Cairo, Egypt. Our team here is mainly working remotely from home since it just saves a lot of time in travelling. Cairo is a mega city with a bad traffic jam - letting people to work from home saves 1 to 2 hours of pain and misery every day. This fact alone makes people happier.

Of course you’d prefer co-location. You’d also prefer to be able to have all “A” players , afford them within your budget, not have to deal with people juggling careers and families, never have to deal with Google poaching your colleagues, and so on, and so forth.

The simple fact is, hiring, retaining, and managing people is a difficult juggling act involving many trade-offs. David is simply pointing out that co-location is one of the trade-offs that many people call a “deal-breaker” while simultaneously bemoaning a lack of available talent.

IF you have plenty of talent within walking distance of your office, don’t hire remote, no problem. But if you one day find yourself unable to get the A players you need, all he’s saying is either hire remotely or don’t complain about the lack of talent.

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.

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.

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

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.

This is exactly how we use Ventrilo at Cheezburger. Skype is better for back-and-forth conversations; Ventrilo is better for status updates.

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.

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.

Yes, this is a very common practice.

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

>> And I can assure you there are amazing Indian, Japaneese, German, Russian, Finninsh and Australian devs.

>> And you can get some prime developers at lower than $100K/year

Totally agree with that. I work remote from Bangalore for a YC startup.

I can't say if I'm "amazing" or "prime". Before I got hired, I had a bunch of opensource projects which I had passionately crafted for personal use. But I do get paid on the far lower side of $100k. I joined on an independent contractor agreement just the next day after I finished college.

About managing tasks: we do 5-minute meetings every day and discuss what each of us are working on.

I'm curious to know what kind of legal work is required to hire remote workers outside the country (US) and how the hires are compensated.

I looked into the requirements when hiring abroad, and the IRS makes it insanely confusing (surprise, surprise). I finally determined that I had no U.S. payroll/withholding responsibility as my foreign employee was outside the U.S. and did all their work out of the U.S.

For payment, I use xoom.com to transfer bank-to-bank. Its worked out well for international payments so far and their fees are reasonable.

My pay is being sent via international bank transfers. Costs about $20 (on my end) which is fine with me. It takes about a day but I believe it's reliable.

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.

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

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)

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.

Can you throw some light on what kind of agreements remote workers outside the country (US) are hired?

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.

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.

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.

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

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)

In those cases i have the Team come to my House or the Condo's Amenities Floor, lot's of quite room and wifi.

But yes, this arrangement is not for everyone.

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.

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 (:

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

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.

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.

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.

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.

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.

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.

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.

Apropos:

A few days ago a discussion about just this topic was started at http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=...

A recent poll was started at: http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_...

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.

"SHUT UP AND USE ALL OUR PRODUCTS"

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.

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.

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

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

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.

Keyword is "teams". Not "workers" (individuals).

Remote team is a group of people who work together in a branch somewhere. That's a big difference.

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.

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

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.

If one works in complete isolation from other developers, then doing a "hand them a project, see what they produce" assignment would be a perfect way of measuring ability.

There are certainly cases where that is true, but my experience leads me to believe that they are the marked exception, and not the rule.

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.

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.

Your take on the whiteboard is interesting, and I can definitely see value in that. Of all the interviews I've been on however, it wasn't about brainstorming at all. It was a test to see how well you knew your data structures / algorithms. Examples: Solve a variation of the 8 queens problem; Determine if a graph is acyclic; etc...

some companies just want an ass in a seat and giving you a remote project doesn't accomplish this.

We generally never hire anyone we haven't seen before, unless there's overwhelming evidence that they'll kick ass. For example, we hired Pratik Naik from London and it took more than a year before he met anyone else in the office (couldn't get a visa).

For everyone else, we fly them into the office to determine if they'll be a good social fit. If so, they're hired and fly back home to get work done. Works great!

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.

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

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

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

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

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.

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

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

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.

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.

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.

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

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

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

I sure it was a joke, but do not underestimate rural Ontario. Thanks to the unfortunately now historic funding structure of the education system, Ontario poured massive amounts of money into rural technology.

I cannot speak for the Fenwick area, but here in the most agriculturally productive area of Ontario, the schools had high speed internet access back in 1994-1995. Most of the schools in the city were lucky if they had dialup, if internet at all. Labs full of SGI machines when SGI was a major player. Remote video-conferencing classrooms. You name it, we probably had access to it.

As a result, we seem to have a disproportionate number of skilled tech workers. I am really quite amazed at the talent that has come from this small farming community.

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 :)

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?

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

Reply on news.ycombinator.com