Roadmap Planning and Execution Process
Learn about roadmap planning and the execution process.
Typically, teams do two types of planning: short-term and long-term. Short-term planning is more focused on execution that usually spans one week to a few weeks. This is where the project is broken into smaller components or tasks and then executed at that level. Long-term planning refers to quarterly or half-yearly plans to build a team's roadmap.
Short-term planning
Short-term planning covers breaking down projects into manageable components or tasks and then tracking their progress to achieve the project's goals. Teams use techniques like sprint planning, weekly status updates, and daily scrums for short-term planning.
Different teams have different processes to implement their short-term planning. The planning also varies from project to project and may be influenced by
Long-term planning
Long-term planning is intended to build the team’s roadmap. Usually, this aligns with the company’s processes of building roadmaps. In most companies, roadmaps are defined for each quarter or half year. Some companies might have an annual plan, but it is not that common. Mostly, long-term planning cadence is influenced by company policies and priorities. However, when priorities change, the planning cadence may need to be changed occasionally.
The prioritization trickles from top to bottom. The CEO sets the company's direction and vision with the top leadership of the company. This influences the various organizations within the company, and they decide their goals based on this direction. This direction trickles down all the way to individual teams, and teams adjust their goals based on the larger organization’s goals.
Note: During this process, team members will also be setting their own goals. As a manager, you need to review them and help them align with the overall company direction while also promoting individual growth. Throughout the performance cycle, you should continue reviewing the progress of the individual's goals and make sure they align with the company’s goals and success.
Another thing to consider is the team’s internal prioritization. Internal prioritization can be for various reasons, such as improving the reliability of the system or reducing operational costs, or other engineering excellence-related projects. For example, assigning team members to improve a service developed urgently by cutting many quality corners to deliver a high-priority business goal. The product manager or company leadership may not have visibility and may not care much about it as it does not directly add business value. As an EM, you must understand the team’s internal prioritization and their upward and downward dependencies and influence prioritization accordingly.
Another essential thing to understand is the team’s bandwidth. Plans should be made based on the availability of engineering resources within the team. A team of ten people should not take on work that requires twenty people. An effective EM should be able to identify their team's bandwidth and choose projects accordingly. While this is not a perfect solution, a simple way to do this is to estimate the teams’ resources (engineering time) needed to complete each project. When looking at the available bandwidth, it is important to consider the duration for which engineers are available, i.e., accommodate any on-call time and any vacation or other leave of absence time. It’s good to keep a buffer time for each team member to absorb unplanned tasks, leaves of absence, or someone leaving the team.
We can summarize the main points to consider as an EM for long-term planning as follows:
Identify candidate projects
Talk to upward and downward dependencies
Project prioritization
Team bandwidth
Rough estimation and costing
Typical questions
Let's take a look at some typical questions related to roadmap planning.
What is your roadmap planning process?
As a candidate, you should be able to articulate the planning process, both short-term and long-term, and its outcomes. You should be able to talk about how your team is engaged in the whole process. This includes the impact of your ICs and team leads on roadmap planning. You want to include all team members when coming up with a roadmap instead of collaborating with a few ICs and team leads and dumping the plan on the rest.
Senior EMs should be able to talk about bigger-scope planning with the purview of multiple teams. They are not involved in the roadmap of individual teams and are not as deeply involved, but they consolidate the roadmaps of multiple teams. With their broader view, they can help EM1s and their respective teams identify dependencies and prioritize accordingly.
Red flags
The following responses can be considered red flags:
Over-committing to partners or leadership
Making statements that give the impression that you go along with whatever the partners or leadership suggest regardless of the technical or logistical difficulties that may arise later. Since both partners and leadership are a bit far from the actual implementation, it is the EMs job to identify what is and is not doable, how much time a project will take, etc.
Not considering people taking time off, maternity and paternity leaves, on-call duty, business demands, or emergencies.
Even though a quarter has around 12 weeks, it is incorrect to assume that people will be working the entire 12 weeks. Making estimates without accounting for some buffer will lead to an unhealthy team.
The buffer is decided based on the team's operational work, tech debt, random asks (customer requests), partner asks, and working with legacy code. Based on these factors, you must plan effectively and make correct project estimates.
Deciding the roadmap without involving the entire team or only involving a few members.
Decisions should be made with collaboration from team members, especially the team leads. Involving people selectively may also give off hints of bias.
Not being involved and letting the senior ICs and team leads handle the roadmap planning.
This might be good when you want your senior ICs to grow, but as a manager, you must closely monitor the roadmap planning. Your team will work based on this plan, and their growth and health will depend on this. You should be involved in this process from end to end.
Not tracking the progress throughout the cycle.
Progress should be tracked at a regular cadence. Based on the team's requirements, this can be every 4–6 weeks. Project tracking lets you know whether you are falling behind and whether you need to reprioritize.
How do you make sure that the tech debt is taken care of?
A tech debt refers to tasks that are carried over from the existing infrastructure and that have to be managed/handled as you work on new features.
The first and most important thing to understand are the trade-offs when working on tech debt tasks. Taking care of tech debt becomes necessary if it causes operational overhead or poses significant risks. Some important things to consider when thinking about handling tech debt:
How much time will it take?
Are the tech debt tasks worth dedicating resources to, right now?
Can they be made part of the next cycle's roadmap planning instead of being considered tech debt?
Taking care of tech debt should not be ad hoc. There should be a systematic process to take care of the tech debt. This can include things such as:
You can have tech debt sprints, where the team works on tech debt tasks.
You can reward individuals based on how many tech debt tasks they resolve.
You can define a process of handling tech debt during their on call.
Instead of working on features, the individual will work on resolving tech debt.
Senior EMs should be able to talk about investments across multiple teams to reduce the operational burden and tech debts. If something is wasting time across multiple teams, a senior EM should be able to identify it and invest in areas that can resolve the underlying issue and save time. The senior EM must be able to get their managers to reprioritize to address such issues if it saves time across multiple teams.
How do you do costing and budgeting for your team?
Costing and budgeting are two separate but related activities. Costing is where you estimate how much time a project will take to complete. Budgeting is how you will manage available engineering bandwidth for the project. At the roadmap planning stage, both of these are very rough estimates.
The core idea behind costing is breaking down the project into smaller components that will allow you to make a rough estimate. Dedicating too much time to this task is counter-productive. An estimate that is 70% correct is sufficient at this stage. Try to come up with a reasonable estimate based on your intuition and project knowledge. You may also need to talk to dependency teams and XFN partners and gather any information required from them.
There are various ways of budgeting. The best approach is to simply ask each individual which project they are interested in and budget based on that. You can also do a headcount allocation where the team leads will assign individuals to unassigned projects. Sometimes, as a manager, you have to choose project owners based on skill match and priority. Some teams don’t do budgeting at all and break down projects into tasks. During the sprint planning, each team member picks the tasks from a task board.