You're new to the business. You want to find work, but instead you're finding — to your intense frustration — that, as hungry as Bay Area employers are for experienced technical communicators (especially C++ and Java-literate software technical writers), they're even more impatient with candidates who aren't what they're looking for.

Well, Synergistech can help, but not in the way you may be hoping. I probably can't get you work unless you already have the kind of technical experience and 'demonstrated aptitude' that my clients pay me to help them find. But I can put over a decade's industry experience to work for you — for free — to make some suggestions about how to get yourself out of the Catch-22 of "No experience? Sorry, no job." (And after you've gotten that first job and held it for 18 months or so, I'm sure to be able to work with you to our mutual advantage.)

Understanding the hiring manager's perspective

Before we explore what to do to make you marketable, let's first look at things from the hiring manager's perspective.

Today's technical publications hiring manager is not in an enviable situation. More than likely, he or she is what's come to be called a "working manager," meaning that they don't just supervise people and attend meetings — they write, edit, and produce pages (a lot of them) just like their writers.

Most Silicon Valley technical publications managers started out as staff technical writers or editors in the same department that they now manage. They are often expected to continue to carry their full writing workload after they've been 'promoted,' and must learn how to manage 'on the job' because most local employers don't train new managers (or offer much support if things go wrong). Is it any wonder that few do it well?

Among the privileges of management is expanded responsibility. In practice, this means that it's the manager's fault if someone on their (more than likely overworked) team misses a milestone, goes over budget, or fails to document that nifty feature the developers added the day before the deadline. Their own management is always pressuring them to improve productivity and reduce costs, and their staff gets increasingly frustrated, resentful, and tired. It takes a rare manager to survive (much less resist) these pressures; we know more than a few who have ulcers.

If you're still unsympathetic, consider that the Bay Area's love affair with all things technical threatens publications managers' future just as much as it makes your life as a job seeker tougher. Engineering-centric Bay Area companies — the majority of them, in other words — seem only interested in hiring those candidates (including pubs managers) who are the technical peers of their product development counterparts. They won't hire 'mere' people-managers (smart adults who value individuality and understand the importance of cooperation and compromise) if they can instead hire a techie they can trust (someone with a CS degree who will defend the engineers' right to do things their own way and who'll just make sure the writers are "ready to ship when we are").

Okay, you say, but at least managers already have a job. True, but perhaps not for very long. To compound their problems, most can't return to the ranks of 'regular writers' because their skills are out of date — their tools knowledge is too weak, their product understanding too light — and their salary requirements are out of line, to say nothing of their motives being forever suspect in the eyes of their would-be future peers.

In case you're curious how they resolve this dilemma, many managers choose to leave their employers and try contracting, but others (often those with dependents) hang on and do their best to hire (or retain) the people who'll make them look good — frequently those they would have passed over a few years back for being "overqualified." They're scared, and with good reason.

So why precisely should I care about a pubs manager's problems?

Because it's your job to solve them. Not by providing managers with a new career path (!), but by making it possible for them to meet their current responsibilities without having a heart attack. To most managers, the gurney is not the reward they had in mind. In fact, most managers really do want to meet (and even beat) their own management's expectations.

What's my real job? Your job is to give the hiring manager convincing evidence of your ability to do the job, and specifically to demonstrate your ability — not just your willingness — to:

• learn about the company's products
• understand their audience's requirements and expectations
• master their documentation tools
• gather, analyze, organize, edit, and produce effective information
• cooperate, learn, and support whenever possible

Why 'Give me a Chance; I'll prove myself' seldom works

To see why this attitude seldom works in anyone's favor, let's reverse the roles for a moment. You're sitting behind the hiring manager's desk with orders from above to, say, bring someone aboard at $25/hr to produce a quickie web page for an important project. You're sifting through a dozen resumes from your favorite headhunters, knowing that at least ten of the candidates are more expensive than you can afford. You know you don't have the power to pay more (many managers don't), so you turn to the remaining two resumes.

Both candidates are junior writers with no commercial publications experience. One went to an Ivy League school and boasts a good GPA and a cell phone number, the other went to Podunk U. and majored in Art History. But the latter has a URL on her resume, and no typos either. You're intrigued. You fire up your web browser and look at her work. Humble, but clean. What's this, though? She's listed some references, people she says taught her HTML. She's also, you notice, volunteering as a copyeditor on her STC chapter's newsletter. So who ya gonna call, the one with the rich daddy or the woman with initiative and a demonstrated interest in doing what you need? And whose job is it to lose?

Does it make sense now that, unless you show some initiative to learn the kinds of skills hiring managers need, you don't have the right to complain that they won't take a chance on you. Put another way, if you've got the phrase book and the time to study, and you're not even trying to speak their language, is it any wonder that the natives are reluctant to learn yours? In the current context, can you understand how such an attitude can appear arrogant to someone who needs your services but fears being exploited?

From the hiring manager's point of view, technical communications in the Bay Area is much more technology-centric than it is communications-centric. Many managers assume, albeit often wrongly, that everyone can write. The reason they can justify to their management that you're worth more than, say, a computer-illiterate journalist is that they value your technical know-how and industry experience.

What do I really have to know?

Certainly the alphabet soup in many of Synergistech's job descriptions can be overwhelming. Just know that we are often asked to find some pretty rare specimens (who may not even exist at all), and that the budget for the teams to which these technical communicators will be contributing frequently extends into the seven-figure range. If you were in their shoes, could you afford not to try to hire the best and the most technical?

However, as a newcomer to the business, all you need do is take note of which skills reappear in the majority of our listings, and make it your business to learn as many of them as you can, preferably before you apply for a job. Refer to our tech writers' resources page for some suggestions on how and where you might do this.

When we're asked which technical skills can ensure a technical communicator's marketability with our clients, we often cite the following (in descending order of importance):

• FrameMaker (text entry, text editing, working with variables and cross-references, building books, TOC and index generation, importing graphics, implementing conditional text, designing/fixing templates, etc).
• UNIX (from a user's perspective — editing files in vi or emacs, creating and navigating directories, understanding its architecture). If you can't access UNIX from your Internet Service Provider — by logging in in 'shell' mode rather than PPP or SLIP mode, for example — you should consider downloading a telnet application for your operating system from a shareware site such as www.tucows.com or shareware.com, or buying a third-party book that includes a CD-ROM of Linux (a complete freeware implementation of UNIX that runs on any Windows PC). The latter solution assures you of usable documentation (!), and Linux includes both C and C++ compilers for those who wish to 'go to the next level' in their technical pursuits.
• C (an understanding of its structure as well as basic features. You usually won't need to write code, but you'll get extra points if you can read it and determine what the program is doing.)
• Databases (a conceptual understanding of relational databases, their purpose, architecture, and role in client/server systems)
• Networking (an understanding of TCP/IP and the concepts of Local and Wide Area Networks. Detailed networking protocol knowledge is beneficial but seldom required.)
• HTML (know how to use it, convert Word and FrameMaker files to it, and what it's good for)
• Windows online help (authoring tools include RoboHELP, Doc-to-Help, ForeHelp, and HDK)
• OO programming (a conceptual understanding of C++ or Java and object-oriented development systems, including inheritance, polymorphism, etc. Again, you probably won't have to write code, but the ability to read it is a significant advantage.)

Also, and very importantly, be aware of your "crossover skills" — those skills you already have that are relevant to technical commnications. You must be able to sell a hiring manager on the relevance of your prior work experience. Although not a substitute for knowledge of the audience (eg, developers) and/or subject matter (eg, computer software), technical communicators require significant non-technical skills such as the proven ability to:

• educate yourself about, and identify with, the interests of a specific audience
• gather information from busy or remote resources
• understand and communicate complex concepts clearly and concisely
• organize, write, edit, and update large, dynamic documents
• orchestrate reviews

For example, you could discuss:

• your experience writing an academic thesis in terms of managing a long-term documentation project
• a special research project you did in school or for a former employer in terms of interviewing and compiling information from preoccupied personnel and preparing it for diverse audiences with different goals
• teaching experience in terms of the insight it provided into the importance of understanding who the particular readers are every time you sit down to write something
• committee-based projects in terms of the insight they afforded into business needs - researching customer demographics, allocating scarce resources, defending decisions, etc.

Practical suggestions for getting experience

The rest of this page contains some practical suggestions for getting experience and creating a portfolio when you've never worked in the business.

1. Volunteer. An STC chapter — any STC chapter, anywhere — can surely use your services on their newsletter, greeting (and getting to know) their members at meetings, conducting surveys, even taking minutes at their board meetings. The more you can hang out with people who do the kind of work you want to do, the more you'll learn and the more opportunities you'll find to get started professionally. Plus, if you work on the newsletter, you'll have real pages for your portfolio and, more than likely, a colleague who'll be happy to act as a reference for you.
   
2. Get an internship. These are hard for companies to set up and most hiring managers who've never had an intern consider them more trouble than they're worth — "Why should I bother training someone from scratch when they're just going to go away again in 3-6 months?" — but they're an invaluable source of experience for you, the intern.

   
   If you find an employer willing to train and pay you (typically $10-15/hr) for up to 30 hours/week (more than that and the employer is required by California law to provide benefits, which gets pricey), doing anything related to technical communication, grab on tight with both hands. Of course, you don't want to be exploited; be sure that you'll be able to take a copy of a real documentation product (to which you contributed, of course) with you when you leave, and that you'll have at least one warm body (preferably with an impressive title) to use as a reference. In exchange for that, however, you'd best do whatever it takes (within reason). Why? Because over 90 percent of all internships turn into offers of staff employment.

   A variation on the formal internship arrangement that may prove equally valuable to its participants is for an aspiring tech writer to subcontract from a busy contractor. STC members who show up at meetings looking bleary-eyed and/or haggard are often putting in insane hours because their employer or client demands it, and they're very easily talked into giving up some of their workload to an eager (and presumably cheap and reliable) helper. In exchange for a little informal training and perhaps the use of their computer while they're sleeping off an all-nighter, many contractors with impossible deadlines can profit handsomely by offloading the more repetitive or boring of their responsibilities to someone else. In this way, aspiring technical writers get to contribute their existing skills quickly on a commercial project and get a reference out of the bargain as well. Pay rates range from zero to a modest lump sum for completing the work to the primary contractor's satisfaction within the deadline.

   You should also understand that Synergistech advises contractors not to expose themselves to too much risk, financially or otherwise, when dealing with subcontractors. It's impossible to anticipate the nature and number of potential complications, and the goal of the exercise is primarily to assist you. Don't get too optimistic that "anyone can do it," and do ask for clarification from the contractor whenever you're unclear on the next step. Even if you're getting paid a lump sum, so your mistakes don't add to the contractor's cost to engage you, the time wasted doing something that has to be redone can mean missing a deadline or damaging a reputation.
   

3. Beg, borrow, rent, or buy a computer, get online (free internet access), then:

• Browse the worldwide web. Check out the web sites of local companies you've heard about - see what they do, see if they're hiring, and see what skills they're looking for in their future technical communicators.
• Read the newsgroups, specifically the "ba.jobs" hierarchy. You'll see lots of recruiters demonstrating their cluelessness (how many ways, we wonder, are there to spell "FrameMaker" or "SQL"?), but you'll also see plenty of companies you've never heard of, all hoping to become tomorrow's Microsoft or Sun. Watch these folks - their technical requirements are a good bellwether of what everyone else will be asking for in six months.
• Read the trade press to learn who's doing, saying, and thinking what. Don't subscribe to the paper version; that's old-fashioned and bad for the environment. Now you can find all that information on the web, and there's much less advertising to slow you down. Hunt for, bookmark, and stay current with the major publications from such publishers as Ziff-Davis, IDG, and CMP, and with individual magazines such as ComputerWorld, ComputerUser, Red Herring, Wired, and any others you find insightful.
  We especially recommend a site maintained by the Applied Technologies Group from which you can download, for free, 70+ relatively impartial technology guides on a wide variety of important information systems topics, such as data warehousing, internet technology, document management, enterprise solutions, and data communications. Visit IT Papers, register, enter your user ID, then download the Adobe Acrobat versions of these detailed white papers by right-clicking on the link called "Download, View and Print in PDF format" and selecting "Save Link As". You can then open the original version of the document in Acrobat, and copy and paste it from there.
• Learn HTML. Step One: Find a web page. Step Two: Use your browser's View Source feature. Step Three: Figure out how the codes correlate with the functionality. Buy a book, if it helps, or visit one of dozens of sites on the web that offer to teach you for free. Step Four: Implement your own web page with your acquired knowledge. Too difficult? Are you sure you want to be in this business?
• When you have a portfolio, add your work to this web site and point your potential employers or clients to it. That way you won't have to haul a ton of paper everywhere you go to interview.
• If the work you'd like to show off was created for internal use or your former company or client fears for the security of their proprietary technology, make an online copy of your documentation and change enough of the key words to protect their interests, then ask their permission to include it in your portfolio.
• Subscribe to STC's job leads distribution service. Ask about your chapter's implementation at your next STC meeting; someone will be happy to help you out. When the listings arrive, read them, visit the employer's web site, and respond — quickly!
1. Attend industry trade shows at Moscone, Santa Clara, and San Jose convention centers - you'll find out about them from the trade-press publishers' sites. At these (mostly free) events, you'll get the chance to talk face-to-face with live humans who are involved (albeit usually as salesfolk) with a real company's products. Ask them for a demo, ask questions, and learn as much as you can. Hang around as they answer paying customers' questions. If you get up the nerve, you might even ask them what they think of their company's documentation. Chances are they'll wrinkle their nose and relay an anecdote about its problems — here's your entree to ask how it could be improved, or even to offer your services to improve it
2. Edit some 'commercial-quality' work. Get your hands on some documentation (preferably a complex software manual) that you think is of palpably poor quality — it should be easy to do! Take a particularly exceptionable chapter (no more than 5-7 pages), and mark it up ruthlessly in red or blue ink. If you have suggestions to make or clarifications to request, do so. Write clearly, because the result will be a sample of your copyediting (or, if you've transformed it sufficiently, your developmental editing) prowess. At an interview, present the hiring manager with the before and after versions, and let them be the judge.
3. Rewrite part of an existing document. Even more impressive to a prospective hiring manager is a rewritten version of an existing commercial document. Take the aforementioned 5-7 pager and rewrite it. The only constants between the original and your version should be the subject matter and the requirements of the document's audience; everything else is fair game. Improve, to the best of your ability, on the information's accuracy, clarity, appearance, and overall usefulness, without 'dumbing it down.' To take full advantage of this exercise, you should use a publishing tool that you might expect your future employer to use, such as FrameMaker.
   A good source of raw material for your editing and/or rewriting efforts is a shareware site, that is, one from which you can download, for free, trial or demo versions of commercial software utilities. The aforementioned www.tucows.com is an excellent example; you'll find lots of categories of utility software here, most of it simple to use and containing either no, or extremely incomplete and unprofessional, documentation. Improve upon what you find.
4. Develop a dummy portfolio. If you liked rewriting the chapter and found that using the publishing tools came easily, consider doing it for three separate kinds of documents, as follows:
   • a procedural or step-by-step series of instructions written for a non-technical audience, heavily illustrated with screenshots (which you can cut and paste from the original, if you like)
   • a piece of reference prose written for a sophisticated audience (eg, programmers) that 'drills down' into successively deeper layers of a complex product's functionality
   • a conceptual piece that provides an abstract or overview of a complex product or process, and ideally creates an analogy to help it all make sense to a non-subject matter expert (such as a company's purchasing manager, who knows what problems he or she needs the product to solve, but not how the software does it)

     
     You'll now have before-and-after samples for the three most common kinds of writing done in the Silicon Valley. In producing them, you'll have demonstrated:
     

   • a working knowledge of the required documentation tools
   • excellent (if not perfect) insight into the requirements of the audience
   • a substantial amount of initiative in even undertaking the project in the first place
   Assuming that you didn't actually make the prose worse than the version you started with, most hiring managers with whom we've dealt would be thrilled to interview you and may very well end up offering you an entry-level writer's position on the spot.

   

   So there you have it, my (highly opinionated) take on the market for entry-level writers.

   If you're a techie trying to get into Technical Writing, I hope these suggestions will help you prove to the hiring manager that you can write technical documentation. If you're a writer new to Technical Writing, I hope I've communicated how to prove to hiring managers that you're a) capable of understanding their company's technology, b) a defensible choice to the product development team, and c) actually able to create effective technical documentation.

   Thanks for your interest in working with Synergistech, and for telling others in your situation about this page's suggestions. I look forward to working with you when you are ready to get in touch.

   Main Menu       Career Development Corner