3

How can I define performance expectations for a new software development manager/architect (new in that this is a new set of responsibilities for him, specifically in the architecture area)? Then, how can I effectively evaluate his performance against these while still providing autonomy as his manager? Defining metrics and evaluation criteria in terms of project delivery isn’t a problem, but there are also technical outcomes I need to hold him accountable for - specifically

  • Making progress towards long term strategic goals (yes, these are explicitly defined), and aligning incremental work on these to current projects
  • Being proactive, not reactive, to technical debt and supportability issues
  • Leveraging best practices and standards and evolving them
  • Doing adequate technical design to ensure what gets built is what was communicated (in terms of high level design/architecture)
  • Identifying and remediating inefficiencies in our SDLC processes

How can I as a manager best be clear about my expectations in this regard and have a way of evaluating success?

  • 1
    Look into creating SMART goals as a useful tool for setting expectations. – DanK Jul 7 '18 at 6:20
  • Using SMART is a great idea. I would start by having him capture the current state of affairs so you and your direct report can prioritize and understand the impact of his work. Then have him propose what success looks like for each initiative. – jcmack Jul 27 '18 at 20:08
2

I suggest establishing a 30 / 60 / 90 plan with them. I'm sure you have goals/expectations in your head, you just need to break them down and come up with measurable goals around these periods of time (30 days, 60 days & 90 days). Once you've come up with the list, you present it to them and discuss their expectations, and you can have a conversation, and adjust as necessary.

You are doing two things, providing a clear guideline of your expectations, and giving them a deadline to demonstrate proficiency. When you come to them in a month with a performance review, they will know beforehand what you expected, and you can target your review to these specific goals. Also, since they know what goals will be discussed, they will make sure they good and well have met them.

There is more information about this type here: Onboarding Isn’t Just Day One: Creating a 30/60/90 Day Plan

1

?

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).

  • The gap in just measuring “output” is that “as long as what built works” doesn’t say that much. How is works 30/60/90/*** days out, how much maintenance it requires, how much it costs to add functionality to it are all unobvious from just looking at “does it work” – User Jul 7 '18 at 13:01
  • @User that would be a different question though. Your bullet points won't guarantee the issues you raise, but you did ask how to measure those bullet points. If you want this question answered, then I'd suggest you ask that instead! – bharal Jul 8 '18 at 2:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.