High Performance Standards
Fight the drift to low performance by setting high performance standards. Here are tactics to do just that.
This is the 6th post in a series on support systems (though it’s evolved to be more about business systems), which began with Your First Support Model. The most recent post in this series was about Drift to Low Performance.
Let me ask you a question: If you were hiring the first person for a new role at your company, how would you go about it?
For example, if you’re hiring for customer support, would you write down the number of tickets per day that you expect that person to solve? Would you outline a list of projects you expected the person to complete? Would you describe the qualities of the person you’re hoping to hire and the experiences they likely have?
Whatever you write down, you’re attempting to define a minimum performance standard for the new role. You implicitly understand that in order for the role to fulfill its function and purpose for the business, you have to have someone who can meet the minimum requirements expected of that role. How you choose to set performance standards matters and ultimately has an effect on whether the performance bar you set stays high or drifts to low performance over time.
Set High Performance Standards
In Thinking in Systems1, the way out of the drift-to-low-performance trap is to set high performance standards. We looked at one method last week, namely, using a leaderboard to shine a bright light on what high performance looks like. Sales teams use this method all the time to motivate and reward performance, putting the names, total number of deals won, and total dollar amount on a leaderboard for all to see. It works!
Leaderboards do work, sort of, on support teams, but if you’re not careful they can come at the risk of burning out your team. In contrast to sales professionals, who will gladly draw down their personal supply of energy for a greater commission, the same expenditure/reward system doesn’t work the same way in customer support. We looked at this in detail last week, so take a look at that post if you’d like a refresher.
If leaderboards aren’t always the answer, what options do you have?
Levels and Growth
Setting a minimum bar for performance standards is necessary, but may not be sufficient, especially for larger organizations2. The minimum bar helps keep out the lowest performers, but even with a minimum bar, you can still have an implicit drift to the bare minimum performance standard over time.
If you’ve set performance standards, one pattern that may emerge is some people hit the bar and seem like they could go a lot farther. If you raise the bar for everyone, though, others may fall short. On the flip side, if you don’t raise the bar or reward higher performance, you may lose the high performer to another opportunity, either at another company or an internal transfer3.
One way to avoid the drift to low performance while maintaining a minimum performance standard is to offer distinct levels within the same practice. Levels provide a way to establish different sets of performance standards. While there may naturally be a drift to minimum performance standards within a level, having line of sight to the performance standards at the next level up can shine a light on the path forward.
Traps with Levels
Defining levels are a great start, but they doesn’t solve all of your problems with drift to low performance. Here are a few common traps associated with levels.
Levels don’t maintain themselves
One thing to keep in mind is that if you set a bar for performance standards, you need to be prepared to maintain them. That means letting low performers go4. If you set the bar at a particular performance level and fail to remove the individuals who aren’t meeting the minimum bar, you’re implicitly communicating to the rest of the team that the bar has been lowered, causing a drift to low performance.
Levels aren’t based on tenure
Another trap to avoid is to ensure that levels aren’t based (purely) on tenure. Yes, it may be true that at roughly the 12 month mark, a Junior Support Specialist will typically level up to become a Support Specialist, but it shouldn’t happen automatically just because the calendar rolled over. If promotion becomes expected purely based on tenure and not on performance, there’s a real risk of promoting someone before they’ve met the required performance bar, which will mean the performance bar for the entire practice will effectively be lowered.
Levels aren’t based on a single metric
In the case of customer support, this means that going up in level isn’t just about cranking out more tickets. If that were true, you’re essentially just endorsing a leaderboard model where the reward for going up in level just means more occasions to flirt with burnout. Not good.
At FullStory, we implemented a concept called “Extra-queue-rricular Work” to account for time outside of the queue. We incorporated extra-queue-rricular work into levels in two ways. First, in addition to performance standards for queue-based throughput, we defined standards based on the type of work output we would expect from someone outside of the queue, e.g. the level of impact and scope of the projects someone might work on. People at higher levels would work on projects with greater impact across a larger area of the business.
Second, we intentionally gave more senior members of the team a greater percentage of time out of the queue. In this way, high performers are rewarded for staying on the team, not just with higher compensation and a new title, but with the opportunity to make a larger impact within the organization because they have more time outside of the queue.
Levels aren’t a checklist of tasks to complete
Levels shouldn’t be defined as if they were items on a checklist5. “Okay, once I hit 60 tickets per day, then I’ll be a Senior Support Specialist.” Rather, they should be viewed as what high performance looks like when someone is consistently hitting the bar. Or put another way, they should be a reflection of what a seasoned professional looks like when they’re operating at that level on a consistent basis. This helps to ensure that everyone is truly operating at their level—and therefore maintaining a high performance bar—across all levels within the practice.
Hire the people that model your levels
This brings us to my last point about levels: hire the people that model your levels. Each person you hire is an implicit test of the performance standards that you’ve written down and defined. If you hire a “senior” team member and they perform at a lower level than the more junior members of the team, you’ve just lowered the bar for the senior level. On the other hand, if you hire a senior team member and they’re a total boss and earn the respect of everyone on the team, you’ve just raised the performance bar across the board.
Observation of one’s peers is a much more powerful reinforcing feedback loop than a bunch of numbers and words on a levels spreadsheet. Yes, you should have the levels spreadsheet, but it’s how people actually work that matters. Hire the people that model the performance you want to see.
Where to start?
We’ve talked about three topics this week: setting a high performance bar, levels, and hiring. Where should you start? For most teams, I’d start with hiring the people that will model the levels you want to see, perhaps even before you’ve tried to define them. Especially at early start-ups, where it may not make sense to have clearly-defined levels on day one, the people you hire will implicitly set the performance bar for all future hires. If you hire the right people, you can observe what they do and describe their behavior when the time is right to start defining levels. Then, having defined them, you can hold people to the clearly defined performance standard outlined in the levels.6
How do you maintain high performance standards at your organization?
As mentioned previously in this series, I’m borrowing terminology and concepts from Thinking in Systems. Add it to the top of your reading list.
You don’t have to be all that large of a company to start defining levels. I want to say FullStory was maybe ~75 people or so when we started doing the hard work of defining levels. I believe I had only myself and two individual contributors on the support team when I made the first draft of levels. They’re incredibly clarifying.
These dynamics—having people leave the company or transferring internally—aren’t always bad, but I’d argue that if they’re an effect of the system, they should at least be clear and intentional.
It’s beyond the scope of this post to go into the specifics of how to fire someone. It sucks, I’m sorry.
This doesn’t mean your levels shouldn’t be clear! Wishy-washy levels are another anti-pattern. The hard work for the manager is to define clear, unambiguous levels that aren’t mere checklists. It can be a tough balancing act, but it can provide a ton of direction for team members when done well.
This was essentially my approach to building out the support team at FullStory, which I described in the post, Why you should optimize for queue-based performance.