One of the jobs of a Technical Writer is that of customer advocate. First, we do this by translating all of the corporate and programming rhetoric into, hopefully, simple to understand, every day English. Secondly, we must look at everything that crosses our desk with a client’s eye and ask, “Will our clients understand this? Will this confuse (or worse) our client base?”
Recently at work we decided to reuse our build nomenclature and “force” a build in between two previously scheduled builds. My company uses the W.X.Y.Z build scheme; W=the main program iteration, X=the main program subdivision, Y=the current update or patch version, and Z=the current build of that update or patch. So, for example, version 1.2.4.3 tells users that the main program is on version 1.2 and we are on update 4 of that version and we had 3 rebuilds of update 4 before releasing it to clients.
We released version 4.6.0.6 to licensed clients (those who host our software on their own systems) and installed it for the in-house clients for whom we host our software. But, because we already had a planned 4.6.1.1 release with its own set of changes and patches, and we needed to get out a “rush” build prior to that next version, the PTB determined to release a 4.6.0.7 build.
As a client advocate, and knowing that our clients understand and follow our numbering scheme, I questioned this decision. I argued that our clients will assume that 4.6.0.7 is a replacement for the 4.6.0.6 release, not a separate build. This, I said, will cause clients who wait and test items before installing them to possibly get confused and cause additional work for our Product Support staff and Account Managers. I figured our staff would have to explain that this is a separate build that should be installed on top of the 4.6.0.6 build, and not as a replacement for the 4.6.0.6 build.
I was met with very condescending looks and mildly annoying answers that included:
· “I think our clients will understand this.”
· “We’ve done this in the past.”
· “It is not like our clients read the documentation anyway.”
In an attempt to advocate for client clarity and understanding, I am met with condescension and outright derision. First, I was confused and the person who creates our builds and releases them to clients was confused (I spoke with him and he admitted as much). If two people in house and involved in the process are confused, at least 1 client will be, too. Second, just because we have done something in the past doesn’t mean that we should do it again in the future. Third, thank you so much for letting me know that my job is, basically, useless.
In our review process at this company is a section where our managers grade our ability to be client-oriented. My manager consistently grades me quite high in this area as I am always concerned about the client’s understanding and acceptance of what we do. Yet, more often than not, that concern falls on deaf ears within the company. I am starting to think that my talents are being wasted in this arena and that maybe something more client-facing would be a better fit with my talents. Then, at least, when I bring client concerns to product design they would have to listen.
When I managed at Blockbuster Video, I always enjoyed solving customers’ problems and making them happy. My boss hated that I had the highest “credits” (money given back to customers) of the managers in the area (there were multiple Blockbusters and we sometimes got traded around a bit), but she also admitted I brought in a ton of revenue by encouraging new clients and managing to keep disgruntled clients. At my previous job, I came into my own when I started dealing directly with clients. At one point, the sales department complained because I had generated more revenue in a month than they had—combined. Since they got incentives based on the amount of sales they made, they complained and got the rules changed so that all my invoices had to be signed by one of them (side note—they frequently lost money I handed them as, when I passed clients off to them to finish the sales, they often managed to screw it up a completed sale and piss off the customer).
I cannot help but wonder if I should look at new and different work for my skill-set. Maybe I have gone as far as I can with technical writing and need new challenges.
John, I know exactly what you mean. I tend to put the customer first as well, and sometimes a few programmers are not entirely enthusiastic about making recommended changes in the application. At times it is very frustrating, being the only technical writer and having a differing opinion than a roomful of engineering personnel (programmers, quality control reps, etc.). We see things differently than the rest of the group because our discipline is entirely different than theirs. Oh, well. I am fortunate that most of the personnel at our organization are genuinely nice and helpful, and there seldom is any friction. As far as pursuing a another line of work, I guess you'd have to determine whether doing that other job would be more fulfilling for you in the long run. But it's good to know that you have other options if you should decide technical writing isn't where you ultimately want to be in your career. Good luck and hang in there! - Daralee
ReplyDeleteA parallel to your job situation is mine: I love teaching--as long as I can stay in the classroom and work with the kids.
ReplyDeleteAdd in an administrator who is only worried about the public's perception of him/her or a parent whose only concern in life is to relive their lives through their children's lives--and you have enough incentive for anyone to pack it in.
You've provided your input, so it's time to sit back and let the good times roll. You don't have to say a word; your enigmatic smile will do it for you.