The FT Word – May 2006
The FT Word
The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.
Welcome
Welcome to the May 2006 issue of the FT Word. Thank you for sharing it with your colleagues to continue to spread best practices in support.
Topics for this month:
- Changing the culture of the support organization: can it be done? what works?
- Fixes in an open source environment
- New overnight shipping option for all FT Works books and booklets
Changing the Culture of the Support Organization – The Practical Side
Changing the culture of the support organization is often on the mind of my clients, whether they’d like to break established (bad) habits or are planning a new initiative that will require a mind change throughout the team. Can culture be changed? What are some effective techniques? Here are seven thoughts about culture change.
1. Culture is a downstream phenomenon
Let’s face it, you can’t just get up one day and change the culture as you would repaint the walls. Culture is a consequence of many factors including the types of people in the organization (hence, recruiting choices made over time), their stated goals and objectives, the formal and informal reward system, etc. There’s no way to control or change the culture itself: you need to change the environment so a new culture can emerge.
2. Recognize the benefits of slow and steady change
Sometimes culture change is urgent. If you inherit a support team with dysfunctional values, you may want to immediately establish that serving customer is the purpose for the support center’s existence. So you call a all-hands meeting and decree that from now on “Customer Satisfaction is Job One”? I would bet that would not work at all. If you’re lucky, the “Big Bang” approach can only get the group started in the right direction, with lots of reinforcing yet to do. In stubborn cases the Big Bang presentation would be carefully and cynically ignored by the team.
If you’re serious about changing the culture, arm yourself with patience. Expect culture change to take 3-6 months for any sizeable initiative – although you should start seeing positive changes from the first few weeks.
3. Change the management team?
While culture cannot be dictated from above, it cannot change or endure without the warm support of the management team. Whether you’re going for a focus on customer satisfaction or embracing a number-driven approach, you’d better have the management team on your side. Give the veteran managers an honest chance to rally to the new regime: it may be difficult for them to abruptly change values they held for a long time and behaviors they have been rewarded for. If you determine that some individuals just won’t go with the program, you may need to make changes. Don’t delay if you must do that.
4. Adjust metrics and objectives to match the desired results
What gets measured gets done. If your central metric is cases per day per rep, don’t hope for a strong focus on customer satisfaction… In virtually all support organizations multiple metrics are required to capture the desired performance. Don’t fixate on any one number.
Make sure that metrics are appropriately applied to individuals vs. groups. If you use group metrics exclusively with the goal of promoting teamwork you are likely to find that some individuals slack off and allow others to carry them, creating resentment and lower performance overall. If you use only individual metrics, on the other hand, you may provoke anti-social behaviors such as cherry-picking cases. Why not use both individual (mostly) and group metrics?
Check that appropriate metrics and reports are available at each level of the organization. It’s hard to manage one’s customer satisfaction ratings if the only number available daily is the overall rating for the support center.
5. Hire, reward, and promote to match the new culture
The most powerful messages in support organizations are people-based. If all your hires are young male new college grads, the culture will be more testosterone-laden than if you hire a diversity of people (and you may have an unpleasant interview with the EEO office). If you promote people exclusively based on their technical skills, you will struggle with customer satisfaction ratings even if your metrics and objectives include customer satisfaction. If the big quarterly award at the all-hands meeting always goes to the mavericks who “saved” customers during difficult escalations, the slow-and-steady staffers who quietly do a good job will go seek their fortunes elsewhere.
You may not be conscious of bias in individual hiring and promotion decisions, or awards, nor may your management team. Take a good look at the strengths and values you project as a team: do they match your cultural goals? If you find a mismatch, correct it. Don’t forget informal elements: who gets the office with a view? who gets assigned to the cool new beta program?
6. Be transparent
Hidden agendas foster suspicion and distrust. If your real goal is to manage the center through pure metrics while doing away with the touchy-feely mentoring program your predecessor had instituted, come out and say it rather than delaying the news in an effort to let the team down gently. I would distrust any manager who starts by saying she won’t change anything, wouldn’t you?
Walk the talk. If the new culture is lean and mean, watch out for perceived extravagance in planning meetings or even the size and furniture of your office. If not, the new culture may be more “Upstairs, downstairs” than lean and mean.
7. Train, communicate, repeat
Training is an essential part of change. In dire cases you may want to train about change itself: I still have fond memories of a workshop I took years ago as part of a large downsizing effort that simply explained the stages of grieving for the past and for old friends. It was comforting to know that my colleagues and I were not crazy: it is difficult and it takes time to adapt to such drastic changes.
More specific training is always welcome. If you’d like the team to get with the new metrics program, the first step is for them to be able to read the metrics reports. If you want to increase participation in knowledge management, start by showing people how to create and update the knowledge base documents.
Training is a process, not just an event. While attending a class on knowledge management is a great start, expect to have to repeat the knowledge management mantra daily. This is why having a committed management team is so important. And watch what you say in unguarded moments. If your usual greeting is, “Are your customers happy today?” you may want to adopt others, including “Did you use the knowledge base today?”
So be patient and persistent with your culture-changing efforts.
Fixes in an Open Source Environment
Thanks to Jennifer Walker for suggesting this topic.
If your company supports open-source products, you are well-familiar with this dilemma: customer wants a fix; a fix is proposed; the community denies the fix; customer is stuck and unhappy (and blames you). If your products are not open-source you may be surprised to find that they include some open source software, which you cannot control.
Did you ever think you would pine for the good old days when you just had to slug it out with the Engineering VP to get a fix? I mean, discuss the issues in a calm and constructive manner, of course… Here are the new rules of engagement for open source code fixes.
1. Check the contract
Any support contract, whether for open source software or not, should not guarantee fixes per se, only “resolution”, which as we cynical support people know can mean just about anything. If you specifically rely on open source software you may want to highlight that in the support Ts & Cs (terms and conditions): no fix can be guaranteed or forced through for open source software; all a vendor can do is propose a fix.
2. Check the support collateral
Many times the person who negotiates and signs the support contract is not the actual support user. Include a nicely-worded description of the open source fix process in the customer guide or other support collateral (including online).
3. Be aware that the customer may modify the software
One of the features of open source software is that it’s easy to change it, and customers do avail themselves of that possibility. Make sure that all support staffers ask a few indiscrete questions about modifications before troubleshooting against a product that’s different from what the customer is using.
4. Set expectations for fixes
If your company creates fixes for open source software, great! You can have that conversation with the Engineering team to get the fix created. Acceptance of the fix is community-based, so set that expectation with the customer (who may or may not be aware of this, despite your contract and collateral.)
If your company does not support the open source software itself, the situation is similar to any other third-party issue you may have, with the important difference that the customer may be able to submit a fix.
5. Expect to create workarounds
Whether your organization can create open source code fixes or not, support’s mission is and always has been to deliver solutions to customers: so get busy creating workarounds to the bugs.
FT Works in the News
ASP announced the winners of the “Ten Best Support Sites” contest. The winners include Reuters, for which I was a judge. You can find the complete list at http://www.asponline.com/awards.html
Many thanks to the 34 brave individuals who spent their Sunday before the SSPA conference with me discussing knowledge management in the support organization. It was great to see so many newsletter readers in that room and during the rest of the conference. If you missed my other presentation, 10 Commandments of Knowledge Management, a summary of it is posted in the April issue of SSPA News at http://www.thesspa.com/sspanews/_06april/article2.asp.
Thanks to a suggestion by a FT Word subscriber, all FT Works books and booklets are now available with an overnight shipping option (thanks, Lynn). You can see a full list here. This applies to the best seller, the knowledge management guide, Collective Wisdom: Transforming Support with Knowledge.
Next month I will unveil a new booklet, which discusses managing global operations. Let me know if you can’t wait and would like an early notification of availability.
Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.
Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826
About FT Works
FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com.
Subscription Information
To request a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.
