The FT Word – January 2009
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
Happy New Year and welcome to the January 2009 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription by clicking here.)
This month’s topics:
- Managing the Unknown: techniques for managing staff that supports a product you are not familiar with
- Sustaining Engineering: should it report to Support or to Engineering? The pros and cons may surprise you.
- Start a well-informed year with the Smarter Support LibrarySM
Managing the Unknown
Many thanks to Stephen Laroche for suggesting this topic.
Many support managers are promoted from within and enjoy the comfort of managing people who do a job they know well (actually the job may have changed since they did it – and if so some of the suggestions below will help, but I digress.) For the rest of us, who are managing support engineers or reps that support a product we don’t know about, here are 10 strategies to manage successfully.
1. Forget about being a technical expert. Being a manager and a technical expert may feel good, but you simply don’t have the time to become an expert – and if you make time you will cheat your other responsibilities. Give up the idea of being a technical expert and you and your team will be better off. This may be a difficult transition for you, especially if you loved being a techie. And it also happens to be a key criteria for whether you would be a good support executive one day.
2. Get some basic technical knowledge. Your goal should be to be able to do two things: (1) hold your own in a conversation with a customer’s executive (not the customer’s technical contact, that would be too much to ask) and (2) not get bamboozled by your staff on technical issues. Neither activity, and especially the first one, requires detailed technical knowledge but you can’t just walk around proclaiming total ignorance and still be effective. Basic knowledge can be gained by browsing through customer-training materials or even documentation. Or bite the bullet and attend a customer-targeted class. It should not take more than a few days.
3. Listen in on calls. Listening in is a great way to get a feel for how the support staffers are working with customers so you should be doing it anyway, but when you’re getting familiar with the product it’s also very helpful to gain an understanding of the types of problems customers have and how they can be handled. Listen to several support staffers to get a better feel for the variety of approaches they use. If your team uses technical case reviews drop in occasionally. Don’t say a word, just listen.
4. Use metrics to your advantage. If you don’t know much about the product it can be hard to distinguish between a well-handled case and a wild goose chase, especially if the wild goose chaser was polite and professional. So you will want to scrutinize the various metrics you have for differences in achievement levels. Who gets the kudos? Who plows through cases? Who contributes the most useful knowledge base documents?
5. Figure out who is the recognized expert on your team. People vote with their (virtual) feet. If there is a perpetual line outside Kathy’s cube (or a long line of IMs for her) chances are that she is the recognized expert of the team even though she may appear shy or tentative to you. You can safely ask her to evaluate a technical solution or help out with an escalation.
6. Seek out outside stakeholders. It’s always helpful to create a network outside your team who can advise you on technical issues if needed. Specifically seek out allies in the Engineering, Product Marketing, and Consulting teams. You may well have to team up with them on customer escalations and you can occasionally use them as your personal sounding board on a technical issue when you feel you cannot simply go with what your staff says.
7. Remember that you are an expert – at managing. Your team members may and should know more than you about resolving technical issues but you have plenty of knowledge and savvy about how to manage a support team or how to work with customers. Don’t get cowed into deferring to your team on non-technical decisions just because you don’t know the product as well as they do.
8. Consult and make decisions. Your job as a manager is to make good decisions. When you don’t have enough data to make one, gather input. So for instance if you need to decide what the team needs to get ready for a big product release, ask the team members. Some will have outlandish lists, some will just mumble something about getting the documentation. The right answer is probably in the middle (and if you’ve done your homework on #5 you should be able to get the answer even faster.)
9. Practice just-in-time learning. Let’s say you have a big customer escalation call in an hour and the team has come in to brief you. If everything hinges on being able to reproduce the problem on the customer’s specific environment now would be the time to ask about why the environment is different and why it matters (at a high level, remember your goal is to be able to converse with the customer’s management about it. Don’t waste your staff’s time explaining each and every little detail on each case. You don’t need it.)
10. Be humble. Don’t hesitate to admit that you are no technical expert to your staff. Don’t be apologetic and don’t be a doormat; simply defer to their superior technical knowledge. You will find that most people will be happy to help you overcome technical obstacles and won’t take advantage of the situation to pull the wool over your eyes.
Sustaining Engineering: in Support or Outside?
Many thanks to Abdo Albeshelani for suggesting this topic.
I think all of us have been tempted at one point or another to adopt the Sustaining Engineering team so we can finally get that engineering backlog down. But is it a good idea? Does placing Sustaining under the control of Support really helps?
I should start by mentioning that plenty of vendors function quite well without a separate Sustaining Engineering team. Instead they ask each development engineers to fix bugs in their expertise area as they are reported. Having a separate Sustaining Engineering team is just one possible strategy to expedite bug fixing. If you’d like to read more about the pros and cons of Sustaining Engineering per se, try here.
Here are arguments in favor of having Sustaining report into Support
1. Greater control of Sustaining priorities. This is the big emotional draw towards this strategy: no more fighting, um, negotiating with Engineering; no more having to justify why yesterday’s priorities need reshuffling; no more begging to backport a fix; no more groveling for someone to get onto a customer conference call. Certainly putting Sustaining within Support will deliver greater control.
2. Better synergy between Sustaining and Support. The Sustaining team often has superior technical knowledge of the product and is a great asset to lead case review sessions, provide advice on difficult cases, and participate in building the support knowledge base and training. Having the team with Support naturally fosters tighter collaboration.
3. A career path for support engineers. Wouldn’t it be nice if the more technical support engineers who have an affinity for coding could transition seamlessly into a Sustaining role? As a bonus, since they understand customers’ needs they would naturally be more responsive to your needs (see point #1.)
4. A better understanding of customer issues by Engineering. Often the Engineering team has a strict interpretation of rules and guidelines, a la “if your production system is not completely down please don’t bother us”, while we in Support know that each rule has valid exceptions. Having Sustaining report into Support, especially if it’s staffed with ex-support engineers, allows for more flexibility to adhere to the spirit of the rules and not necessarily the letter of them.
But there are also many arguments against having Sustaining report into Support…
1. Disconnect between Sustaining and the rest of the Development team. Even when Sustaining is part of Engineering it cannot handle all issues and needs access to development engineers to resolve the more difficult or obscure issues. That is often painful (although hidden from us in Support.) Now imagine trying to do the same thing but across departments. Painful. So when you need help the most, because difficult and obscure issues always occur with difficult customers, you will have to grovel and beg like never before.
2. Resistance from the existing Sustaining team. If you already have a Sustaining team in place you will likely find that its members are not completely thrilled to move into Support, in part because they understand the disconnect described above. So you get your own team of grumpy engineers. Not so good.
3. Incompatible skills sets. On the other hand, if you’re thinking of building the team by transitioning support engineers into it you may find that the very skills that make for a great support engineer don’t apply so well to Engineering. As in good support engineers really don’t like to stare at their screen all day long and be quiet while they code.
4. No Sustaining voice in Engineering. Going beyond the disconnect described under #1, having Sustaining report into Support can create issues when selecting Engineering tools, making decisions on packaging updates and new releases, being included in training sessions, and even providing feedback on systemic product quality issues. So Sustaining may be stuck with using inappropriate processes and tools and trying to deliver against unrealistic goals.
5. More conflicts with Sales. How could this be? Sales often drives customer issues directly into Engineering so those issues will be deposited at your door if Sustaining reports into Support, putting you in the position of having to referee not only existing customers’ issues but also prospects’ problems. And you thought your job was hard.
So what to do? As much as getting control of Sustaining Engineering’s priorities is tempting, I would leave it within the Engineering team where it can have ready access to the tools and resources it may need to be successful. This does not mean you have to give up on the advantages of having Sustaining work more closely with Support. Start with a frank discussion of needs and issues with your Engineering counterpart. Many times Engineering managers simply don’t understand customers’ pressures and don’t see how an inflexible approach to responding to customer issues creates very difficult management dilemmas. Invite them to listen in to customer calls, to participate in case reviews, and to review support metrics.
Meet them halfway: expecting Engineering to drop everything (and the next release) to attend to a relatively minor customer issue is simply not realistic. Having to prioritize (and re-prioritize is not unacceptable.) And yanking engineers from one priority to another makes them crazy and unproductive. On the other hand, you can and should expect a clear SLA from Engineering for response time; productivity metrics for fixing bugs; a mechanism to answer “quick questions” without having to go through a lot of bureaucracy.
FT Works in the News
Having to do more with less this year? Get the entire Smarter Support Library for your team and educate everyone about best practices for support offerings, support processes, hiring and training. Go here for more information.
Check out the new posts at Marketing Wise, the FT Works support marketing blog (or subscribe to the blog.) In particular read about Providing Engineering support for older releases (what’s “current release and one back” anyway?)
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.
You may reproduce items in this newsletter as long as you clearly display this entire copyright notice. Contact us if you have questions about republications.
