Since the last time I posted anything to this blog, a lot has changed in both my Second Life and my real life. The two most significant changes are that I finished the work for my Ph.D. (graduation is this coming Sunday) and that I've been on the Phoenix/Firestorm Support Team since February of 2011 and on its management team since last September. I still host and play lots and lots of trivia in SL, but I don't hunt much anymore. My goal is to make my living as a freelance proofreader/editor, or possibly voiceover artist, and hopefully move someplace new. I'm a fan of big cities.
It was inevitable that I would want to write about some aspects of support eventually. Although we help hundreds of people a day through our inworld groups, our web-based JIRA issue tracker, and our classes, in addition to one-on-one help in IMs and any number of casual encounters that turn into support, there are still a lot of people who don't know what kind of help we give. Some of those end up not seeking out assistance when they need it (and either complain about the viewer to people who can't help them or hang back on aging versions because the new ones "don't work"), while others want our help to be something it's not and grow angry when we don't fit their expectations.
In fact, in my experience, unrealistic expectations -- not only concerning the role of the support team but also concerning the way a variety of things work on a technical level -- become a primary barrier to receiving support. And so I've been working on a series of posts highlighting some of the perceptions, arguments, and misunderstandings people bring to us that end up becoming barriers to troubleshooting.
Happily, most people don't approach us with any of these. I want to be clear about that from the get-go. Usually, the folks we help are postiive, open to providing whatever info they can, and willing to look into the suggestions that are offered to them. They enjoy learning more about the viewer while they work on their problems, and these are the users that I find myself learning the most from, as well.
So I hope this will be informative, or entertaining, or something. I hope it can spark discussion, but only if dissent is kept civil. I also hope that at least some of these have some use beyond the context they were written for, since that context is admittedly rather narrow.
|A totally unrelated picture of folks at Flying Badger Trivia. Just because.|
And with that, let's kick off the series I'm calling "Heard That One Before," on things that are not as useful as some people think they are to say to viewer support team members:
1) "I'm a programmer / I build computers / I'm a NASA engineer / I do tech support for < insert non-viewer product here > / I've had a computer stapled to my fingers since before I was old enough to read the keys."
When people inform us of this in the middle of receiving support, the implication always seems to be that we therefore need to be careful not to insult their intelligence. However, all it really communicates is, "I'm embarrassed to be talking to you in the first place so I'm going to fight every one of your suggestions if I can find a way to do so."
Knowledgeable support in any area is going to be specialized, so it matters very little what quasi-related background you have. Even members of the team come to each other for help, and we don't (I hope) feel any humility about it. By all means tell us what you know, but don't mistake titles and labels for an indication of useful knowledge. More importantly, don't expect support to know what those positions suggest you do or don't know, or what you might have already tried before you came to us. The basics need to be covered regardless of what you do for a living.
Do we know everything? Of course not, and it's pretty normal to hit a number of dead ends in the troubleshooting process before finding the right route. But attempting to pull rank on someone who's trying to help you isn't going to lead to a faster fix. It's not like we hold a set of sooper sekrit Fixes for Advanced Users Only in reserve.
In fact, we find that those who do know what they're doing (and not just know how to slap a gold star on their own noses) understand why it's important to start with basic steps and double-check even the most obvious possibilities, and also to make sure both user and team member are on the same page about terms, tasks, and meanings.
For instance, if you hear, "When you did your 'clean reinstall,' did you get all three folders?" it's your own choice if you decide to be insulted by such questions, when all we really just need to know is, "Are we talking about the same thing here?"
So check your expert ego at the door when you need us. As any responsible proofreader will tell you, even proofreaders need their work checked.
Watch for the next post in the "Heard That One Before" series: "A lot of my friends / people I've talked to / people in this group are having the same problem."