Performance Management as a New Manager: How to Create a Plan (Part IV)

This is part 4 of 6 in a series that gives guidance on how to manage employee performance for new product design managers — or those facing performance management situations for the first time.

← Read the previous article: “Performance Management as a New Manager: How to Assess (Part III)”

When you’re managing a team member’s performance, how do you create a plan that the team member can use to be successful? Here’s what you should and shouldn’t do.

Don’t: Go too broad or overly simple

When you’re looking at a team member’s thematic performance data, it may feel like a lot, and you may also run into a number of themes that cross many domains with serious consequence. If you present a version of “you need to improve on everything” to your team member, they may not be reasonably able to improve in a short time frame.

On the other hand, overly simplifying things may not get to the heart of the problem. If you’ve done the work of assessing the situation, you’ll be able to prioritize one or two direct themes that, if improved, will have a positive improvement on multiple domains.

Do: Stay concrete, clear, achievable

As you work through your assessment, you’ll want to use a framework to outline what improvement will look like. Your goal is to set up a plan that a team member can take ownership of, and — with your support — will get them out of the performance management situation.

Earlier in the overview of this series, we identified that great performance comes from:

• Understanding and alignment of performance expectations
• Clear and achievable goals and outcomes
• Flexible pathways to reach goals
• Regular feedback and support.

Your plan should use these four parts to get performance—situational themes and related skill domains—from not meeting to meeting expectations.

Let’s use the example we’ve been working with throughout this series, where a team member works overly independently and fails to get feedback on progress. You’ve already collected your themes based on the situation, and you’ve mapped to their costs and domains.

Take time to work from the situational theme and evaluate it against the elements of good performance. Think of this like a check list. Here are two versions of the same situational theme at different levels.

Example: Junior designer

Let’s say you have a junior designer on your team. Perhaps they’ve been in the role for two years, which is generally when their peers have been promoted to a mid-level designer. Their abilities to manage their own performance won’t be completely at a beginner level, but they’ll still be earlier on in developing those abilities.

Example performance data for a junior designer

As performance is about behaviors and skills that drive results, a junior team member will be working on developing skill domains to get results. Looking at the domains applicable to the situation as direct behaviors will be helpful here. In this example, you’d be able to reasonably expect the following in regards to the situation:

1. Expectations: What is expected for this situational domain or theme? This expectation — in our example domains — is collaboration and design process. A junior team member should be able to internalize the expectation that they’re expected to get regular feedback and apply the skill as they get regular feedback. Ask: does the designer internalize and apply expectations at a junior level?
2. Goals & outcomes: What are the goals for this situational domain or theme? At a junior level, a team member should have heard and can repeat back why feedback is valuable: in this case, the outcome of regular feedback is better evaluated solutions that are more likely to solve problems. Ask: does the designer intake and replay goals at a junior level?
3. Pathways: How might the team member get to these goals? This junior team member should be given pathways: they’re told how to get feedback, for example, that they show up to critiques or talk to customers to get design feedback, and they actively try these things out in their practice. Ask: does the designer receive and implement pathways at a junior level?
4. Support: How should this person be managing support on the situational domain? When a team member at this level receives notes on how they collaborate and get feedback, they’re expected to both receive the support and modify behaviors. In this example, the SBI feedback was given about failing to show work in critiques. Reasonably, they should be able to take that and adapt by showing work continually in critiques. Ask: does the designer accept and respond to feedback on the situational domain at a junior level?

Skill domain development and project approach comparison for a junior designer

Example: Senior designer

In a different scenario, when you have a just-promoted senior designer on your team, it’s possible they’ll have the same feedback theme, however, expectations will be different, and the domains to address will also likely be different.

Example performance data for a senior designer

Senior team members are held accountable for not only the behaviors that drive results, but also the results themselves. Looking at the cost and indirect domains first, and using the situational domains as supporting context will be useful here.

You’d be able to reasonably expect the following in regards to the situation:

1. Expectations: What is expected for this cost domain or theme? At a senior level, this team member should be responsible for contextualizing the expectation of business results and cultural impact, and adapting skills for the given context. With the corresponding domains of collaboration and design process, it’s also expected that collaboration and design process are contextualized and adapted. This is a much broader and more loose expectation than the junior level, and that’s normal, given junior designers are held more responsible for inputs, and seniors are held more responsible for outputs. The answer to this prompt may need a deeper look at goals & outcomes & pathways, as those parts are requisites of meeting this expectation. Ask: does the designer contextualize and adapt expectations at a senior level?
2. Goals & outcomes: What are the goals for this cost domain or theme? In this example the senior team member should be able to set and refine the goals & outcomes of what the skill should deliver in context. They’re likely able to forecast the potential costs for the domains of business impact and culture: “if I don’t get regular feedback, that puts the success of the project at risk; I and my team will need to start over or scrap the project, or we may need to get additional help from a teammate”. Phrased as a positive outcome, they may be able to refine to this: “By working collaboratively and getting feedback from multiple sources, I’ll increase the possibility that this project will hit our success metrics, we’ll minimize process time, and I’ll also be contributing at level and our team collectively will be working together to meet our customers’ needs.” Ask: does the senior designer set and refine goals at a senior level?
3. Pathways: How might the team member get to these goals? Whereas a junior designer may need to be given their pathway; a senior designer should be able to create and execute on their own pathways to deliver on the skill. Keep in mind that this is about creating pathways to skill development, not process to project success. In our example, the cognitive work and preparation to make the decision and plan on how to set up feedback to deliver business and cultural impact is the pathway. Ask: does the designer create and execute on pathways at a senior level?
4. Support: How should this person be managing support on the cost domain? Because we’re prioritizing the cost domains here, a senior designer is expected to get feedback and support to reach the expectation: creating and executing on pathways. Remember, support here isn’t about about the act of getting feedback on the project, but is about getting support on their performance in the domain. They should be actively soliciting feedback on how they set goals and how they create pathways. Ask: does the designer solicit and compound feedback on the cost domain at a senior level?

Skill domain development and project approach comparison for a senior designer

Using the skill domain develop and project approach comparison from the overview in this series will bring clarity on how to frame around skills rather than projects. This is of the utmost importance because as a manager, you want to develop your team member’s skills in order to have repeatable and scalable successes rather than singular project success. It will also prevent you from micro-managing, or expecting things to be done the precise way you would have done something in the past.

Plotting the performance

As you’re checking these four things, you can critically plot your responses to help inform your plan. Let’s look at this in the more complex senior example.

Let’s say your responses were the following:

1. Does the designer contextualize and adapt expectations at a senior level? No
2. Does the designer set and refine goals at a senior level? Yes
3. Does the designer create and execute on pathways at a senior level? No
4. Does the designer solicit and compound feedback on the cost domain at a senior level? No

Looking at these as heuristics will help you with a few things. First, you’ll be double checking not only that there is a performance issue; if your answers are all yes, then your team member is likely meeting expectations! Second, You’ll also be determining if you’re looking at the right theme or domain. In the case of all yeses, you also may need to go back through the process against a related domain or theme and see if you get the same results. Third, and most importantly, you’ll be able to zero in on which of the four parts need the most support. Many performance issues come from expectations simply not being clear, while others come from simply not having the toolkits to receive or create pathways.

You can also look at these four parts of performance qualitatively, using the data you’ve collected and assessed to plot where on the level spectrums a team member might fall.

Example performance data for a senior designer

In this case, let’s say the senior designer actually has set the goal for collaboration and feedback in terms of business outcomes and culture: “By working collaboratively and getting feedback from multiple sources, I’ll increase the possibility that this project will hit our success metrics, we’ll minimize process time, and I’ll also be contributing at level and our team collectively will be working together to meet our customers’ needs.” They’ve set and refined the expectation in context.

But they aren’t meeting expectations at level, because they simply aren’t creating the pathways or getting the performance support they need to do so.

This analysis will be the heart of your framing. You can use the following outline to frame this in a clear and concrete summary.

Putting it all together in a plan

Your plan should have—not surprisingly—expectations, goals & outcomes, pathways, and support. It’s quite literally the same thing as skill domain development! In this situation, however, these things have already been in place, and your team member still isn’t meeting expectations through their project approach. This plan will reiterate the already-in-place development components and will go into more detail on what is happening, what to expect, and what the timeline looks like.

Performance Improvement Plan (PIP) components for a senior designer

Let’s put it this together in a full set of components, with the intent of this being a draft Performance Improvement Plan (PIP), that you’ll share with your team member. If you struggle with this or any other part of the performance management process, call on your advisors and approvers for feedback and guidance.

This outline is framed as questions that your team member might ask you?

1. Plan Expectations: What is this? Why is it happening?
2. Plan Goals & Outcomes: What’s expected of me? How will I know when this is over?
3. Plan Pathways: How will I get through this? What do I have to do?
4. Plan Support: What’s my role? What role will you play as my manager?

It will be beneficial to formulate this as a word doc and use your own style and tone to pull these components together. Additionally, as you’re writing this, make sure that the plan is crisp: brief enough to be easily understood, but detailed enough to stand alone. Work with your manager, HRBP, and advisor(s) to ensure clarity. The written articulation of the plan will serve multiple purposes; it will guide your kickoff conversation with your team member, serve as written documentation, and be a tool that you and your team member can use to manage throughout the specified performance management period.

Once you’ve completed a concrete, clear, and achievable plan, you’ll be ready to approach your team member.

→ Coming soon: “Performance Management as a New Manager: How to Approach Your Team Member(Part V)”