On Remote Teams
Thoughts on distributed product teams
I’ve worked with or lead distributed product teams[1] for the better part of 10 years now. They’ve ranged from a startup in which no one lived in the same city, to a team where a single member exclusively worked from home, to a team where half the members were based in one branch office and half in another, to a two-person operation where the project manager/designer and I lived in different countries.
While these arrangements have definite upsides (less capital overhead, much larger talent pool, etc.), today I wanted to offer some high level thoughts on preempting the difficulties that inevitably arise from working on remote teams.
A.B.E. — Always Be Empathizing
The majority of problems in remote teams are rooted in a lack of empathy. We simply do not put ourselves in the shoes of our teammates. Don’t get me wrong, this happens in traditional office environments as well, but it is especially acute in remote and asynchronous setups. If you get nothing else from this post, remember to A.B.E.[2]
Specifically, I work on two practices to help me be more empathetic in an async-world: one for incoming communications and one for outgoing.
For incoming communications, I tend to only need my empathy hat when I read a message and audibly say, “what the fuck?” That’s usually the perfect time to pause, take a breath, mentally place myself in the sender’s shoes, and assume their intentions were good. Once I do that it tends to take about 30 seconds to figure out what the sender was trying to say — and then I can process it. Also, if the message was from a teammate I’ll try to file it away in my feedback pile for them (as I mention later).
For outgoing communications (emails, PR comments, IMs), before hitting the “send” button, pause for a few seconds. During this pause, forget all the context & caveats in your head and re-read your message cold — as your recipient will. Look for anything you’ve said that is vague or could be misinterpreted. Clarify whatever you find. Maybe add some context to help the recipient empathize. Then hit send. Or, maybe you realize that there is a lot more that needs explained — more than you want to type now (this happens to me a lot). In that case, pick up the phone and call them.
Note: Managers and leads especially need to crank up their self-awareness levels to combat lack of empathy in their processes and communications. You are in a position of power/authority and set the tone for how the whole team interacts. Don’t slack on this one.
Learn when to just get on a call
When we work on remote teams where asynchronous communications is king, it is often forgotten that we can still talk to each other. I’ve seen numerous email threads, slack conversations, pull request comments, etc., start to heat up only to cool down once we all got on a call together. I’ve also seen teammates spin their wheels for most of a day (while talking to them via Slack the whole time), then we get on a call and a few minutes later they are moving ahead smoothly again.
In practice, I look out for a handful of red flags that trigger my, “hey, let’s get on a call” reflex. Namely:
- a pull request comment thread is getting unproductively long (long comment chains are great, as long as the conversation is still productive)
- longer than normal radio silence from a teammate (super contextual, but still a signal)
- a teammate is not progressing through a task at the expected rate
- I start getting questions about a task that indicate there are obvious misunderstandings
- a question comes up and I need to explain something at length (a.k.a. I don’t want to type right now…)
These flags are mostly geared towards team leaders but I think individual contributors shouldn’t hesitate to do this as well (and if you find yourself in a position where your lead isn’t receptive to jumping on a call with you, maybe you should come work with me).
Learn how to use your video chat program properly
So far, I’ve mentioned getting “on a call” a few times. This is just my shorthand for “initiate a video chat on your preferred platform.” The tool you use doesn’t really matter — Skype, Hangouts, Zoom, whatever — just take the time to learn how to use it.
Basic video chat literacy includes:
- Keyboard shortcuts — if you work on a remote team and you can’t mute yourself without clicking anything, stop reading and go find out how.
- Always use headphones and a mic. They don’t have to be fancy, use the set that came with your phone. Even if you are sitting alone in a quiet room, use them. The person or people on the other end of the call will appreciate it.
- Understand how screen sharing works on your platform. Be ready to crank up your text size or slide windows around to make things easier for others on the call to see (remember: A.B.E.)
Reflect — “Let’s 🌮 ‘bout it”
In software development today, we worship fast feedback from our systems. TDD, CI, user surveys, etc. — they all let us know how we’re doing in near real-time. Shouldn’t we strive for the same feedback among the humans building the system? Isn’t that how we get better functioning teams?
I’ll admit, I wasn’t a big fan of diligent, structured feedback sessions when my co-founder introduced them into our company years ago. Then, after a few sessions, I saw the effect they had on how the team worked together and I was sold. Now I like to think of them as preventative medicine — do it now and you won’t feel bad later (when team members suddenly start rage-quitting).
What do I mean by diligent, structured feedback? It can take shape in different ways, but the goal is to have regular discussions where the focus is not what you’re working on but how you are working as a team. Having a specific time dedicated to these discussions is especially important for remote teams.
Some folk think of feedback sessions like sprint retrospectives (you can use the same format if you want) but with the focus being on general team dynamic and interaction as opposed to the just-finished work of the sprint. That’s a fine setup, as long as the sessions are happening.
Your conversations should be in the context of your team, but here are some starter questions to consider:
- How do you handle interrupts? What are your feelings on the current volume of interrupts?
- How are you feeling on the confused <-> confident scale?
- What’s a signal that you’re “in the flow” and need some heads down time?
- What’s your pre-work routine? (since we don’t see each other)
- What was your last “oh snap, I like how we did X” moment?
- What was the last team interaction that made you (ﾉ °益°)ﾉ 彡 ┻━┻?
- (from above) There have been few times were I read a message from you and interpreted it completely different from your actual intentions. Can we chat about that?
How often should these feedback session occur? In typical developer fashion, the answer is “it depends”. In my experience, with a team of 6–8 people, once a month is a pretty good cadence. The trick is to schedule the meeting well in advance and treat it as immovable (bordering on sacred). If not, it will start to get bumped (“oh, project XYZ is slamming us right now, can we reschedule?”). Remember, this is preventative medicine.
Find ways to be non-remote
Getting your remote team together in the same physical location is crucial for achieving both high functionality and longevity. I’ve seen this happen a couple of in different ways, but they usually break down into two categories: when there is a head office, folk come work there for a week every quarter; if there is no office, then the company hosts an offsite in a neutral location once or twice a year.
The time the team spends together should be utilized, but not over done. If you are a maximizer like me, you’ll have a tendency to want to pack lots of meetings, workshops, etc. into the together time — try to hold back. You should definitely pencil in some sessions that benefit from being in meat-space (like a feedback session!) but be sure to leave some time for meetings/activities to happen organically.
The point is to build relationships among the team which will in turn create empathy which will make the times you aren’t physically together run more smoothly. It’s amazing how much easier it is to put yourself in someone’s shoes when you’ve actually seen their shoes (and the lower half of their body).
Go forth, distributed
Technology has made remote teams a much more viable option than in the past. The issue that technology can’t solve (at the moment anyway) is that a remote team is still just a group of humans. Remembering that fact is the key to building high functioning remote teams.
[1] For clarity, I’m defining a “distributed team” as one where all of the members are not physically together in the same space for the majority of the work week. Essentially, if you’re not all in the same office 3+ days a week, you are on a distributed team.
[2] A.B.E. also stands for “Anyone But England” and is typically the answer you get when you ask a Scottish person who they are supporting in the World Cup. If you only remember that, that’s ok too 😝
