Why Remote Engineering Is So Difficult (opens in new tab)

I 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'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 suddenly make the project fail.

I personally find the very disconnected nature of the teams I lead in my consulting work actually forces us to communicate in an open, concise, discoverable way that would be good for any type of team, but that co-located teams get to cheat out on because a weak team member can always ride his stronger teammates' organizational coat tails with nosey interruptions and annoyances.

We have to think things through and write clear specs, because we can't use body language to clarify and count on the people involved in the meeting to just remember the attitudes expressed. We have to be good about change management, because we can't just turn around and ask someone to "get out of a file" or do whatever we want to the database whenever we want to. We have to keep meetings to a minimum, because you just can't have a productive, two-hour phone call.

These are all good things for non-remote teams, too. But they cheat and don't follow good practice.

My 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.

I 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".

Very 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. Personally I'll take a crack team made up of five best people sitting in San Francisco, New York, Berlin, Bangalore and Tokyo over a special team with a powerful corporate mandate ensconced in Microsoft's Redmond campus.

If everyone is good at what they do and has their eye on the ball, then communication can be managed from anywhere, but if you're dealing with the political reality of operating in a major corporation then you need all the help you can get.

What I always wondered with remote work is how do you prevent angry ex-employees to "share" their code-base with the rest of the world (dump it on The Pirate Bay) or with your competitors (in this case you may not even know that they did it).

Of course if they live in a first world country you can probably sue them (and hopefully it could refrain them from releasing your code) but if they come from countries where the law is an abstract concept there will be no brake to exacting their revenge.

I think it's almost impossible given human biology to expect excellent architectural/engineering decisions from remote teams. You need the in-the-flesh discussions, whiteboarding, leadership, etc.

In a former life as a corporate software developer, I distinctly remember having to get up at graveyard-shift hours to infrequently coordinate with some of our Indian team members.

Some minimal time-zone overlap is never overrated. I think it is hard to beat real-time communication over chat or voice - asynchronous delays break up any flow in collaboration and turn it more into throw the requirement over the wall and listen for an echo the next morning.

I believe the key to making remote work work is that everybody has to work remotely, or as if they were remote. If you have meetings and other communications happening face to face, then the remote people, to a greater or lesser extent become Cowboys, through no real fault of their own.

The more interesting thing about this story is how all of the examples are tied together in an already well known way stated by Fred Brooks in his 1975 book, "The Mythical Man-Month". You may have heard the adage of how adding developers to a late project only makes the project more late. The reason is communication overhead. One developer can produce some number of lines of code in a given day, so you'd expect adding more developers would result in more lines of code being written -- essentially O(N). Unfortunately, there is communication overhead and it increases complexity at O(N^2) as well as being an even bigger drain at the start when bring new developers up to speed with the existing group. If you take a step back, all of the remote working patterns presented in the article as working are essentially ways to eliminate the need for communication.

Very 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

> If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. The very model you use to keep work geographically efficient are globally sub-optimal for the evolution of your code.

I think this is true of any organization, geographically divided or not. These are the challenges of organizational structure, and I've seen them affect organizations in a single location just as much as organizations with remote engineers.

In my mind, the single most important thing to do is to re-evaluate and adjust the structure early and often. The way you divide up work today will almost never be sustainable - regardless of geography. The trick is to help everyone understand and expect those changes to occur frequently.

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.

The only thing about remote work that is different than local work is communication paradigms. Specifically, whereas you could normally poke your head around a corner and interrupt someone to ask them something trivial, with remote work it's harder to forcibly intrude on them and get instant feedback. And I think that's what people have a hard time grasping: how to 'work' without instant feedback?

Of course we all own a telephone, so the instantaneous-ness is always there. But timezones create a mandatory delay to availability which can't be easily worked around. So whereas people are normally very accustomed to working via a continuous flow of real time communication, they now have to learn to communicate via delays and compartmentalize decisions and production.

Some people can't deal with this. So they start to find ways of splitting up work by location. But eventually, things get out of sync, because they never learned how to communicate in a new way. This then creates things like a mandatory daily meeting just to figure out what's changed in the last 24 hours, or red tape designed to keep people from making decisions on their own, or a lack of any kind of tape, or a breakdown in leadership, or the inability to accomplish tasks independently, or lowered morale, etc. This lack of being able to cope with communicating and working asynchronously is, I believe, a sort of stagnating death spiral that (without seriously competent self-starting workaholics) just results in mismanagement and tepid progress.

As a contrary example I like to use the open source development world. They work on different parts of different projects in different regions all the time. They self-organize and come to consensus quickly, and are led by a small team of well established hierarchy that makes quick, decisive executive decisions. There is basically no bone-headed executive level muddling with your work, nor contemptible middle-managers fighting for power, nor tepid low-level engineers waiting for someone to make a decision. Everyone just gets shit done because they all have one goal: to ship a good product. That's all very nice because you aren't part of a corporation, and you feel like your contribution matters more.

But in a corporation, you have to deal with all the usual corporation bullshit, in addition to now working asynchronously. I think this is where the big breakdown occurs in practice; two different sets of problems (asynchronous communication, and corporate bullshit) add up to a more complicated way of working. If you're very lucky, everyone will be able to work the same way and things will go smoothly. But in practice, not everyone works the same way, and thus bugs crop up in the work due to process incompatibility.

So why is remote engineering difficult? It's not; it's just a specific skillset.