The FT Word – January 2008

By Technical Support

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.


Happy New Year and welcome to the January 2008 edition of the FT Word. Please forward it to colleagues who would enjoy it.

Both of this month’s topics are appropriate for New Year resolutions (along with hitting the gym everyday at 6 and eating our five daily servings of fruit and vegetables, which we’ve all been doing for the past 3 days…)

  • Post-mortems or M&Ms: why it’s useful to look back after escalations

  • The future of training for support engineers: why heavier demands require a clever approach

Post-Mortems or M&Ms – They are priceless

Customer escalations are stressful, resource-intensive, and often unavoidable in high-complexity support environments. Beyond the usual proactive measures (respond to requests promptly, display good customer handling manners, don’t let issues linger), the most effective method to minimize escalations is to look back after each escalation, analyze why it happened in the first place, and make appropriate changes so the same situation does not happen again. Support organizations are not the only type of organizations faced with this problem – here are two stories, one from healthcare and one from cockpit management, that illustrate the benefits of looking back.

Let’s start with healthcare, which gave us both the “post-mortem” phrase – a bit depressing, perhaps – and my current favorite, M&M – which stands for ”Mortality and Morbidity”, not much more cheerful when spelled out, so let’s stay with M&M.

Imagine you have a choice of two apparently identical wards when entering a hospital. Ward B has 10 times the number of reported medication errors than Ward A. Which ward should you choose?

It turns out that the “right” answer (if you’re interested in the best outcome for the patient) is Ward B. Wards with more reported errors have better patient outcomes. This is because they don’t actually commit more errors than other wards: they just report more. It turns out that the kind of work environment that fosters the reporting of errors also fosters the teamwork that helps reduce errors in the first place. Also, reporting errors leads to improving processes. For instance, if there are lots of dosage errors for a particular medication perhaps labeling the bottles better would help, or getting confirmation from the prescribing physicians, or eschewing hand-written prescriptions. (As reported by Amy Edmondson, Learning from Mistakes is Easier Said Than Done: Group and Organizational Influences on the Detection and Correction of Human Error.  The Journal of Applied Behavioral Science, Vol. 32, No. 1.)

The learning point for support is to create a culture where M&M reviews are conducted with the goal of unearthing and fixing problems, not shaming and exposing individuals.

Onward to the cockpit management example. In August, 2005, an Air France Airbus failed to stop at the end of the runway in Toronto, fortunately causing nothing more than light injuries – although it must have been very scary for all involved and the plane was gutted in the fire. The analysis of the causes of the crash was released last month and reveals interesting interplays between numerous factors:

  • The weather was awful, stormy with lightning strikes and heavy rain that left a couple inches of water on the runway (“act of God”). Clearly the accident would not have happened in good weather. But read on…

  • The pilot probably realized that he was about to land too far into the runway but decided not to abort the landing because he had already been circling for a while in severe weather and it was not clear that he would get another chance at landing safely (personal judgment.)

  • The co-pilot did not question what the pilot was doing, although he, too, probably realized the problem. It turns out that the co-pilot had worked for a company that was acquired by Air France in a merger that was not friendly (corporate conflict). Moreover, he had received a negative review from that same pilot, a review that had prevented him from being promoted (personal conflict.) No love lost in the cockpit, and investigators thought it was likely that the personal conflict prevented effective teamwork during the crisis.

  • Since there was not enough room to stop the plane on the remaining stretch of runway, especially with the amount of water on it, the plane fell into a ravine at the end of the runway and a very chaotic evacuation ensued, with flight attendants reaching the ground before passengers were evacuated, a big no-no in their training (poor training or poor execution?)

We in support rarely crash planes, but some escalations feel like plane crashes, right? Next time you conduct an M&M review, be open to the idea that most big accidents are caused by multiple factors, and that personal issues are often at play in addition to technical problems.

For more tips on managing escalations, see Managing Escalations.


The Future of Training for Support Engineers

Thank you to Mike Jordan for suggesting this topic.

Training is a constant in the life of support engineers, whether they were just hired or years into the job. How will training evolve over the next few years? Here are 5 trends.

1. Training requirements are up together with the complexity of the products being supported.

There’s complete job security for support instructors: more and more training is required as systems become more complex and more layered. In many support organizations I work with, it’s virtually impossible to hire someone who can hit the ground running. Even established support engineers require days or weeks of training each year to keep up with new releases and products.

2. Support Engineers continue to require 3 kinds of training: technical, support skills, and process

Although the quantity of training may be up, it still falls into three categories. Technical training starts with how to use the products being supported as well as other layers involved such as the OS, but it goes beyond that. It’s not just how the product is supposed to work, but about how it actually works. And not just how the product works, but also how it breaks – often ungracefully. And how to untangle the mess when it breaks. And how the product is coerced into non-natural hoops by some customers. Most technical training is deficient or absent the minute it gets out of the safe territory of what can be read in the documentation, or what is taught to customers. Focus your effort there.

Support skills training includes how to work with customers as well as the all-important skill of troubleshooting. This last bit is a little messy since troubleshooting includes both general techniques (e.g. change one variable at a time) as well as specific strategies appropriate for the products you support, which would belong in the technical training category.

Process training is all about how to do the job in the particular support organization you’re in, from using the phone and the tracking tool to escalating properly to the next level. All the new hires need process training regardless of their background and you will have to refresh the training each time you make a change to processes or tools.

3. Buy training off-the-shelf whenever possible

If you’ve ever had the chance to create training you know that (good) training requires hours to craft so avoid course development whenever you can, concentrating on those topics for which off-the-shelf training is not available: training on your own products and training on your processes. Everything else can be purchased and tailored if needed. Technical training for products that are not your own should be purchased, not created in-house. Support skills are another good example of training that should be purchased, not created.

Note that this strategy leaves you with the more complicated bits of training to develop in house. Lucky you! This means that the staff in the training group must either be technically knowledgeable or skilled at working with subject-matter experts (SMEs.)

4. Much (valuable) training happens outside the classroom

Ask yourself about the last time you learned something important: chances are it did not occur in a classroom…  and yet the idea that learning means sitting in a room listening to an instructor is deeply ingrained. Nothing wrong with classroom learning! If you can manage to bring together an engaging instructor, a strong curriculum, and eager learners, I guarantee that useful learning will occur. But do not despair if you cannot afford classroom training, and foster ways of disseminating knowledge without a standard classroom format in any event. For instance:

Create simple self-guided training for new hires and beyond by simply listing some interesting documents, including knowledge base documents, interspersed with practical application tasks. Have the learner check in with a mentor from time to time.

Encourage mentoring. Each new hire should have a mentor for the first weeks or months.

Organize brown bag lunches and other informal sharing sessions, including with Engineering.

Provide informal meeting places with a white board and a few chairs for impromptu discussions.

Make time for short assignments with groups outside support such as the pre-sales technical team, the consulting group, and the customer training group. It’s good for support engineers to widen their horizons, to see what customers are really doing with the product, and also to experience customers when they are not in a crisis.

Schedule semi-formal case review sessions, which are a great way to learn just-in-time. Ask the support engineers to bring their tough cases to scheduled meetings, once or twice daily, led by experienced support engineers. Not only will they get suggestions about what their own cases, they will hear about others, too.

If you have a distributed group, include the remote staff members in the informal network. Online chat sessions or technical conference calls can help.

Emphasize knowledge management. If someone learns something new as a result of a case review session, a brown bag, or a special assignment, that should be captured in the knowledge base for collective use.

5. Measure results rather than satisfaction with the training

Measuring the effects of training is not an easy task, especially if everyone follows the same curriculum (so there is no control group) and especially for soft or complex skills that are not amenable to multiple-choice tests.

Use certification programs where they exist. For instance, if you already offer a certification program for customers or for partners, leverage it for the support staff. It probably won’t cover all they need to know, but it’s a start.

Create your own certification program if you have a larger support team. Crafting a certification program, just like creating curriculum, is expensive so you won’t be able to justify the effort unless you’re training hundreds of staff members. And don’t feel constrained to using multiple-choice questions only: why not give the support engineers a (real) customer problem and evaluate what they do with it. It’s more resource-intensive than feeding a sheet into a Scantron machine but it will be a better predictor of the actual performance on the job.

Rely on standard metrics to measure the success of the training program. Well-trained staff members should be able to attain good productivity levels and achieve high levels of customer satisfaction. Naturally there are many other factors that influence performance such as recruiting and coaching, but achieving performance metrics is more meaningful than any test or certification.

Use data from any naturally-occurring differences. For instance, if a group of support engineers did not get a particular part of the training, are they performing any differently from support engineers who did? If not, perhaps the training is not that important or successful…

Use course surveys but remember that surveys, especially taken right at the end of a class, reflect more the level of enjoyment of the participants rather than anything they learned. Delayed surveys taken a few weeks or months after a class are more helpful in judging how much was learned. And make sure that surveys are truly anonymous: most people find it difficult to state their disappointment with a class when the instructor is a colleague and they believe s/he may find out about their assessment.

FT Works offers a full line of training offerings for support skills as well as custom assistance to create process training. For more information click here.

FT Works in the News

You still have 2 months to sign up for ASP’s Best Support Web Sites of 2008. A great, inexpensive way to get an expert evaluation of your site by several judges (and perhaps I will be assigned to your evaluation.) To learn more, visit

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.

Françoise Tourniaire
FT Works
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

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.

Back to Newsletter Archive

Tagged under: