Technical Roadmap Planning
debt(d9/e7/b7/t7)
Closest to 'silent in production until users hit it' (d9). The detection_hints confirm automated detection is 'no' and the tools listed (jira, linear, notion) are project management tools, not automated scanners. The absence of a technical roadmap manifests only when technical debt accumulates into a production incident or team is surprised by an outage — by definition a silent, lagging signal with no tooling to catch it proactively.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes creating a quarterly roadmap with triaged categories, but the real remediation is organizational: establishing new planning ceremonies, negotiating capacity with product/business stakeholders, changing prioritization culture, and maintaining ongoing scheduling discipline. This touches team processes, stakeholder relationships, and planning cadences across the entire engineering organization — well beyond a single-component fix.
Closest to 'strong gravitational pull' (e7). The applies_to scope covers both web and cli contexts broadly. Without a roadmap, every future decision about capacity, prioritization, and technical investment is shaped (or misshapen) by the absence of this structure. Common mistakes show it affects product/business alignment, capacity reservation, and outcome framing — meaning nearly every work stream is taxed. It doesn't quite reach b9 (system rewrite level) but it strongly shapes how all future technical work proceeds.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states explicitly: 'Technical items do not need business justification — without it, technical work is deprioritised indefinitely.' Developers and engineering managers familiar with technical planning naturally assume technical merit alone justifies scheduling, but in practice the opposite is true in most organizations. This is a well-documented organizational trap that contradicts the intuition of technically-minded people and leads to systematically wrong behavior.
Also Known As
TL;DR
Explanation
Communicate: what investments are planned, why (business impact), when. Frame as business outcomes: prevents X incident, enables Y feature, reduces Z by amount. Formats: now/next/later, Gantt, impact/effort matrix. Without business justification, technical work is deprioritised until it becomes an incident.
Common Misconception
Why It Matters
Common Mistakes
- No business outcomes
- No capacity reserved for tech work
- Roadmap as wish list
- Not sharing with product/business
Code Examples
// Roadmap: 'Upgrade PHP', 'Refactor auth'
// Business: 'What does this deliver?'
// Q1: PHP 8.3 — EOL June 2026, eliminates 3 CVE categories
// Q2: Tracing — reduces MTTR 2h→30min, ~$50k/year savings