Want Respect? Get out of Publishing

By | 2011/12/29

I recently wrote the following in a comment on Tom Johnson’s blog post What Tools Do Technical Writers Use:

That writers are still expected to do their own publishing strikes me as one of the tragedies of the profession, and a major part of why tech pubs does not get the respect it thinks it deserves in organizations. It is a big part of the reason that so many people still dismiss what tech pubs does as “making it pretty”.

It was not the most deeply considered statement I have ever written, and when I read it over after having posted it, I rather wondered at the sentiment it expressed. Why exactly should engaging in publishing lose you respect? It’s not as if people universally lack respect for publishing. It’s not as if publishing is something akin to pyromania or politics, rightly despised by all. Yes, there is the “making it pretty” thing, but why exactly should the ability to make content pretty lose you respect? People are not generally opposed to pretty. They like pretty. They pay a lot of money for pretty.

So was my intuition correct that tech pub’s association with publishing is to blame for the lack of respect that so many technical writers complain of? I’ve thought about it a lot, and my conclusion is that my first intuition is correct: if you want respect as a technical communicator, you need to get out of publishing.

Here’s why. It’s not that people don’t respect publishing skill. It is that there are two different kinds of respect that skills in any field will get you: one-of-us respect, and one-of-them respect. I respect all kinds of professions: mechanics, accountants, landscape painters, particle physicists, custom tailors, airline pilots, comedians, acrobats, and concert pianists, to name but a few. I respect these professions because I can see that they are difficult to do, and that they have social value. I can’t do any of these things, and I don’t know nearly enough about them to make specific judgments about how these people do their jobs. I respect them from the outside. I give them one-of-them respect.

I also respect many writers and many structured writing practitioners and consultants. But I give them a different kind of respect. These are my fields, the things I know well, the ways I make my living. I am qualified (I flatter myself to believe) to make specific judgments about how individual people in these fields do their jobs. My respect is based very much on the details of how individuals perform. My respect is not given universally or uncritically, but individually and on merit. I respect these folks from the inside. I give them one-of-us respect.

Here is where the respect problem comes from for technical writers. Most engineers, software developers, and other technology folk respect publishing skills, but they give them one-of-them respect, not one-of-us respect. The problem this creates for technical writers is that while they may get one-of-them respect from their technical colleagues, it is one-of-us respect that they need to get their job done, and to feel valued and appreciated by their colleagues.

Writing well about technical subjects is, however, something that technical folk do respect as a one-of-us skill. Some engineers write well and some write poorly, but all engineers have to read technical material to do their jobs, and they can tell the good stuff from the bad stuff. Much of what they read is written by other engineers, and they know this and recognize effective communication on technical subjects as a technical skill, the kind of skill that gets you one-of-us respect.

So why can’t we have both one-of-us respect for our technical writing skills and one-of-them respect for our publishing skills? I suppose we can, if we are good enough, and work hard enough. But I think there is an inherent human bias that says, if I am giving you one-of-them respect, then you are one of them, and therefore not one of us. If you were really one of us, your whole focus would be on our set of skills. If you show mastery of another field, then clearly you cannot be focusing sufficiently on our field to deserve one-of-us respect.

Many writers do this to engineers. They respect their engineering prowess, they give it one-of-them respect, and they tell themselves, by way of compensation, that engineers can’t write. They deny them one-of-us respect, even in the face of clear evidence that many engineers actually write well, and that some really good engineers can also write really well about technical subjects, both for other engineers and for lay people. Once we give one-of-them respect, we shut to door on one-of-us respect.

This is not entirely unreasonable. We don’t have to subscribe to Gladwell’s 10,000 hour thesis to acknowledge that mastery of any craft requires dedication of time and mental energy. It follows that it is comparatively rare for a person to be a true master, a person deserving of respect, in multiple disparate fields. Nature does not produce DaVincis in abundance. The prejudice that if one is a good mechanic then one is not going to be a great concert pianist as well is a reasonable one on which to make daily judgments about life (like deciding not to hire Glenn Gould to replace my clutch). It may not be truly just in every case, but it works pretty well most of the time, and that is how we make most of our daily decisions.

So yes, I think for tech writers to have, to cultivate, and to display publishing skills saddles them with one-of-them respect in the technical community, and that makes it very hard for them to win one-of-us respect for their ability to write about technology. So if you want respect, a good first step would be to get out of the publishing end of the business.

23 thoughts on “Want Respect? Get out of Publishing

  1. Scott Abel

    Nail. Head. Hit! Need I say more (you know I want to, but I’ll reserve my commentary for a coffee house discussion some day very soon).

  2. Pingback: Let’s talk and teach, not fight, about accessibility - Mardahl.dk

  3. John Tobin

    I just don’t know about all this discussion about respect.

    So as as writer, you get to document stuff you only peripherally understand. You’re working with engineers, but you’re not an engineer. But so what? That’s not what you were hired to do. You know that. The engineers and developers know that. They know who’s who. So both parties, in reality, should be ok with that.

    You’re not going to get one-of-us respect, because you’re working with senior engineers and you’re not one of them. Why crave that? Why try to be where you’re not? Their attitude to themselves is their problem. Our attitude to ourselves is our problem. Or it doesn’t have to be a problem at all. It’s all in how we conceive it -not being an Engineer or a Developer and being ok with that. I do what I do. They do what they do and everybody’s happy. We don’t (in any profession) have to be all things to all people.

    The fact that many engineers write extremely well, is just something we’re going to have to live with. It’s just surprisingly true. So much for putting people in boxes. There doesn’t have to be an us and them conflict.
    Just being confident in an environment like that counts for a lot, and the only way you’re going to have confidence with them, is through acquiring more and more knowledge about technical stuff, if you really crave acceptance to that degree. but if that’s the case, they’ll pick up on that much more than be bothered about whether you’re an Engineer or not.

    The fastest way to get to the bottom of the respect pile is to behave in an insecure fashion. Good old humans can be relied on to attack where they perceive some weakness. Those bullies will just push you around from pillar to post. They want to just absorb your energy so they can become stronger. Your less is their more. (even they’re insecure-it’s an international problem).

    Even if you don’t walk the walk, by gradually acquiring more IT knowledge you can talk the talk (a little). Meeting them half-way counts for something, (doing your homework before you talk to them-though that can be difficult if required to do a subnetting crash course). But talking the talk can be dangerous too, if you only half know what you’re talking about. It’s like name-dropping in Literature. Someone asks you what aspects of Proust’s writing were you referring to? Then you may be in trouble. If you know you’re on safe ground, then you can bluff a little.

    But why bluff at all? Like it or not, it’s a technical world out there, and the title
    “Technical Writer” says it all. The boundaries are blurred these days. You pretty much have to be a writer and you have to be technical to some degree or other, even if it’s only fighting with MS Word numbering and fighting your own trouble-shooting battles.

    If you’re not getting respect, pound on the table, red-faced and manic, and say vociferously: “I will not tolerate this insolence”.

    1. Mark Baker Post author

      Hi John,

      I agree completely that confidence is key to respect. If we don’t get respect, though, should be worry about it, or just learn to live with it? It’s a good question. But I do think there are pretty clear practical consequences for writers who do not enjoy the respect of their engineering colleagues. I don’t think you have to be a peer of a senior engineer to enjoy their respect, but they do have to have the sense that you are worth talking to. There are probably several components to that are-you-worth-talking-to calculation. Confidence is certainly one. Knowledge and intelligence are clearly factors also. To what extent does seeing you as someone whose job it is to lay out the docs and make them pretty weigh in that calculation? I’m convinced it’s a factor, but I agree it is not the whole enchilada.

  4. pamela clark

    I think “respect” from others is about credibility, accuracy, and reliability. I found the comment by Leigh White (http://idratherbewriting.com/2011/12/19/what-tools-do-technical-writers-use/comment-page-1/#comment-263077) to be the one that resonated the most for me.

    I think your post, Mark, “Tech Comm’s Place in the Choir” is more to the point as well.

    I think we (companies, tech pubs management, writers) need to spend more time on what works for the intended audience than on “what works for the writers”. This will vary depending on the company, the product, and obviously on the audience. The thing most lacking in my opinion is a fact-based understanding of who the audience is, what information they really want, and how they look for and use it (including what devices they might want it on). I don’t think there is a one-size-fits-all answer. Most companies don’t really know what audience they want tech pubs to address.

    At my last employer, a complete and drastic reorg of tech pubs occurred (resulting in a RIF of half the department) with only anecdotal information (as far as I could tell) on what the audience really wanted. There was lack of respect for the tech pubs department in that equation too, but I’m not sure it had much to do with being in the “publishing” end of the business.

    1. Mark Baker Post author

      Hi Pamela,

      Thanks for the comment. I agree with you on the positive things that build respect. Certainly, merely avoiding the negatives, or that things that might get you pigeonholed as one-of-them, does not automatically gain respect. You raise an important issue in regards to the company not really knowing what audience they want tech pubs to address. Certainly you are not going to get a lot of respect if no one in the organization knows who your job is supposed to serve.

      I think one consequence of the company not knowing who they want tech pubs to reach can be the dumbing down of the docs. Without a clear directive about whose needs to serve, writers tend towards serving the most naive and hopeless user, the user who just fell off the turnip truck. There are always such users, of course, and I can’t count the times I have had writers justify documenting the most tedious elementary stuff on the grounds they someone somewhere once asked about it.

      This leads to two problems. First, you end up with a doc set that covers all the things you could work out for yourself and nothing you couldn’t. Second, the docs that are produced show no kind of depth or understanding, which diminishes the respect that everyone on the technical side has for the writers.

      We really need to write for the middle of the bell curve, where most of our users, and, usually, most of our revenue are. Merely getting out of publishing isn’t going to win us respect if the company does not know who it wants us to write for, and if we don’t know how to write for them. (Though getting out of publishing might give us more time to work on those things.)

  5. Scott Abel

    John, I love the line –> “I will not tolerate this insolence”. I see a t-shirt with that saying on the front of it in my near future.

  6. Barbara Saunders

    I’m wondering what the “respect” that is lacking looks like. That’s an important piece. What behaviors are coming across as lack of respect? How reasonable is it to expect – or demand – that those behaviors change? (In specifics.)

    Are tech writers not invited to meetings they need to attend to do their jobs better? Or are they invited and then asked to fetch people’s coffee? Or something else?

    1. Mark Baker Post author

      Hi Barbara,

      Thanks for the comment. You ask a very fair question. So many tech writers complain about not getting respect, but it would be a good think it they were to specify more precisely what they meant. My experience has been that good tech writers do get respect from their technical colleagues, but that it has to be earned. I also find that respect for good tech writers tends to run ahead of respect for the tech pubs function itself.

      The issue of meetings is an interesting one. People really do not like to have people in the room who they do not feel are one-of-them. They fear, with reason, that they will slow down or derail the meeting with questions, or else just sit like a bump on a log, taking up oxygen and contributing nothing. Since most design meetings are ad hoc, the only way to even hear about them is if the developers themselves are willing to put their heads around your cube and pull you in. For that to happen, they have to be confident that you will not only keep up, but contribute. In this sense, meeting invitations may serve as the ultimate barometer of respect for tech writers in a technical organization. (This is also why, when I managed tech writers, I always insisted on distributing them among the developers. You are much less likely to be left out of the meeting if everyone has to walk past your cube to get to the meeting room.)

      1. sarah leritz-higgins

        Mark, your idea of distributing tech writers physically amongst the offices of the developers is of course ideal. Even if the writing organization is a separate entity from the development organization, it is hugely valuable to place the writer(s) in the same physical location. That being said, the world today has become far less reliant on “knowledge workers” (e.g., tech writers and software engineers) working in a traditional office. These days, knowledge workers often work full-time at home; or come into an “office” only rarely. Many businesses have instituted “hoteling” as an office model (that is, offering cubes that workers can “borrow” as a temporary workspace). So, knowledge workers are much more mobile today than ever. Also, don’t forget all the challenges posed by off-shoring; there are huge numbers of “knowledge workers” working in India, Cairo, and various other places around the world. Tech Writers often interface with these off-shore workers.

        This mobile model does potentially diminish all those serendipitous design meetings and water-cooler discussions and random brainstorming sessions; but it doesn’t have to. We have to adjust to the mobility that the virtual world imposes. There is no reason why a virtual brainstorming session can’t happen, as long as all the players have computers (of one kind or another; laptops/smart phones/ipads, etc.) and a fast, reliable network connection. It boils down to getting used to this mobile, virtual model.

        This all being said, nothing can ever replace the convenience of all players physically working in the same location.

        1. Mark Baker Post author


          I agree, it is increasingly hard to achieve co-location, and I think we are only just beginning to figure out how to work effectively with people who are remote. One practice I have seen is that if anyone is on the phone for the meeting, then everyone must be on the phone. You cancel the meeting room and everyone phones in from their individual desks. It certainly levels the playing field for the meeting. Still, I think it will always be a problem if you are working remotely and the rest of the team is co-located.

          1. sarah leritz-higgins

            Mark, that is PRECISELY what i’ve implemented for my work. I work at a headquarters office (which is a symbol for this migration towards mobility; it used to be that everyone wanted to work at the “mothership”; that there was a perception of inherent power by working at the mothership; this is no longer the case. Workers have actually left the mothership to telecommute full-time, or have relocated to satellite offices). Since i hold a lot of training sessions, i have instituted a Webinar-only policy (that is, ALL attendees must attend via Webinar). I used to book a conference room and some would attend physically; but as you say, having an “all-hands” Webinar (where everyone is remote) levels the playing field (and, I would argue, is often more convenient that trying to corral everyone into a conference room). Indeed, the most substantial challenge is the “lone-wolf” out there, working remotely, when everyone else is co-located. But i think this is a short-term problem, as more and more people decide to pursue mobile arrangements for working.

  7. sarah leritz-higgins

    I think the discussion of tools (“getting out of publishing”) is a red herring. If you want respect as a technical writer, it’s rather straightforward: you’ve got to earn it. You earn respect by establishing and maintaining your “street creds.” And how to go about establishing and maintaining your street creds? Try the following:

    * do your homework and ask intelligent questions
    * learn the tool you are documenting
    * seek out customers and field personnel and engage them in conversation; learn from them about how they use the tool
    * use the tool you’re documenting
    * file thorough bug reports when you encounter bugs
    * offer advice to the development groups about usability.

    Do all of these things frequently and well, and then come talk to me about the respect you’ve garnered. You’ve earned it.

    1. Mark Baker Post author

      Thanks for the comment Sarah,
      Your list of the positive ways to build respect is really good. In particular, I have found that filing bugs is a great way to get the respect of the developers.

      I still see value in removing the negatives as well, however. People pigeon hole, and you want to avoid the things that consign you to the one-of-them pigeon hole just as much as you accentuate those things that consign you to the one-of-us pigeon hole.

      Besides, if you get out of publishing, you will have more time for all the things on your list, and there are only so many hours in the day. 🙂

  8. sarah leritz-higgins

    Hi Mark – yes, precisely; “getting out of publishing” does indeed create more time to work on those VALUE ADD items. In my mind, it’s all about priorities. For example, people often say to me that they “don’t have time” to talk to customers. When in fact, what they’re actually saying is, “Talking to customers isn’t high enough on my priority list to actually do it.” And this is a travesty of priorities, because in fact, talking to customers is of paramount importance. I’ve wondered what it would be like for people in other industries to look at how we (tech writers) do our jobs. I imagine that they would be incredulous at how many of us do our jobs, as in, “What? You mean you write content for your customers that explains to them how to use the tool, but you don’t ever actually TALK to these customers? How can you actually know that they need? What they don’t need?” Bottom line: all we have is time (until we don’t); so it boils down to a matter of priorities. What bubbles up to the top of the priority list? I agree with you, Mark, that we cannot let “publishing” be our top priority.

    1. Mark Baker Post author

      Hi Sarah,

      I agree entirely. Many tech pubs groups have the priorities all out of order. Worse, I think more an more tech writers are making it their priority to defend their current turf — which never ends well.

  9. David Worsick

    I would say that Sarah’s letters are much closer to the truth than the article actually was. I don’t think the us/them respect approach is that helpful. We lose respect, not because we publish, but because we don’t seem to add value that the engineers/developers cannot add themselves. We’re hired to write, not because we write so much better than them, but because we write cheaper, especially compared to using the engineer’s time to write. If what you add is low in value, then the costs must be low, and the lower the better. A janitor may be faster at cleaning the office than an engineer, but that only makes her cheaper, not more valuable. It’s the one-of-them respect that is most valuable: people are in awe when you can do something VALUABLE that they can’t do (e.g. doctors and lawyers know what we don’t know, good novelists can think of plots and combine words we can’t do, and mixed-style martial experts can scare us because we can’t do what they can do).
    I’ve had success by being better at improving GUI’s than many developers, able to understand what users actually want compared to what developers want to give them, and able to know how to talk in writing to users both as support and as a marketer. The problem is when you’re seen as just improving words, instead of making the product much more valuable. Even if you publish something that makes the product sell better than the competitors, you’ll get respect. If they can’t see you doing anything valuable, particularly uniquely valuable, you’ll get no respect.

  10. Mark Baker Post author

    David, I agree, you get respect by being good at things that other people value, and especially if it is something they value and can’t do themselves. But being a doctor or a lawyer is a one-of-them skill, while improving GUIs is a one-of-us skill. As a developer, I won’t talk to my doctor or lawyer about GUI design. I will talk to a tech writer who has shown they have chops as a GUI designer.

    I wasn’t recommending the us/them respect divide, just noticing that it exists (and that writers are as guilty of it as anyone else). If people stopped doing it, the world would probably be a better place. But as long as they continue to do it, it is something we have to be aware of to function in an organization.

    As long as people do continue to be like this, it is going to matter whether developers give you one-of-us or one-of-them respect, because if they don’t give you one-of-us respect, they won’t teach you the secret handshake or let down the ladder to the club house so you can climb up.

    I’ve managed enough tech writers to know which of them could get into the club house and which couldn’t. Some of the ones that couldn’t were liked and admired by their development colleagues for the other things they were good at, but they were never pulled into a design meeting or asked to review a design spec.

    As long as the product gets designed and developed in the club house, you need to be in the club house to do the work. Otherwise, they can always find someone still cheaper than you overseas.

  11. David Worsick

    Thanks for the response. I work in Canada, where much of the technical writing is done by techs who learned to communicate instead of writers who learned tech. In my more than twenty years of writing, I have not noticed such a divide, but Canadian firms tend to hire single writers as the entire doc department while I’ve heard that American firms used to set up whole departments of ex-journalists. That may cause a difference in perception and office politics.
    What I have also noticed that would apply to both cultures is that the software engineers usually need help understanding the users’ needs and that’s a skill we technical writers can excel at. It’s not really how to program the GUI but rather how to design a GUI that users can understand well and use quickly. That puts writers into the users’ club, not the engineers’ club, and yet the ability to do that can really impress the engineers.
    Another skill useful for writers, mentioned above by Sarah. is the ability to understand more fully what functions the users (e.g. the subject matter experts) really need and communicate that to the developers. This, however, requires the ability to teach developers the needs and processes of users, and that’s communication. Yes, you may need the politics to convince the engineers to listen, but you need the skill to make it worthwhile for them to listen. And once you’ve made their life better that way, they will listen again.

    1. Mark Baker Post author


      I’m in Canada too. All the companies I worked for had multiple writers, so I don’t know if the lone writer situation is more common here than in the states. I’ve also worked with both career tech writers and with techs who moved into writing. In fact, I have, at times, tried very hard to recruit the latter because they tend to have a much better understanding of the user’s task and a much easier time gaining the respect of the engineering department.

      That said, all of my tech writing jobs except the first were in the business to business space rather than the consumer/office products space, and that makes a huge difference in the technical demands of the job, and therefore to what it takes to gain the respect of the development team.

      As far as I’m concerned, the ideal tech writing candidate is a former customer who has used your product professionally for a number of years, and now wants to write about it. They know the reader because they have been the reader, and the dev group is going to welcome them to the design meetings with open arms. Hard to find, but pearls of great price if you can find them.

      But whether in the B2B or B2C space, the ability to intelligently represent the customer is certainly something that can help the writer gain the respect of the engineering team (and it has, of course, nothing to do with publishing).

  12. Ex tech writer

    Great article! I’ve been a writer for about 16 years now. My aim is to leave the field permanently within the next 12 months. Ive got my graduate degree in and practical experience in other fields. I’m tired of all of the work that you have to do to get the simple respect given to a wet-behind-the-ears engineer who just graduated from college last year. I’ve done it all … programmed, tested, trained, worked with the customer,designed GUIs. Ive gained respect, whether it is the “us” or “them” respect, but really, who wants to have to start from scratch doing that over and over again every few years as projects change? It gets old and I have no desire to impress anyone anymore. I don’t want to play the “I’m smarter than you are” game. Its silly. Plus, I’ve got a life to live and better things to do with my time.

    Many technical writers blame themselves or worse, each other. This is unfortunate. Rarely does anyone one talk about the elephant in the room. My experience has been that many technical people (though not all) are more comfortable with things and ideas, not people. Many lack social empathy needed to appreciate differences or to even consider the possibility that not everyone wants to be an engineer or a programmer. I’ve heard enough stories of “stupid users” over and over again to know that this is part of their culture. There is a reason that many technical people are stereotyped as socially awkward and obnoxious. Many are, and when there is a concentration of people like with those same blind spots, it makes for an unpleasant and irritating experience. Again, not everyone is that way, and I’ve met amazing, empathetic engineers and programmers. Where I am now, most of the people I work with are respectful. There are one or two who are not, of course. Yet, I’m done with this field. As the years roll by, I see no reason to not be given simple respect right off the bat, just as a fellow employee. I’d rather work with other people who get that.

  13. Joe

    The subject of one-of-them respect got me thinking about what I percieve as a common paranoia among tech writers. At least it has been for me.
    I think one-of-them respect is something that technical writers (and most workers) covet, because it means job security. We can’t be replaced by engineers if there is a knowledge barrier between what they do and what we do. The harsh reality, though, is that most of what we do involves soft skills that are taught in some degree to all students. I’ve been in tech pub departments that seem determined to claim that their skills are inaccessible to outsiders. But any savvy engineer could see right through that notion and the writers probably ended up looking like elitist frauds. I know I stepped back many times and asked why I really wanted to be a “one-of-them”.
    I believe the essense of a professional in any field is not exclusive knowledge of – or even mastery of – that field. It’s ownership. It’s saying that “this documentation is my domain, and if it fails the user then I have failed the user”. That kind of dedication is hard to commit to fully if you wear a different hat. Most engineers will write documentation if pressed, but how many of them will do so enthusiastically? In my experience, most of them don’t want to. It’s an annoyance. It’s busy work. They don’t necessarily care. I’m a technical writer because I make it my primary business to care, and the results are hopefully indispensible. I’m not the gatekeeper to the secret knowledge of parallelism, grammar, and PDF bookmarks.
    Put another way – if you want respect, drop the one-of-them act. Creating a line between yourself and engineers is only a good thing when it forces you to re-evaluate exactly why you belong on the team.


Leave a Reply