Improving Team Execution in a Remote Environment

Problem

When my company transitioned to a remote workplace, my team faced a few challenges from an execution point of view. We had quarterly planning but felt that we couldn’t achieve as much as we wanted each quarter. My cross-functional partners would inquire about the time frame of my projects, but my team didn’t have any centralized location to track the state of our tasks. We had an informal spreadsheet where engineers would casually enter information, although it was poorly organized or immensely impractical. I became a middleman between my engineers and cross-functional partners because our tracking system was not scalable for our company.

Actions taken

There were two significant topics that we addressed: planning and day-to-day execution. In the past, we had quarterly planning, which was done every 13 weeks, where we would subtract one week for on-call weeks. I found that this system did not work in execution. Our estimations were not always accurate because of frequent ad hoc requests and company-wide initiatives such as quality fixes. We realized that we were planning too much work for our engineers during a quarter.

Moving forward, we created a framework for our quarterly planning, starting by understanding an accurate bandwidth of an engineer. While beginning with 13 weeks, we subtracted a week for vacation, one week for engineering quality, and one week for an on-call. Then we started to plan dedicated time for ad hoc tasks and previous follow-ups regarding A/B experiments. Sometimes A/B experiments would ship, but other times they required follow-ups which were nearly impossible to plan upfront. I discovered that it was best to include an ad hoc A/B experiment follow-ups week each month out of a quarter. After including the dedicated weeks to our quarterly planning, we had seven weeks of work that we could plan for an engineer.

In some cases, we significantly underestimated the complexity of projects. To mitigate this challenge, we split each task into categories dubbed P1 or P2. A P1 project was a task that was included in our team goal and needed to be completed. A P2 project was a stretch goal, where if we had time, we could achieve these tasks. Seniority dictated the proportion of P1 and P2 projects for an engineer. Junior engineers would have a third of their tasks be P2 goals, while experienced engineers would have all their projects as P1. This process created a buffer for the less experienced engineers so they wouldn’t burn themselves out. After implementing our new planning model, my team completed more projects in a quarter and worked with higher engagement.

In terms of execution, I searched for options that could replace our project status spreadsheet. We began using Asana internally for our project management solution, which put in place a timeline accessible to all engineers. I helped engineers add additional information that cross-functional teams would need to know in Asana, so I didn’t have to act as a middleman. It included information on major updates, implementation, kickoffs, or experiments regarding each project. If there were any blocks within this system, I scheduled four standups each week. One was a larger execution meeting, and the others were shorter standups where my team could receive feedback quicker. I delegated a rotation where engineers would run these weekly standups. This allowed my schedule to be open for other tasks and my team to work more independently.

Lessons learned

• Within a remote environment, there is no easy way to communicate with one another. Aligning projects and using a system that provides context in one place will uplift this challenge.
• When planning, you need to take into account the extra tasks that engineers do. This can include bugs needing to be fixed and on-call work. Many estimates are very inaccurate when it comes to planning for the workload. You need to have a margin of error that allows your team to complete required goals without compromising other priorities.