manager-dot-dev/manager-skills/roadmap-planning

Roadmap Planning

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

How to Use This Skill

• Negotiating tech debt time with stakeholders → Tech Debt and the "20% Rule"
• Feature is being broken into phases — pressure-test whether it's right → Phased Releases
• Need to show the ongoing cost of building new things → Maintenance Costs as a Third Dimension
• Team keeps missing sprint goals / perception of the team is "slow" → The Always Green Method
• Sprint rituals are creating more friction than value → Sprint Anti-Patterns
• PM keeps adding one-off custom features → Hidden Costs of Custom Features
• Hard deadline is at risk — what to do → When the Team Can't Make a Critical Deadline
• Project estimates keep being wrong → The Iron Law of Projects
• Technical work keeps getting deprioritized → There Are No Technical Projects
• Team is shipping but nothing seems to have impact → Feature Factory Warning Signs
• Running a company-wide cleanup event → read `references/extended.md` — The Cleanathon

Default Response Shape

When helping with roadmap planning, make tradeoffs visible:

1. Planning problem: tech debt, phases, deadlines, capacity, maintenance, feature factory, or stakeholder alignment.
2. Decision frame: what options are actually on the table.
3. Business translation: why the engineering work matters in product or company terms.
4. Recommendation: what to do now and what to defer.
5. Stakeholder message: concise wording for PMs, leadership, or the team.

If the issue is "technical work keeps losing," translate it into risk, cost, speed, reliability, or customer impact before arguing for it.

Tech Debt and the "20% Rule"

Dedicating 20% of capacity to purely engineering work is a widely recommended practice — and it genuinely helps. But most teams implement it poorly and fall into predictable traps.

The 5 Traps

1. Separate backlogs for product and tech

When product work and tech work live in separate backlogs, Product stops interfering in tech decisions and Engineering stops engaging with product priorities. It sounds like peace — it's actually a slow failure.

Product and technology are not separate things. Bug fixes, library updates, automation improvements, security patches — almost all of these have business value (reliability, security, speed of delivery).

The fix: every item on the technical list should have a clearly defined business value. Once it does, move it to the product backlog — where it gets prioritized alongside everything else. Reserve the separate tech track only for critical work too hard to explain to non-technical stakeholders.

2. The company doesn't understand the value of your work

If the business doesn't care about or understand your technical initiatives, those initiatives will always be the first thing deprioritized when "urgent" things appear. And you'll have a much harder time negotiating for hiring, training, or additional time.

The fix: make technical work visible. Hold monthly reviews where engineering teams present the progress of technical initiatives not tied to specific product teams. Show why the work matters in business terms — not just "we migrated to Swift" but "this reduces compilation time, improves developer experience, and helps with hiring because fewer engineers want to touch Objective-C."

3. Diluted focus

Getting 20% doesn't solve everything. If you assign a separate tech initiative to every single person on the team, each going in a different direction — you'll make no real progress anywhere.

The fix: focus your 20% on a coherent set of initiatives that contribute to a longer-term engineering strategy. Know your goals, know which initiatives contribute to them, and resist the temptation to address every technical itch simultaneously.

4. "We'll fix it later"

Once a team has 20% protected time, it becomes tempting to push things faster, assuming tech debt will get cleaned up later. It almost never does — the next sprint always has something more urgent.

20% time is to make things better, not just less bad. Even when building an MVP, it must be functional, usable, and reliable. Writing tests "after we push to customers" is a classic — those tasks almost never get done because you're either fixing production issues or jumping into the next initiative.

5. Ineffectiveness on large initiatives

20% is one day a week, 1.5 hours a day, or ~4–5 days a month. For genuinely large initiatives — breaking down a monolith, re-platforming — this means a year of context-switching to make 2–3 months of progress. It doesn't work.

The fix: large strategic initiatives shouldn't live in the 20% — they should become product priorities with business justification, full organizational support, and tracked progress. Save the 20% for genuine maintenance and smaller tactical improvements.

Phased Releases: When They Help and When They Don't

Releasing a feature in phases sounds careful and de-risked. Often it just delays learning and creates drag.

Five questions to pressure-test a phased roadmap:

1. Are you phasing because users asked for it, or because the team wants to build more? Phase 2 is often a wish list, not a user need.
2. Will Phase 1 actually be used without Phase 2? If Phase 1 alone isn't valuable, you're just shipping a stub. Users don't care about your internal phases.
3. What are you learning in Phase 1 that should inform Phase 2? If you can't name it, Phase 2 is already fully designed — which means you're not actually using Phase 1 as a learning milestone.
4. What's the cost of stopping after Phase 1? Phases create internal expectations. Once you ship Phase 1, Phase 2 starts to feel like a commitment rather than a choice.
5. Is there a simpler version that delivers the full value? The best version of "Phase 1 + Phase 2" is often just a better-scoped Phase 1.

The Honda story. When Honda entered the US motorcycle market, they planned to lead with their large bikes — the serious motorcycles. Those broke down. Their small, cheap motorcycles (which they were riding around themselves) caught attention instead. They pivoted fast and built a market they hadn't planned for.

The lesson: the plan you start with is a hypothesis. Great product teams are willing to stop a feature mid-build if the signal says to. They treat stopping as a sign of good product culture, not failure.

Communicate this to your team. Engineers often feel demoralized when a feature is stopped. Your job is to frame it differently: "We shipped, we learned, we're redirecting based on real data. That's how this is supposed to work." The alternative — continuing to build something that's clearly not working — is the actual failure.

Maintenance Costs as a Third Dimension

Roadmap discussions usually get trapped on two axes: what to build and how long it will take. This misses the ongoing cost of everything you commit to.

Every feature you ship adds permanent weight. Maintaining it, supporting it, keeping it fast and secure — even with zero technical debt — takes ongoing team capacity. The more unrelated the systems, the harder this becomes.

How to add maintenance cost to the conversation:

1. Map the current ongoing costs of each system you own (bug fixes, outages, urgent customer requests, security patches)
2. Estimate as a percentage of team capacity (e.g., "~10% of our time per system")
3. Show the estimated increase in ongoing cost if you take on the proposed new work
4. Let the other side make the decision with that information visible

The numbers won't be accurate. That's not the point. The goal is to make the maintenance cost dimension visible in the conversation — not to be precise, but to change what gets considered.

When you start tracking these things and bringing in real stories, it becomes much easier to push back on scope without it feeling like obstruction.

The Always Green Method

Delivery speed is 95% about perception. A team that consistently delivers on-time small goals is perceived as fast. A team that swings for ambitious goals and misses looks slow — even if they shipped more.

The core insight: you can always deliver on time if you choose the right goals.

The Hill Concept (from Shape Up)

Every project has two phases: climbing the hill (discovering unknowns, figuring out what to actually build) and going down (executing on what's now clear). You can't fully understand what a project requires through planning alone — you have to climb far enough to see everything.

Before committing to a goal, start the work a sprint early. Spend a few days actually doing it — uncovering the hard parts, the dependencies, the unknowns. Once you've reached the top of the hill, you can commit with high confidence. Scope surprises become rare.

How to set a sprint goal that you always finish:

1. Pick a minimal goal. One clear, user-facing outcome. Nothing fancy. It should fill at most half the team's capacity — so you're confident it's done by midweek.
2. Break it into parallel work. Pieces that people can work on without blocking each other. No dependencies on other teams.
3. Announce it publicly. Post in a shared channel: "If all else fails, this is what we deliver." Take full ownership.
4. Watch it daily. Be on top of it. Unblock immediately. Pull people from "non-goal" tasks if needed.
5. Finish it. If you have 3 goals, you need 3 checkmarks. Two out of three is not a success — it just resets the expectation that your team doesn't finish.

The rest of the sprint doesn't stop — bugs, tech debt, planning, supporting other teams. The minimal goal is just the non-negotiable floor.

On ambitious goals: teams with consistent 100% delivery rates do more over time than teams chasing ambitious goals and missing. An always-succeeding team is more effective, more trusted, and more willing to over-deliver as a bonus. The alternative — ambitious goals, consistent misses — just burns everyone out.

Sprint Anti-Patterns

Sprints, when followed rigidly, create their own problems. Signs that sprint process is working against the team:

• Taking a smaller bug at sprint end because 2 days aren't enough for the real work
• Pushing to finish sprint goals that no longer make sense
• "Making progress on X" counted as a sprint goal
• Velocity tracked as a success metric while features are consistently late
• Tech debt moved to "next sprint" for 6 months running

What to do when you can't change the process: