To me this is why OKRs work more effectively (so long as you take the metrics with a pinch of salt) than traditional roadmaps. You're focused on achieving a business state rather than chasing a set of arbitrary deadlines for "Feature X". Smart people suddenly have space to use their brains.
In fact typical product roadmaps end up a source of toxicity in most organisations I've worked in...
- Out-of-date the moment they are published.
- Tying down product managers with moving little boxes around PowerPoint; people who'd be better off getting out of the building and talking to customers or working with engineers
- Causing a blame culture around missed deadlines, sapping everyone's morale
- Needing multiple versions depending on the audience; low granularity for top level management, high granularity for engineers, carefully worded for customers and users e.g. "Add ad tracker" or "Fix bug causing data loss" may not be what you want sales people to present
- Always subject to (mis)interpretation
- Based on wild estimates of how long things will take 3 quarters ahead through the year
- Too focused on shiny deliverables and ignoring things like "We need to have to this quarter for re-writing a major component that blocks everything else"
- Often unread or poorly reviewed
- Bad at visualising dependencies between things being worked on
- A source of silliness like "Why are wasting time doing X when we know we need to be doing Y?" ... "Because it's on the roadmap"
... and probably loads more.
- Getting More by Stuart Diamond - https://www.amazon.com/Getting-More-Negotiate-Succeed-Work/d... . On the cover it’s about negotiation but most of what a leader does involves negotiation. Rather than try to convince you, I’ll just say Google engages Stuart Diamond to trail engineers in negotiation. There’s a talk by him here at Google that might convince - https://youtu.be/2QtZ-vObJrk
- The other is “Corps Business” - https://www.amazon.com/Corps-Business-Management-Principles-... - about how the US Marines do management. The big thing you can get some this book is expressing projects and tasks in terms of the _end goal_ instead of the steps required to get there. Make sure teams collectively understand the end goal and let them figure out how to get there is the basic message. That implies you need to put your effort in being good at story telling and presentation
This naturally leads to a situation where those working at the top are being overwhelmed with demands for their attention and decision making approval.
A conscientious person - arguably a good _leader_ - will take this responsibility seriously, and devote their time and energy to handle all those demands as best they can.
But another type of person - a "player" - will realise that the work of decision making actually _detracts_ from their success within the organisation. A "player" will figure out they should avoid the work of leadership as much as possible and instead devote their time to fostering their own image, gaining popularity, claiming responsibility for other peoples good decisions and generally working their way up the pyramid.
For me hierarchical power structures are the root cause of the problem here, not human nature - the "player" is really acting rationally, taking the path of least resistance to achieve their goals.
The problem IMO is we're using legacy approaches to organising ourselves groups that stems from military theory of the 18th century - that most armies themselves have now moved beyond - see https://www.amazon.com/Corps-Business-Management-Principles-....
We need smarter ways to organise and we probably need AI at some level to help us scale up to higher volumes of effective decision making.
[1] http://www.amazon.com/Corps-Business-Management-Principles-M...
...otherwise - being a bit of a history nerd - I’ve run into the idea many times in discussion of how military units have evolved over time. Much of the thinking about ideal squad sizes began in WW2 - don’t have single thing I can point you at though