How to Stay Up-to-Date Managing a Large Remote Team

Problem

I’ve managed remote teams of 50+ engineers that are located all around the world. There are many advantages, such as a lower cost per hire, more hourly availability, and a larger talent pool 一 meaning many diverse solutions. However, there are problems that I’ve faced and learned to overcome. It is difficult to track what each individual contributor is working on, what they are motivated by, and what their problems are with a large remote team. The second problem related to remote teams made up of international members is that many off-shore developers are kept out of the loop or not held to an equal standard and a domestic partner. I strived to create a process that would enable change and uplift my teams to increase collaboration and productivity.

Actions taken

I formalized a process that allowed off-shore teams to obtain full responsibility for any tasks they were part of. Throughout this, I included them in all agile ceremonies - planning, estimation, and problem-solving meetings. In turn, I made sure my international developers were equally as responsible if something went wrong.

To put these systems in place, I created a new onboarding lesson that said that location did not jeopardize equality within my team and that all members were equal partners. I gave my international team members access to the company email IDs, VPN, and the right resources needed to complete their job to the highest degree. I disrupted any segregation related to geographic location.

In my largest team, I began weekly meetings with my dev leads where they were supposed to bring one-slide presentations. The slide consisted of bullet points that explained what a team delivered that week, what they were working on in the upcoming week and a column that compared completed projects to projected completed projects.

At a higher level, these meetings provided me with a weekly report card for each team. From there, I created a running metric on the variation between the data points they provided me with. If I saw any metrics moving substantially, I could step in and designate a specific time for a team to work on specific issues.

I started skip-level meetings with individual contributors every month. Within these meetings, I determined if my team members were aligned with the team and company’s goals as well as their OKRs. The second thing I looked at was that the individual contributors had key incentives for individual learnings. I was pushing my team to acquire additional skills to move through the career ladder and be satisfied with the level of challenge they were facing on my team.

Initially, I faced pushback about the time required for creating the individual slide showing a team’s weekly work. I showed my teams that had reservations a method of automating this process, taking less than five minutes. I found that this step was a preemptive step to find challenges in my teams before they occurred.

Lessons learned

• Change is always difficult for everyone involved. Bring change to a team as an open suggestion rather than a forceful decision. Along with the open suggestion, bring positive points that reflect the change and why making the change is a good decision for your team. This process is especially important for key leaders during the change, as they will drive teams to make a group decision. When they feel it’s a democratic process, there is an easier buy-in for that change.
• Having processes in large teams has advantages. When you move from a 10 to 50 person team, informal chat sessions will not work anymore and instead has to be replaced with a formalized process.