> If you're a manager, how do you tell if your team is spending 50% of the time slacking vs. working on a problem that is twice as difficult as everyone thought?
Why not... Ask them directly? If you understand the type of work your team is doing it should be easy to figure that out. If you manage software engineers and have no idea how software is created no metric is going to save you.
> Was another company or team able to deliver the same feature with less resource expenditure?
How many corners did they cut do deliver faster? And how long will it take before they get crushed by technical debt? There is always a trade-off between quality and velocity. High velocity is immediate to see, but good quality takes time to be appreciated.
>There is always a trade-off between quality and velocity.
This is a common trope but is rarely the case in my experience. Components designed to be flexible and 'future-proof' are the ones that quickly become overengineered, resulting in late deliveries and costly maintenance.
Writing the minimum code required to solve the problem is often a winning strategy.
Why not... Ask them directly? If you understand the type of work your team is doing it should be easy to figure that out. If you manage software engineers and have no idea how software is created no metric is going to save you.
> Was another company or team able to deliver the same feature with less resource expenditure?
How many corners did they cut do deliver faster? And how long will it take before they get crushed by technical debt? There is always a trade-off between quality and velocity. High velocity is immediate to see, but good quality takes time to be appreciated.