The Best Job I Ever Had

By | 2013/12/17

The best job I ever had spanned the full spectrum of technical communication.

In a response to a comment in a discussion related to my post Content Engineering is not Technical Writing, Scott Abel said:

Who cares what tech writers do. There’s no future (read: great paying careers) in documenting things. That ship sailed a long time ago. Now, companies pay top dollar for someone with a hybrid set of skills.

I’m not sure if I would go that far. I know lots of tech writers who still make a good living. And frankly, for anyone who wants to make a career as a writer, technical writing is a godsend, since there are few other writing jobs that provide middle class incomes.

Still, I do believe that the price of admission to a tech comm career has gone up since the 90s, and will likely continue to go up. As Alan Pringle notes, you can’t be “just a writer” anymore. You need to deeply understand the product you are writing about in order to create the kind of content users really need.

But Scott’s emphasis on a hybrid set of skills brought to mind the best job I ever had. My employer was OmniMark Technologies, the makers of the OmniMark programming language, which, as its name implies, was a language for processing all forms of markup. Think XSLT, long before XSLT existed, but much more powerful and capable of more than just XML processing. (I know it is customary in these sorts of personal experience posts to draw a veil over the names of employers and associates, but my work history is easy enough to find on the Web that it would be pointless not to name the company here.)

I was the first technical writer hired as an FTE, and I was actually interviewed twice, once for a tech writing job, and then, after they realized they needed more than one person, interviewed a second time as a tech comm manager. I had several titles in my 6 years with OmniMark, peaking at Director, Communications, but even the wide range of job titles does not capture the variety of things I did there. Even the following list is not exhaustive:

  • I wrote documentation for the OmniMark programming language and for other OmniMark Technologies products, such as a load balancer and an IDE. In doing so, I learned to be an OmniMark programmer, which really opened my eyes to the variety of programming paradigms that exist. Programming in OmniMark required a whole different way of thinking about programming from the languages I had used before, such as C and VisualBasic. This, in turn, involved a whole new way of thinking about data and data structures, which has shaped my whole outlook on structured writing to this day.
  • I wrote a book about OmniMark programming, Internet Programming with OmniMark, which was published by Kluwer Academic Publishers. In writing the book I learned a huge amount about network programming and the ability to distribute functionality and data, which has shaped my views on decentralization in content management ever since.
  • I wrote articles on OmniMark and on SGML/XML processing and design for leaning industry magazines and websites. I learned a great deal about writing self-contained articles about aspects of a broad subject. That experience was a step on the road towards Every Page is Page One.
  • I hired and led a tech writing team. It was not my first management role, but it was the first (and so far only) time when I got to shape everything from scratch, without any preconceptions or old ways of doing things to limit what we did.
  • I was part of a team that designed and built the structured writing tools that we used. OmniMark was a markup processing company with a deep commitment to structured authoring, having developed some of its most powerful techniques. We pioneered several techniques in that system and the lessons I learned from that experience are the foundation of everything I believe in and practice in the structured writing field today, and the foundation and inspiration for the SPFE project.
  • I moderated the OmniMark User’s Group mailing list, a list used by many OmniMark programmers to exchange information and ask for help. Many of the OmniMark development and consulting staff participated on the list, and it was sometimes my job to explain what the boffins were saying in terms that the users could understand. The archive of this list became one of the most important sources of answers for OmniMark programming questions. From this experience I learned the importance of user-generated content, and of fostering an environment where users can share their experience. I also learned the importance of the Long Tail of product information as part of the overall information resources for a product, and why documentation cannot succeed if it attempts to stand in isolation.
  • I gave presentations at developer conferences introducing new product features and once went on a tour of Europe giving training seminars to the company’s European customers, sharing the training load with the CTO. I wrote most of the material for that tour. From this experience I learned that technical communication is personal, that much depends on the trust that the reader has in the writer or speaker, and that if you want to gain that trust, you have to know your stuff, and know it really well.
  • I manned the booth at trade shows, talking to a wide variety of users and potential users, and working with the sales staff, introducing them to people interested in following up, and handling technical question that they were asked by the people they were talking to. From this I learned the importance of the difference between someone wanting information and someone wanting a relationship with a company and its products.
  • I did pre-sales engineering work, working with sales staff to assess opportunities, to understand the business problem that a potential customer was trying to solve, and showing them how an OmniMark solution would work. On a couple of occasions I traveled with the sales staff to perform these functions on site. From this I learned the key role that technical communication, and particularly the ability to relate technical capability to real world business problems, plays in the sales and marketing of a product.
  • I participated in product design meetings with the development staff, often bringing perspectives from the customer contact that I had had from the mailing list, conferences, trade shows, and sales calls. I was also instrumental in the design of a couple of libraries, based on my experience in previous positions and the problems I struggled to solve in those roles.
  • I presented on structured writing at conferences and cultivated relationships with the luminaries of the tech comm field, often coming back with leads for the sales staff, some of which led to new consulting or product business for the company. The relationships formed then continue to be important to me today. From this I learned to be an effective conference speaker, and, equally importantly, learned how to get a presentation accepted by a conference, a skill which is particularly important to me today.
  • On one occasion, I lead a consulting team in an engagement with a major customer. This was as a result of the contacts I had made at a tech comm conference, and the client specifically asked for me to lead the team. This was the foundation of my subsequent consulting career.
  • I managed a team of writers and designers, dealing with all the usual employee issues from hiring to training to direction and assignments to promotions and compensation, and layoffs.
  • I worked with the training and tech support teams on sharing information and reusing information, and also wrote and delivered some of the training.

The interesting thing about this very varied list, though, is that, with the exception of the management roles, every single one of the things I did, from conference speaking to sales support, to magazine and book writing, to consulting, to the building of writing tools, was technical communication and/or content engineering. And every one of the technical communication and content engineering tasks I undertook in that job strengthened my ability to do the other tasks. Writing manuals (“documenting things”, as Scott puts it) is a pretty narrow field, but technical communication is a very broad field, and one I think is best practiced broadly.

It was the best job I ever had. I have never once seen an ad for a role as diverse as this one, but if anyone is looking for someone to do all of the above, give me a call. I’d do it again in a heartbeat.

15 thoughts on “The Best Job I Ever Had

  1. Leigh White

    Great post, Mark! I can also say that during my years as a technical writer, I did everything from documenting software applications, to Web design, to functional spec writing, to process documentation, to presenting at conferences…you name it. I enjoyed every bit of it and I am certain that the variety of work contributed to a more holistic understanding of users’ needs and how to help them solve their problems. I definitely feel that it made me a more valuable employee. Plus, heck…it was just fun!

    1. Mark Baker Post author

      Thanks for the comment Leigh. Indeed, a more holistic understanding of user’s needs is one of the key benefits of running the gamut of technical communication, which, of course, makes you better at each aspect of it.

  2. Eileen

    So why did you leave OmniMark? Sounds like there was no limit to what you could do there, including being the CEO 😉

  3. Rick Broquet

    This was an excellent post !!

    Your career path summarizes and supports the statement “You need to deeply understand the product you are writing about in order to create the kind of content user’s really need.”

    To gain that deep understanding of the product requires that you take the initative to learn the product and not just rely on re-formatting engineering content to meet a branding or structured writing format.

    The other key point is to know your audience and become the user advocate. See the product you are writting about from the customer perspective. As you point out technical communication is a very personal experience. The customer is trying to use your product to be more efficient at their job so the technical content must be tailored to fit the audience.

    Every technical communicator should give training seminars in front of a live audience. It is a daunting task to stay on topic while at the same time addressing the specific questions from the audience. They came with a personal agenda, specific questions they need answers to. The information they want may or may not follow the presentation outline and it is an excellent insight to understand the variety of ways users want and need information.

    Another important point you made was when you connect to the target audience the sales improve. It doesn’ t matter if this is training sales, product sales, or consulting sales. When you help your audience grasp a complex technical topic through your writing or presentation you enable their success. The classic win-win.

    Food for thought – isn’t a hybrid set of skills another way of saying that you have experience at this technical communications craft?

    1. Mark Baker Post author

      Thanks for the comment, Rick.

      Indeed, successful communications everywhere depends on two things: knowledge of the subject matter and the ability to communicate effectively. You have to be the SME, and a great way to prove (to yourself and to the company) that you are not just the person who makes the docs look pretty is to deliver live training. There is nowhere to hide in that arena.

  4. Ray Gallon

    Ah, Mark, I knew there were multiple reasons we see things so similarly. Best job I ever had was one that was actually created for me. It took the company six months to recruit me away from another job where I was quite happy. My somewhat grandiose title was “Global Technical Information Systems Designer,” and I had the responsibility of coordinating and maintaining coherence and convergence on several different product lines, developed by teams in France, UK, USA, Israel, and China. I guided and specified:

    -User Interfaces (including enterprise-wide graphics chart)
    -Progressive Information Disclosure systems in both Agile and Waterfall development environments
    -Coordination with web team on look and feel, content strategy and message
    -Meeting customers at user meetings, and conducting usability research
    -Coordination with regulatory compliance department
    -Coordination of tech doc teams that were organized completely differently and using different tools
    -Development of a plan to move to structured writing using DITA and a proper CCMS
    -Collaboration with marketing on new logo and product mark designs
    -Collaboration with marketing and product management on selecting outside consultants for design of visual communication system and iconography for new product line on new platform.

    Best job I ever had, too.

    Oh yes, did I mention I also wrote a few help files?

    1. Mark Baker Post author

      Thanks for the comment, Ray. Sounds like a very similar experience. Pity such jobs don’t come along more often.

  5. Chris Despopoulos

    While Scott may have been harsh in his statement (looking for a little Shock and Awe?), I think there’s general agreement here… Technical writers cannot count on being hired to produce pages. That approach to the job is obsolete, or at best it has become a commodity.

    I’ve come to look at it through two axioms:

    1. Any project you can think of in the developed world is largely an exercise in information management. Building a bridge? Farming wheat? Distributing medicine in a gvmt health care system? Building software? It doesn’t matter. The information component is huge.

    2. Technical “writers” are information professionals. They conduct research, manage terminology, test work flows, build teams, forge relationships, clarify or even define products or product features, disseminate (publish) content… The list goes on.

    What more needs to be said?

    1. Mark Baker Post author

      Thanks for the comment, Chris.

      You make a very good point about most jobs today being largely about information management. Seeing technical writing as as industry serving those needs is certainly something that would see the profession adding much more value than it does now. But is this actually happening anywhere? It seems at the moment that it is split into two camps: IT and tech writing, neither of which have much regard for the other’s skills.

      Can we hope to see tech comm acquire the IT chops that would seem necessary to really fulfill that role?

  6. Vinish Garg

    Large corporations generally offer a specific and well-defined role whereas comparatively smaller organizations give more flexibility to participate and work on different types of documents. The best job I ever had NOT in terms of work satisfaction BUT in terms of the learning scope was at PHi business solutions. I learnt:

    – Writing Case Studies
    – RFPs and Business Plans (for their in house IT products)
    – Responding to RFPs as a service provider (this was my introduction to product scoping, IA, prototyping, and product strategy)
    – Process documentation (internal style guides and documentation process)
    – And of course, online user manuals

    I loved the variety of work there and the challenges of course!

    1. Mark Baker Post author

      Thanks for the comment, Vinish.

      You make an excellent point about company size and specialization of roles. It raises an interesting question about the relative agility of small companies. Perhaps it is not merely their ability to change quickly that makes small companies agile, but the broader view of the business that every employee gains by playing multiple roles.

  7. Pingback: The Best Job I Ever Had | Technical Communicati...

  8. Pingback: The Best Job I Ever Had | content motorist | Sc...

  9. Pingback: The Best Job I Ever Had | Every Page is Page One |

Leave a Reply