4 ms·
> 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 g
by timv 9y ago
> 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.
- bonaldi 9y ago> 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 I think the point I'm trying to get across to you is that this is always the case — even if they try to shut you up by putting it on a roadmap. If Geo's not such a priority that they'll do it now or next, then it's going to be at the mercy of whatever it's competing against when the roadmapped date rolls around. You may not get it then either — and you'll have wasted all the time and money you spent on compliance/reskilling/contracts based on the faulty assumption. The idea that "I need this thing and they provide the thing, so they ought to do it" is nonsensical. They ought to do what provides the most business value at any given time. If that's genuinely providing your thing, gravy, it'll be high enough up their priority list that you'll know they'll very soon be working on it. If it's not, then the fact that it's on a roadmap for somewhere in the next year is still meaningless: the chances are extremely high that something of higher business value is going to arise between now and then. Basically, you should treat other internal teams like you would any third-party supplier. Have a plan B. Say it's (eg) Oracle who are promising a geo feature you need in their upcoming release. You don't know when it's going to ship, but you know if it does you can make use of it. So you plan and act as if you might get it, but you also work out what you're going to do if it gets pulled. That's prudent risk management. You should be doing that anyway. It's not "working around Oracle". Your organisation doesn't suffer because it doesn't control Oracle. Your organisation is more resilient because it has increased its flexibility.