3 ms·

> It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have

by timv 9y ago

> It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions. Yet, the extreme alternative of being entirely unable/unwilling to answer the question: "I need this, when are you able provide it?" also has huge repercusions. If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. If the internal "Database as a service" product team doesn't offer any sort of Geo capability, and I need it then I have to solve that problem. If that team cannot provide a roadmap, then I have to build a work around within my product team. This costs money, and that affects the P&L of the organisation. The organisation's goals are best met by having this capability built in the right place, with respect to upfront cost, ongoing cost and time to market. You need _some_ form of roadmap to make this stuff work. The argument is about size (volume and duration) and flexibility. But those aren't absolutes, and we can argue forever about "how big is too big?" (but let's not). And so we end up with articles that talk in vagaries like "big change programs with detailed roadmaps" which doesn't mean much.

bonaldi 9y ago
> If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. Yes, you need co-ordination. No, you don’t need a roadmap. If you’re doing innovative new things, a roadmap is almost the worst possible way to try and co-operate on them. Let’s say you really do need your geo feature now. There are two happy answers from the DB PM: “we’re working on it now, estimate is x” or “it’s top of our list, we estimate starting on it after x”. Neither of these need a roadmap. The unhappy answer is something like “we’re not working on it, it’s fifth on our priority list”. You also don’t need a roadmap for this. In fact, this is a more honest and useful answer than the roadmap one — which would be something like “it’s behind four other things so slated for Q3”. The roadmap is a crutch to avoid the hard conversations about priority that are the core of good co-operation. Why? Because the roadmap suggests that while geo isn’t priority 1 now, somehow by the time Q3 rolls around it will be, and so you can start planning against that. That is going to leave you unhappy in Q3, almost for certain. Because the truth of the matter is implied in the priority list answer: “this is fifth to us. So we will work on it when we finish what we’re on now and if we get through the four things in front of it and if nothing else comes up as a higher priority in the meantime.” If you need geo, either way you now need to make a case for higher priority, to escalate, or figure out some other way to do what you want because clearly what you need isn’t an overall business priority. The roadmap also makes all those conversations harder because they become about dates and the PM can say “of course it matters to us we just can’t start it until Q3, do you really want to resequence all these other things? What about the impact on all the other dependencies? Seems bad”. Obviously this just leads to worse and worse conversations, until management steps in and says the real problem is a lack of transparency. What is really needed, they’ll say, are better roadmaps, ones that expose dependencies properly, ones that let the consequences be seen, ones with a much higher granularity. And a PMO to help us run it all. Before long, you’re no longer co-operating, you’re fighting over Gantt charts. This is the state of affairs the article is intending by “big change programs with detailed roadmaps”. And it can all be avoided by not pretending that work stretches out in front of us on a calendar. We don’t work on geo because Q3 has arrived and “we promised on the roadmap so I suppose we’d better”. We work on geo because of all the items on the shifting sands of priority, geo is the top one now and that priority is broadly agreed across the business. All you need are three ordered lists: “stuff in flight”, stuff that’s up next” and “stuff we’re looking at but haven’t committed to at all”. All the benefits of roadmap transparency and priority still surface, with none of the bad consequences of trying to express those things via a calendar.
- DerpyBaby123 9y ago
  Well said!
- timv 9y ago
  > 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.
  - bonaldi 9y ago
    > 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.

by timv 9y ago

bonaldi 9y ago

> If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. Yes, you need co-ordination. No, you don’t need a roadmap. If you’re doing innovative new things, a roadmap is almost the worst possible way to try and co-operate on them. Let’s say you really do need your geo feature now. There are two happy answers from the DB PM: “we’re working on it now, estimate is x” or “it’s top of our list, we estimate starting on it after x”. Neither of these need a roadmap. The unhappy answer is something like “we’re not working on it, it’s fifth on our priority list”. You also don’t need a roadmap for this. In fact, this is a more honest and useful answer than the roadmap one — which would be something like “it’s behind four other things so slated for Q3”. The roadmap is a crutch to avoid the hard conversations about priority that are the core of good co-operation. Why? Because the roadmap suggests that while geo isn’t priority 1 now, somehow by the time Q3 rolls around it will be, and so you can start planning against that. That is going to leave you unhappy in Q3, almost for certain. Because the truth of the matter is implied in the priority list answer: “this is fifth to us. So we will work on it when we finish what we’re on now and if we get through the four things in front of it and if nothing else comes up as a higher priority in the meantime.” If you need geo, either way you now need to make a case for higher priority, to escalate, or figure out some other way to do what you want because clearly what you need isn’t an overall business priority. The roadmap also makes all those conversations harder because they become about dates and the PM can say “of course it matters to us we just can’t start it until Q3, do you really want to resequence all these other things? What about the impact on all the other dependencies? Seems bad”. Obviously this just leads to worse and worse conversations, until management steps in and says the real problem is a lack of transparency. What is really needed, they’ll say, are better roadmaps, ones that expose dependencies properly, ones that let the consequences be seen, ones with a much higher granularity. And a PMO to help us run it all. Before long, you’re no longer co-operating, you’re fighting over Gantt charts. This is the state of affairs the article is intending by “big change programs with detailed roadmaps”. And it can all be avoided by not pretending that work stretches out in front of us on a calendar. We don’t work on geo because Q3 has arrived and “we promised on the roadmap so I suppose we’d better”. We work on geo because of all the items on the shifting sands of priority, geo is the top one now and that priority is broadly agreed across the business. All you need are three ordered lists: “stuff in flight”, stuff that’s up next” and “stuff we’re looking at but haven’t committed to at all”. All the benefits of roadmap transparency and priority still surface, with none of the bad consequences of trying to express those things via a calendar.

DerpyBaby123 9y ago
Well said!
timv 9y ago
> 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.
- bonaldi 9y ago
  > 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.