Comment by timv | Hacker News Reader

Comment by timv | Hacker News Reader

Parent Full thread

> If you’re doing innovative new things, a roadmap is almost the worst possible way to try and co-operate on them.

Very few organisations are or should be exclusively doing "innovative new things". Upgrades of old tech, compliance with new regulations, automating out dated processes. Those are all needed and rarely need innovative new things.

> it’s top of our list, we estimate starting on it after x”. Neither of these need a roadmap.

Because you've decided that "roadmap" is term that doesn't apply to "starting on it after x".

"We haven't started on this, but we will plan to do it next" is a roadmap!

"We like the idea, but the team are all busy on things that we expect to take up all their time for the next 6 months" is also a roadmap

As I said in my parent comment:

> You need _some_ form of roadmap to make this stuff work. The argument is about size (volume and duration) and flexibility.

It is unlikely that any organisation can/should do a 3 year roadmap. But a lot of teams already have a 6 month roadmap because they're already committed to that work.

> Because you've decided that "roadmap" is term that doesn't apply to "starting on it after x".

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 know you know what's really meant by roadmap, because your example of "when am I getting my geo?" doesn't work without a classic date-driven roadmap.

> But a lot of teams already have a 6 month roadmap because they're already committed to that work.

And those teams are inviting trouble when things pop up that override those commitments. Like Meltdown/Spectre. Or an unexpected competitor event. Or an economic change. Or a third-party intervention. Or any one of a number of things that need reasonable-sized responses and can't wait six months.

If you're working off a prioritised but uncommitted list, none of these things are problem, because you won't have allowed your stakeholders and those dependent on you to become coupled to your current 6-month view. If you have allowed them to become coupled, then you've just multiplied the organisational impact of each one of those events.

PMs should be creating decoupled, co-operative and flexible organisations where disruptive change is expected and accommodated, not tightly coupled, brittle, organisations where change is mitigated and worked around. Dated roadmaps are a symptom and a cause of the latter.

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

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

Reply on news.ycombinator.com