
Managing Remote Teams - feross
http://klinger.io/post/180989912140/managing-remote-teams-a-crash-course
======
ken
> 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.

~~~
codemac
Have you worked on this small of a team before?

When the team is actually small (not a small part of some mondo corp), you get
a lot of great team dynamics, and it's very easy to know that 'ken doesn't
like being interrupted.

Working with a small team in the context of an open office w/100 people where
10-20% of the team is actually remote is what I've found to be the most unique
intersection of terribleness.

~~~
ken
Yup. I've worked at a _company_ of 2!

The last software team I was on was about 3 or 4 (depending on how you count),
in a company of about 10. Nobody in management or sales ever really learned
the "doesn't like being interrupted" lesson.

In my experience, as soon as a company is big enough to hire non-programmers
with physical access to programmers (usually around 4-6), this problem rears
its head.

~~~
Moru
A: "Do you have a minute?"

B: "I do, now..."

A: "Oh good, could you fix this please?"

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

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

I still haven't figured this one out. Unless it is a criticism or "hey you
broke this", my thought is the default should be a public channel, no?

~~~
toast0
It depends on how many people are in the channel and the expected purpose of
the channel.

There is certainly some amount of information dissemination by having
discussions in a public forum, but you have to weigh that against the
information processing burden it adds to the people in the group.

Also, it may become searchable, but it's only findable if you and your
communication partners use consistent, appropriate, and relatively unique
keywords. There are likely better ways to document things; although,
documentation is one of my worry areas, and I understand the desire to have
_something_ rather than nothing.

------
dhh2106
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)

~~~
planetburgess
Not convinced you are totally limited by timezones if you can embrace
asynchronous working. Definitely makes it harder though. 100% on self
starters. Micromanagers or workers that require great oversight aren't going
to work.

------
andreasklinger
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

~~~
ctrudeau
Any good books you can recommend? Most of what I've seen is about "offshoring"
rather than "remote-first" situations, I'm about to build a team using the
later and want all the reading material I can get my hands on.

Thanks for a great article!

~~~
andreasklinger
I have not read it but it's by Jason Friend and DHH:
[https://www.amazon.com/dp/B00C0ALZ0W/ref=dp-kindle-
redirect?...](https://www.amazon.com/dp/B00C0ALZ0W/ref=dp-kindle-
redirect?_encoding=UTF8&btkr=1)

~~~
planetburgess
Lisette Sutherland's book is very practical and very thorough
[https://www.amazon.com/Work-Together-Anywhere-Remotely-
Succe...](https://www.amazon.com/Work-Together-Anywhere-Remotely-Successfully-
Individuals-ebook/dp/B07C2TTZVG)

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

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

~~~
konschubert
The problem is that video calls are _broken_.

There are many reasons for that, mostly people using inadequate equipment and
bad internet connections.

~~~
nottorp
Video calls are fun for socializing perhaps, but for serious work I prefer
having an automatic record.

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

~~~
dfischer
Agreed – with remote teams you have to embrace async. Don't force meetings
that everyone has to be apart of unless it's a critical planning session or
something in that realm.

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

~~~
KlaymenDK
[https://addons.mozilla.org/en-
US/firefox/addon/superstop/](https://addons.mozilla.org/en-
US/firefox/addon/superstop/)

With SuperStop, you just hit Shift+Esc and all animations will stop. :)

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

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

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

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

------
g4k
> 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?

~~~
cheriot
I don't think the author is saying tech debt is ONLY fixed on Fridays.

Companies have a hard time prioritizing things that only engineers can see.
Especially small things. So some form of reserved engineer bandwidth for tech
debt can be useful.

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

~~~
jordinl
As a counterpoint, in my last company we used scrum and every developer hated
it. In fact, I've never seen scrum work...

~~~
schmrz
What did work in your experience?

~~~
jordinl
I've seen extreme programming work well in some situations, but I've seen it
not work in some others...

In my current project we're three people: the owner, front-end dev and back-
end dev. We don't really have a methodology other than having a daily call at
the same time every day and discuss what needs to be done and any issues we're
having. We also have Slack and if there's something urgent we jump on a call.
I would say it's worked well so far.

But IMO with smaller teams it's way easier than with larger teams.

------
richardhod
(2012)

