login


Google Sign inLinkedIn Sign in

Don't have an account? 

Making Some Hard Decisions About a Geographically Split Team

Team processes
Remote
Reorganization

29 April, 2020

Chris Rude, Engineering Manager of Managers, Payments Infrastructure at Stripe, explains how he handled some hard decisions about a geographically split team.

Problem

At that time I was managing a number of managers and had been put in charge to manage this particular team. The team was working on a broad set of internal tools important for the company -- including all communication tools -- and involved a great many stakeholders. It consisted of six engineers, each assigned one area of work with no collaboration or overlap taking place. Our internal survey indicated that the team was fairly unhappy -- they were always behind, lacking the direction, and felt that no one is appreciating their work. Meanwhile, the stakeholders were upset because the team was failing to deliver. I identified two main problems:

  • The team was doing too many things at once.
  • The team was split between two offices with senior engineers all located in Seattle and junior engineers, team manager and all the stakeholders based in the Bay Area.
     

Actions taken

To become more familiar with the situation I decided to have a coffee chat with all the engineers. I tried to present myself as someone who is genuinely interested to learn about their problems and help. It was clear that the team was overwhelmed and that the former manager was not able to control the situation as he was more keen to please the stakeholders than to stand up for the team.
 

The next thing I did was to critically evaluate a roadmap for the team and make priorities. I encouraged the team members to prioritize tasks and I vouched to give them air cover mediating with stakeholders. To curtail the overwhelm I proposed that the maximum number of projects should not exceed the number of engineers divided by two. For example, if you have six engineers there shouldn’t be more than three projects at the time. By pairing people up we prevented fragmentation and bolstered collaboration.
 

The geographic splitting of the team had its own ramifications. The senior engineers in Seattle were underutilized and felt they were not plugged into what was happening. If deployed effectively they could solve some of the problems with their experience and capacity. Early on I realized that the ideal situation would be to move everyone to Seattle but being such a sensitive issue I didn’t want to bring it up immediately. I understood that the manager I would be asking to make this happen would be putting himself out of the job and I needed him to go along with it.
 

We had the manager coming onsite to talk through different aspects of the problem. We wanted to encourage him to make the decision since he knew the team better than anyone else.
 

I lessen the tension by presenting two options: either to split the team into two subteams located in Seattle and San Francisco that would be both empowered to own a separate area of the product or to move everyone to Seattle. My preferred option was the latter. We went through all the pros and cons and the manager agreed that the best solution would be to have everyone in one place. When we had him on board things started to unfold naturally from there.
 

During the whole process, we were very transparent with the team and shared with them all we knew at that moment. When we were certain that the team would be headquartered in Seattle, we were distinctly clear that no one working in San Francisco would be laid off and that we would find a fulfilling job for each and every engineer. This eventually happened -- we found a good home for all the engineers. It was important to communicate transparently and understand why people are angry and upset.
 

The stakeholders were initially disappointed because many of their requests were deprioritized but in the long run, they knew that their demands were not sustainable and that the team wouldn’t be able to deliver on them. One of the reasons they were angry was that they were led to think that the team could deliver on their demands. We were clear that for the first six months the team would work only on the top-priority projects but we were willing to find another team to help out or to find some creative workaround. By getting the roadmap under control and managing effectively stakeholders’ expectations we made them more appreciative.
 

Lessons learned

  • The clear and uncompromising commitment is of vital importance. We were resolute that we will have a team working effectively, burdened with a reasonable amount of work an that people on the team will feel good about the work itself.
  • It is important to get people on board with messy things and join forces to figure out the way.
  • If the journey from today to the happy future world (which eventually materialized) would come as a proclamation it would come rougher on everyone. Treating people with respect implies to be open with them about what is happening and to hear their concerns.

Related stories

How to Effectively Communicate on Slack
6 July

Shridharan Muthu, VP of Engineering at Zoosk, discusses effective communication using Slack including a recommended framework that entails three simple tips to make the most of the tool.

Internal Communication
Remote
Productivity
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Improving Collaboration Between Engineering and Product Across Time Zones
6 July

Shridharan Muthu, VP of Engineering at Zoosk, describes how to make communication effective between PMs and engineers when they are located in different time zones and have very little overlap.

Collaboration
Internal Communication
Reorganization
Remote
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Handling a Mistake - Adopting a New Workflow
6 July

Shridharan Muthu, VP of Engineering at Zoosk, describes how he quickly agreed to adopt new workflows, a mistake he later regretted, and how he handled the situation by spending the time to course correct and taking a stab at making things easier for his team.

Team processes
Agile / Scrum
Collaboration
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

An Acquisition Across Time Zones
6 July

Shridharan Muthu, VP of Engineering at Zoosk, speaks of the time his company was acquired by another org in a time zone half a world away, listing issues and providing solutions to how he overcame the time disparity while transferring product knowledge.

Reorganization
Internal Communication
Motivation
Remote
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Cultivating a Relationship Between Collocated and Remote Teams
3 July

Arjun Rao, Director of Engineering at Place Exchange, highlights three ways that induce a genial, positive, and flourishing atmosphere between collocated teams and their remote, contracted, or outsourced counterparts.

Remote
Collaboration
Company Culture
Arjun Rao

Arjun Rao

Director of Engineering at Place Exchange

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.