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 Roslanche.com.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the San Francisco Bay area of California. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.