> It's more like you're defending the idea of roadmaps by saying any list of stuff to do — or even saying "we're busy!" counts as a roadmap. That's not what's generally understood by the term, nor is it what the article is getting at.

I'm defending roadmaps because I believe that any plan with future dates counts as a roadmap, and because such things are essential to any sort of cross unit coordination.

If the DB team says "I've prioritised Geo, but I've not committed to it, so I therefore cannot give you any idea of dates", then that's not helpful to me. I still need to deliver my Geo capabilities, but all I know is that the team I'm dependent on may or may not do it, at some point in the future, and even though they have the best information about when that might be - because they know their priorities, workload and team size, better than I do - they're not willing to tell me what it is.

So, I need to work around them to get something done, and build it myself, even though there's a possibility that they'll deliver it in the timeframe I need. I have no other choice because they won't help me put a plan together. Sure, I've now avoided being affected by those "things that popup" but only because I've avoided having any dependency on the team that ought to be doing the work.

Other teams are making plans. Launching a product takes time. Meeting compliance deadlines takes time. Reskilling a workforce takes time. Getting contracts signed takes time. They are incorporating your roadmap into their plans, and if the roadmap you give is "I'm not willing to give you any predictions past the end of this month" then that's the roadap that they're basing their plans off. It absolves you of any responsibility because you never committed to anything, but the organisation as a whole suffers because everyone else is having to spend more time and money to work around you.