Distributed Teams: A Lesson In Expectations, Connection, and Inclusion

Problem

We have been building distributed teams across multiple locations, which is relevant now because everyone is going remote. It can be challenging to figure out how to go about building and getting teams together remotely.

I have teams distributed across three different locations, Seattle, New York City, and San Francisco. My job is to grow my teams across these different locations, which ranges from ICs to managers.

We have been building these teams out for the past couple of years. Given some of the challenges, I had three different goals I wished to accomplish. I wanted to fill the void that happens from in-person interactions. For example, when you work at a desk with everyone in the same building, people run into each other and can quickly brainstorm ideas. Obtaining this flow is something we miss. How can we fix that?

The second goal is more about inclusion. How do you get everyone involved in the discussion and decision-making? If certain team members are left out, that gap can impact the speed of our decision making and brainstorming.

The third goal is ensuring we are keeping documentation of our virtual interactions. This goal is important for posterity reasons as well as bringing data and previous discussions to our decision making. Documentation should give us something to refer to when necessary and help us keep up to date across our different teams.

In addition to those three goals, I have been trying to figure out how to grow people within distributed teams. Since not everyone is working at our headquarters, how do we plan and develop people into their roles? Furthermore, how can we promote them into more significant roles?

Actions taken

One approach I took to help solve for some of my goals was to institute a café discussion. It is a free-flowing discussion and forum where people can grab lunch and then participate in the forum. It allows for and encourages participants to talk about anything they want to. It might start with an agenda collection at the start, then the rest of the meeting is structured around those topics.

The topics discussed might range from engineering discussions to team improvements to process adjustments or any other issue that the teams want or need to address.

The second thing I implemented during our meetings and discussions is to encourage conversations around personal experiences. For example, I encourage everyone to share a story from his or her past week that is non-work related. These stories can help us have a better connection with our teammates and see how they are doing outside of work. Like, did someone go for a concert, or did something interesting happen at someone’s childcare.

The third thing I have done is to create an “always hangout.” We have some monitors all across our different locations that have a Google hangout continually running. It is almost like a live stream between each site, and it allows for a more natural and quick virtual interaction. Anyone can jump on and ask quick questions rather than trying to schedule meetings or have drawn-out conversations on Slack.

I also introduced standups which has everyone speak about their workday or his or her daily goals.

We also have what is called “parking lot” time, which is 30 minutes allocated to the end of our meetings. If we have a topic that comes up and is not necessarily related to the meeting discussion, our parking lot time allows us to table it for later in the meeting.

To accomplish the goal of documentation, we have everyone creating a paper trail of what is happening. For example, if two people are discussing an important topic on Slack, we should have them go back and capture that conversation. Now we have a record of that, and it can help others in the company be aware of what is going on.

Lastly, with distributed teams, I wanted to build an organizational muscle around the growth of our teams. To do this, one of the things I have done was formalize the patterns and took over the initiative to how everyone grows individually. I wanted it to be more objective than subjective in terms of what we were looking at within each level. We put it on paper and socialized our new thoughts to the teams to have a better idea of who might be going down a management path or a senior IC position.

Lessons learned

By aiming to accomplish the different goals, there is an opportunity for our teams to be better connected. For example, the open forum has helped a lot because the various teams get a chance to talk about anything they want to, which creates a deeper connection between those individuals and the teams.

I learned that Google hangout has been super helpful for everyone. It allowed the teams to engage in quick and productive conversations, which moved many things much quicker. By creating the paper trails of our discussions now, we do not leave people out of meaningful conversations and learnings. It is incredibly helpful when we do not have to make sure that everyone is being included actively, especially when we have a way that keeps everyone updated.

For the career growth and growing out teams, the approach to formalize the process and put things on paper has allowed us to be more purposeful. It is much less personal and more objective. Now we can easily acknowledge that someone is doing great we may have missed initially.

The new focus has shifted, which helps us understand the real impact someone is driving, and as long as I can show that real impact, his or her growth has happened. Now the ability to grow people into different offices into senior ICs and managers is excellent. This indeed highlighted the importance of getting everyone aligned on how we should think about growth.

As I worked towards all of the different goals, I also learned some other high-level lessons. The first lesson is to understand the cost of distributed teams. This is important because you can plan all the work your teams are going to complete, but to effectively plan all your work, you need to have conversations around the cost of your teams. If you are not mindful of that cost, you can end up paying more by shifting to a distributed workplace. This costly mistake and result in your distributed workplace failing.

The second lesson that was a big learning curve for me was that you should not shift to distributed teams and think everything is going to work out. You must be intentional. Being intentional is more than just one person, as well. Everyone needs to be on board with the changes and the shift. Everyone on the team needs to understand the change and have a level of investment in it.

By being transparent and repeating the message, our teams can understand why the change is going to be helpful. However, too much resistance to the change is likely going to make success harder.

Understanding those two takeaways has helped me effectively communicate to my teams, the stakeholders, and leadership to make sure they know where I am coming from, the costs involved, and what we are learning during this process.

I would say like anyone fresh and new to shifting to distributed teams that these are two big blind spots at the beginning, and the sooner you are aware of them, the better.

Overall, the goals and ideas are to create a similar experience for everyone within the teams and different locations.