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.
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...
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!
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 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.
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.
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.
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.
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.
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.
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. :)
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.
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".
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.
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?
"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:
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.
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.
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.
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!"
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 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 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.)
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!
"so much emphasis on looping in the remote people"
You mean "the team"?
"screwing around with the video camera, trying out this video service, etc, etc."
A team of programmers and you don't have this sorted by day 3? Are you going to tell me you really tried to make it work and failed? Is it possible that, deep down, you didn't really want it to work?
"ended up going with a contracting company"
oh.
And don't say it's too hard to interview remote people. I once got a job at a local company, but they still flew me to their head office to check me out face to face.
"there's no one to have a beer with after work and talk about the latest coding issue, problem, point of interest, socialize"
There's lots of people. They just don't work with me.
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.
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.
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.
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'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.
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.
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.
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?
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 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.
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.
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?
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.
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.
... 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.
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.
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.)
241 comments
[ 4.2 ms ] story [ 242 ms ] threadIt's mind-boggling how broken our hiring practices are, yet how easily it could all be fixed.
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.
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.
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!
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.
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.
That's the unfortunate part of freelancing. The most amazing developers might be horrible with the marketing / business end.
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.
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.
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 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 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.
Edit: I don't have first hand experience working remotely myself. I do have coworkers who work remotely.
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).
Yes. What needs to be asked is: "Are you ready to hire remote workers?" with a laundry list of items, such as:
My point is that making effective use of remote workers is much easier said than done.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:
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".
I think they are right about this one. What's your problem with this?
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.
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.
people who makes incomplete and faulty lists of what good leadership consists of = someone we should take serious
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.
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.
I have freed many good programmers from this trap, but not nearly enough and many remain to be saved.
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?
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."
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...
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.
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.
Would you say a "tech lead" is a manager? They have (technical) authority of the product, but not necessarily hiring/firing of other people.
Plausible if you accept that problems can be broken into separate pieces. Furthermore, measuring/comparing the productivity is non-trivial/impossible.
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.
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 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.
Maybe you just haven't worked with a cohesive fully remote team ever?
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.
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 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'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).
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.
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.
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.
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?
Taking responsibility is the single hardest quality to find and hire.
On the other hand, I find that attitude matters a lot, and one even mildly disgruntled / unmotivated person can really sink a team.
Awkward is just fine. Someone who is mean or lazy is another story.
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.
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?
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.
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.
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).
http://www.irs.gov/businesses/small/article/0,,id=99921,00.h...
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.
It's not nearly as hard as it appears.
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.
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.
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.
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!
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.
Open source projects generally have no deadlines. It's always a work in progress. So, team "magic" isn't really necessary.
Once there is a basic plan in place, face time (or phone/IM) are fine to flesh out smaller issues, Q&A, etc.
Apparently someone did. The express purpose of the Kernel Developers Summit is to work out problems that couldn't be resolved online.
An equivalent would be someone working 9 to 5 in an office and doing two days of "work from home" in a year.
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.
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.
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"
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?
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.
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.
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.
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.)
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.
You mean "the team"?
"screwing around with the video camera, trying out this video service, etc, etc."
A team of programmers and you don't have this sorted by day 3? Are you going to tell me you really tried to make it work and failed? Is it possible that, deep down, you didn't really want it to work?
"ended up going with a contracting company"
oh.
And don't say it's too hard to interview remote people. I once got a job at a local company, but they still flew me to their head office to check me out face to face.
"there's no one to have a beer with after work and talk about the latest coding issue, problem, point of interest, socialize"
There's lots of people. They just don't work with me.
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 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.
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.
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.
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)
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.
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.
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.
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 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.
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?
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.
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.
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'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.
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?
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.
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'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.
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.
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.
- 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.
... 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).
Remote team is a group of people who work together in a branch somewhere. That's a big difference.
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.
But yes, this arrangement is not for everyone.