?
My problem with your question is this - your job should be defining targets, and working out how to efficiently measure them. You should also be meeting with your direct reports at least once every two weeks for an hour catch up to find out what they are up to.
Their jobs are to work out what to do to match those targets, and to use their time with you to let you know of any problems so you are prepared in advance.
From your list then, if you cannot define the target, you must drop it. And if your target is "manage in this way" then you should drop it - because that means you're just doing your report's job, thus defeating the purpose of having a report.
- Making progress towards long term strategic goals (yes, these are explicitly defined), and aligning incremental work on these to current projects
Well you presumably have a timeline for these long term strategic goals, so surely you would expect there to be progress along them that aligns with that timeline? This seems relatively straightforward. Assuming you're meeting with your report once every week or two you could also just enquire about this. Seems easy.
- Being proactive, not reactive, to technical debt and supportability issues
This is slightly measurable. In your meetings you can determine how often issues arise due to technical debt problems. If they arise less frequently, then you can assume that your report is being proactive.
- Leveraging best practices and standards and evolving them
Oh lord no. This sounds like twee from a bad job spec. What does "evolving" a best practice mean? What standards are you even wanting? There are code-measurement tools that can be tuned to a host of issues. Comments, class size, test coverage etc. You could simply use them, and then bring up the practices you want used and measure them. If you're talking about management practices - then unless you're specifying a specific practice to be used you shouldn't be expecting your managers to be changing their practices to match trends.
- Doing adequate technical design to ensure what gets built is what was communicated (in terms of high level design/architecture)
Surely this is relatively easy to measure. As long as what is built works then adequate technical design was completed, no?
- Identifying and remediating inefficiencies in our SDLC processes
Surely this is unneccessary. The manager's task should be to make improvements, yes. Defining how to make those improvements should be left to the manager though. That is to say, as a manager makes improvements in delivery or whatever, those improvements would presumably come from inefficiencies in your process. Ergo the presence of improvements in output prove improvements in process (and even if they somehow don't, why would you care? Surely the point is to improve output).
