Making Some Hard Decisions About a Geographically Split Team

Chris Rude

Senior Engineering Manager at Facebook



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.

Be notified about next articles from Chris Rude

Chris Rude

Senior Engineering Manager at Facebook

Leadership DevelopmentCommunicationOrganizational StrategyDecision MakingCulture DevelopmentEngineering ManagementPerformance MetricsLeadership TrainingPerformance ReviewsFeedback Techniques

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipPeer GroupsBountiesBecome a mentorChangelog

© 2023 Plato. All rights reserved

LoginSign up