How do you run a technology programme?

As one connected plan rather than a list of projects. I own the technology roadmap at Rapha, planned twelve months out and sequenced against budget and capacity. The sequencing is the real work. With a remit that covers engineering, cloud, product, ERP and business systems, security and IT, most things are possible and far fewer are possible at the same time, so the roadmap is mostly a set of decisions about order.

By making the trade-offs explicit. When something moves up, something else moves down or out, and I put that in front of the business so it can choose with its eyes open. I own the technology budget and the vendor relationships, so cost and forecast sit inside the plan rather than arriving afterwards as a surprise. Evidence over assertion applies here too: I would rather show what a change costs than argue about whether it is a good idea.

Architectural governance, QA and delivery are part of my remit, so the roadmap connects to how work actually ships. I run technology evaluations in a structured way rather than on instinct, and I stay in the detail, including writing production code and running releases, so I know when a plan is drifting before a status report tells me. I will not describe what is on the roadmap here, but I am happy to talk about how it is run.