It was the best of teams, it was the worst of teams…
Distributed teams are terrible.
There’s no team cohesion, there’s difficulty communicating with one another, meetings at inconvenient hours, constant loss of context, rebuilding context and rebuilding context again, and time zones.
They’re bad enough to deal with as a developer, but as a constant irritant to getting work done every day, they reach a whole new level of annoying.
Distributed teams are great.
You can hire the best talent regardless of location, people can work on their own schedules, there’s always someone around to help out, more and different perspectives result in a better product and a more flexible, productive team.
Both of these viewpoints are true to a certain extent, and for those of you who’ve worked in distributed teams before, you likely have examples which fit nicely into both statements.
The thing is distributed teams are no better or worse than co-located teams, they’re just different.
So I firmly believe that any team organization can be made successful, but each team requires different rituals, techniques, and practices in order to make it so.
There are dozens of books and hundreds of blog posts on the subject. Some of them are even pretty good.
Today, I wanna talk to you specifically about my experience building and scaling successful distributed teams. That way, you can avoid some of the mistakes I’ve made as well as benefit from some of the things that went right, even the accidental ones that I only realized in retrospect as well as the ones that I realized while writing this presentation.
Some background
So thanks for coming today.
My name is Jason and I work at Shopify as a senior manager.
My teams do a mix of infrastructure development and site reliability engineering, specifically dealing with the company’s stateful systems.
I’m gonna take you through my time at Shopify since becoming a manager about four years ago.
In that time, I’ve directly managed and help grow three different distributed teams with various blends of in-office, cross-office, and remote workers. The 2 dozen people whom I now support are spread across 10 different cities in 3 countries, span 6 time zones and 4 offices.
What infrastructure do distributed teams need?
I’m very, very thankful for video conferencing. And speaking of video conferencing, the first step towards successful distributed teams is a supportive, physical and digital environment.
That means meeting rooms with decent acoustics, headsets for remote folks, group chat for everyone, issue tracking systems, source control, good chairs.
If you’re trying to build out a distributed team and your physical environment is getting in the way, fixing that is pretty much step zero.
This picture here is one of the conference rooms in my office back in Ottawa. There’s a few things to notice here.
So the monitor and the camera that’s sitting on top of it are set up so that anyone remote can see the whole room. It’s a little tough to see in the picture, but there’s a couple of mikes coming down from the ceiling and the back wall is made of echo dampening material. It’s basically covered in felt.
Also, the chairs are good quality and they’re comfortable. I know I’ve sat in this room.
I’m fortunate to work at a company where people have thought about this and mostly taken care of it and it only requires the kind of occasional intervention or tweak.
If your company environment is not this friendly to distributed work, I’d suggest treating the physical improvements the same way you’d treat a software project.
Figure out what the biggest pain points are by interviewing your customers, in this case, the distributed teams that are going to use it, the equipment, fix those first and iterate.
Or you could just come work at Shopify.
Either way, distributed work gets a little bit easier and better.
What infrastructure do remote workers need?
The other side of this equation are people who work from a home office or a co-working space. These people will all have slightly different setups, different routines.
The best thing you can do is pay for stuff. Your company’s saving a bunch of money because they aren’t taking up physical space in an office. Funnel that money into reimbursing them for good monitors, headsets, chairs, standing desks, whatever it is that will make their places of work comfortable and productive.
And most importantly for digital work, which was what most of us do, make sure they have an excellent internet connection.
It’s the conduit through which they’re going to interact with the rest of the team in the company.
It’s bad enough for the remote person in question, but if you’re trying to sell the rest of the organization on the merits of distributed teams, you don’t want them to experience distributed work as blocky pixels and robotic choppy voices.
Make sure that everyone understands that physical and digital environments need to be of equivalent quality across the whole team. Back that understanding with money and an easy-to-navigate expensing process.
How to manage and expand distributed teams
So now that we’ve talked about some of the more practical physical support needed for distributed teams, let’s get into organizing and growing the teams.
We’ll start at the beginning of my managerial journey roughly four years ago.
The first team I managed consisted of six people, five in Shopify’s Ottawa office and one in Winnipeg. They’re indicated by the arrows here.
And if you don’t know a whole lot about Canadian geography, that’s roughly longitudinally equivalent to Minneapolis, Minnesota and Washington, DC. When I did this presentation in front of one of my American coworkers, his reaction was “Nobody knows where Minneapolis is,” but it’s on the map, so.
Basically, it’s a couple hours by plane or a really, really, really long day in a car but only in the summertime.
So I didn’t know it at the time, but this is a really dangerous configuration for a distributed team.
Because there’s a center of gravity with the physically co-located members in Ottawa in this case, it’s easy to accidentally starve the other team members of information.
Humans are social creatures. If you’re physically surrounded by people who are working on the same problems as you are and you need their help, all you have to do is look up and start talking.
Now, I didn’t have much experience as a manager at this point, so I just generally treated it like a co-located team with one of the members on video conference.
You can imagine this didn’t go very well.
At one point we made a major technical decision during an impromptu hour-long whiteboarding session, which only got communicated to the Winnipeg member of the team a week later.
Imagine how angry and frustrated this would make you.
Now, fortunately, this person wasn’t shy about pointing these things out and rightly let me know how difficult this was for them.
This didn’t feel great for me either. As a first-time manager, you know you’re going to make mistakes, but it still stings when they happen.
The rules of distributed teams
Which leads me to the first rule of distributed teams.
There are only two types of teams: co-located and distributed. You’re one or the other, never both.
The second is that if your team is not entirely physically co-located with one another for the vast majority of their working hours, you have a distributed team and you need to treat it as such.
It doesn’t matter what the ratio is, whether it’s working from home or a coworking space or multiple offices. If you want to contribute fully, if you want people to contribute fully from anywhere, you need to make sure that the communication of information is location-independent.
What does that really mean? Well, it means that the way the team acts and interacts needs to be consistently and constantly aware of the distributed nature of the team.
In practice, it boils down to three things.
The first one is every team meeting is a video conference, every single one.
Make this as automatic and frictionless as possible.
Set up your calendaring software to automatically add a video conference link to every meeting by default and then use it.
Make it a habit to log in when the meeting starts.
If the discussion is going to be something that will be helpful for people to refer to in a month or two or three, or useful to new people joining the team, record it. Provide attendees with a written summary of the decisions made and actions to be taken.
In fact, write it all down.
Chat, email, documents, spreadsheets, issues, tickets, presentations: all these things can be indexed, they can be searched, they can be recalled, you can update them later, you can edit them, but the most important attribute for them on a distributed team is they can be consumed and contributed to asynchronously, unlike a meeting.
Try doing that with something someone said in a meeting last week—or was it the week before?
Actually, it wasn’t that meeting at all.
And finally, be aware and cognizant of time zones.
Some things I’ve done, which you should not repeat, don’t ask people to review code when it’s late evening for them. Don’t book team discussions at 6:00 in the morning. Don’t send chat messages out of hours when it’s not urgent. Make sure everyone in the team is aware of when people are working and where they’re working from. Designate a set of hours during the day as acceptable for everyone and enforce it.
Just generally be respectful of people’s time, their day is not your day.
And adjust the communication accordingly.
Now, fun fact, did you know that the idea of time zones, as well as universal coordinated time, was invented by a Canadian, Sir Sandford Fleming? This is a picture of him. He’s got a very nice beard.
It’s my theory that this is why Canadians apologize a lot. It’s because we inflicted time zones on the world and Celine Dion and Justin Bieber.
So on behalf of my country, I’m sorry. But back to distributed teams.
The distribution of people on your distributed team…
So now doing all of this is easier to implement when the distribution of people is more even across locations.
That’s why I stated earlier that the team configuration of five co-located in an office and one remote working from home was particularly dangerous.
There’s an imbalance and an inequality there, which means that the benefits of changing the methods and styles of communication is felt unevenly across the team.
It doesn’t make it any less important to do, but it might make it harder to implement.
So our lovely Winnipegger who’d been excluded from the technical discussion earlier, he’s one of the senior technical members of that team and someone who we absolutely needed to have full context on all of our decisions in order for the team to be successful.
So how did we overcome the natural human tendency to collaborate in person so that he’d be included in the decisions and the discussions?
Make all your communication remote first
Time for another rule. Remote first means in-person last.
So at about the same time that all of this was going on, the Ottawa office was getting an upgrade in our buildings.
So that included new pods for our department. So we had three pods each capable of holding between 10 and 15 engineers. And of course, teams all wanted to sit together, so we had a draw to assign the spots.
We got a hat for each pod and each team was put into a hat…except for my team. For them, two of the hats got one team member each, the third hat got two team members, but those two were told that they had to sit at opposite ends of the room from each other. And the last team member was me and I decided to go squat in the pod down the hall, which was empty at the time.
So I sat by myself in a corner of that pod for six months until another team needed it and kicked me out.
It ended up looking something like this with the red arrows indicating where people were sitting.
The team thought this was crazy. And I still think they do. It kind of was, I think at the time.
Maybe I’d read it in a book or a blog post or whatever, but my flawed memory, he says, I kind of came up with this on my own.
It doesn’t really matter where it came from because it worked.
So even though the team members were only separated by a couple of dozen steps and a couple of flimsy walls, that was enough friction to drive most of the discussion and problem solving into chat, issue tickets and video conferences.
It wasn’t instantly perfect of course, but the team definitely got the message that all communication should be remote first.
Face-to-face collaboration was still okay, but the decisions made were now documented and many discussions were stopped temporarily only to be restarted later via video conference.
If you want remote first to really work, you need some friction for the other modes of communication that might occur more organically.
How to pick your distributed team
Next challenge, growing the team.
So my first time as a hiring manager also had a few bumps.
Another rule: new company, new tech, new to distributed work, you get to pick two.
So hiring someone is an exercise in calculating risk-reward ratios. You want to minimize the risks, maximize the reward. The sum of these risks is largely predicated on, “I’ve never done this before.”
Hiring someone from outside the company is riskier than an internal transfer. There’s a whole set of cultural norms, internal jargon, and processes to understand and apply.
Similarly, hiring an engineer to work with a set of technologies they’ve never touched before is riskier than someone who’s been using those same technologies for years.
But since this is about distributed teams, let’s talk a bit about “new to distributed work.” I’m not saying you shouldn’t hire people who’ve never worked on a distributed team. I’d never worked on a distributed team before Shopify, although the rule still didn’t apply to me. (My first team was co-located).
I’m saying that hiring someone who’s never done distributed work for a distributed team is riskier than someone who has.
The way distributed teams operate and communicate is different. And if you’ve never done it, that’s one more big thing you need to learn.
And there’s only a certain amount of “I’ve never done this before” humans can take before they feel really overwhelmed.
Now, you can maybe ignore this rule if you’re really amazing at onboarding or your company has this incredible onboarding program. A great onboarding program will reduce the anxiety around all the newness and give people a better shot at success.
I’m not that good at onboarding yet.
The hiring mistakes I’ve made can largely be traced back to not following this rule.
But whether you agree with the rule or not, let’s suppose you do hire someone who’s new to distributed work.
How do you set them up for success? So we’ll take a look, we’ll take a break from rules, and we’ll look at a few tips and techniques on how to do that.
The importance of written communication and documentation
Documentation, yeah, it’s a great sign.
Documentation issue, details, pull requests, descriptions, group chat, design and architecture documents, emails, spreadsheets, presentations, notes, you name it, it’s all written communication.
In a distributed team, it’s not just the trail you leave behind, it’s how a lot of people experience you as a person.
Becoming a better writer has all kinds of benefits, but in a distributed team, it’s fundamental to being understood and effectively doing your job.
Set the expectation in your team that writing clearly and well is a skill people should be constantly working on improving, and pay for training and materials here just like you would for someone who wanted to learn and Go or Ruby.
So the whole notion of butts in seats comes from physically seeing you in a chair at a place of work. For the type of work we do, I’d argue that’s not desirable. But without getting into that in a distributed team, it’s not physically possible.
Distributed team members need to make the effort to communicate regularly and frequently with teammates. Co-Located teams get this mostly for free because they can all see each other, gather around the water cooler, talk about Chernobyl over lunch. But if I can’t see you, I need other reminders of your presence and your work.
So don’t fall into the trap of putting your headphones on and diving into code for eight hours a day every day.
That can be appropriate of course, and it’s often necessary, but it’s not going to lead to long-term success because the visibility of it is poor.
Some ideas for one-on-one meetings
Software development is a team game and if you’ve ever played or watched a team sport, you know that players and coaches are constantly communicating to improve their outcomes.
One-on-ones between managers and individual contributors are a fundamental tenet of management and team functioning at Shopify. They’re effective, they work, half my calendar is taken up every week by them.
There’s lots of books and podcasts and articles about how to do them well, and I encourage you to hunt those down and apply them.
On a distributed team, peer one-on-ones become much more valuable as a way of increasing trust and empathy between teammates.
It’s important to get the ball rolling here, facilitate introductions, make sure people know it’s okay to spend time discussing things and getting to know their teammates. For example, we frequently have lunch or coffee breaks over a video conference.
Building stronger connections between people makes for a stronger, more resilient and more productive team, and that happens by talking about life things as well as work.
As peers develop deeper relationships, they’ll be more comfortable being vulnerable around one another.
It’s pretty tough to admit to your boss that you don’t quite get Kubernetes when your whole tech stack is resting on top of it, and you’ve been using it daily for the past six months.
Pro tip: your boss doesn’t get Kubernetes either.
Learning necessitates that you’d be able to admit you don’t know something, and that means you’re putting yourself in a vulnerable position.
Saying the same thing to a peer is certainly not easy, but if the trust is there, being vulnerable and open about these kinds of topics opens the door to learning and improvement, which is exactly the direction you want your team going—because it means they’re getting better.
Check in with your team members
And finally, check in.
Just be there, say something, ask how their day went. Make sure they feel included in team conversations. Offer a quick chat to explain a concept or draw an architecture diagram.
Basically, be there to support them in small ways so that the tide of newness doesn’t overwhelm their brains.
Being the new person on the team or at the company can be really stressful, confusing, sometimes lonely, and it’s much harder if you don’t have that face-to-face physical contact with people that makes these new relationships much more tangible and real.
Small gestures can go a long way to alleviating those feelings and building a trusted relationship.
I mean, look at these two. Look at how happy these people are to be checking in. If your team is even half this happy, you’ve won
So doing these four things——writing more or writing, better, over-communicating, peer one-on-ones, and checking in——doesn’t guarantee success with a new hire on a distributed team, but it’ll go a long way to ensuring that new hire is given a solid foundation from which to grow and thrive.
Now, after having worked with this first team for a while, I was asked to start a new team to tackle a different set of systems and technologies.
So this team consisted of four people, myself included, in four different physical locations, three offices and one person working from home. And that person’s home was in Dnipro, which is the fourth largest city in Ukraine.
Now, depending on the time of the year, the time zone difference between the team members is either six or seven hours, and that means it’s time for another rule.
The impact of time zones on collaboration
Time zone differences make collaboration exponentially, not linearly, harder.
Differences of less than four hours are pretty manageable. There’s overlap between team members, lots of opportunity for interaction.
You have to make sure that people structure their days appropriately to make room for those interactions, as well as being conscious of the time zone differences when scheduling meetings. But other than that, it’s not too difficult.
Between four and eight hours, things start to get harder.
In my case, I was lucky that the engineer who was six or seven hours removed from the rest of the team had been working like this for years and knew how to manage it.
So he’d worked for a while in his morning while the rest of us slept and then take a midday break to have lunch, go do errands, go to the gym.
He’d then work another few hours in his afternoon, evening, which was our morning and they talk with the team, answer emails, chat with us, participate in any meetings we had scheduled.
Now, that worked really well, still does, but that’s not a sacrifice everyone is willing to make and it’s something that you need to evaluate when composing teams.
Be upfront about it. If shifting your day is an expectation of working on that team, make sure people know that beforehand. You don’t want to be surprised by this when you join a team.
When the time zone difference is larger than eight hours, it becomes significantly more difficult. This is the exponential bit of the curve. You have to treat this more like a day shift, night shift kind of situation (or day shift, day shift depending on time zones). See, this is why they’re hard.
People may be doing the same kind of work in the same areas, but trying to work on specific projects together across such a large time zone difference is very difficult.
It’s better to separate the work into pockets which are temporally closer than to ask people to work night shifts and have meetings at terrible hours.
Now, some of you might disagree and have seen this work well. If that’s the case, I look forward to your conference talk because I really like to learn how to do this properly. In my experience, it’s something you should avoid (if at all possible).
A year and a half later…
So fast forward about 18 months and with some hiring growth, the second team got large enough that it needed to be split into two smaller teams.
Meanwhile, the first team I talked about earlier had also become larger.
So hiring was going alright. The work of these three teams was related. They all dealt with the development and reliability of stateful systems. So the decision was made to put them all together in a larger group, and I would be the manager of that group.
The three teams still worked independently from each other and each team would have a manager. I’d be looking after any shared concerns across the group and making sure that the teams were well supported and sharing information and solutions.
All in all, this group consists of about two dozen people. The red arrows on the map represent where they work and live. Some of the arrows represent more than one person.
So these three teams are all configured a bit differently, but each team has a presence in at least three separate physical locations and are a mix of in-office and work from home engineers.
Distributed leadership for distributed teams
And that brings us to another rule: distributed teams have distributed leadership.
This one, I’ll admit, I kind of lucked into a bit given where the existing team members were, but as the team grew and hired over time, it became a deliberate strategy.
The senior members of these teams, both on the technical and the managerial tracks are spread out across different offices, with two of them working from home full time and everyone working from home part-time, myself included.
There’s also a four hour time zone difference across the leadership group.
So having their leadership group be as spread out as the rest of the team shows people that this is really about walking the walk.
You need highly trusted people across all locations to deal with something happening which is geographically specific, like for example the Toronto Raptors winning the NBA Championship and Toronto collectively losing its mind for about a week and a half or two.
Your leadership group reminds you that decisions and policies need to be inclusive and fair to all locations and modes of work.
And if like me, you’re in a company which also has a number of co-located office teams that you collaborate closely with on projects, it’s pretty great to have a local person in a senior position to have discussions with those teams in the way that they are used to working, which is in-person.
The benefits of having experience spread around make the whole team stronger and help dissipate the branch office type of issues, which can come when a team has a clear physical center of gravity.
So here’s the map of North America again. It’s the same locations, but the arrows are now color-coded. The Blue Arrows are where people managers are, the Green Arrow is a technical lead, and the Yellow Arrow is an office with both managers and technical leads.
So you can see it’s spread out reasonably well.
Having distributed leadership is also really great for hiring.
So some people have the flexibility to work from anywhere or relocate to another city. A lot of people don’t.
Having senior team members everywhere means that my group can be in on all the hiring conversations. So when a good engineer comes along who will likely need some fairly intense mentoring and they can only work in say Montreal, we become a possibility.
And in a high growth organization like Shopify and like a lot of the places you work, I’m sure, it also means you aren’t limited by the size of the local talent pools. Your potential hires can come from a variety of places and backgrounds.
It’s taken several years to get to this point, but I consider the geographical distribution of experience a huge advantage, and one of the main reasons why this group has retained a strong distributed culture.
And that’s where the group stands today. It’s three teams. This is all of them, each distributed differently across multiple locations and modes of work.
So now that I’ve gone through how we got there, I wanna share a few more things we do to support and enhance distributed work.
Team-building activities for your distributed team
The first one is probably counterintuitive. You should get together regularly in real life.
Once a quarter is ideal but make it at least twice a year.
Budget for it, plan for it well in advance, publish the dates, make sure people understand that it’s an expectation of their jobs.
The focus of these get togethers should be on building relationships between team members.
These relationships are what the team is going to lean on when they’re hundreds of kilometers (or miles) in this country from each other and trying to make difficult technical decisions.
While the ability to leverage technology to work in a distributed fashion is amazing and wonderful and fantastic, it’s also something which is at best a couple of decades old.
Humans have been relating to one another face to face for hundreds of thousands of years. The processor in between your ears is tuned to understand and build off of these interactions and you should use it regularly to your full advantage.
The two modes of interaction are not mutually exclusive. You can support distributed work while simultaneously acknowledging the importance of physical interaction. And used together, they amplify and support each other.
So the picture here is part of the team skating together on the Rideau Canal in Ottawa. The Rideau Canal is the largest skating rink in the world. It’s in January, that’s why everybody’s wearing tubes.
Now, not all Canadian team activities involved skates in winter just to put that stereotype to rest, but clearly some of them do.
The next tip is to make virtual space for something that co-located teams get for free, which is water cooler talk.
It’s not really free, and its lack is something which is often cited by people who work on distributed teams as a benefit, but I’m here to tell you it’s important for the same reason as getting together face to face is important: it builds relationships.
Without sounding too salesy, it’s not only nice to know what people did on the weekend, what their hobbies are, or how that restaurant was last night. (It’s really good.) It’s vitally important for the success of a productive team.
How chatbots can help
Your team will make hundreds of engineering decisions over the course of a project, most of them collaboratively.
It is much harder to make these decisions with strangers because you don’t know what makes them tick.
In my teams, there’s a couple things that have helped people to get to know each other a little better. They’re both done via a chatbot, which posts a series of questions to you as direct messages at set times during the week, and then broadcasts your answers as a single message into a team channel.
Oof, that’s a lot of texts.
So here’s the first set of questions which is asked on Mondays. It’s not complicated, but it hits a lot of different areas though the first question is the standard, how was the weekend? This helps getting to know people, what they’re interested in spending their free time on.
The next one is great for sharing books or articles which have often sparked interesting discussions among team members. It’s also good for people who want to point at issues, code changes, pull requests, tickets that they found particularly noteworthy.
The third one’s a bit more procedural and kind of lets everybody know about vacations, travel conferences, you know, where are you physically going to be and how can I get ahold of you kind of thing.
And the last one is fishing for new questions and making basketball jokes.
And this is the Friday afternoon set of questions, shorter, this Friday afternoon.
These are more anchored around gratitude and expressing appreciation for others. It also gives people a venue for expressing doubts and fears.
So not everyone will be comfortable with this level of disclosure, and not everyone answers this question or these questions.
But normalizing gratitude, appreciation and sharing is something which pays huge dividends over time.
Especially for a group who’s tasked with the stateful systems of a multi-billion dollar company, which is what these people do, mistakes can be really costly, and making sure there are multiple safe spaces to express these kinds of feelings is paramount to long-term psychological health of the team and its members.
So these last two slides were a sampling of my answers over the past couple of weeks.
In a group of two dozen people, there will be people with which you don’t interact all that often.
People who know me well probably didn’t learn much from the above answers, but I’ll bet someone on the team did.
And it’s especially important and valuable for people who are new to the team or the company as they’re able to find others with whom they might have something in common or from whom they can learn.
In conclusion…
So distributed teams are terrible, and distributed teams are great.
The fundamental requirement to getting more great and less terrible is pretty simple.
You need a team with some amount of organizational power that cares deeply about making the environment amenable and productive to distributed work.
If that’s true, all you have to do is make sure that your iteration speed on making things better is fast enough and you’ll get there.
The information I’ve shared today was designed to help you avoid some of the pitfalls in this process and give you a head start on making things better.
There’s lots of organizations and teams who do this well, and I encourage you to stand on their shoulders and learn from their mistakes.
Thank you.