Adobe Experience manager

Get new posts delivered straight to your inbox.

Subscriber count: 4,300

Stitcher radio

Search results

Adobe Experience manager

A Creative Way to Become a Technical Writer

Dec 30, 2009 • general

One of the tough paradoxes of the technical writing field is that you can't get a job without experience, but you can't get experience without a job. Or so it seems.

A reader recently wrote to me explaining how she decided to write manuals for her existing job as an account maintenance clerk, even though the task of writing documentation wasn't in her list of required duties. Doing so transformed her role. After learning more about her experience, I asked her to write a guest post, so here it is.

Post by Sarah Pruitt

Deciding to become a technical writer was easy. But finding the experience and the time has proven unforgiving. My job is not based on writing; in fact, writing is rarely needed. Between working full-time at a bank doing account maintenance (which is equivalent to data entry and entry-level coding) and going to school part-time in the evenings, I don't find much time to create writing samples for a portfolio.

Writing is based on critical thinking and organization, but how do you measure proficiency in brain activity? Most employers tend to measure it through experience, which they often view through writing samples that you submit to them. But by the time I get home at 9:00 pm, I'm burned out from the day, and any hope of writing is gone. I have even attempted a blog, but without a focus it jumped from creative writing to personal dilemmas to sporadic quotes.

In contrast, my place of work is where I spend the most time and where I probably have the most chance of getting experience. When I realized there was some documentation that needed to be written, I took the initiative and created it for my department. I produced a schedule for the work that needed to be processed by whom and when, and I made it the most detailed and organized as possible. Cheat sheets, logs, descriptions of duties, duty assignments, birthday announcements, and anything else that I could possibly add I produced, often without request, but always with review and approval.

Noting the need for a manual for our policies and procedures, I undertook another writing project, this one more massive.  The notes we had been using were old, outdated, and at odds with other notes -- a manual would be invaluable. So during my spare time at work, I conjured up a 100-page manual in a month and gave it to my manager for review.

My supervisors and fellow supervisors were impressed enough to allow me to write the manuals for seven other departments in our area. If this works out well, I may be documenting policies and procedures for my entire building full-time. Being at the bottom proved helpful because even though I bear the brunt of the work as an account maintenance clerk, I also have the right information to produce the documents.

Granted, my supervisors wanted a few things changed in the manual, such as some terminology and the table of contents, but the meat was there.  I demonstrated that I could organize and articulate information in a way that was valuable and useful to my company. I opened my work up to criticism and other feedback for the chance of improvement and reward.

I do not have the schooling of a technical writer (yet!) nor the experience, and there were probably a 101 ways to write the documents better. But I'm willing to learn, and the documents I've created, while showing that I have plenty of room for improvement, are  enough to help me get my foot in the door and transform my job towards the career I want.

You can follow Sarah Pruitt at

follow us in feedly

Get new posts delivered straight to your inbox.

Subscriber count: 4,300

About Tom Johnson

Tom Johnson

I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in simplifying complexity, API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.