The roadmap is a divisive artifact. It is ascribed magical powers by managers, while developers often loathe it. It's the only thing stakeholders care about. Every CEO has a slide with the plan for the rest of the year. And most developers roll their eyes at it.
It's always been like that.
Back in the days of what we now call waterfall, the project manager would create and maintain their plan in an intricate MS Project file. And developers wouldn't bother looking at it. They only cared about the next work item. The stakeholders, on the other hand, weren't interested in those implementation details. They just wanted to see the big picture. And so, once every few weeks, the PM would prepare a slide deck for them: the roadmap.
To the stakeholders, the roadmap was the main attraction. It gave them insights into how their investment was going. Like a multi-million dollar advent calendar, they would look at it to count down the days until Done. To the engineers, the roadmap was their nemesis. It was the PowerPoint promise their boss made. It was out of touch, unrealistic, and would result in overtime.
Somewhere in the nineties, software developers took hold of their industry's steering wheel. They uncovered better ways and threw out what didn't work in the past. Planning and roadmaps were the first to go.
Gantt charts were dumb all of a sudden. Remnants of the old world. They were "not Agile" and certainly not "true Scrum". In the course of a single decade, it became socially acceptable to claim that "we can't predict the future" and "anything further than two weeks is gambling".
We invented Story Points, backlogs, and Now-Next-Later gizmos to ensure no one could calculate a due date.
While the days of heavyweight planning are behind us, and MS Project is nothing but a bad dream, the roadmap divide is more active than ever. One side still has that burning When question, and the other has given up trying to answer it.
And in the middle of that chasm, there's a lonely figure: you.
More than anyone, the technical leader is stuck between these two camps. CTOs, Tech Leads, Lead Devs, and Engineering Managers understand that slapping a delivery date on a feature is tough. They get that. They are techies, after all.
But they also understand the need to answer When questions. They need to get things done and have to balance goals and budgets. That’s their job.
Their peers ask "When?" while their teams can’t seem to give clear answers. It's a tough job, but someone needs to do it. If you’re a technical leader, that someone is you.
Taking control of the roadmap is the first step to crossing that divide. Here are a few pointers:
Start small. If you don't have a roadmap supported by the entire team, start with a three-month plan. If you have an unrealistic three-year plan, turn it into an actionable roadmap for the coming quarter and start from there.
Expect change. Once you start connecting the high-level roadmap with the actual work, you’ll notice how often priorities shift. You’ll be adapting that early roadmap 24/7. Good! It’s not supposed to be fixed. This change has always been happening. You are now making it visible for the first time. That’s the transparency we need.
Use Stakeholder Aikido. Your stakeholders will demand flexibility and predictability at the same time. They will ask you to drop everything to build this shiny new feature and expect you to stick to the plan. That's fine. They've been working without a plan and still need to learn to adapt. This will be your main weapon: "If we prioritize Shiny New Feature, we'll have to postpone Expensive Promise to November. Is that what you want?"
Maintain your developers’ trust. Apply iterative buffer planning to make sure long-term plans are sustainable. Keep that first roadmap unambitious. Let the team feel ahead of schedule and increase the rhythm from there. Developers rightfully fear the roadmap is going to contain promises at their expense. Prove them wrong.
Centralize and share. Roadmaps are so despised because they are shown in backrooms where managers engage in wishful thinking. It’s tradition to make compromises without involving the devs. Centralize that roadmap in a place where it's accessible to all and make it a habit of discussing it regularly. Every team member and stakeholder should know the roadmap by heart.
I talk to many teams, and the least productive ones have something in common: management has fabricated a roadmap detached from their teams' realities.
As a technical leader, it's your task to prevent this.
You nailed this. with one big exception - no one really used Project - for example, when we shipped Windows XP, we used Excel to build and execute...