And yes, you're not going to end up with your exact vision when you delegate. The question is whether the end goal is sufficient and minimal, and if not then you should evolve that with the other people involved.
Ideally.
In practice I've seen it go the opposite way where management's reaction is trust less and less, making smaller and smaller tasks. Developers aren't innocent either, instead of griping about having less control, they throw up their hands and work-to-rule. Doesn't matter if the task description has obvious problems, that's what is getting implemented. Nothing less and nothing more.
Honestly this all comes off as toxic. Maybe it's high time to leave where I am seeing this all go on.
From my own experience, I would say yes.
You might have to take baby steps. Can you watch someone make a mistake without intervening? Can you do so without severe emotional turmoil?
Most managers never break the micromanagement habit, and will always pay the price. Probably the biggest price of not trusting people is that they don't trust you either, and they find ways to keep you out of the loop so they can make decisions and get work done. This in turn causes you to trust them even less. Distrust is a self fulfilling death spiral.
You might have no choice, e.g., if you work in a micromanagerial culture. Can your boss watch you, as you are watching someone make a mistake? In other words, are your management habits the source of a culture, or merely its effect?
Thus the final step is: Can you stick up for your people after they've made a mistake?
Some of my best jobs involved constructive discussions with my managers just like this. If a developer is any good, they're smart. It's okay to treat them like a fully functioning person.
I don't enjoy small tasks as a manager but they can be necessary depending on how much I trust someone.
That's a little bit extreme for example but there's definitely benefits to standardizing things across projects.