On June 20, we hosted the first-ever «Reshaping teamwork» meetup in San Francisco. Together with our guests Eventbrite’s Pete Lim, Upwork’s Jessica Tiwari and Pivotal’s Aloka Penmetcha, we talked about building products in distributed teams. Today, we are excited to share a full video recording of our panel discussion and a summary of key learnings from our speakers’ experiences successfully managing remote teams.
Learn about your colleagues’ culture
We have product, engineering and design teams globally, in Argentina, Nashville, Spain and other places. Recently, I was visiting a group in Argentina, and the thing I didn’t realize, which seems so silly but is very important, is that their lunch hour starts at 1:00 and ends at 2:00, and here it starts at 12:00 and ends at 1:00. We thought we were being very gracious by booking the meeting at one o’clock for them. But if you know someone from Argentina, lunchtime is sacred, so it’s the worst thing we could have done.
That was a learning because obviously culture is different, and you should spend some time getting to know the culture of the people you work with. Lunchtime might seem like a very small thing, but that was a big thing that I learned.”
Try to empathize with remote employees
of Product Management
I didn’t realize how much burden is on the person who is remote when the rest of the team is collocated. We used to have situations where everyone was collocated and one person was dialing in. There is a lot of burden [associated with] being remote because they need to put themselves out there and be more assertive to be included in a conversation.
Re-evaluate the way you communicate in a team
of Product Management
I used to work for a company that was fully distributed, so I thought I knew everything after I started working with distributed teams for Upwork. Now we have a third of the team located in the office and two-thirds are not. As soon as you have at least two people who are working together in the same space, the complexity in aligning people is so much bigger. When everyone is distributed, the paradigm breaks down and you have to find a new way of communicating.
There are a lot of facets to effective communication, but killing water cooler conversation is a big part of it. We make sure that any decision you’ve made is written down, so people who weren’t there can refer to it. With our remote Agile teams, engineers can be very distant from strategic decisions made at a higher level. We also have short team meetings with those teams so they can get a debrief on what the leadership team discussed, what the strategy is, etc., and they can see which problems the company is trying to solve.
Minimize information disparity and add regular meetings for alignment
For me, a huge part of how to manage the inclusion of people who are distributed tends to be about having people understand that transparency minimizes information disparity and [reinforces] the team values and principles.
At Pivotal, we also have certain rituals that are very team oriented (standups, retros, etc.), and they help teams be autonomous and iterative in process. It’s imperative that, whenever you have distributed teams, you have to be thoughtful. It’s not going to work itself out.
Listen to your team
People communicate in different ways, and it’s hard to implement one communication strategy as a solution for everybody. It’s important to give distributed teams the space and flexibility to create their own processes. Instead of proposing something, ask them what the actual challenge is here and create an agreement on how you will work together. We do that a lot at Eventbrite; we foster these conversations. It’s important not to jump to conclusions.
Don’t judge people by one single factor
We have some incredibly talented people on our team who really hate talking in any meeting because English is their second language and often I talk too fast. So these people are more comfortable with chats and written communication. We need to rethink how we evaluate people and how we can measure their progress, separate from how well they can talk. That was a key learning about how we can be successful with teams that are super distributed.
Facilitate networking onsite
We have around 2,500 people and around 21 offices across the world, and there are also fully remote individuals. I think a huge part of it is decentralizing, so each office has its own leadership and autonomy to run the office without consulting with HQ. It means that people are more engaged, and the career path also tends to be easier.
The harder thing is when someone is not tied to any office, because it’s hard for them to make connections. I think a huge part of growth is to do networking. We have people flying in every month to work with the team. They can be collocated as much as they want to, and we will pay for it. It builds more relationships with the team, and they can also talk to other people in the office and look for opportunities. As a manager, I’m also always looking for opportunities for remote workers.
Create space for people to build relationships
We have meetups for product, design and engineering employees who are distributed and work from all across the world. We started doing these meetups every year and a half. It’s not frequent, but you’ll be amazed how well it works. We get all of these people together in a place where none of them live – often somewhere in Europe. It’s about 10 days, like a summer camp. It helps build personal relationships at a speed that you lack when you don’t meet people face to face every day. It really helps with retention of these distributed team members and also with engagement.
Invest in good tech
The amount of non-verbal communication that you do when you are in the same room with somebody is phenomenal. When we send emails or message each other, there is so much that is lost there. So if you invest in good tech, you are trying to narrow that psychological distance between people so it feels more like face-to-face.
When hiring someone, don’t forget to check the basics
When we are hiring people who are going to be distributed, we check basic things like, ‘do you have bandwidth to work? Can I talk to you on a video call?’ It can really be a barrier.
The second part is that, in order to be successful, you have to be enormously autonomous. That’s the best way to make it work. Practices like test projects and short-term evaluation are something that we carry through with all our distributed employees or freelancers. It’s also great when people who are distributed can support each other. We have enough remote PMs that we started weekly remote PM breakfast sessions, and they just discuss their challenges. It’s a bunch of tips and tricks for people who know exactly what you are going through.
Invest in people, especially in the onboarding phase
I don’t think there is anything we can do to make distributed better than collocated. So at Pivotal, for onboarding you have to be at the office. When we hire someone, for the first one to two months they are at the office working with the team to build the relationships and build the context. As a company, we should invest in people who are distributed and do what’s needed to reduce the friction.