On Distributed Teams

I started my team at eero in late 2019, and I decided early on to build it distributed. We already had a few remote engineers, but at the time they were the exception. The default was still an office, and remote people were the ones dialing into a conference room, missing much of the context that happened in-office.

I'd been reading about remote teams for years and it just made more sense to me. So when I was handed the lead on a new team, I decided we'd run it as a distributed team from day one.

In practice that didn't change much at first. The majority still came into the office every day, and all it really meant was that our processes would assume a distributed team rather than an office one. But even that had an immediate effect. We started working asynchronously by default, and the remote folks stopped being out of the loop.

Then, a few months later, everyone in the world became a distributed team overnight, because of Covid.

Obviously I hadn't anticipated this, but it did mean that when the offices closed I'd already spent a while thinking about how this should work, while a lot of people were improvising.

Throughout Covid my team kept growing, and with no clear end date in sight we decided to take a leap and hire across the US and across Brazil. We had no presence in Brazil at all yet, and getting that off the ground is a chapter in itself, which I'll get to some other time.

Needless to say, we learned a lot of things along the way, but I wanted to highlight just a few here. As with everything, it might sound like common sense in hindsight, but everything is easy once you know how to do it.

Start with flexible hours, because I think people get this wrong in both directions.

What I care about is the work, not the clock. I don't need to know what time someone started, and if they took two hours in the middle of the day to deal with something, that's their business.

But flexibility is also a trap, and it's the same trap as unlimited vacation. On paper it's generous. In practice a few people will take advantage of it, and the ones you value most will do the opposite. They'll work too much, because nothing in the system ever tells them to stop.

So I do keep an eye on who's still online late. Not to check that people are working, but to check that they aren't working all the time. If someone started their day at eleven, fine. If someone is consistently online at 10pm having started at 9am, that's a conversation, because I don't need anyone doing 16 hour days and burning out six months from now.

The flip side is being clear about when people are around. Flexibility isn't the same as unpredictability, and if nobody knows when anyone is reachable you get a team that can't make a decision without a 24 hour round trip. So we're explicit about the hours we overlap. Outside that window, your time is yours.

Which leads me to meeting windows, and a nice side benefit of working across time zones. A good chunk of my team is several hours ahead of me, so I made the call to put meetings in one half of the day and focused work in the other. They get heads-down time in the morning and meetings in the afternoon. I get the reverse. In traditional teams the calendar looks a lot more scattered, and we all know that interruptions, especially in engineering, cost far more than the 30 minute block they occupy. That said, the goal should always be to have as few meetings as possible.

Speaking of avoiding wasted time.

One of my biggest pet peeves is the endless Slack thread. Slack is a great tool, but watching a discussion go back and forth for forty minutes with four different opinions in it, when the whole thing could have been settled in a ten minute call, drives me absolutely crazy.

In an office someone would have walked over and settled it. When everyone is remote, and particularly when half the participants are hours ahead, some of these threads can span across multiple days.

Everyone already knows the fix. During an incident nobody debates it. Someone says “jumping on a call” and ninety seconds later six people are sorting it out. The instinct is right there, it just seems to need a crisis before people feel allowed to use it. So I tell my teams constantly: you don't need permission and nothing needs to be on fire. If a discussion is running long and there are multiple opinions in play, get on a call and talk it through.

Then there's the matter of tracking decisions. Few people can keep up with every thread in every channel, not if they want to stay productive that is. So we have an understanding that every decision needs to be documented. It sounds like a lot of work. In practice it really isn't that bad, and it saves time in the long run.

Every project wiki page in my org has a decision table: what was decided, when, and why. It means nobody has to excavate a channel to find out where we landed, or worse, reopen a debate that was settled three weeks ago because they never saw it happen.

While I think we've made a lot of optimizations to make remote work actually work, it's still important to meet in person regularly, and we do that on a few different cadences. Each team in my org gets together once a year on their own, and on top of that there are two trips I never skip.

The first is Brazil, once a year, where we get the whole team together. We run a few knowledge sharing sessions, but most of the time is deliberately unstructured: ad hoc 1:1s, and a lot of just hanging out and getting to know each other better. That's the part that actually matters, and every time I come away with something I would never have learned if we hadn't done the onsite.

The second is HQ, twice a year, with my leadership team. We use it for roadmap alignment and process improvements, and for what has become my signature session: tell me the one thing that sucks the most right now. We can only get better if we're willing to say out loud what isn't working. That conversation goes very differently in a room than it does on a video call where everyone is politely waiting their turn to speak. It also only works if there's enough trust in the team to give you an honest answer, and that isn't something you can arrange on the day. We always do a team event as well, which is fun, and also does real work.

In closing

I'm not going to make a grand case for or against returning to the office. People have strong opinions in both directions and this isn't the piece that settles it.

What I will say is that remote work comes with real benefits and real challenges. I get to pick my kids up from school, which I wouldn't trade for anything. I also find it harder to shut down at the end of the day, because the office is right there and there's no commute to mark where work ends. That one took me a while to get a handle on, and some weeks I still don't.

What I am sure about is that a distributed team can be a genuinely good place to work. Mine is. That didn't happen by accident though. It took intention: clear agreements, writing things down, and a willingness to call out what isn't working and then fix it.

As I mentioned, none of this is complicated and most of it is common sense. But sometimes reading about it helps you see what wasn't that obvious to you before. Hopefully it did, and if so, you're welcome. Now go build something people want to be part of!