Why would you ever give a developer a task without ensuring they understand your strategic long-term goals? That sounds like a sure-fire way to end up with a product that doesn’t match your vision.
There’s plenty of work (possibly a majority of it) in the industry that can be of the form “take a ticket, do the ticket, close the ticket”. Someone in the cascade has to understand the strategy and product vision to ensure you get a good overall outcome, but it doesn’t have to be the 22 year old SWE-1.
My benchmark for this being wrong is that military briefings don't do this if they don't have to.
The gold standard for a military briefing is that it includes a high level overview of the global, regional and local situation before getting into specific orders and this was adopted because small unit doctrine depends on unit commanders having enough context to make informed independent actions in lieu of direct chains of command being available.
Everytime I've watched a ticket languish in any organisation, it's always because people don't feel a need to give context. They think they understand what they're asking for, it doesn't match reality and then the back and forth culminating in a bunch of calls and finally someone explaining the goal happens.
I wasn't in the military and my knowledge stems only from others' personal accounts and what I read about it.
I agree for the need of context. Because only then can the operative understand why it is important what they are doing and in case of decisions to be made on the ground either decide or clarify with the org structure.
I know that unit commanders are being (ideally) briefed like you described. But how does this context trickle down to their people? Does the military have a means to ensure the passing down of relevant and qualitativ information?
Because that is what I personally see as a problem more often than not. The information is lost at the lower rungs of the ladder.