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.
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.
|Skills||Technical writer||Scriptorium consultant|
|Product knowledge||Critical||Nice to have|
|Tools knowledge required||Intermediate||Expert|
|Programming/scripting||Nice to have||Critical|
|Preferred environment||Thrives on consistency||Thrives on variety and/or chaos|
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.
Tom Johnson on getting a graduate degree in technical writing
Business Week on retraining the unemployed
Fantastic idea. I wish more folks would consider setting up apprentice/intern options.
I really do feel like we are in the midst of a groundswell of discussion around the future of technical communication–what are the value-adds of a graduate degree, how have workplace demands changed, in what ways have the disciplinary/professional divides between tech comm, UX, & ID fallen away, etc.
Thanks much for posting this and sharing valuable industry insight to those of us very much interested in evolving alongside this rapidly changing profession!
Julio Vazquez (@juliov27612)
XSL stylesheets are fun to write? I tend to disagree with that, Sarah. However, it’s quite satisfying to write one that works precisely as you expect and that it solved the problem you’re working on.
Lots of good points in this post. The skills needed to fill the position are considerable and most folks need at least 6 months to learn them. Unfortunately, most consultants who already have the skills (or at least some of them) are becoming too busy to adequately mentor those who need the mentoring.
Anybody thinking of entering this field needs to prepare themselves. They need to purchase books on XSLT and XPATH. Learn some of the basics and then dig through the DITA Open Toolkit (which is becoming something it was never intended to be) to find out how things are done there then follow the discussions on the changes coming through.
The landscape continues to change even as you think you have a handle on it. The key is to juggle the learning and doing, much like Luke had to on Dagobah and keep at it until things become a little easier. It will take time, but when you keep at it, you will develop the skills to do the technical end of the business. Then it’s time to learn to become human.
XSLTs are fun for the right kind of person, but DITA’s specialization overhead makes writing them a lot less fun. You can’t just match on element names. You have to match on substrings in the class attribute, which is pretty tedious.
“Documentation Build Developer” is a title that fits the consultant role described here.
Btw., If you’re in a hurry, http://www.cranesoftwrights.com/ is a good place to learn xslt and xsl-fo fast.
I especially like »Preferred environment: Thrives on variety and/or chaos«. If I would live in the US, who knows…
@Julio: Oh, I think XSL stylesheets are lots of fun. I never said I was normal. 🙂 Great point about the changing technology — you’ve nailed the current “hot” items, but they will change. The only question is…to what?
@David: That’s a good title for some of what we do, but it’s too narrow for the overall job.
@Michael: Yes, I’m afraid that liking variety and/or chaos is something of a prerequisite.