Jasmine Christensen

When you become a new manager, you’re unfortunately not handed a magical guide that walks you through all the tough managerial stuff like performance management.

Often, you’ve become a manager because you’re someone who loved mentoring and developing junior folks, and you’ve been tapped for management because people thrived with your support. You’re also usually someone who’s demonstrated their own success as an individual contributor, and flourished when you’ve been given guidance and feedback. You’ve taken ownership of your own development — internalized expectations, set goals, responded to feedback, and created avenues to achieve your goals time and time again.

Great performance comes from this: understanding and alignment of performance expectations, clear and achievable goals and outcomes, flexible pathways to reach goals, and regular feedback and support.

As a manager, your job is to make sure that the people who report to you — your team members — have the abilities to develop domains of skills at their level by means of skill expectations, goals & outcomes, pathways, and support. As people move across levels from junior to senior and beyond, those abilities in themselves will develop from being a recipient of these four things to being an owner and driver of them.

Not coincidentally, this is a mirror image to the parts of a solid project approach: project objectives, success criteria, process, and feedback.

Looking at two designer examples, one junior and one senior, we can see that the same pieces of a project approach can be applied to development of domains of skills. The practice of designing products is much like the practice of developing skills:

1. We must have expectations or objectives to know what we’re going after.
2. We need goals & outcomes or success criteria to know when we’ve achieved the expectation or outcome.
3. We use pathways or process to reach the goals and outcomes or success criteria.
4. We benefit from support or feedback to shape our pathways.

‍

While the outline is the same, what’s important to differentiate here is that skills are developed to apply to project approach, and performance — while managed through developing domains of skills — is measured by skills being demonstrated through projects.

It’s okay if this isn’t super clear yet. Performance management is a new skill domain that you develop as a manager, and you develop that skill domain by applying the skill as a practice. Meta, right?!

Now, what happens when one of your team members isn’t hitting the bar? What do you do when someone isn’t thriving under your leadership?

This guide will go over five areas that will help you navigate the critical and delicate process of performance management, and will go in depth on the following topics:

1. Who should I involve to make sure both me and my team member have the right support?
2. How do I assess the situation in order to understand the severity and urgency?
3. How do I create a plan that the team member can use to be successful?
4. How should I approach the situation with my team member to get the best outcomes possible?
5. How do I hold the team member accountable so that results are fair and expected?

As you go through this guide, remember that you are developing a practice, and that you’ll get better at this over time!

1. Who to involve

When you’re managing a team member’s performance, who should you involve to make sure both you and your team member have the right support? Here’s what you should and shouldn’t do.

Don’t: Talk to anyone and everyone

It’s really easy to want to talk to people about your under-performing team member. It may even be under the guise of getting support or learning more. But socializing someone’s personal performance details can be detrimental to the team member getting back on track; performance management not kept under wraps is fodder for gossip. It deserves confidentiality and respect.

Do: Keep it to people who play a role

Determine who your key players are. Try using a DACI framework, which might look like the following:

• Driver: You
• Approver: Your manager and/or your Human Resources Business Partner (HRBP)
• Contributors: The team member not meeting expectations, feedback givers, advisors
• Informed: Managers of team member’s peers

You’ll also want to determine how and what you’ll communicate with these people. You can use the DACI framework to shape this as well.

Driver

As the driver, you’ll be responsible for running the process, communicating with all other parties, and ensuring action is completed. In a performance management process, you’ll be responsible for intaking and soliciting information from your team member and the people they work with, shaping a Performance Improvement Plan (PIP), delivering the plan and corresponding feedback, working directly with the team member on the plan, determining results, and recommending final actions.

Approver

The approver(s) will be responsible for making big decisions. In a performance management scenario, this may be specifically putting your team member on a PIP, giving a formal performance rating below expectations, or determining if termination is the final action. Because performance implications can be serious — and often involve legalities — it’s critical to bring in your manager and an HRBP early so they can approve and sponsor key steps and decisions.

You’ll want to schedule regular check ins with your approver(s) to monitor the situation.

Contributor

The contributors will bring knowledge and context to the process. What’s important here is that you bring people in contextually and with appropriate confidentiality.

For example, if a team member is chronically failing to get feedback, you may need to learn more from a peer of your team member. You’ll also need to approach them with confidentiality in mind, meaning you won’t alert them of the context — that your team member has performance flags — instead, you’ll just be collecting feedback and information.

Within contributors, you should also consider people who will help you get the support you need. Be specific here, and decide up front who you will go to for advice: your HRBP, manager, coach, or trusted peer or mentor. This will not only make sure you have proper guidance and support, but it will also save you time from needing to bring your advisors up to speed as the situation progresses. While confidentiality is also required here, the context will be more open; you will likely share in depth.

You’ll work with contributors on an as-needed basis.

Informed

The informed are non-contributors who need to be kept in-the-know. The key word is need; think about those who have a role to play. Here, this may simply be the managers of your team member’s peers who might be receiving feedback about your team member.

You’ll share updates with the informed as you progress throughout the situation. In some cases, there may not need to be informed parties.

By outlining who’s involved, you’ll set yourself up to properly and safely assess the performance situation.

2. How to assess

When you’re managing a team member’s performance, how do you assess the situation in order to understand the severity and urgency? Here’s what you should and shouldn’t do.

Don’t: Make assumptions or jump to conclusions

When you first encounter a situation that looks like it requires performance management, it’s easy to take first impressions as definitive. You may feel obliged to jump into action mode. However, your job is to make sure that what’s being surfaced is both real and relevant, and you’ll eventually need this assessment to create a plan.

Do: Take the time to thoroughly evaluate the situation‍

Start by asking a few key questions to determine the relevance and severity of the situation. The following prompts will help you gain enough context to decide the importance and urgency, as well as inform the plan.

Is this the first time the behavior or scenario has happened?

If so, this may not be a performance management case, but might simply need feedback. Feedback is an element of performance management, but is also an element of all performance, whether positive or questionable. When it’s the first-time the behavior has occurred, you’ll want to encourage the people involved to give feedback directly, or in some cases, you’ll need to deliver it yourself.

The SBI model by the Center for Creative Leadership is an exceptional feedback model, by very simply articulating the following:

• Situation: describing the specific situation in which the behavior occurred.
• Behavior: describing the actual observable behavior.
• Impact: describing the results of the behavior.

For example, if your team member fails to get feedback on a design decision and another teammate has to step in to revise, the feedback should be something like: “When you chose not to present in the last two critiques and moved forward without getting feedback, your teammate had to step in for you, causing them to lose momentum on their project, and it was also really frustrating for them.”

This will also give you a chance to learn about the team member’s intent — what they had hoped to accomplish — and what the context was. To learn about this, when you give or follow up on feedback, ask your team member open-ended questions like the following:

• “What was behind that?”
• “What was going on there?”
• “What do you think the cause was?”

Is the situation demonstrating repeated scenarios or patterns of behavior?

Essentially, you’re looking to determine if this is a one-off or if it’s something that’s become or is becoming problematic.

Keep in mind that someone who receives a lot of constructive feedback isn’t necessarily an under-performer. Feedback is vital to anyone’s career development, and all of us have areas to grow in. In order to to qualify as a performance problem, a team member will be receiving feedback on the same area, and it will coalesce into a theme. If the SBI model has been used consistently, you’ll find it relatively simple to collect and document feedback instances in the past and any actions that have been taken to determine deeper or broader themes.

In performance management — where a scenario or pattern of behavior is recurring — intent and context are also critical to understanding the whole picture and setting up your team member in a way that makes it possible and motivational for them to succeed. Look for repetition and patterns here as well.

Are there consequences to this situation?

Here, we’re trying to determine how grim the situation is. Consequences could be a wide range of things from social and emotional costs like other people’s reactions, feelings and perceptions to business costs like losing time or revenue.

Using our previous example, a team member who works overly independently and fails to get feedback on progress may cause another teammate to have to step in and revise the solution at hand. This is of consequence because it’s costing not only the time it takes to revise the work, but also the time it takes for the other teammate to ramp up on the problem and solution space, not to mention the cost on team dynamics.

Defining the costs will help you approach your team member and help them understand the implications of the situation, particularly if it continues on. If there are no clear consequences, you may need to explore why the situation has been either brought to your attention or why you feel it is consequential, and you can do so by consulting your advisors or your approvers.

Is it a requirement?

This question is ultimately asking “does this matter?” If you’re fortunate enough to have documented expectations for roles and levels, this may be a simple act of placing the situation in its relevant bucket — what I’ll call “domains”. If you don’t have these articulated, it will be helpful to get something in place. Product designers are generally held accountable for design strategy that leads to business and customer impact, collaboration, communication and other facets of culture, and the craft and process of design.

Be sure to look at the domain for both the situation and the cost in order to get a full picture of both the direct and indirect domains affected. Extending the example from above, if your team member has failed to get feedback, you may be looking at a collaboration or design process domain. This might be easy to place, because we know that collaboration and feedback are part of a product designer’s role. Looking at the costs — for example, if another teammate has to step in — the domains are compounded. Now the other teammate has to step away from their project and its associated impact. That teammate might also become frustrated because they’re asked to pick up the slack, which could affect team culture.

On the flip side, beware of situations that don’t have costs or domains. As examples, if one of your team members repeatedly isn’t available in the evenings, uses a colloquial phrase that may seem annoying, or asks a lot of questions; be sure to determine whether there’s cost and if it’s a requirement you can place in a domain. Some things are simply not of consequence or are not required, either in a role or in a level.

Have you checked for bias?

Unfortunately, all of us as humans carry biases, whether they’re conscious or unconscious. As a leader, you need to hold yourself and others around you accountable for bias, prejudice, and extreme-yet-often-subtle acts like bullying. I’d highly recommend reading or listening to Kim Scott’s book Just Work: How to Confront Bias, Prejudice, and Bullying to Build a Culture of Inclusivity to develop expertise. Ultimately, you need to leave space open for what you’re observing or hearing to be only part of the story, and that it may be colored with negative perspective or experience.

Do you have thorough details and context on the scenario?

Whether you’re observing a situation or someone else is bringing it to your attention, you need to make sure you have enough data to synthesize into a plan. One of the easiest mistakes to make is to fail to talk to your team member directly, be sure to do so if you haven’t already!

By completing a thorough assessment of the situation, you’ll be ready to create an effective plan.

3. How to create a plan

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.

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?

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.

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?

Using the skill domain develop and project approach comparison from the overview 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.

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.

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.

To be continued!

If you've found this guide in any way helpful, let me know on LinkedIn.