Estimates vs. Actuals (Score 1)

First time poster here.

I built web apps for 20 years, and have recently shifted to a career in management. Having developers report to me for the first time in my life, I was concerned about the "estimates/actuals" problem, having personally experienced the awfulness of both corporate and agency life.

From an agency perspective,
- estimates were often taken as contracts, ie. this isn't a guess, you *WILL* deliver the functionality in the time denoted.
- this led to a culture of fear/overworking to meet unrealistic goals "committed" to (when in truth, no actual commitment was intended). Rushed/frazzled developers often made more mistakes, making late projects even later, further blowing their original estimates out of the water.

But, from a corporate perspective,
- developers were never asked to estimate (or management had given up asking?), because project failure often translated to "oh, this is just extra clean-up for DevOps"
- this led to a culture of minimal/zero developer accountability. Developers didn't track their time, and no-one held them to any standard. Over time, they took as much time as they needed, while the real (read: Stack Overflow-based) tech industry did laps around them. I contend that they stagnated or, worse yet, lost skill/ability.

For my first development team, I wanted to be sure I did not make these same mistakes, so:
- I *do* ask them to give me estimates, and I have them track their time (we use Trello).
- When I run month end reports, we look at their estimates/actuals (among other metrics) to look at issues where they were **way** off, get into the guts of the task, talk through what they did to come up with their estimate, what might have caused their actual to be so far off, and what they could do to narrow that gap.

That's not enough, however. I also:
- Insist that all task requests go through me, rather than the individuals on the team. *I* own delivery expectations, so I give the customers very wide margins on when they can expect their requests to be completed. It is **vitally important** that the customers themselves never inject their own lack-of-tech knowledge/communication problems/agenda into project management discussions, lest the "your estimate is now a contract" problem surfaces.
- **Repeat like a broken record** to the team that estimate/actual measurement is **not** (NOT!!) about spying on them/finding a way to write them up, but to expand their own knowledge of their tech craft and work to perfect it. This includes setting a fundamental expectation up front: I do not, nor will I ever, expect estimates and actuals to be 100% (which is definitely not the case with the customer!)

I've also worked with a data scientist colleague of mine to build a scoring system that ranks them, month to month, on their ability to be *consistently narrow* on their estimate:actual difference ratio (this is not the only metric, there's about five or six different metrics all at various weights), which challenges them to improve by seeing an actual number, and then doing what they can to increase it.