To Train Up a TSM …

I’ll not name names here. But Notre Dame, in the course of our relationship with Blackboard, has had a number of Technical Support Managers. Most institutions I’ve talked to have had similar experiences. And they’re tired of it.

So… as the primary contact for Notre Dame to Blackboard (Read: writes the most support tickets), I’m offering you my strategy here. For free.

You see, I’m a former Technology Trainer. I think everything is training. Sometimes I overdo it. My husband says so. Not every moment is a teachable moment, he reminds me.

I’ve got our current TSM trained. Or is it the other way around? Either way, we ‘get’ each other. So, here are my secrets:

1. Say what you think. Even say what you speculate.(Who knows? It might strike a chord, “Aha, I’ve seen this same thing somewhere before…”). You may look stupid. Go with it. Why not?

2. If your TSM does something stupid, like asks for the webct.log you’ve already uploaded in your initial ticket, be direct: “I gave you that information in the note dated yesterday.”

3. Our current TSM doesn’t read. I don’t either. (Except for the RTFM thing. But Blackboard Manuals are painful. Really painful. I create documentation error support cases when I read them. Really. Am I the only one who does this?) Anyway, the not reading thing makes our support ticket updating complicated. Here are those rules:

a. Subject line: Explicit.Unique. NewsPaper Headline.

Example: PROD JMS Server Down. Need Immediate Assistance. (Don’t use that last part too often…)

b. One piece of data per Support Ticket Note. Use numbers and bullets. The facts only.

c. Name your uploaded files with your institution, node and, if you have multiple environments, which one. When I remember, I do something like webctlogNodeA_prod_NotreDame_469033.log  (This means you’re not assuming your TSM, with 37 other clients, is going to remember which institution and which problem and which file necessarily go together. Including the ticket number in the file name is a good idea too…).

[I once wrote a horrible scathing novel as a Support Ticket. It went on for screens. -I was certain I would encounter an input limit so I composed the whole thing in Word and pasted it into the web form-. Our TSM sent me a personal email that said something pithy like, “I can’t read that. Summarize please.”   I couldn’t believe he said that. How rude. How unprofessional. How … Then I broke down the two sentences into their constituent parts. I removed any emotion I may have attributed to it (smugness. condescension. annoyance.), and I smiled. Those emotions may have, any or all of them, been there, but what he said was true. It was truthful. It was direct. We were trying to work together, weren’t we?]

4. Do not be offended if your TSM initially thinks you’re an idiot. Face it, you think he’s an idiot too. The only difference is he’s trying to hide his feelings and you’re not. This is what you really have to get over. You have to figure out how to accurately assess each other’s knowledge and to use each other’s strengths. Over time, I’ve realized even though he/she may not have the experience with the product I have, he’s an excellent researcher. He knows how to work his system and he trusts me when I give him leads on areas I think are worth researching  (ie,my hunches). I need to trust him too.

5. Finally, if you do your job right, your TSM will get promoted and you’ll have to start all over again. Or, if you have one of those nice people-person TSMs who have no technical bone in their body and plainly spend too much time trying to make everyone feel good, while getting no useful information into your hands at all -and we had one of those a couple of TSMs back, do not be dismayed, eventually they will crack under the pressure of all your brutal honesty and move into a line of work to which they are better suited. Either way, you’ll have to start all over again. Try to cut to the chase, build trust quickly, sort this person out and get your problems solved.

I haven’t implemented this idea yet, but I may as well blog about it… I’m thinking about starting off new TSMs with a few ‘trial’ tickets, get them trained on the basics first, see how they do with some logs on garbage collection failures or JMS migration problems. Then I’m thinking a couple bogus tickets on load balancer configuration questions followed by what the default multicast port is, running on up to a few basic ORA- errors and a couple of those ‘benign’ errors that Java throws in the logs just to make you think there’s a serious issue going on.

Meanwhile, let’s hope a real problem doesn’t come up…

One thought on “To Train Up a TSM …

  1. I guess, I view our TSM as more of a partner than someone who just works tickets. I’m more interested in my TSM being an advocate for us to Bb Development and upper management. Of course, most of our open tickets are confirmed security issues or bugs. The TSM knows us better than anyone else in the company, thus is the best person to speak on our behalf in internal discussions.
    Additionally, my TSM should warn us about trending issues that may be applicable to us.
    I’d like for our TSM to be able to tell Dev, “That is a stupid [claim / fix workaround]. I can’t take that to my client.” Of course, this was because I had one who was able to do so.

Comments are closed.