Earlier quoted context omitted.
> Tie it to deliverables That's a great idea in theory because tackling a real world problem tends to motivate towards a real world solution. However, learning invariably encompasses failure which rarely measures up well with typical (if arguably useful/useless) performance metrics that developers contend with.
If the deliverable is a team report, then failures are super useful and still count. "I tried implementing X as a test after reading about method Y, but found that for our domain there are serious drawbacks."
I was referring to the potential for a metric that could backfire in the context of a performance review. (And that'd be a relatively tame surprise in one of those god-forsaken events...)