I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up.
Let's take two projects. Project A is estimated by the eng team to take three months to complete. It's not broken down into tasks that are individually estimated and tracked. Just one monolithic task: Do Project A. The project manager says "go!" and then leaves the tech lead to basically run open loop, maybe with a monthly "So, how are things going, eh?" conversation.
Project B is estimated by the engineering team to take three months, but is then broken into small week-long sub-projects, and days-long sub-tasks, highlighting dependencies. After stacking the tasks up and assigning them to the team, it looks like the project will actually take four months. Throughout development, new tasks are created as bugs are found and assigned priorities. The project manager and eng lead watches the finished/remaining task lists daily or weekly, and can easily tell when something is taking much longer or much shorter than expected, and what other parts that depend on that will be delayed.
Which project do you think has the best chance of making its estimated complete date? If the complete date is actually a deadline, which project can be more easily re-sized half way through if we need to cut scope in order to make it? Which project can the team's boss's boss's boss more easily obtain status information about? How does anyone besides the eng lead know whether Project A is even done?
Of course the way to do it is not to completely let the team go untethered with monthly checkins. You can still monitor progress, at the tech-lead level. But micromanaging the team members has always seemed hugely detrimental to me. In particular, let the team deliver in chunks: a prototype, a major feature, a reduction in bugs. But let them follow their passions in their day-to-day work.
In my experience, plan B gets something done, but you pay for it by shipping half as much and it's half the quality, plus everyone is unhappy. I guess if all you want is to ship something for a deadline go for it.
edit: to be clear, I don't think you should turn the team totally loose. I just think the right level of external micromanagement is at the scale of weeks, rather than the 'hours' I see useless managers doing in practice.
My heart wants to agree, and I think that up to a certain level for internal projects you can do this. But at some point that’s just not possible from a business perpective.
Can you imagine going to your client and saying “you know that project you’ve paid us 150M$ for? Don’t worry about it, Bob’s on it, he’s the best. See you in 3 years’ time for the launch!”
But it does look pretty different from tech project management. Department heads are not treated as task monkeys. They are treated as being potentially myopic about their own pieces of the puzzle, and given support on integration with the rest of the production.
After all, programming is a craft that can have things akin to "writer's block" (for instance, being stuck on a bug or design). It's more like writing the script than shooting the movie.
A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort.
More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables.
Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.