all this WFH fud. its total bullshit. i work on a distributed team and i do video conferencing, pair programming (screenhero) and chat all day w/ them. I talk to these coworkers more than I ever did my onsite cohorts.
Why Remote Engineering Is So Difficult
21–30 of 43 posts
Re: Why Remote Engineering Is So Difficult
#22It's easy to say that communication is key, because it is, but all else being equal, if your team can't execute projects in a distributed, remote environment as well as it can in a centralized place, then it's not as good at communicating as you think it is. Dragging a failing remote team into an office isn't going to magically make them successful, and scattering a successful team across the world isn't going to sud…
This and the top comment nails it down that if your team is not delivering the stuff in remote model then they most probably wont deliver in collocated space as well. I am not very sure why people still refer to year 2000 time of offshoring difficulties till now. For last 14 years I have been in working in the offshore(software and infra outsourcing) model. And I can vouch for the model to be very workable while it w…
EDIT ADD: There is no additional issues in managing remote worker than it is with regular in office . It is just kind of issue, it is definitely manageable.
Re: Why Remote Engineering Is So Difficult
#23Very interesting food for thought here, but the difficulties of remote engineering are not fundamentally any more challenging than any other collaboration obstacles. Obviously having all the stakeholders sitting in the same room is the platonic ideal of a team, but to me this is a secondary concern after getting the absolute best people we can. I think the author is a bit out of touch with how startups operate. Perso…
Agree. It's interesting to compare the remote worker debate with the open office configuration debate- they seem like different degrees of the same problem. I find it interesting that I myself am all for remote workers, but have had nothing but horrible experiences with workplaces where everyone has their own office. Pondering this a bit I think it's because every workplace I've been in with individual offices (Micro…
Could you please elaborate a bit on what sorts of horrible experiences you had with the individual offices arrangement? How frequent were your team meetings? Did you guys use Slack-style chat softwares?
Re: Why Remote Engineering Is So Difficult
#24My experience is that engineers often:
* hate meetings
* prefer slack/hipchat/etc even if seated adjacently (myself included)
* work asynchronously
Re: Why Remote Engineering Is So Difficult
#25I worked at two companies where everyone worked remotely. I think one of the big differences I noticed is that I never felt like I was that close to the rest of the team. We talked a few times/week through Webex or Skype, but it's just not the same as being there in person. Communication was also a big issue. It's not impossible to have good communication remotely, but I've rarely seen it in practice.
This might be good since it can prevent a lot of bullshit politics that come with offices.
Re: Why Remote Engineering Is So Difficult
#26Very good writing. A few comments:
"as a product you’re betting that your API design is robust enough that groups can remotely work at their own pace or velocity. The core question is why would you want to constrain yourself in this way? "
I am not certain which constraints are implied here - to me an API that facilitates such a work is simple and understandable which to me are admirable qualities.
Perhaps the challenge then is to split the architecture into small enough testable units which communicate through the simple APIs? Once again, this sounds great.
But in practice simplicity, understandability and good architecture are reachable by experience or trial and error so I suppose it would require either a situation were a known pattern is reapplied to new business requirements or one where there is ample time for designing and prototyping with these qualities as explicit design constraints.
"how to balance resources on each side of the API."
I suppose the best situation would be then an API that supports a directed graph of rensponsibilities. Like a plug in system, for instance?
"...however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. "
So I suppose to make remote working work software architecture and team management need to be linked on a very intimate level? This would be nice in any situation, I think
Re: Why Remote Engineering Is So Difficult
#27I worked at two companies where everyone worked remotely. I think one of the big differences I noticed is that I never felt like I was that close to the rest of the team. We talked a few times/week through Webex or Skype, but it's just not the same as being there in person. Communication was also a big issue. It's not impossible to have good communication remotely, but I've rarely seen it in practice.
The missing part might have been Empathy.
I keep forgetting to enable that feature!
Re: Why Remote Engineering Is So Difficult
#28I worked at two companies where everyone worked remotely. I think one of the big differences I noticed is that I never felt like I was that close to the rest of the team. We talked a few times/week through Webex or Skype, but it's just not the same as being there in person. Communication was also a big issue. It's not impossible to have good communication remotely, but I've rarely seen it in practice.
It might be because companies use cheap tools for collaboration and not go for something like telepresence that gives experience very close to a real one, including eye-contact - which is criticial in trust and bonding.
Also, to the best of my knowledge nobody applied telepresence directly as a bonding tools - it's mostly used for straight work, because(at least the cisco versions) are quite expensive.
Re: Why Remote Engineering Is So Difficult
#29My experience is that engineers often: * hate meetings * prefer slack/hipchat/etc even if seated adjacently (myself included) * work asynchronously So the main friction is in the interface between engineering and other disciplines. Remote works well so long as non-technical leadership has a local lead they can interface with.
The communication skills of other non-engineering team members can often suck in the digital domain. Empathy by text message can be hard to have. A combination of on-site and remote often works best. Learning the language of other domains can take a long time. The role of people who interface and translate between domains is important.
Re: Why Remote Engineering Is So Difficult
#30I have always worked remotely. My company works this way, my employees work remotely.
IMHO it is not hard or difficult per se, but you need to design your company around it, like with other things.
It is also an area that needs more study in order to develop fully.
Probably if I had a conventional company and I had to transform or convert it to remote, it wouldn't work. There would be vested interest against the conversion on some people, some people would not believe it is not possible(people tend to believe that if you don't look busy to others you are not working) or managers will fear their employees slacking.
When you create a company that makes money from day one remotely, you have not this problem, as you organize around it and it is not optional.
In some ways it is weird. If you go out of your house to get your children from school because you did not spend 1 hour commuting to work, 1 returning from it, society could believe you are not working at all.
They are often surprised to see you have money, and much more money than they have.
But I suppose it is not different from an old farmer watching people sitting in a chair in the city call it "work".