Improving Team Execution in a Remote Environment
29 November, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Angel Jamie, Chief Product Officer at Yayzy, shares how he created the first product roadmap at a startup, and a simple process to keep it alive.
CPO at yayzy
Nani Nitinavakorn, the Sr Product Owner at Revolut, describes how she keeps learning hard skills to increase motivation and respect her team.
Sr Product Owner at Revolut
Nani Nitinavakorn, Sr Product Owner at Revolut, recalls her experience initiating a structural change to optimize her entire company.
Sr Product Owner at Revolut
Rachit Lohani, Head of Engineering at Atlassian, shares all his ideas and principles on providing feedback and avoiding discomfort while doing so.
Head of Engineering at Atlassian
Vishal Ramrakhyani, Director of Engineering at Zoomcar, shares how grooming an existing senior team member to a leader can boost team morale and keep the culture intact.
Director of Engineering at Zoomcar
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.