Getting Experience when you have none: Escaping the Catch-22

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++ literate software Technical Writers), they're even more impatient with candidates who aren't what they're looking for.

Synergistech can help, but not in the way you may be hoping. We probably can't get you work unless you already have the kind of technical experience and 'demonstrated aptitude' that our clients pay us to help them find. But we can put over two decades' 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, we're 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. After all, the first rule of technical writing is 'know your audience'.

Today's technical publications hiring manager is not in an enviable situation. More than likely, he or she is a "working manager," meaning that they don't just supervise people and attend meetings. They also write, edit, and produce content (a lot of it) just like their writers.

Most Silicon Valley technical publications managers started out as staff technical writers or editors in the same kinds of department that they now manage. They often carry the same workload as their lead individual contributors. And they are never trained how to manage people. (As Guy Kawasaki says, in Silicon Valley "management trainee" is an oxymoron.) Most of today's tech pubs managers learned how to manage 'on the job' with an employer who offered no support when things went 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 surreptitiously the day before GA. Their own management is always pressuring them to improve productivity and reduce costs, and unless they are gifted load-balancers, their staff gets increasingly frustrated, resentful, and tired. It takes a rare manager to survive (much less resist) these pressures; we know quite 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 jobseeker 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 Computer Science degree who will defend the engineers' right to do things their own way and whose top priority is ensuring that the doc is "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. (Synergistech advises individual contributors contemplating a 'promotion' to management not to stray from their current role for more than two years, because after that the only way up is out.)

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 hiring 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.) Given that most managers really do want to meet (and even beat) their own management's expectations, they need the help of demonstrably superior talent.

What's my real job?

As an entry-level jobseeker, 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 for $35/hr to produce a quickie web page for an important project. You're sifting through a dozen resumes from your favorite recruiters, 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 technical publications experience. One went to an Ivy League school and boasts a good GPA and membership in Phi Beta Kappa, 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 overachiever 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 communicate? 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 poet or a playwright 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 contribute frequently extends into seven figures while their delivery schedules are usually measured in weeks. If you were in their shoes, could you afford not to try to hire the people with the shortest learning curve?

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 the Communicators in Transition page of our Advice section, and especially the Learning what the Natives Know article, for 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 — know how to enter and edit text, work with variables and cross-references, build books, tables of contents (TOCs), and indices, import graphics, implement conditional text, design and fix templates, and export to Acrobat (PDF) and HTML. You'll get bonus points for understanding how and why to create structured documentation.

• C — understand its concepts and 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 — understand relational databases' concepts, purpose, architecture, and role in enterprise applications.

• XML — know what eXtensible Markup Language is and what it's good for. You'll get bonus points for knowing the difference between a 'valid' and a 'well-formed' document.

• Networking — understand Transmission Control Protocol/Internet Protocol (TCP/IP) and the concepts of Local and Wide Area Networks (LANs and WANs). Detailed knowledge of networking protocols is beneficial but seldom required.

• Online help — know how to organize content for, and produce, web-based online help using a tool such as RoboHELP or Doc-to-Help.

• OO programming — understand the concepts behind C++ or Java. If you can define a class, object, method, inheritance, polymorphism, abstraction, and polymorphism, you know enough to get started. You may never need to write code, but the ability to read it adds substantially to your marketability.

• HTML — know how to use Hypertext Markup Language, convert Word and FrameMaker files to it, and what it's good for.

• UNIX — know the differences between UNIX (now mostly Linux variants) and Windows, and be able to edit files in vi or emacs as well as create and navigate directories. Synergistech advises buying a third-party book on Linux that includes a CD-ROM of the operating system, installing it on your PC, and working your way through at least the first few chapters. If you wish to go to the next level in your technical pursuits, keep reading to learn your way around the C and C++ compilers. You won't break anything, and will likely boost your marketability by gaining a visceral understanding of what software developers actually do.

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, and so on

In this way, you can turn what some might see as weaknesses, or even liabilities, into valuable assets.

Practical suggestions for getting experience

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

1. Volunteer. Any chapter of the Society for Technical Communication (STC) can use your services on their newsletter, greeting (and getting to know) attendees at meetings, conducting surveys, even taking minutes at their board meetings. The more interaction you have with those who already do what 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 an invaluable source of experience. Internships are available through most of the Bay Area's academic programs in technical communication, and occasionally from hiring managers in forward-looking, well-run publications departments. Most companies find it hard to justify training someone from scratch when their own time is at a premium, but those that do benefit from being able directly to instill their processes and values as well as to bypass the bad habits that more-experienced communicators learn. IBM in particular is famous for training highly productive, respected technical communicators. Even if they don't hire you themselves after your internship, there'll likely be a bidding war for your services.

The local economy since 2000 has made it hard for inexperienced candidates without Computer Science degrees to start technical communications careers. For most, Synergistech's advice is that, if you find a company willing to train and pay you (typically $15-20/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, you should accept on the spot. To avoid being (grievously) exploited, ensure 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 portfolio samples and an industry reference or two, you'd best do whatever it takes (within reason). Why? Because over 90 percent of all internships turn into offers of staff employment.

There is a variation on the formal internship arrangement that may prove equally valuable to its participants. Specifically, a busy contract technical communicator can subcontract some activities to an aspiring one. Experienced Technical Writers who show up at (for example) STC meetings looking bleary-eyed and/or haggard are often putting in insane hours because their employer or client demands it; 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, new technical communicators 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.

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 to meet the deadline, not educate the newcomer. Contractors shouldn't get too optimistic that "anyone can do it," and subcontractors should ask for clarification whenever they're unclear on the next step. Even if the subcontractor is getting paid a lump sum, so mistakes don't add to the contractor's cost, the time wasted redoing something can have far-reaching consequences. Finally, the subcontractor probably won't get to meet the subject-matter experts (SMEs), use the company's product, or have a by-line on the deliverable, so this arrangement is inferior to a formal internship — but it's better than nothing.

3. Get online. Then educate yourself about current technologies and local companies you've heard about. Visit the job boards and subscribe to the local STC jobs list, find out who's hiring, and see which skills they're looking for in their future technical communicators.

Read the technical trade press to learn who's doing, saying, and thinking what. Don't subscribe to the paper version; that's bad for the environment. All the content you care about is on the web, and there's much less advertising to slow you down. Hunt for, bookmark, and stay current with the publications we've listed and any others you find insightful.

4. Create your own web site. Instead of simply exporting Word files to HMTL, Synergistech recommends using your browser's View Source feature to figure out how HTML tag pairs correlate with a given web page's look and feel. Buy a book or visit one of dozens of sites that offer to teach you for free. Too difficult? Are you sure you want to be in this business?

Publish your resume on this site and, when you have a portfolio, post it here too. Point potential employers and clients to it. That way you won't have to haul a laptop or 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. We call this 'neutering' the content. It is not acceptable to tell hiring managers that your former employer or client had an NDA that prevents you from proving that you can produce what they need.

5. Attend industry trade shows at Moscone, Santa Clara, and San Jose convention centers. These events are well-publicized in the technical trade press, and it's usually free to get on to the exhibit floor. Take the opportunity to talk face-to-face with people 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. Listen carefully as they answer their customers' questions. Ask them what they think of their company's documentation. Chances are they'll relay an anecdote about its problems — and that's your entrée to ask how it could be improved or even to offer your services to do the deed.

6. Edit some commercial-quality work. Get your hands on some documentation (preferably a manual for some complex software) that you think is of palpably poor quality. This part 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.

7. Rewrite part of an existing document. Even more impressive to hiring managers 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, but don't 'dumb it down.' To make the most of this exercise, 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 such as Tucows or Download.com. You'll find lots of categories of software that's free to download and use on a trial basis. Most programs here contain either no, or extremely incomplete and unprofessional, documentation. Improve upon what you find.

8. 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 prefer)
   • a piece of reference prose written for a technically 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 take you seriously and maybe even interview you in person.

So there you have it, our (highly opinionated) advice for entry-level technical communicators.

If you're a techie trying to get into technical writing, we hope these suggestions help you prove to hiring managers that you can create what they need. If you're a writer new to technical writing, we hope our suggestions help you convince pubs managers that you can understand their company's technology well enough to look like a defensible choice to the development team and produce high quality documentation to boot.

If, after following these suggestions and those elsewhere on our site, you could use some personalized advice about writing your resume, leveraging your experience, polishing your portfolio, and other aspects of your job search, consider Synergistech's career-coaching service.

Thanks for reading this far, and for telling others in your situation about our suggestions.

. . . . . .