But in the past year we’ve had a few engineers who needed to move (due to various life events). We didn’t want to lose them, so they became remote employees on our team. In some cases it worked really well.
Remote work is a big part of the future in development. It is a big favorite of developers who are self starters, good communicators and deliverers.
Over time it will take longer to build bigger things and people do indeed move in some cases every couple years for many reasons, doesn't mean they aren't as committed because they can't be within 2 hours of an office. Remote works biggest benefit is keeping a team of professionals on the team even if lives change and locations move, might even be a big advantage to those currently that can do it well.
Every remote capable organization has better communication virtually and better external views of themselves. This is also key for working with clients/customers (almost always remote) and other offices (again remote offices in the same company). Remote work can even improve intra-office communication/information flow as many times even though you go to the office, you work with many people in the building or the building over remotely just closer in vicinity.
Kudos to you for embracing the remote culture (partially).
However, you should take it a step further and not "fly them out to visit HQ" but instead:
Take the entire team out for some team-building and working from a different locale (you can stick to the US - as most remote-first companies do).
Your company is not exactly the same as the next advertising-eyeballs SV startup, so perhaps getting out of the Silicon Valley hype-train and "pat each other on the back" environment, exploring a different area/wilderness will open your team up to greater innovation and lateral thinking.
See Automattic for a reference-point of how to do it.
Great move. Love the 'self-starter' bit. People who need to be constantly monitored and told what to do aren't worth it, even if they're easier to hire.
Interesting. I interviewed with them once. Their interview process was pretty strange: after a technical round they wanted me to work full-time for them for a week as a next step. Wat? How do I do that if I have a job? Plus, it seemed like they pay their engineers way below the average. Not surprising they are having hard time hiring and had to move on to hiring remote workers.
I concur. I've had interactions with that team, and they've all been strange. The engineering and security are buggy and poor, and attempts to get to the bottom of issues are stonewalled and shunted.
Is it so strange? If their engineering and security are poor, they wouldn't want that fact exposed by somebody outside the company. A reputation for poor engineering is the touch of death for a startup. Especially a bitcoin startup.
I also interviewed with them, and they gave me the same offer. I told them that was disrespectful to seasoned engineers, and that they could bone off, and I ended up getting a job at a much more interesting company, so it worked out in the end.
That sounds like relatively inexperienced technical people attempting to hire more experienced technical people, to over-simplify a bit.
If you want to build a house and you're not sure how to best build a house you're going to be very cautious hiring someone to build a house because you don't know if their way of building a house is any good, because you don't know how to build a house.
I imagine this strategy works against them as I can't think or a single respectable engineer who would be willing to do this. It may work in their favor of recent college grads.. but certainly not seasoned engineers.
Yup, their logic is very hard to understand. What am I supposed to do, take a week of PTO? I'd think they want to find people who badly want to work at their company, but they are just not that kind of company yet.
I was thinking that maybe it would be kind of interesting and even possibly beneficial to work there for a short period before joining permanently. But could you do that in one week? I guess you could get a look at their tool chain, but you aren't going to learn much about what it's really like to work there in such a short period.
I'm always a bit disheartened when I see misinformation and negativity spiral like this.
The work trial is no longer required, but it is an option since some candidates really enjoy working with us to get a better sense of what it is like before deciding.
I think it served us really well in the early days but you're right it doesn't work for all people (especially more senior folks). And of course we offer to pay people for the time.
In terms of overall comp, we pay more than 7 out of 10 comparable companies (sub 200 employees, tech, in the bay area) across both cash and equity according to http://conneryconsulting.com/ who we hired to help us with this.
Overall, our hiring process (especially in the early days) was weighted toward not making a bad hire, so this means we missed out on some good people occasionally, but ended up with a stellar team. Given the chance to do this over again, I'd make the same choice.
"Have people audition for roles instead of interviewing for them"
"A single bad hire left unfixed for long can kill a company."
etc
We definitely didn't have it perfect early on, and still don't, so apologies if you had a negative experience. It is something we are always working on.
I've had nothing but success working remotely on projects. It's all about having communicative remote people, having the onsite team use the same chat/screenshare/video systems. I can get so much done with absolute focus yet still come out for big meetings a few times per year. It gives flexibility to the onsite people to work from home occasionally, too. On a team with poor cohesion or a lot of strong introverts, it might not work.
In my view, onsite work is only good for two things:
1. Team building. There is no doubt being around the office is good for socialising and creating stronger bounds.
2. Stronger junior people or people that need direction. Many, many, many developers are only good when they have the superstars around. It's people that need direction and help. Having the stronger workers around make these other average workers stronger.
If your team is made of superstars/hyper-professionals then there is no obvious reason not to be doing remote work. If on the other hand your team is mostly made of regular 9-5 workers, well, not doing remote work must just be the excuse for hiding some other bigger issue in the organisation.
I do remote work and I honestly miss the team building.
There's an incalculable benefit to me to socialize on a daily basis with a consistent group of people. A great deal of ex-coworkers from non-remote work jobs are still good friends of mine who I communicate on a weekly basis. And it came from gradual and steady interactions. Being remote has made it very hard to build closeness with a lot of the people within the company, especially the newcomers. It's arguable whether or not closeness or friendship is important to a team, but I'll say that I perform better when I personally care about the people I'm working with.
Furthermore, by not being there (while others are) I also miss out on spontaneous information sharing that happens between people in moments like sitting away from the computer, having lunch together, or lining up to wait for something. It's also difficult to participate with small groups who go on-site to observe customer behavior.
I'm not against remote work because the benefits largely outweigh the negatives. It's just after over two years of doing so, I've gradually moved to the belief that I really prefer a split solution where I come into the office once every few days to energize/adjust my connection with the team.
I've worked remotely for the past year and it has by far been the most productive year of my career as a software engineer. I'm not sure if I will ever want to work in an office again. In my experience, when working in an office environment, people will interrupt you while you're in the middle of writing code. You'll be asked to attend meetings that are ultimately pointless. You'll feel bad about wanting to work from home or from a cafe. The amount of freedom and the feeling of finally being treated like a responsible adult that comes with working remotely is addictive to someone like me who just wants to code all day.
I started working onsite a couple of months ago, after working remotely for two years, and yes it is as bad as you remember. As I'm a contractor I don't even have proper equipment, so I'm stuck with and old broken chair, an old broken table and my 13" laptop vs my setup at home.
I understand how for some people remote just doesn't work, but I think that's mainly because the company doesn't know how to work with remote engineers. The best company I've worked with in terms of remoteness had teams in India (+5.5), Greece (+2), London (+0) and LA (-8).
1. Time zone differences are very real. A 14 hour difference only allowed for a brief window of reasonable real-time communication. Latency went from seconds to half a day.
2. My project had a hardware component, and we could not easily assist each other with electrical or mechanical issues, or even things like firmware (e.g. "why won't this board boot?")
3. Meetings were worse. Video conferencing often had technical problems, and we'd waste time trying to get it to work. Normal human interaction (body language, nonverbal cues, etc.) was lost. Remotes frequently interrupted, through no fault of their own.
4. I came to resent the remotes for enjoying this unequal perk, one that inflicts a cost on the rest of the team. Why don't they have to sit in traffic and then in this noisy room with the rest of us? What makes them special?
Those are all very bad reasons to dislike remote engineers. "Remote" doesn't necessarily mean on the other side of the globe; obviously you wouldn't hire remotes for hardware projects; some video conferencing software is better than other; and if you're so jealous of remote workers, maybe you should try your hand at it.
In regards to 1 & 3 it sounds like the problems are more your company than the remote engineers.
First of all due to the timezone differences I will assume you are US based and outsourced to somewhere in Asia - this alone without the remote working has its own set of challenges (n.b. there is a good comedy TV show "Outsourced" about this). As an example, if someone in India gets stuck doing something they are unlikely to speak up about it until you ask then about it, this isn't because they are lazy or whatever but just because their culture is a lot different to the West. The way you need to work with a team here is a lot different to how you would work with a team in the West - this alone can be the cause of a good chunk of problems that occur when outsourcing.
As your team is remote you can't ask them a question and expect an answer in 10 minutes, but you shouldn't expect this of a onsite engineer either as you'll just ruin their flow. Have daily stand ups at times that work for both teams and discuss any issues after that.
In regards to the communication just use Skype (audio) and get a good microphone. If you don't have a good internet connection or it's not working, just call them on the phone. Companies have been working with distributed teams long before Skype was even invented...
As to 4, well sorry but that's your problem. No one is stopping you from getting a remote job except yourself :)
All of these represent costs that a co-located team doesn't bear. A co-located team is most effective, and every remote saps some of their effectiveness. This is well understood everywhere: it's why companies dedicate remote offices to particular projects.
Google even has a name for this: "defragmenting," where they attempt to reduce the amount of remote work by giving engineers opportunities to move, or to switch to a local project.
I would consider a remote job, but only on a 100% remote team. It's mixed teams that I want to avoid.
> 4. I came to resent the remotes for enjoying this unequal perk, one that inflicts a cost on the rest of the team. Why don't they have to sit in traffic and then in this noisy room with the rest of us? What makes them special?
Seriously? Because your working conditions are terrible, remote engineers are bad for having good working conditions? Here's a hint - stop wasting your time hating others for being happy, and work out how to improve your own working conditions into something you enjoy.
"Hating others for being happy?" Where the hell did that come from?
I resent my peers being given visibly unequal treatment. It's no different than if some engineers get free lunches and others did not. I guarantee you there's onsite engineers in Coinbase who feel the same way.
As for "improving my own working conditions," that's exactly what I did, by quitting that job and taking one with a co-located team, and I'm much happier because of it.
So you're happier now because everyone else has to suffer in the same way. You still have to sit in traffic. You still have to sit in the noisy room. Nothing has changed for you. You're just happy now because you can't see other people who are avoiding it?
Let me repeat it again - for you, nothing at all has changed except that other people around you are also suffering. Your attitude is awful.
If someone came tomorrow to your office and gave a million dollars to each of your team members and $10K to you, you would resent your team members for receiving more money than you, right? People like that are only happy to see others clawed down to their own level.
I'm happier now because I no longer have to deal with the issues in my top-level post. I spend less time being blocked, and I am more effective at unblocking other people. Yes, commutes and open offices suck. But the team as a whole is better off if we sit together, and that makes it worth it to me. I prefer to work with people who feel the same way.
That there's no (visibly) unequal treatment is definitely part of it. I want to work for an employer that I believe is fair.
> If someone came tomorrow to your office and gave a million dollars to each of your team members and $10K to you, you would resent your team members for receiving more money than you, right?
Dude, I hear your protests, but your attitude really does suck. Life isn't fair. The sooner you learn to be happy for others versus trying to keep score the more people will like you.
You sound very bitter. I hope you find what you need to cure that, but please don't pollute hacker news with your sour grapes. I'm sure there's a nice person underneath that veneer and I hope you can find a way to be that person more often.
I think people often combine remote with asynchronous. You can have people who work 3PM to midnight in the office, when everyone else is working 9-5 and it can be annoying for communication.
I like the idea that those are separate things and when people hire remote engineers they should go for engineers in the same time zone or ones who want to work synchronously wherever they are.
One of the benefits of software work is its asynchronous nature[0]. Unfortunately, it requires a certain amount of trust that engineers aren't extended in these days of Scrum micromanagement. If managers could get past that, imagine the possibilities. Engineers could work on your product round the clock. Things would get fixed and progress made while you sleep.
[0]: Hardware isn't software. I can see where that might be an issue.
I'm fortunate enough to have joined a team where this frequently happens. We have people in pacific, eastern, european and antipodean timezones and things often pan out like you describe.
It requires everyone to be both conscious of and conscientious towards other people's working hours, so flexibility is key. People get up early and/or stay up late to attend the (few) regular meetings that we have.
Sometimes I work late on a Thursday to get something reviewed before the reviewer's week ends. Other times I put hours in on a Sunday so that the review can happen before I start work proper on Monday morning.
There is a lot of shared trust required for it to work and I can see that it might not work for every team. But it's definitely working for us.
Ya, I have experienced times where it has worked but I don't remember a time it has worked better than collocating a team. There seem to always be some inefficiencies introduced but it really speaks to the professionalism of the team members when it works
40 comments
[ 2.9 ms ] story [ 72.6 ms ] threadRemote work is a big part of the future in development. It is a big favorite of developers who are self starters, good communicators and deliverers.
Over time it will take longer to build bigger things and people do indeed move in some cases every couple years for many reasons, doesn't mean they aren't as committed because they can't be within 2 hours of an office. Remote works biggest benefit is keeping a team of professionals on the team even if lives change and locations move, might even be a big advantage to those currently that can do it well.
Every remote capable organization has better communication virtually and better external views of themselves. This is also key for working with clients/customers (almost always remote) and other offices (again remote offices in the same company). Remote work can even improve intra-office communication/information flow as many times even though you go to the office, you work with many people in the building or the building over remotely just closer in vicinity.
However, you should take it a step further and not "fly them out to visit HQ" but instead:
Take the entire team out for some team-building and working from a different locale (you can stick to the US - as most remote-first companies do).
Your company is not exactly the same as the next advertising-eyeballs SV startup, so perhaps getting out of the Silicon Valley hype-train and "pat each other on the back" environment, exploring a different area/wilderness will open your team up to greater innovation and lateral thinking.
See Automattic for a reference-point of how to do it.
If you want to build a house and you're not sure how to best build a house you're going to be very cautious hiring someone to build a house because you don't know if their way of building a house is any good, because you don't know how to build a house.
That is a tough problem for a group to solve.
Sacrificing a week of PTO to just interview is a bit much already.
The work trial is no longer required, but it is an option since some candidates really enjoy working with us to get a better sense of what it is like before deciding.
I think it served us really well in the early days but you're right it doesn't work for all people (especially more senior folks). And of course we offer to pay people for the time.
In terms of overall comp, we pay more than 7 out of 10 comparable companies (sub 200 employees, tech, in the bay area) across both cash and equity according to http://conneryconsulting.com/ who we hired to help us with this.
Overall, our hiring process (especially in the early days) was weighted toward not making a bad hire, so this means we missed out on some good people occasionally, but ended up with a stellar team. Given the chance to do this over again, I'd make the same choice.
Finally, I'd suggest reading some of Paul Graham or Sam Altman's advice on this topic, for example: http://blog.samaltman.com/how-to-hire
"Have people audition for roles instead of interviewing for them" "A single bad hire left unfixed for long can kill a company." etc
We definitely didn't have it perfect early on, and still don't, so apologies if you had a negative experience. It is something we are always working on.
1. Team building. There is no doubt being around the office is good for socialising and creating stronger bounds.
2. Stronger junior people or people that need direction. Many, many, many developers are only good when they have the superstars around. It's people that need direction and help. Having the stronger workers around make these other average workers stronger.
If your team is made of superstars/hyper-professionals then there is no obvious reason not to be doing remote work. If on the other hand your team is mostly made of regular 9-5 workers, well, not doing remote work must just be the excuse for hiding some other bigger issue in the organisation.
There's an incalculable benefit to me to socialize on a daily basis with a consistent group of people. A great deal of ex-coworkers from non-remote work jobs are still good friends of mine who I communicate on a weekly basis. And it came from gradual and steady interactions. Being remote has made it very hard to build closeness with a lot of the people within the company, especially the newcomers. It's arguable whether or not closeness or friendship is important to a team, but I'll say that I perform better when I personally care about the people I'm working with.
Furthermore, by not being there (while others are) I also miss out on spontaneous information sharing that happens between people in moments like sitting away from the computer, having lunch together, or lining up to wait for something. It's also difficult to participate with small groups who go on-site to observe customer behavior.
I'm not against remote work because the benefits largely outweigh the negatives. It's just after over two years of doing so, I've gradually moved to the belief that I really prefer a split solution where I come into the office once every few days to energize/adjust my connection with the team.
Doesn't mention which languages in the post. Am I supposed to know this?
I understand how for some people remote just doesn't work, but I think that's mainly because the company doesn't know how to work with remote engineers. The best company I've worked with in terms of remoteness had teams in India (+5.5), Greece (+2), London (+0) and LA (-8).
1. Time zone differences are very real. A 14 hour difference only allowed for a brief window of reasonable real-time communication. Latency went from seconds to half a day.
2. My project had a hardware component, and we could not easily assist each other with electrical or mechanical issues, or even things like firmware (e.g. "why won't this board boot?")
3. Meetings were worse. Video conferencing often had technical problems, and we'd waste time trying to get it to work. Normal human interaction (body language, nonverbal cues, etc.) was lost. Remotes frequently interrupted, through no fault of their own.
4. I came to resent the remotes for enjoying this unequal perk, one that inflicts a cost on the rest of the team. Why don't they have to sit in traffic and then in this noisy room with the rest of us? What makes them special?
First of all due to the timezone differences I will assume you are US based and outsourced to somewhere in Asia - this alone without the remote working has its own set of challenges (n.b. there is a good comedy TV show "Outsourced" about this). As an example, if someone in India gets stuck doing something they are unlikely to speak up about it until you ask then about it, this isn't because they are lazy or whatever but just because their culture is a lot different to the West. The way you need to work with a team here is a lot different to how you would work with a team in the West - this alone can be the cause of a good chunk of problems that occur when outsourcing.
As your team is remote you can't ask them a question and expect an answer in 10 minutes, but you shouldn't expect this of a onsite engineer either as you'll just ruin their flow. Have daily stand ups at times that work for both teams and discuss any issues after that.
In regards to the communication just use Skype (audio) and get a good microphone. If you don't have a good internet connection or it's not working, just call them on the phone. Companies have been working with distributed teams long before Skype was even invented...
As to 4, well sorry but that's your problem. No one is stopping you from getting a remote job except yourself :)
Google even has a name for this: "defragmenting," where they attempt to reduce the amount of remote work by giving engineers opportunities to move, or to switch to a local project.
I would consider a remote job, but only on a 100% remote team. It's mixed teams that I want to avoid.
Seriously? Because your working conditions are terrible, remote engineers are bad for having good working conditions? Here's a hint - stop wasting your time hating others for being happy, and work out how to improve your own working conditions into something you enjoy.
I resent my peers being given visibly unequal treatment. It's no different than if some engineers get free lunches and others did not. I guarantee you there's onsite engineers in Coinbase who feel the same way.
As for "improving my own working conditions," that's exactly what I did, by quitting that job and taking one with a co-located team, and I'm much happier because of it.
Let me repeat it again - for you, nothing at all has changed except that other people around you are also suffering. Your attitude is awful.
If someone came tomorrow to your office and gave a million dollars to each of your team members and $10K to you, you would resent your team members for receiving more money than you, right? People like that are only happy to see others clawed down to their own level.
That there's no (visibly) unequal treatment is definitely part of it. I want to work for an employer that I believe is fair.
> If someone came tomorrow to your office and gave a million dollars to each of your team members and $10K to you, you would resent your team members for receiving more money than you, right?
I take it you're a fan of Jeb's tax plan.
You sound very bitter. I hope you find what you need to cure that, but please don't pollute hacker news with your sour grapes. I'm sure there's a nice person underneath that veneer and I hope you can find a way to be that person more often.
I like the idea that those are separate things and when people hire remote engineers they should go for engineers in the same time zone or ones who want to work synchronously wherever they are.
[0]: Hardware isn't software. I can see where that might be an issue.
It requires everyone to be both conscious of and conscientious towards other people's working hours, so flexibility is key. People get up early and/or stay up late to attend the (few) regular meetings that we have.
Sometimes I work late on a Thursday to get something reviewed before the reviewer's week ends. Other times I put hours in on a Sunday so that the review can happen before I start work proper on Monday morning.
There is a lot of shared trust required for it to work and I can see that it might not work for every team. But it's definitely working for us.