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:

We hear you saying "Duh!" Strangely enough, not every aspiring Technical Writer can (or even wants to) do these things. Trust us here — we've met a lot of them. Most quite innocently take the "just give me the chance, and I'll prove myself" stance.

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):

Knowing FrameMaker and any two of the other skills listed above will usually be sufficient to get you started.

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:

Re-cast your work experience in terms of technical communications skills. This not only demonstrates your qualifications, but also that you understand the requirements of the job for which you're applying and have given some thought to accomplishing the crossover.

For example, you could discuss:

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.
  1. 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.
  1. 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.
  1. 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?
  1. 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.
  1. 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.
  1. 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.
  1. 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)

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.