Managing an East Coast Team From the West Coast

Problem

I started my job as a remote engineering manager based on the West Coast while my organization -- with its culture of “everyone should be in the office -- was located on the East Coast. I was tasked to modernize the way the team was thinking and building products. But being remote, it was hard to build relationships, understand people, and influence change.

At that time, video conferencing wasn't widely used within the organization, which almost made it impossible to have regular face-to-face conversations on a video call.

Actions taken

Time zone difference was one of the biggest challenges I encountered from the start. I wanted to make sure I get maximum overlap with the teams in NY and Toronto. Even though I was (and I am still) not a morning person, I started working on Eastern time and would begin my days at 6 AM. That helped me schedule more meetings and have more conversations with others which, as a result, allowed me to understand better the product, office culture, and technologies we used. I also started traveling to the East Coast often (once every four to six weeks), which helped connect with other team members.

To be able to modernize the existing solutions, it was important for me to understand the use cases, architecture, technology, and most importantly, what team members thought of the code and architecture. Once I thought I had some grasp of the situation, I started recommending different architecture patterns and implementation strategies, which not everyone was excited about. Some weren't sure if I understood all the complexities and use cases enough to recommend changes as I was still fairly new to the organization. Understanding the reluctance in the team, I decided not to rush to change anything significant but to set myself a goal of a few months to thoroughly understand and "appreciate" what I was working against. We kept making small improvements day-to-day, though.

This strategy helped me become a part of the team and earn the trust of others, as I was able to demonstrate my skills without having to challenge anyone. Once I earned the trust of the team, it was much easier to influence changes in design and execution and take our product and engineering in a different direction.

Finally, I also had scheduled casual one-on-one meetings with many people across the organization, which helped me establish and maintain a good relationship despite being away from the office.

Lessons learned

• I probably went overboard with my work timing. I could have worked on Pacific Time, and people would have still supported my efforts.
• Seeing each other and talking (even on a video call) is a lot more effective than talking over the phone or email. Now I make sure all my meetings are video calls. I never insist on others to turn on their cameras, but I always keep my camera on.
• Be empathetic. A lot of things that you now find to be poor code or bad design was once the right code or design.
• Earning the trust of others is very important and a prerequisite to influence any change.