The (work)force is strong…

Technical communication is in the midst of a huge transition from a craft/artisan model to an engineering model. Our consultants are the vanguard of this transition, and as a result, we are experiencing significant challenges in finding new employees.

Scriptorium currently has two job openings. One is for a technical consultant, the core employee category at Scriptorium. Consultants are those nice people who develop content strategy, write DITA Open Toolkit plugins, and do all the other cool stuff we do.

Unfortunately, qualified consultants are extremely difficult to come by. If qualified, many candidates fall into one of two categories:

• They work at a huge company and like the benefits.
• They are self-employed and love it.

In neither case are they particularly interested in working for Scriptorium or any other small company.

We have resorted to hiring interns and spending 6–12 months teaching them to be a technical consultant. Apparently, we are not the only ones. Brain Traffic recently advertised a Content Strategy Apprentice position. Here’s what Melissa Rach, Vice President of Content Strategy, told me:

We decided on an apprenticeship model because we’ve realized there’s a long lead time for most people to learn to be content strategists. We hire really smart people who like to excel, so we want them to have realistic goals and successes during their first 6–12 months with us. Also, it allows us to hire people with fresh ideas and perspectives. Finally, it’s an opportunity for some of our most experienced consultants to mentor others, and they grow by teaching. Everybody benefits. It’s kind of like Yoda and Luke. Except nobody gets an arm cut off in a duel with Vader. (Not yet anyway.)

Wouldn’t we rather hire someone qualified who can contribute immediately? Well, yes. The problem is, we are not getting applications from people who have the requisite qualifications. The vast majority of technical writers, however experienced, are not qualified to work as consultants here (nor would they enjoy it). Our focus is on the tools and technologies that drive automation in technical publishing. We need the people who think it’s fun to write XSL stylesheets, who enjoy wrestling with font configuration files (or who are at least good at doing so), and who see the big picture of content strategy and process automation. A very few technical writers are interested in this type of work and are good at it, but the skillsets don’t really intersect. There is a big leap in technical sophistication from “expert FrameMaker user who can build templates” to “configuring the DITA Open Toolkit to make less-ugly PDF.”

As my colleague Alan Pringle pointed out, we are dealing with open-source tools with limited (or no) documentation and programming challenges rather than configuring commercial tools. We need people who have the ability to charge into the unknown, solve problems that haven’t been solved before, and like it.

We teach our apprentices how to exploit information technology to make publishing more efficient. For this, we need people who are interested in both scripting/programming and content. Traditional programmers are too…programmery. I had an interview with a programmer candidate a few years ago that went something like this:

Me: So, you had some experience with the DITA Open Toolkit and making PDF output.

Candidate: Yes, it’s really easy.

Me (hyperventilating at the thought of someone who thinks DITA PDF is “easy”): Tell me about some of the problems you fixed in PDF output.

Candidate: What do you mean, problems?

Me: What sort of things are not good in the default PDF output?

Candidate: It looks fine to me.

Me: <thud>

From a programming perspective, it is true that the default DITA PDF is “fine”—after all, it meets the requirement of “create a PDF.” But there is also the publishing perspective, and from that point of view, the default DITA PDF output is not exactly fine at all.

We are looking for an unholy combination of “understands publishing techniques” and “can do automation stuff.” Interestingly, the interns we are hiring often come out of tech comm or journalism programs, but we are hiring them because of outside work that they have done, especially web development. Neither an academic program nor technical writing experience prepares individuals for our type of work.

There is understandable resentment from some candidates, who are aghast that their decades of technical writing experience doesn’t seem to count for anything in our evaluation process. But we are not looking at their technical writing skills, which may indeed be considerable. Our evaluation centers on tools—how many different publishing tools has this candidate learned? How deep is her expertise with tools? How much programming or scripting work has she done? Does his career show a progression from simple to complex toolsets?

Given the shortage of candidates with broad expertise across a variety of publishing tools and technologies and the lack of relevant education programs, our solution is to create our own workforce.

We look for people with interest and aptitude for creative problem solving, great people skills, and most of all, the ability and the desire to learn a lot of new technology.

If this sounds like you, we might have a job for you.

Related posts:
Tom Johnson on getting a graduate degree in technical writing
Business Week on retraining the unemployed