Striking a Balance between Individual and Team Metrics

Many thanks to Angus Klein for suggesting this topic.

Support is a team sport, right? So why do most support teams rely exclusively on individual achievements to measure performance?

A typical set of objectives/QBRs for a complex-support organization reads something like this:

  • 50% rating from CSAT and the internal quality audit, which includes contributions to knowledge management (target: 8/10)
  • 30% case productivity (target: close X cases per quarter)
  • 5% achievement of resolution time goal (target: 80% of cases closed in less than a week)
  • 5% achievement of response time goal (target: 90% of cases responded to within SLA; team goal)
  • 10% achievement of training or other personal goals

This means that a whopping 5% of the goals is a team goal — and that’s for the least important aspect of support work, response time. How can we do better? It all depends on how the work is organized, but here are some ideas:

  • Capture assists in the case-tracking tool and have them “count” alongside case productivity. (A side benefit of this approach is that you will be able to spot the support engineers who need frequent assists.)
  • If you organize teams around experts, measure the experts by the team output. So instead of an individual rating, the expert carries the customer satisfaction rating and productivity for all the cases in the team.
  • Make a portion of the goals based on team performance. So an individual support engineer would carry both her individual ratings (for a large percentage of the total) and team ratings. This is a good incentive to work cooperatively.
  • If you are using swarming, use team performance as the main metric, with individual performance as a minor factor.

How do you balance individual and team goals in your organization?

Support Star Interview: Dana Polyak

Thank you all for your kind comments about the first Support Star interview with Deepak Chawla last month. This time around, I am speaking with Dana Polyak of Addepar, a B2B software company serving a specialized market in the finance field, wealth advisors. Having started her career as a software engineer, Dana pivoted into support a few years later, looking for a tighter connection with customers (to the puzzlement of her friends at the time, she says).

Dana also spent a year at the Stanford Graduate School of Business to pursue her goal of building customer-facing services organizations, and she now heads the Client Success organization at Addepar, which consists of four teams – Support, Client Advocacy (relationship management), Training, and Practice Management.

FT: One thing that’s interesting about your organization is that you are recruiting support engineers with a background in finance. How did you make this decision and how do you make sure that they will be good at software support?

DP: As you know, Addepar’s clients are financial services professionals in a very specialized area of finance, wealth management.  To build rapport with the clients, we need to understand what they do and the language they use to describe their jobs.

That said, some members of my team come from Finance, but others have technical backgrounds.  In addition, we look for people with deep data expertise, as data is a big part of Addepar and understanding how to work with large data sets helps expedite resolutions of some of our most common issues.

Before I started extensive hiring efforts, I outlined the skills needed to support our clients and mapped out the current team against the skills.  That quickly informed me what I needed to develop (where scores were low, but with small gaps from the ideal state) and where I needed to hire externally.  This method also helped to inform me when to bring in an external consultant (FT Works) for training on support skills.

FT: How do you measure success for support organizations?

DP: Support for me is the ER of the company.  So we need to resolve the issues, but also offer a superb bedside manner.  What it translates into for us is that success of the Support organization is CSAT and the response rate on CSAT. The more responses we receive from the clients, the stronger the emotional connection between the clients and us.  That’s key to strong relationships.

While client experience is of utmost importance to me, I also work towards improving our product, because the support organization is the one that sees most of the issues and, can therefore influence product improvements. What I am working on rolling out is a metric that will enable us to track how Support is influencing product improvements: the number of high-impacting bugs resolved and features implemented.

In addition, we are looking into increasing our client-facing content in order to empower clients to resolve their own issues faster. Having a tight loop with the content writing and training teams, and then measuring the impact of the content and training, is something I am extremely interested in.

FT: Without stressing you out, what keeps you up at night? What do you worry about?

DP: Addepar continues to grow and that creates a lot of opportunities for a lot of us.  Support has excellent reputation at the company and we regularly see members of our team moving on to other opportunities at Addepar, which means we are constantly hiring and rebuilding our skills.  I am thinking of how to improve this and create a more predictable model.

As we grow, we also get more Enterprise level clients and I am thinking of our Support model and organizational structure – what will we look like in 2018, 2019, and beyond.

FT: Is there something you learned or saw done earlier in your career that you now completely reject? What was it and what made you change your mind?

DP: I have seen separation of the support organization into two teams, premium support and regular support.  What I observed is that the regular team ended up with better product expertise because of the number of issues they work on compared to the premium team.  I therefore, am not the biggest fan of such separation of teams.  Plus, it creates an elitist culture, which I don’t want to foster in my organization.

FT: When you look at the support field today, what do you wish more organizations would do or try?

DP: Trust the people to do the right things, invest in their education, empower them to create the processes they’ll follow, rather than dictate the processes.  I have a lot of respect and appreciation for the people who get up in the morning and dedicate themselves to solving hard problems every day.  The stress levels in support are constant and the work never ends.  It takes a special character to thrive in this amazing, stressful, yet rewarding environment.

FT: Thank you very much, Dana!

 

Culture and Leadership Style – A Primer

The July-August issue of the Harvard Business Review contains an article written by the author of The Culture Map: Breaking Through the Invisible Boundaries of Global Business, Erin Meyer, about differences in leadership styles around the world. Since support team are typically global, the outcome of her research is very helpful to us practitioners.

Here’s a quick summary:

  • There are two dimensions of leadership: attitude towards authority and attitude towards decision making.
  • Authority can range from egalitarian (we freely discuss ideas without regard to rank or role) to hierarchical (where the boss is deferred to).
  • Decision making ranges from consensual (we expect everyone to discuss and agree to decisions before they are made final) to top-down (decisions are made at the top, without waiting for consensus).
  • We implicitly accept the way things work in our culture and, if faced with a different culture, get confused (or angry!) that things are not proceeding “as they should”.

The author’s perspective is that leaders should expect these differences and adapt to them. I don’t quite agree: I think everyone in a global team would benefit from understanding the leadership dimensions and openly discuss both the overall decision-making process and individual decisions (I guess that makes me a consensual/egalitarian!) In any case, here are some suggestions on how to function in each of the 4 types of leadership cultures:

  • consensual/egalitarian (e.g. the Netherlands): expect a long discussion before decisions are made, and resist the temptation to have the boss just jump in an make a decision.
  • consensual/hierarchical (e.g. Japan): while the team will accept decisions pushed from above, it’s very important to seek input from everyone, and especially from those that dissent.
  • top-down/hierarchical (e.g. India): if you want the team to give input, specifically ask for it — and beware of making an off-hand comment if you are the boss, as it may be interpreted as a command.
  • top-down/egalitarian (e.g. US): politely speak up regardless of your rank before decisions are made, but be prepared to “disagree and commit” afterwards.

What are your experiences with your remote teams?

4 Tips for Meaningful Customer Health Scores

We are supposed to track customer health scores, but we tend to throw together a few numbers and just carry on with them for months. Here are four quick ideas to refresh our thinking.

Tip #1: Use different formulas for different customer segments 

Such a simple, but powerful idea (shared by Abby Hammer from ChurnZero). If you segment customers, and most vendors should, health scores should also use segmented definitions. For instance, the health score of enterprise customers may rely more on the judgment of the customer success manager (see tip #3) than on mechanistic factors such as product usage.

One prime idea for segmenting is treating new customers differently from established customers. Health score formulas should reflect that.

Tip #2: Automate whenever possible

Carefully pondered and harvested qualitative factors are wonderful — and also expensive, and quickly dated. Instead, look for meaningful, relevant, automated factors such as the number of users, usage of specific features, and of course support history, including bugs and feature requests.

Tip #3: Carefully define subjective factors

I’m a great fan of qualitative factors, since it’s awfully hard to automate the measurement of whether your solution brings real value to customers. But don’t just give up and rely on individual CSMs’ assessments of qualitative items. Some will be overly optimistic, other pessimistic, and perhaps predictably so if they are responding to badly-chosen objectives.

Create realistic descriptions: what does it mean to have a rating of 5 on relationship quality? How it is different from 4?

Tip #4: Use actual referrals instead of NPS

I know everyone just loves NPS — but likelihood to recommend is no match for actual referrals. Sure, referrals are hard to track, but they are not impossible to track. Give it a try!

 

What techniques are you using for health scores? Please share in the comments.