The Best Job I Ever Had

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.