--- title: "Technical roadmaps should preserve options | Dhruv Doshi" description: "A technical roadmap should explain how engineering investments change business capability and system risk. A list of technologies with quarterly dates is a delivery calendar, not a strategy." canonical: https://doshidhruv.com/notes/technical-roadmaps-should-preserve-options/ author: Dhruv Doshi --- [Skip to content](#main-content) [Dhruv Doshi](/) [Work](/projects)[Experience](/resume)[Notes](/notes)[Guides](/guides)[Research](/research)[About](/about)[Contact](/contact)[Search /](/search)dark mode [All notes](/notes) [Staff engineering](/topics/staff-engineering) # Technical roadmaps should preserve options 2025-08-01 · 3 minute read A technical roadmap should explain how engineering investments change business capability and system risk. A list of technologies with quarterly dates is a delivery calendar, not a strategy. ## Begin with outcomes and constraints State the current condition in evidence: delivery delay, reliability exposure, security gap, scaling limit, operating cost, or inability to support a product direction. Connect each investment to a measurable change. “Adopt Kubernetes” is not an outcome; “reduce environment provisioning from days to under an hour while enforcing workload identity” is. Document constraints such as regulatory deadlines, vendor end-of-support, staffing, migration windows, and dependency ownership. This prevents a future reader from assuming every sequence was arbitrary. ## Organise around decisions For each horizon, identify the decisions that must be made, the evidence required, and the options kept open. Near-term work can be specific. Longer-term work should describe capability and direction without pretending uncertain implementation details are commitments. Use discovery milestones where uncertainty is high: prototype a control, measure a bottleneck, migrate one representative service, or validate recovery. The output should change a later decision, not merely demonstrate activity. ## Show dependencies and stopping rules Make cross-team, vendor, security, and data dependencies visible with owners. Define what would cause the organisation to accelerate, pause, alter, or stop an initiative. This turns the roadmap into a decision instrument rather than a promise that survives regardless of evidence. Architecture decision records can preserve the choices made along the way. The [Technology Radar model](https://www.thoughtworks.com/radar) is one useful way to express differing levels of confidence in technologies, but a roadmap must still connect those positions to the organisation’s actual systems and goals. ## Review as a portfolio Balance feature enablement, reliability, security, cost, and retirement work. Count the operational burden removed, not only new capabilities added. A roadmap that continually adds platforms without decommissioning old ones increases cognitive load and risk. Update it when assumptions change, and retain the previous rationale. Stable outcomes with adaptable implementation are a sign of learning, not weak planning. A credible technical roadmap gives teams direction while preserving room for better evidence. It commits to problems and outcomes more strongly than to tools. ## Use horizons instead of false precision A practical roadmap can separate **committed**, **planned**, and **exploratory** horizons. Committed work has an owner, capacity, dependency agreement, and acceptance evidence. Planned work has a defined outcome and sequence but may change as earlier evidence arrives. Exploratory work frames a problem and learning objective without promising an implementation date. This language helps stakeholders distinguish confidence from importance. A high-value initiative can remain exploratory because the solution or dependency path is uncertain. ## Express investments as hypotheses Write: “If we provide a supported service template with automated identity and telemetry, then teams can reach production with fewer security exceptions and less setup time.” Attach a baseline, target signal, review date, and disconfirming evidence. Delivery of the template is an output; changed team behavior is the outcome. For foundational work, show the downstream decision or capability it unlocks. A dependency map, prototype, or migration inventory is valuable when it reduces uncertainty for a named next step. ## Manage capacity and retirement Allocate capacity across product enablement, reliability, security, platform improvement, and decommissioning. Make the cost of keeping old systems visible. A new platform milestone should often include migrated workloads and retired legacy paths, not only feature availability. ## Review checklist Every roadmap item should have a problem owner, desired outcome, evidence, confidence horizon, dependencies, risk, decision date, and stop condition. Review the portfolio at a stable cadence and after material assumption changes. Remove completed work, record abandoned directions with rationale, and resist rolling unfinished items forward without learning why they slipped. ## Continue reading - [Staff engineering is measured through leverage](/notes/staff-engineering-is-measured-through-leverage) · Note - [Incident command is a coordination system](/notes/incident-command-is-a-coordination-system) · Note - [Architecture decision records that remain useful](/notes/architecture-decision-records-that-remain-useful) · Note **Dhruv Doshi** · Toronto, Canada · [work@doshidhruv.com](mailto:work@doshidhruv.com) [Resume](/resume)[Notes](/notes)[Guides](/guides)[Topics](/topics)[Search](/search)[Research](/research)[LinkedIn](https://www.linkedin.com/in/dhruvdoshi25071999)[GitHub](https://github.com/DhruvDoshi) [Sitemap](/sitemap.xml)[RSS](/feed.xml)[LLMs](/llms.txt) © 2026 Dhruv Doshi