August 18, 2010 
My heart was racing like a single-seat Formula One car: It was my first morning on the new job. I was already worried that I might be unemployed by lunch time! As I stepped slowly through the abandoned print-shop, the words “stealth-mode start-up” took on new meaning. Ventilation tubes swung from an open ceiling and boxes of computer parts lined the walls and corners. The HR manager pointed me to my desk, smiled and walked away. There was NO computer on my desk!
My future workspace was completely bare, save one sheet of instructions, written in 9-point “Courier” font. It was a TEST. The document sneered at me: This is a SELF-HELP company. Don’t ask for answers that you could have found on your own. Take whatever hardware you need from the boxes. Instructions for installing RedHat Linux 6.2 are on this page.
My new teammates, the engineers who founded the company, were testing both my character and my skills. They had hired me to build an XML publishing system from scratch, using open source tools. But they didn’t inherently respect Technical Writers. They wanted me to prove my worth. I knew I might not be able to make them respect my profession, but I wasn’t going to give them cause to disrespect my character. So after three tears, two prayers and one trip to Borders (to buy “Linux for Dummies”), I came back and set out on our common quest: To win respect.
Our common quest: courtesy of Scott Adams
Aretha got it right: Respect matters. The need to be respected can be a core motivation for Technical Communicators, not to mention a source of daily frustration. It made me relentless. It took two full days, but I finally defeated Linux. And, after two full months, I felt that my co-workers had come to respect my character. But it took two full years before I felt like they respected my work. The turning point came when a prospect mentioned high documentation quality as a driver in their decision to partner with us. At that moment, I finally understood: It wasn’t the developer’s respect that mattered: It was that of my AUDIENCE!
I wasn’t hired to please the developers, I was hired to help the reader. And, unless you are writing API Documentation, your subject matter experts are simply NOT your audience. The developer’s role requires them to categorize their thoughts around the features they create. But your reader categorizes thoughts around tasks they must complete. My job is to bridge the gap. So I made a new resolution: No more anxious striving, grasping for respect from my subject matter experts. Instead, I would work to create content that earned the respect of my readers.
May your co-workers respect your character and may your customers respect your work.
KnowledgeBishop 
Tristan! Exactly… we must bridge the gap, and we serve our readers. thanks for the great story.
Most welcome Barrie! Happy to connect here as well.
You’re right. Respect of your readers is more important than the respect of the development team, but you do need that respect also. The developers need to see you as a resource they can go to when they hit a wall with the interface to the product customer. They should see that you are the expert when it comes to the interaction between the customer and their product. You, along with a user-experience designer, if there is one, should be the center of competence for making their product shine in the eyes of the customer.
When they come to you of their own volition, you know you have their respect and you’ve hit the pinnacle of our career. 😀
Agreed: Developer respect is affirming. In my experience, it came shortly after they realized the customers respected my work. That was the proof they required.
What a great story. I’m jumping up and down on my desk shouting “Yay!” If I fall and hurt myself — or worse, if I damage company property — it’ll all be your fault, Tristan.
For many years technical communicators (not all, but many) have walked around like Tina, saying that we don’t get any respect. It’s a self-defeating attitude, and you’ve proven that by saying (1) we’re awesome, and (2) we need to earn the customer’s respect — not the SME’s. I hope that everyone will take this to heart.
OK, I’ll climb down now. Very carefully.
I’m going to hope you are safely reseated? 🙂 Thanks so much, Larry! The visual was sublime.
Great post, Tristan. While I agree that it is your audience that matters, I think that doing everything you can to be professional and not waste your SME’s time is very important, too. For example, I always counsel my writers to do their homework before they reach out for help.
It is very easy to simply walk into an engineer’s cube and say, “So tell me about your product.” But it shows a tremendous lack of for the engineer’s time. Instead, study up on everything you can find first. Then you can walk in wi, “I understand , but could you shed some light on how
I have found that this approach allows me to build much stronger, respectful relationships with the SMEs. Respecting someone else’s time and not expecting them to spoon feed al, of the information has changed they way SMEs have viewed me and my work – even to the point where my UI suggestions (for example) were treated seriously and quite often implemented.
Respect is a 2-way street. Rather than not care about it, I would suggest showing some before expecting it automatically. It makes for more thorough and accurate docs, which leads to better and happier customers, which also leads to a good feeling for a job well done.
My 2 cents, for what it’s worth!
Whoa – typing on my iPad left out a whole lot of important words in my comment! Apologies! I hope you can figure out what us missing from the context!!
Makes sense to me. I always read EVERYTHING the engineer has written about a feature before I ask them about it. If they take the time to write a spec, I owe them the courtesy of reading it. Thanks Val.
Thanks for this crucial reminder, Tristan. Respect is an essential part of any team, no matter what role each team member plays. When working with my product/feature teams, my goal is to put titles aside and see my teammates as colleagues, each with a valuable contribution to offer; no one is more or less “important” than the other. I will give everyone my utmost respect — and I want it back the same way. I believe that the respect team members give — or don’t give — each other eventually finds its way into the quality of our deliverables. (I think that’s why you encountered a document that sneered at you!) Thanks again for the great post!
Most welcome, Lori! Indeed, every member of the team matters a great deal. I endeavor to treat the SMEs with the utmost respect in all my interactions. But I no longer require their respect to feel satisfied with my work. That was my “a Ha” moment. I appreciate all of your encouragement! 🙂
Great post, Tristan. I can relate to the pre-task anxiety, as for it reminds me of a time when I was retained to oversee a Project Server implementation. The overall deployment needed to be completely scalable and once we were half way into it, we came to realize there was a communication break between the client, the salesman, the engineer, and myself. Once we were able to workout the snag, I was pulled aside and was thanked for addressing the issue instead of dancing around it. The level of respect grew further and the solution provided was able to grow…as anticipated.
Thanks for sharing this, Geoff. It’s so important to speak truth, as kindly as possible, at those critical moments. Honesty is a such gift when the road ahead is about to fork.
Fantastic post. Really loved it. But I am afraid that I have to give you some guff for this line: “It took two full days, but I finally defeated Linux.”
Out of curiosity, before you showed up for Day 1 what were you planning on building the XML publishing system in?
-Michael
Would you believe, Windows? That was my plan at the time. 🙂