Roadmapping

[!NOTE] “Plans are useless, but planning is indispensable.” — Dwight D. Eisenhower

A Roadmap is not a project plan. It is a strategic communication tool that aligns stakeholders on the evolution of your system. As a Staff Engineer, you own the technical roadmap for your domain.

1. The Problem with Gantt Charts

Imagine planning a cross-country road trip with a strict minute-by-minute schedule. You might predict arriving in Chicago exactly at 2:15 PM on Tuesday. However, this level of precision ignores the realities of travel: flat tires, traffic jams, and unexpected detours.

Traditional timeline roadmaps (like Gantt charts) often fail in software engineering for the same reason: they imply high certainty in an inherently uncertain environment. When you commit to specific dates months in advance, you are predicting the future without acknowledging the unknown variables.

  • The Trap: “The new Payment Gateway will launch on May 15th.”
  • The Reality: Unforeseen technical debt in the legacy billing system, a critical production fire in a different service, and changing business priorities from leadership all delay the project.
  • The Result: Missed deadlines, exhausted engineering teams, and broken trust with product stakeholders when dates inevitably slip.

2. The “Now, Next, Later” Framework

Instead of strict dates, use horizons of uncertainty. Think of this framework like driving a car at night. “Now” is the immediate road illuminated clearly by your headlights. “Next” is the fuzzy shape of the curves further ahead. “Later” is the final destination on your GPS—you know where you want to go, but the exact path might change.

Now (Q1)

Specific, committed work. High certainty.

  • Migrate User Auth to OAuth2
  • Deprecate Legacy API v1

Later (Q4+)

Vague ideas. Aligned with vision.

  • Self-Service Data Platform
  • Machine Learning at Edge
  • Now: We are building this. Specs are done. (90% confidence)
  • Next: We are researching this. We know the problem, not the solution. (50% confidence)
  • Later: We want to solve this eventually. (10% confidence)

3. Prioritization: The RICE Framework

How do you decide what goes into “Now”? Use data, not volume.

  • Reach: How many users will this impact? (e.g., 500 users / month)
  • Impact: How much will this improve their life? (3 = massive, 2 = high, 1 = medium, 0.5 = low)
  • Confidence: How sure are we? (100% = high, 80% = medium, 50% = low)
  • Effort: How many person-months? (e.g., 2 months)

Formula: Score = (Reach * Impact * Confidence) / Effort

Since Effort is in the denominator, this formula inherently prioritizes projects that deliver the highest value for the lowest amount of work (i.e., high ROI).

Interactive: RICE Score Calculator

Compare two potential projects to see which one wins.

<table>
<thead>
  <tr>
    <th>Factor</th>
    <th>Project A</th>
    <th>Project B</th>
  </tr>
</thead>
<tbody>
  <tr>
    <td>Reach (Users)</td>
    <td><input type="number" id="rice-reach-a" value="1000"></td>
    <td><input type="number" id="rice-reach-b" value="50"></td>
  </tr>
  <tr>
    <td>Impact (0.25 - 3)</td>
    <td><input type="number" id="rice-impact-a" value="1" step="0.1"></td>
    <td><input type="number" id="rice-impact-b" value="3" step="0.1"></td>
  </tr>
  <tr>
    <td>Confidence (%)</td>
    <td><input type="number" id="rice-conf-a" value="80"></td>
    <td><input type="number" id="rice-conf-b" value="100"></td>
  </tr>
  <tr>
    <td>Effort (Person-Months)</td>
    <td><input type="number" id="rice-effort-a" value="2"></td>
    <td><input type="number" id="rice-effort-b" value="0.5"></td>
  </tr>
  <tr class="result-row">
    <td>RICE Score</td>
    <td id="rice-score-a">400</td>
    <td id="rice-score-b">300</td>
  </tr>
</tbody>
</table>

Adjust the values to see how the score changes.

4. Strategic vs. Tactical Roadmaps

As a Staff Engineer, you maintain two roadmaps to balance feature delivery with engineering health:

  1. The Public Roadmap: Shared with Product and Engineering leadership. Focuses on milestones, user impact, and business value (e.g., “Launch multi-currency support”).
  2. The Technical Roadmap: Shared with the engineering team. Focuses on resolving Technical Debt, library upgrades, architectural refactoring, and improving developer velocity (e.g., “Migrate from monolith to microservices for checkout”).

[!WARNING] If you don’t fight for the Technical Roadmap, no one will. Product managers will naturally prioritize customer-facing features. It is your responsibility to advocate for the system’s long-term viability by aiming to allocate 20-30% of engineering capacity to technical excellence.

5. Interactive: Prioritization Matrix

Another way to visualize work is the Impact vs. Effort matrix.

Impact →
Effort →
Quick Wins
Major Projects
Fill-ins
Thankless Tasks
Fix Typo
Rewrite Core
Add Cache
Manual Report
Drag items to re-prioritize

6. Next Steps

Once you have a roadmap, you’ll often face a critical choice: should you build the solution yourself, or buy it?

Next: Buy vs. Build →