Managing Remote Teams

> In contrast, if you are 5 people co-located you just stand up and say: “everyone over there - we talk now”.

I much prefer working on software teams with other people in the same office, and yet this is one of the things I hate about it. Just because I'm physically near you doesn't mean there's zero cost to interruptions.

Working remotely is like memory protection and pre-emptive multitasking. Maybe in a perfect world, it wouldn't be needed, as there's a slight performance hit from requiring these abstractions, and in some cases it can be awkward to have to deal with the communication paths this requires, but the benefit from requiring everyone to be honest far outweighs the performance cost. In practice, not every component of the system is always perfect. Email is my syscall interface, and distance is my MMU. Open floor plan offices make as much sense to me as running all your programs in the same memory space.

Remote work works for software because it enforces desirable management styles -- that I can be sure my process won't be pre-empted in 5 minutes because someone brought donuts.

I manage a fully remote team with staff in time zones from Sydney to LA. In fact I've just messaged people in both zones.

Culture is key:

- People have to be of the mindset that meetings are short and purposeful. Nobody is in the meeting because they are the boss, or forced to join in order to soak up the atmosphere. (Both of those are real things, somehow).

- People exercise judgement in deciding how many people to write to: either DM, or 3-way, or dump it in a public channel.

- Most work is async by far. People post what they're up to, and other people will go and bother them if they're doing something relevant.

There's good and bad things about this:

- We can hire people who are highly experienced, and offer them totally flexible work. Some people like working at 3am. Others like to pick up the kids from school.

- We tend to only hire highly experienced people. There's nobody with under 8 years of work on the team. Juniors will have to somehow convince us they can do it; it's somehow more believable that an older person will be able to work independently than a younger one.

- Work blends in with not-work. Some people like having a division, other people like being flexible and moving their work time around.

Nice article op. I work in a remote-first org and completey agree that org structure is crucial.

A couple additional thoughts: people assume remote work expands your talent pool to everyone. I don't believe it does. You're limited by time zones and by autonomy. Not everyone performs at a high level in a remote context. You need people who are very organized, disciplined and self-starters. Additionally, it can be very hard to unplug in a remote first context so you need a culture that prioeitizes time offline (I.e out of the office)

author here

thanks for posting the article on HN - i am a daily (more or less) lurker and a huge fan :)

let me know if any parts in the article aren't clear or major points are missing - happy to extend or answer here

One great point in this post that I don't see much of in articles on remote work is the importance of setting people up to work autonomously as much as possible. One thing I love about working remote is being able to spend much of my time deep diving on problems without distraction.

Good communication practices are equally important, but I feel like those are less often overlooked these days.

You make a long passionate speech about what the team needs to do to win the market, just to be followed up with a “Sorry Sarah, your internet connection dropped for a second, what did you say?”

That's why you use text based communication, if the internet drops for someone all they have to do is scroll up a bit when they rejoin...

I'd argue that at this point you can still hire the self motivated people that you only need to lead not manage. 'Managing' programmers in general is hard enough, managing remote team in nigh iimpossible so don't do it, just remove the obvious roadblock, be aware of what everyone is up to (roughly) and don't interrupt, if not needed. I dare say the daily standups are not needed - just read the commits to see what's already happened and send an email or a wiki page to edit plan for next week, no need for a meeting involving everyone's full hour. Embrace async and don't manage things that you don't need to.

I enjoyed this article but I wish those GIFs were not there, constantly trying to grab my attention.

One other thing I would add to this is don't treat remote employees as "set and forget". The tendency is to sry someone up remotely and assume they will be happy with that arrangement indefinitely. But many people will experience changes over time in their enjoyment of remote work and productivity. Not always work related and not always positive. E.g.we had someone who injured themself and started to struggle being at home all the time. Another person who loved being remote until their relationship ended and then got lonely at home by themselves day and night. There is a simple fix : every quarter check in with your remote workers to make sure it's still working for them.

Useful article. I really wish startups put a lot more thought into making their team/culture remote ready from day one.

Reading this post is a great step in that direction...

> Innovation easier in person

Innovation is not a group activity, it is always the work of a single individual's creativity. You might think otherwise, that brainstorming and bouncing ideas off each other is important, but you'd be wrong.

There are really good new get remote team management tools (like Bitrix24.com or its clones) that make the remote work model actually workable and productive.

> Friday’s employees can work on what they think creates value: > fixing tech debt

Why wouldn't you fix tech debt on a normal working day?

Scrum methodology is what works for us - creating different apps.

(2012)