What Are Employers Looking For?

Question: I've been asked to give an informal presentation to a TC seminar at Cincinnati State Community and Technical College re TC job availability and what employers are looking for. Even though we are independents, I know we keep an eye on things, if only because potential clients can use our services while they are looking for employees to handle TC duties. Would you mind providing me with some information about how you see the TC market changing or operating currently? What do you see employers looking for, e.g, I know we need to be more than "one trick ponies" -- although that really isn't any different from my experience over the past 30 years (Yikes--it's been that long!) I'd like to be able to give these students some information from beyond the boundary of I-275 (the outer highway belt around southwestern Ohio). Bay Area, California: This year seems much better than the last couple. I've been hearing about more jobs through networking contacts, much in the way I used to. (For several years the "do you have any time or know someone who..." word-of-mouth referrals had become few and far between. There still aren't as many as there used to be, but there are more than 2001-2002.) Most of the projects I hear about are fairly technical, for administrator or IT audiences. Companies seem to be looking for experience dealing with technical information that is similar to, if not exactly matching, their domain. That said, I've had two clients in the last year that hired me for my expertise in designing and developing documentation, and didn't care at all if I knew the domain. (While that used to be the case fairly frequently, it wasn't for awhile.) Single-sourcing is often a need, in one form or another. Most often, it is either the need to have two or more flavors of a book, or the need to create both PDF and HTML versions. It helps that I know multiple tools, as different clients are using different products. An upcoming project will develop MS HTML Help, with that as the primary deliverable -- also a type of project that I used to get, but haven't in awhile. In terms of additional skills -- I've been focusing on usability for quite some time now, and more recently accessibility. Documentation clients appreciate that, and I often get to integrate some UI and usability work into my documentation projects. When there is a limited budget, making sure the documentation that's created is what meets user needs becomes even more important, so focusing on understanding who the users are and what they need is key. I also do projects that primarily focus on UI and usability. That work ranges from writing UI style guides to reviewing the UI for usability and providing feedback, to helping develop the product UI and interaction in a user-centered development environment. It still helps to be able to hit the ground running, get up to speed quickly, and create deliverables in fairly short timeframe. A typical project is anywhere between 6 weeks and 3 months from start to finish. Clients are also very appreciative of the ability to plan, and to look at the big picture, as well as short-term needs. For schedules that don't really allow enough time for what is needed, I work with the client to define optimal documentation, and then to decide what should be created "this time," putting in place the groundwork to develop more later, as time and budget permits. I don't think most of this is anything new. I think the piece that's the most different from 10 years ago is the need for single sourcing in one form or another. With fewer resources, it's more important than ever to get multiple books or outputs from one set of files, and one person! Learning how to do that well is a great skill to cultivate. It's a lot more than just knowing the tools. Boston: Well, the situation here in Boston hasn't improved much. There was a marginal up-tick. And some would still tell you that a good TC can always get a job, but I am not convinced. Too many of my good writer friends are retiring or turning in their keyboards for other, non-technical jobs. There are still opportunities, but fewer and fewer of them are with high-tech companies. In our area, financial services companies, biotech companies, and others are the ones where there is growth. This presents a problem for a person who identifies himself as a TC, because these non-tech companies aren't looking for TCs and if you try to sell them TC skills, they act like you are talking a foreign language. "Writer" or "editor" are titles this group understands. And there will always be a need for good writers and editors. For some of us, the solution is to retool as Information Architects, but I am guessing that that won't be more than about 10% of us, because it is different in many, many ways from traditional TC. The focus here is on design and not content, which is the primary focus for most TCs, and design work is higher up the food chain. The scope of this work is much larger, with more people involved, than a typical writing project with one or a few writers and a few engineers. And IA requires a more broadly based business background than most TCs have. Yes, we are seeing outsourcing, so there probably will be a need for people here in the U.S. to project manage outsourced work, but I don't know that I would look at that as a long-term career option, because the companies and people on the other end will come up to speed in 2-3 years and won't be interested in being project managed from a distance. Finally, what we are not seeing is the next new thing. For me, it was computers, then the web. So what's next? No one seems to know. There was a lot of thinking that biotech was going to blossom, but we're not seeing it. Besides, who needs a user's guide for a new gene? The latest bubble in the high-tech world around here has been in nano-technology. And there may be some real work there, eventually. My guess is that we are at least 3-5 years away from seeing that rose bloom. Cincinnati: There are jobs out there. I think people have to be willing to spend some time researching companies and also need to realize that most good technical communication jobs aren't usually posted in newspapers and/or on job web sites. I honestly believe that networking, especially in small markets like ours, is the way to find out what's going on and who may be hiring/planning on hiring in the near future. This may ramble a bit, but here I go... Seapine recently decided to hire another writer. As I mentioned to you last week, I was first surprised by the lack of quality resumes. We only received a handful of resumes that didn't have typos, format inconsistencies, or misspellings. Even if you don't have much experience, the least I expect is a perfect resume. Even if it takes hours and hours to get it to perfect - that is time well spent. Why should I interview, much less hire, someone who can't even proof his or her own resume? I was also surprised that most resumes didn't include cover letters. Although we didn't specify one, a well-written cover letter can be a great introduction and help me understand how your skills set may apply to what I'm looking for. Next, I was definitely surprised (shocked) by the newer writers' (recent grad/one person with about three years experience) lack of interviewing skills/portfolios/preparation about Seapine. I know that interviewing isn't easy but if you really want a job it's something you need to learn how to do successfully. What happened to preparing for an interview? Even if the interviewee doesn't understand everything that Seapine's software does, I would at least expect them to come in with some basic understanding of what we offer. One interviewee thought we wrote custom reports for users. Nothing about bug tracking or source control or automated testing - just custom reports. In addition, I was expecting writing samples to actually be in some type of portfolio with a brief explanation of each sample. My portfolio is a three ring binder, nothing fancy. But it's organized by writing type and should give a potential employer an idea of what I've accomplished. Two of our interviewees literally handed me a stack of papers, some of which were wrinkled. Even if you're looking for your first technical communication job you should be able to start putting together a portfolio. We were open to everything -- school assignments, volunteer writing, etc. Now, on to interviewing. One thing we were looking for is someone who would ask questions - hoping that person will ask questions when they're documenting a feature, working on a knowledgebase article, or just wondering why a developer used Yes/No instead of OK/Cancel on a dialog. We purposefully didn't give an overview of tech comm at Seapine and how we do what we do. I wanted people to ask about tools, deliverables, processes, a day in the life, deadlines, expectations, training, etc. That only happened with one interviewee. The other two people only answered questions and didn't ask anything. If you followed up with either of those people and asked how I do what I do they couldn't even begin to answer. If you want to be a successful technical communication professional, you have to learn to ask questions and (I believe) have a desire to learn about new things. It doesn't matter what you're writing about, if you're designing web sites, etc. - there should always be the desire to learn about your audience, what you're writing about, etc. By the way, technical communication isn't about sitting in a cube writing all day long. There are days I may spend the majority of my time writing, but that's generally not the case. I spend the majority of my time reading design documents, writing up UI-related bugs for the developers, playing with the software, then finally writing. In the 4+ years I've been at Seapine, and the ten or so years I've been a technical writer, I've never spent the day without interacting with at least one other person (unless I go to work on a Saturday just to get work done, ha ha). Verbal communication skills are just as important as written communication skills. Last thing, if you're interested in the job, tell me at the end of the interview AND send a thank you note. People don't realize how thank you notes and well-written cover letters set them apart from the pack. Baltimore/DC: There are lots of opportunities in the Baltimore/Washington, DC area, but the rates aren't what they used to be, even 6 months ago. Six months ago the rates seemed to be recovering, but the market was slow. Now the market is better, but the rates are less. Some of this could probably be attributed to being an election year, as a well as to the economy. When you live as close as I do to DC, the national news is your local news, those events affect the market more than you would expect. From my perspective, there is a new, enlarging world out here for communicators venturing outside of information technology, particularly those prepared to manage communication and documentation projects; develop training and marketing materials; manage, coordinate, and produce major proposals; coach presenters and help small businesses "get organized"; analyze material for audience appeal; etc. I agree with Judith, especially about marketing. I'm getting that work pretty easily. It's also expanding beyond marketing copy--I'm getting involved in business naming, developing tag lines, and other branding work. It's more stressful in some ways than instructional or tech writing, but it's also more fun, and the projects are short enough that they end before I get burned out. Cleveland: What we look for at RADCom, is someone who has: Business Sense Professional appearance and demeanor Common sense Excellent writing ability Ability to interview SMEs and gather information on the SME's terms Ability to learn quickly Knowledge of human factors issues and how to integrate it into their deliverables Knowledge of instructional design principles and how to integrate them into their deliverables What we do NOT want: Someone who is only good at writing Anyone who is introverted Someone who is so proud of being a great writer that it gets in the way of their job performance. (!) Someone who is technologically inept. Rochester NY: This can vary so much from person to person, but I've been seeing much more growth this year than over the last few years. Here are the main trends I've personally experienced: All of my work is coming from small to mid-sized companies rather than the big corporations. Most of my work is now in documenting procedures and not writing software manuals. I used to write s/w user guides almost exclusively, especially for mega-corps, so my work now is quite different. San Diego:&bnsp; I think you're going to get a variety of answers, depending on where in the country folks are located. For example, I know that the job market (no matter how you work) has still not recovered in northern California, but here in southern California things haven't changed all that much. That said, I'm still seeing a bigger emphasis on the types of tools used, rather than the technologies. I wish this would change, since it's ever so much easier to learn how to use, say RoboHelp, than it is to learn how to create a usable online help system. I've always been more than a one-trick pony, as I have a lot of marketing background. I've also done quite a bit of training stuff (in fact, just got a new contract yesterday to create training materials for a Web-based application). In the online documentation world, I'm seeing more and more people heading towards Web-based applications, and less and less still creating the older WinHelp. I'm seeing less and less emphasis on printed manuals, but still a requirement for PDF. More and more emphasis is heading towards single sourcing and CMS. HTML is giving way to XML. Of course, all of this varies depending on the industry (I primarily work within the software industry). Here in San Diego, we still have a lot of biomed and hardware companies, and those companies demand FrameMaker experts (ugh! 🙂 ) and less emphasis on help authoring. The primary tool here in San Diego is RoboHelp, although I've recently switched MY primary tool to AuthorIT (for it's single-sourcing and CMS aspects). St Louis, MO: The job situation for technical communicators in the St. Louis, Missouri area is bleak. Few companies are hiring either full time employees or contracting with us independents. Some chapters may have job opportunity listings that are open to the public (not password protected or restricted to members only). Students could search the chapters for information in various regions Dayton, OH: I have always focused on finding someone with (a) proven writing ability (not just school-related, and not just co-op or intern stuff) and (b) proven technical ability. By that I mean proof that the person can learn and use some technical skill--maybe a programming skill, network architecture, database design, web design, or even something like geology or agricultural science. Too many writing candidates are really technical lightweights. I can improve writing skill, but I can't instill a technical mindset where there is none. Software skill simply isn't enough to show technical acumen. I expect people to know their own limitations (not the cliche "I'm a perfectionist"). In other words, I expect them to know what they don't know and admit it. I expect a mini-barrage of questions about the work environment, type of workload, and so on. On the flip side, I expect them to show knowledge of my company - beyond what they'll find in our website. If they don't have any questions for me, or if they ask only about self-serving things (benefits, vacation), they're almost certainly out. I expect a professionally written (and edited) cover letter and resume. The cover letter needs to follow a standard letter format -- to a tee. If I ask them questions about their writing samples, they better be able to answer them intelligently--showing me that they learned from the technical content they wrote about. If I ask about some of the basics of tech writing (audience analysis, parallel structure, information mapping, online help), they need to answer intelligently.