An IC’s guide to roadmap planning

How individual contributors can leverage their unique perspective to advance alignment and clarity of vision.
Part of
Issue 19 November 2021


There’s a lot at stake in the planning process for individual contributors (ICs). Their impact, after all, depends on the degree of alignment between the engineering roadmap and the company’s goals, as well as their team’s capacity to execute on that roadmap. ICs are often especially well positioned to identify high-impact areas of work because they’re closest to the implementation, yet they’re often left out of the planning process altogether.

What’s an IC to do?

For those seeking a seat at the table during planning, it helps to come equipped with an understanding of the process and an appreciation of the value of their unique perspective on prospective projects. Furnished with this knowledge, any IC can better contribute to—and gain deeper insight into—their team’s roadmap, and their role in executing it.

Clarify your opinions

Every engineering team develops a product, even if that product is purely internal, like infrastructure. The best products are opinionated, built with distinct intention and a clear vision. In practice, this might mean streamlining the customer experience by developing fewer features; consider the iPod relative to other MP3 players, for example. And—unsurprisingly—developing opinionated products requires, first and foremost, forming opinions. 

Opinions can also be thought of as hypotheses: questions that push us to the bounds of our creativity and curiosity, that we seek to answer through experimentation. Unfortunately, the work of asking good questions—ones that identify real customer pain points—is too often relegated to product managers. While that’s a big part of their role, engineers should also have the opportunity to ask thought-provoking questions and formulate hypotheses that push product development in fresh directions.

ICs who participate in developing insightful hypotheses will have distinctive and valuable opinions about the roadmap, especially regarding the expected cost-benefit trade-offs for their teams. Taking time at the beginning of the planning process to clarify those opinions—perhaps even recording them in private notes—helps preserve your vision, since opinions risk getting muddled as more inputs emerge.

Understand the process

Planning is dynamic by nature; procedures can vary dramatically from team to team, or even within the same team over time. Ensuring you’re clear and up-to-date on the specifics of your current planning cycle is key to making effective contributions. This is useful even if you’re already familiar with the overall process, since additional steps might be happening behind the scenes—like establishing prioritization frameworks or aligning the roadmaps of constituent teams—that could influence the outcomes.

Consider talking to your manager about how you can best participate and what time commitments and trade-offs your participation might require. (Most managers will welcome the opportunity to bring ICs into the process.) You might also want to ask questions like:

  • What are the key dates for the process?

  • When should an IC submit their input, and what’s the preferred format?

  • Is there a preexisting backlog to review?

  • Is there a predefined prioritization framework?

  • How are feature requests balanced against bug fixes or long-term investments like  developing strategic features or re-architecting systems?

These aspects of the process are worth documenting and sharing so all ICs can have the same context. With this information in hand, ICs can start making meaningful contributions in a way that aligns with the specifics of the planning process.

Identify stakeholders

Planning stakeholders usually fall into three categories: customers (including internal customers, like users of an internal tool), leadership, and team members. Each group brings to bear a unique point of view when exploring how the product can best serve customer needs, resulting in distinct planning inputs. For example, a product manager might recommend postponing a much-desired feature if they know it will be better sequenced after another team’s project is finished. Meanwhile, an executive might recognize proposals that are best aligned with the company’s overall strategy.

Identifying all of the stakeholders involved affords planning participants a holistic view of a project’s potential impact. Generally speaking, projects that address asks from a greater number of stakeholders will have a higher impact by virtue of positively affecting more people. For ICs, it’s helpful to understand how a project’s potential impact aligns with their team’s skills and expertise so they can advocate for taking on a set of projects that has the highest overlap of impact and team fit.

Talk to customers

Gathering feedback directly from customers is an essential aspect of effective planning. Customers, after all, are the ultimate stakeholder everyone is aiming to please. Ideally, each participant in the planning process will have an opportunity to talk directly to customers, without having to rely on proxies like salespeople or product managers.

It might not feel convenient to set aside time to gather direct customer feedback, nor is it always a comfortable exercise, but these conversations are necessary to refine the opinions developed earlier in the process. A list of pre-prepared questions can serve as a useful starting point for these exchanges, but it’s important to deviate from them when needed so you can tailor the conversation in real time in order to further understand a customer’s point of view.

Make an ordered list

Most roadmap planning processes produce an artifact outlining a team’s objectives. This often takes the form of an ordered stack rank (OSR) of potential projects. 

To provide input on your team’s OSR, consider constructing your own. This allows you to establish a relative rank among your preferred objectives, which can serve as a helpful reference when merging your list with your team’s. If your team is using a preexisting prioritization framework (for instance, one that indicates how the budget will be allocated for various categories of work), take that into account as you create your ranking to ensure your approach is consistent.

The mechanism for constructing an OSR, whether on an individual or collaborative basis, is broadly constant across organizations. In general, the planner will:

  1. Review all inputs (such as preexisting backlog, customer interviews, or personal preferences) and consolidate the information into a set of distinct objectives.

  2. Estimate the effort required to meet each objective. At this stage, your estimates can be fairly rough. For example, you might use a simple estimation mechanism like allocating T-shirt sizes (S, M, L, XL) to each objective. The planner should constrain the scope of each objective so engineers can grasp both the desired result and the work needed to get there. They should also grade sizes on a curve so the resulting list contains objectives of varying sizes.

  3. Gauge the overall impact each objective is likely to have. This can be a fairly subjective process. For example, the number of stakeholders who would benefit from a particular project might be an objective data point, but quantifying the extent of the benefit is much less clear-cut.

  4. Rank the list’s items in descending order of impact (highest to lowest) and then by ascending size (smallest to biggest). In other words, any high-impact quick wins should be at the top of the list.

A key benefit of this standardized approach: OSRs can easily be compared to one another. When two OSRs have the same objectives in different orders, it’s usually because there are differing estimations of either the effort required to meet an objective or the impact it represents. When this happens, ICs can leverage their perspective on effort and impact to recommend reordering the objectives.

Advocate for underdogs

After your team has solidified its OSR, it’s time for the prioritization and reality check stage. Which objectives can’t you address with the resources available to you? 

To answer this, construct an effort budget that lays out how many objectives the team can achieve in the given time frame. For example, if the OSR uses T-shirt size estimates, the budget might have room for two S, two M, two L, and one XL objectives per quarter. From there, you can draw a cutline according to the budget: Everything above the cutline is doable in the given time frame, while everything below it is not. This budgeting process might result in significant work being deprioritized for the time being, but it should give teams confidence that they’re maximizing their potential impact in accordance with their resources.

ICs can bring a unique viewpoint to this prioritization process by championing objectives management might be less inclined to focus on, such as paying down tech debt. The prioritization framework (if your organization uses one) or the effort-impact estimate you used during the OSR process can be helpful here, allowing you to leverage facts and agreed-upon evaluation criteria to make your case. For example: “I think objective X will have more impact than objective Y because of data point Z,” or “Objective A will probably require more effort than we’ve estimated. Would it make sense to prioritize objective B instead?” 

By speaking up during the prioritization stage, ICs can help ensure planning participants are aligned on the underlying assumptions about the reality on the ground.

Execute the plan

Due to their in-the-weeds perspective and experience, ICs are capable of bringing singular value to planning. Organizations that involve them in the process will be stronger for it. 

That said, it’s possible to spend too much time planning. Because while planning is a crucial aspect of achieving directional alignment within teams, organizations, and companies, it’s also just one part of the equation. The end goal, after all, is to provide value to the business and its customers. Ultimately, ICs will be assessed against their contributions to executing on the overarching plan—so once the roadmap is in place, it’s time to deliver that value. ICs who’ve participated in their team’s planning process can confidently shift into execution mode, knowing their work will be more impactful and better aligned with their organization’s goals.

About the author

David Noël-Romas is a staff software engineer at Stripe and a host of the podcast StaffEng. He works on internal tooling frameworks at the intersection of security and developer productivity and enjoys brewing beer and playing with his dog.


Buy the print edition

Visit the Increment Store to purchase print issues.


Continue Reading

Explore Topics

All Issues