Ask HN: Why are a majority of companies not-open to hiring remote developers?
8 comments
Not only is it the lack of control, it's also the fuzzy feeling managers get from seeing you at your desk. Many managers don't understand that you're not necessarily working when you're staring at your screen and vice versa. Being able to walk by and see someone sitting at their desk gives gives them the (possibly false) impression that work is being done. If every moment not spent doing actual work was spent away from my desk, my employer would view me as lazy. As is, a large portion of my time is spent not doing visible work but because I'm at my desk, it's not a problem.
This floors me. But you are absolutely SPOT ON. I really had to laugh when I read this b/c I feel like this is an ongoing joke in the dev and greater IT community. Sigh... so true.
how come more of these companies don't hire remote devs? Are they scared of lack of control?
Yep. 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?
Yep. 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?
Thanks for the input - I hear you that it can be a challenge. I have actually had pretty good experiences managing remote devs. One team had a guy in NY, 2 in AZ, 1 in WA, and 1 in CO. The guy in NY did not last long, just b/c he went MIA a lot. However, with the others I made it very clear that during "normal" work hours they had to be online and ready to do video chat at anytime. The amazing thing was that these guys appreciated it so much, I couldn't get them to STOP working sometimes!! It would be 11pm CST and everyone was cranking on late night sessions. I am sure their wives did not appreciate it - ha, but from what I can tell, they loved it.
Don't overlook the pain-in-the-ass factor of having to support employees in different jurisdictions with different regulations.
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.
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.
Great point. This was a total pain to deal with. I would argue that hiring folks as contractors first would help test the waters to see if they are employee potential? (and thus worth this headache?)
Just trying to think like a corporation would...
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.
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.
Interesting points. I also think that most mid level managers do not have the technical skill set to review remote developer's work and thus it is easier to walk into a room of developers and yell "Go do X! And it better work!!" :)
Having done significant amounts of remote work with teams in India, I will say that the amount of planning required to efficiently use remote developers who have varying skill sets is beyond most startups. If you have got star programmers who are self-organizing and working on completely independent pieces then that's great, but if you are dealing with a complex app and everyone has their fingers in the pie its like (not the best analogy coming up, but give me some credit for the effort) trying to bake a cake with everyone mixing a portion of the ingredients in different cities then flying to the same city and pouring it all together and expecting to create an award winning cake on the first try.
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.
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.
International remote work is a whole different ball game and #1 I admire anyone who can power though it, #2 Ultimately believe it is only beneficial when given very specific conditions. I had one team that was based in Eastern Europe / Russia and they could write code like demons, but explaining business requirements nearly put everyone over the edge. Communication was a serious barrier, not to mention the time schedules. I love the tech talent there but wow, could totally understand not wanting to jump into that kettle.
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?
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?
Hehe: we finally found a guy to run the Indian team who had worked in the US and he filled that integrator role. It was honestly an order of magnitude performance improvement after he was in place, plus he (partially) solved the time zone issue, which you are right was quite frankly a major pain. If I never have another 11pm or 7am conference call I will be forever grateful.
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.
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.
Have you considered to offer relocating for 2-3 months work onsite, and then transition to work remotely?
You know that is a great question, and I have mentioned this (not on every occasion). It almost always gets the "Umm maybe that will be an option but we can't guarantee it". This always screams to me "Yeah this ain't gonna happen". Ha.
You have to prove yourself in that period. If they're hooked they will let you do anything. Also of course you have to be lucky to find open-minded managers.
In my experience if they see that you are a valuable resource management accepts A LOT.
In my experience if they see that you are a valuable resource management accepts A LOT.
btw, contact me, i've got some Ruby/Rails projects/work every now and then. [email protected]
Communication and team bonding. I've regularly worked with teams that spanned across multiple offices, and without doubt there's huge communication barrier introduced with distance.
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.
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.
Great point. I had a similar experience with the healthcare startup where we would take developers (when they came in town) to our client requirement gathering sessions. While one could easily argue that is not their role, they always offered great input and I think it furthermore motivated them to better understand issues and opportunity areas.
I wonder then if remote
I wonder then if remote
I think you have to realise that when you say a majority of /companies/ you're actually talking about a few key decision makers in this company. The HR manager and your team leader and probably the CTO equivalent have to back this plan.
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.
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.
Agreed - it usually falls on a few people's shoulders, BUT I am curious, why is it riskier? (I am sure I can guess as to what you will say but just interested in your reasoning..)
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.