Ask HN: Why are a majority of companies not-open to hiring remote developers?
As a Ruby developer (from what I hear and see), my skills are in high demand. Take this awesome recruiter email to me:
-- start email ----
I am a recruiter here in the Bay Area working with several significant consumer-focused internet tech companies. What's going on in the Bay Area right now (and why I am writing you) is a major shortage of qualified Ruby engineers. For that reason, there are Ruby openings at probably 30-40 of my portfolio clients (seriously); additionally, I am seeing much higher salaries in this area because of the shortage and increased demand in the market caused by increasing venture investment in startups and more dev teams adopting RoR. This all boils down to you. The reason I'm writing is that I would like for you to seriously consider the possibility of looking at a new full time role as a Rails dev in San Francisco. Is this something that you would be open to? Some of the most innovative companies in the country are here in the Bay Area. I hope that you will be interested in at least looking at a few options that are = available to you. Feel free to give me a ring or let me know a good number and time to reach you.
-- end email ----
Wow. OK so there is huge demand (I think). Now granted NO recruiter is going to help you get remote work, but how come more of these companies don't hire remote devs? Are they scared of lack of control? Is it more fun to run screaming into someone's office yelling "Fire" about some new idea then actually thinking things through and sticking to a plan? Sorry that sounded really negative, but I am baffled.
HN please advise!!
* Also feel free to post if you are looking for remote devs.
If anyone finds the "February Remote Workers" thread, feel free to post here too.
19 comments
[ 3.3 ms ] story [ 22.3 ms ] threadYep. I've managed many programmers, both in-office and remote, and let me tell you, the communication challenges with remote workers are enormous. That doesn't mean that I'd rule it out under any circumstances-- as I said, I've done it before-- but it would not be an attractive option for me as an employer under normal circumstances.
You say you've managed remote teams-- what's your experience been?
Its a significant management challenge, and as a startup if you can avoid adding yet another significant management challenge by requiring your dev team to be local to the rest of the operation then you should.
I like your analogy about the cake and definitely respect your thought process there. The way I have gotten around this is that I (or another team member) always played the role of gate keeper / "integrator" to make sure the merging of branches went as smoothly as possible. Now we also had the benefit of full test suites to run, user stories to compare against, etc. but it seemed to work. The drawback is that as the "integrator" my actual development time would be cut in order to keep timelines met. However the plus was that I could question the dev's intentions maybe make some extra adjustment / cleaner code and ultimately produce a more maintainable code base. I also was never caught off guard about garbage coming in - ha.
Does anyone else use this sort of "integrator" role and seen these challenges / benefits?
Communication was a serious issue: even in English it was bad enough, and I shudder to think about what it would be like with a non-English speaking country. I guess ultimately you CAN make it work and there are SOME cost efficiencies to be gained but even in India we see large companies like IBM and Verizon who end up building out these massive facilities (regular power generation comes to mind: Delhi had these huge power outages and we eventually had to buy our team there power inverters just so they could work part of the time between 11am and 4pm) to normalize the development experience: I question if there are any cost savings left after that kind of infrastructure build out.
And yes, it completely destroys your personal productivity, but the hope is that the multiplier effect gets you more value than writing the code yourself: I'm as yet unconvinced that it really works that way, but what do I know.
In my experience if they see that you are a valuable resource management accepts A LOT.
These people generally have to justify what they do not only to their superiors but to other people in the business. And hiring someone who isn't physically there is always going to be riskier (to them) than someone sitting at their desk whatever they are doing.
That's my 2p worth anyway.
Perhaps it's a signaling thing. Historically companies have wanted their workers to be loyal and dedicated to them -- that's part of the reason they do 401k's, career paths, etc.
So perhaps the unwillingness to relocate to on-site tells the company that you aren't as dedicated to their success as someone who is willing to be there.
Remember that most mid level management still seems to be stuck in 1975. They don't understand that worker loyalty went by the wayside because of the recent RIFs that became commonplace in the last 20-30 years.
Employment contracts need to be customized slightly by state. You've got to sign up for worker's compensation insurance, unemployment insurance taxes, and sometimes disability insurance. You've got to pay state taxes, and for most states you're going to need to do withholding on behalf of your employees. You've got to make sure your benefit plan provides reasonable options in that state. If you're following the letter of the law, every state has different notices you've got to post in the place of work.
If you're not talking about employees in different states, but instead are talking about employees in different countries, the complexity level just went up another notch.
I'm usually happy to employ great talent wherever it lives (and there's nothing at all wrong with living in the French Riviera), but decentralization doesn't make it easy.
Even development teams which are split across different locations in the same building see this problem (to a lesser extent). It's one of the main reason investment banks will put developers on the trading floor, seats on the trading floor tend to be very expensive (everything has multiple redundancy, etc) but the teamwork advantages are so great that it's worth doing.
I wonder then if remote