Technology Roadmap

Infrastructure work has to be sold before it can be scheduled. Nobody outside engineering asks for compute right-sizing, and the work that prevents an outage is invisible in exactly the way that makes it hard to fund. This template is built to make that work legible: six workstreams, one of them nested three deep, three named phase completions, and about nine months of visible sequence.

Who this technology roadmap template is for

This is for a platform lead, head of infrastructure, or CTO at a company where engineering investment needs an argument. It assumes you run multiple concurrent tracks — the platform itself, the reliability practice around it, a security or compliance programme, data infrastructure, developer tooling, and cloud spend — with overlapping people and a shared budget.

The audience is generally a mix: an executive who needs to approve the spend, a peer engineering leader who needs to plan around it, and your own team who need to know what happens after the current thing.

What goes on a technology roadmap?

Six top-level lanes, one nested three deep.

Platform splits into Infrastructure — itself split into Compute (fleet right-sizing, Kubernetes migration, GPU capacity planning) and Networking (a service mesh rollout, multi-region networking, a zero-trust rollout) — and an API Layer (a gateway rollout, then GraphQL federation).

Reliability runs an on-call redesign into SLO instrumentation, disaster-recovery drills, and a chaos engineering program.

Security splits into AppSec (identity and access, then secrets management) and Compliance (penetration testing, then SOC 2 readiness) — the longest single commitment on the chart.

Data Platform runs a data lake consolidation into a real-time analytics pipeline and a data catalog.

Developer Platform runs an internal developer portal into golden path templates.

FinOps runs cloud cost tagging into reserved capacity planning and a multi-cloud cost dashboard.

Three milestones mark platform phase completions, spaced across the programme.

How long does infrastructure work take?

The template spans about nine months, and the bars are long by design — infrastructure work doesn't come in two-week pieces.

Platform is the longest track at roughly twenty-four weeks once Infrastructure and the API Layer are both counted. Reliability runs about thirty weeks end to end. Security spans about thirty-six weeks, driven by SOC 2 readiness landing late. Data Platform runs about twenty-one weeks, Developer Platform about ten, and FinOps about twelve.

The shape worth noticing is that Security is the widest track on the chart, and SOC 2 readiness alone is an eleven-week bar sitting at the far end. If your team is fixed-size, that's a resourcing problem the chart has just made visible, and it's much better discovered in planning than in month seven.

How dependencies work on this roadmap

Twenty links. Twelve are finish-to-start within a single track: fleet right-sizing finishes before Kubernetes migration starts, which finishes before GPU planning starts; the mesh rollout finishes before multi-region networking starts, which finishes before zero-trust starts; identity overhaul finishes before secrets management starts; penetration testing finishes before SOC 2 readiness starts.

Six links are start-to-start, and the one worth pointing at directly is Kubernetes migration, which has two start-to-start predecessors: the service mesh rollout and the API gateway rollout. Migration begins once each is genuinely underway — ten days before the mesh work finishes, well before the gateway rollout finishes — rather than waiting for either to be fully signed off.

One link is finish-to-finish: the zero-trust network rollout's completion is tied to when the disaster-recovery drills wrap, not gated upfront by a fixed buffer.

One link is start-to-finish: the developer portal's completion is gated by when the identity overhaul starts, not by identity finishing — the portal needs a stable auth model to build against, not a fully closed-out overhaul.

Two things are deliberately not linked: there's no dependency at all between Reliability, Security, FinOps, and the rest, because the real constraint between them is shared headcount rather than sequence.

That distinction matters. A Gantt chart models sequence well and resource contention badly. When several tracks all thicken in the same quarter, the chart is telling you something real about capacity even though no arrow connects them — and that's the conversation to have when presenting it.

What to change for your own roadmap

Common mistakes on technology roadmaps

No milestones. Infrastructure work without checkpoints reads as an open-ended cost, and open-ended costs are the first thing cut.

Every track starting in January. Real infrastructure programmes have work already in flight. Bars that start before the chart's zero point are honest, not untidy.

Ignoring capacity. Six lanes on a chart don't mean six teams. If the same engineers appear in every lane, the chart is fiction.

Compliance work sized optimistically. SOC 2, ISO, and similar programmes almost always take longer than the engineering effort suggests, because most of the elapsed time is evidence collection and external scheduling.

Never showing it outside engineering. The whole point of drawing infrastructure work is that other people can see it. A roadmap that stays inside the platform team hasn't done its job.

Making the case with this chart

The audience for a technology roadmap is usually holding a budget. Export a PDF for the funding conversation and a PNG for the quarterly engineering update, and re-export as the bars move. Because nobody needs an account to open it, the chart travels — which is the entire mechanism by which invisible work becomes fundable work.