> 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 p

> 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.