I largely agree with Tristan on this. Business folks are constantly thinking in terms of dates; I'm sure it seems obvious that this is the way. And I largely agree! The system I use to manage teams is gathered from a variety of sources, but contains only two guidelines.
Frontload Risk
One type of slowdown is unanticipated complexity. These snags slow things down because one aspect of the work took longer than expected. These snags are often things we can anticipate in advance. In cases where we think there may be a snag, start working on that part of the project first and create a prototype. I sometimes call this "de-risking" or "retiring risk" in management meetings, but it just means "try to make the tricky parts work first".
Set Target Dates
After frontloading risk, you can allow some time to work through those risks, as well as the "easy" parts of the project. Do some rough sizing ("3 days to identify the correct backend storage system and make it region-aware") and then set a target date for the project. This date is not a commitment, but a public statement of what the team is shooting for. It's not the manager than sets this, but rather the engineers, and it comes with one instruction: the team must raise a flag as soon as the they encounter a snag that they think will alter the target date. This frees the team from sync meetings to assess status, and comes with an added benefit: sources of delay are easy to pick out when the team reflects on the project after it is complete. Some findings might be generally applicable and can be integrate into a list of things to think about during the "rough sizing" phase of the project next time.
That's it! I've used this approach across multiple companies over the past 10 years or so, and it's is fantastic at getting out of everyone's way keeping the focus on shipping great work.