I'll answer this from the perspective of a typical web dev/startup shop. Throw it out the window if you're writing safety critical code or something serious. :)
Yes, it's rare but it takes good leadership from both the technical and non-technical sides of the business.
The technical leadership needs to push back on scope and encourage the folks that need problems solved to be descriptive of their problems rather than prescriptive of the solutions they think they need (but at the same time not dismissive of those ideas).
The reason for the scope pushback is that ideas for problems to solve are likely to have some flaws in the hypothesis given until there's something out there in the real world to learn from. So it's the job of tech leadership to work with other parts of the business to figure out how to fail fast and burn as little engineering hours as possible in the quest to become less ignorant faster.
This has the added benefit of making things easier to estimate, I don't think it's controversial to say that smaller scope means smaller task breakdown leading to more accurate estimates. Teams will usually fail to deliver on estimates until they iteratively go through this process and reduce scope until they can consistently deliver.
When that happens you start to build more trust with other parts of the business, and maybe over time, when you do dare to throw out a ballpark scope for what can be achieved in the month/quarter, you're not that far out.
To be clear though, the trust that you'd be asking for as tech leadership should be a two way street, for the most part it's to be appreciated that the parts of the business that some in tech routinely dismiss are often keeping the lights on, and you need to figure out a cadence that allows your teams time to breathe and refactor in such a manner that still delivers product changes.