Oh for sure.
I think part of the reciprocal aspect, that businesses are also terrible at, is feedback. Most technical work is unremarked upon. There's code review, but how often do your teams retrospect their own work? How often do they retrospect some system or another teams work? Businesses use their same superficial tip-of-the-iceberg views, more often than not, to assess employees. 10x hacker wins again!
Let's take your scenario:
> I've seen 20-something, know-nothing developers relentlessly question every business decision during planning when they clearly have no idea about the larger scope of the business.
I'd like to see some stake in here. If this persons on our payroll, give them, I dunno, 3-sprints of their own work/2-times-per-year to go try to make shit they talk up real. Maybe insist they spend a sprint or two working with at least one other person on it, to make it a little more real & not independent fuck off time. Have some sort of coder council at the end that can discuss highlights & negatives of the approach. Make sure not-passing is a known & not-irregular result. But let them go at it, find out!
It's weird to me how consensus is nearly the only operating paradigm for organizations. The overwhelming & singular pattern is always the same: somehow a path is picked, and everyone must hem to it. The actual cost of doing duplicate work seems low to me, given how often I think we leave massive potential gains behind. I recall a mention of 1-10-100[1] today, which is nominally about the cost of bad data: 1x if prevented, 10x if corrected, 100x if failure happens. Computer systems/code seem like a hyper-complected version of this. Finding good systems, good patterns, good ways to do things, that make things easy & simple will keep paying off, will be endlessly rewarding. It's so so hard to project, and we often pick "safe" in terms of what we know, but we rarely get to explore the opportunity cost of other paths. And we damage our employee's belief in the company by consistently rejecting bold ideas.
Right now it sounds insane to develop something twice, to let two groups do a thing, and then figure out latter where to head- someone's going to get hurt probably- but I think, if we want to tame the 20-something bucks, some real world challenges like this would be very compelling intrinsic motivators. Would show us very quickly a lot of different kinds of legitimacy: the legitimacy of the organization's concerns, which are unmet by the small-scoped young mind, and the legitimacy of the young mind, which may have some great out of the box stellar wins. Right now we don't try to let people try- we reject people's sense of purpose, we deny them autonomy, we refuse to acknowledge their mastery, for a litany of well-intended & perhaps-functional concerns, but they never construct the understanding & knowledge that would clarify why they are snubbed. If they could live the experience[2] instead, it might alter their intrinsic motivations in the future, might align them differently. Instead, we use hierarchy & roadmaps to coral & drive our talent forward.
It sounds daft & wild, the processes we'd need seem like they'd mostly just be spitballed together at this stage, but breaking the mold: rejecting the concensus practice of consensus based knowledge-working, allowing different people to try different things, having stronger review & higher candor & willingness/ability to try things & reject some, say no: I think there's huge wins for amplifying the highly-important intrinsic motivation, and I think it would unlock a lot of higher-performance work. Leaving mono-culture & allowing diversity into the organization sounds is an idea that sounds both radical to me, and flabbergastingly right-in-front-of-us.
[1] https://news.ycombinator.com/item?id=31643434
[2] https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...