Building a tech writing portfolio

February 9, 2007 8:59 AM

How do I build a technical writing portfolio when all of the docs I work on at my current company are proprietary information?

I have been working as a technical writer for my company for just over a year, and am very happy here. I'm continuing to learn, and have worked on some docs that I'm very happy with. However, it recently occurred to me that because almost everything I work on is confidential, that should I ever want or need to look for a new position, I have almost no professional samples to show for myself. How can I work on remedying this?

How can I find some work to do (I'd even do it for free under certain circumstances) to start developing a portfolio, so that no one has to take my word for what I can do?

I know typical advice is to find household objects and write instructions for them, but that seems more like a college assignment than something a tech writer with +1 year of experience should have.

posted by tastybrains to work & money (11 comments total)

consider doing documentation for an open source project. It's lots of extra work, but it's real and useful, and can be a great portfolio builder
posted by cosmicbandito at 9:21 AM on February 9, 2007

Open Source software is almost always in need of better documentation.
posted by Good Brain at 9:21 AM on February 9, 2007

I agree. When we interact so regularly with technology, using appliances as an example is a little lame. Keep one in your pocket though. You might seek work where you have to tell people how to manipulate tangible items.

You've got some options.

* Replace the proprietary and confidential details with fake information. Offer some introductory material, so that your potential employers don't think you're going bandy their confidential information about. And, of course, get permission from your current employer to use the material. Work for hire means they own it; you don't.

* You can carry hard copies of some documents to the interview and not leave them behind.

* There's more to technical writing than just the text. If you have a long document, you can present the outline or Table of Contents as an example of your abilities in chunking and outlining information.

* Model your non-confidential samples on the skills and standards you've already built.

* If you're interested in software documentation, document a tool you use that's poorly documented. The Web 2.0 world is filled with such items.

* Similarly, troll sites for people asking "How do I?" questions. Even ones that have been answered. This will give you an assignment to pursue.

* Document processes and show flow charts. Even non-work ones. For example, the process of choosing and enrolling in a bank account.
posted by nita at 9:28 AM on February 9, 2007

More ideas. Look back over Ask.Mefi in some tech related categories. Look for subjects where people repeatedly have similar questions. Look at the answers, track down the recommended software and process, and then write a comprehensive guide. Or perhaps you have a personal itch to scratch.

Problems that require multiple pieces of software to solve are likely to have an even bigger need for good documentation than those solvable by a single piece of software.
posted by Good Brain at 9:30 AM on February 9, 2007

I second Good Brain's suggestion. Search Ask or troll some software forums and look for common questions.

Often, you'll find questions that have been answered, but only poorly, with little detail or where the complete answer to the question is spread across multiple sources.

Do your research, find the authoritative answers and write a detailed FAQ entry or executive summary with a recommendation. There are plenty of questions out there looking for better-written, more complete and detailed answers.

You could even start a series of these answers and post them to your blog.
posted by syzygy at 10:10 AM on February 9, 2007

I forgot to say, that if you are only a year in the field, you should investigate two resources:

The Society for Technical Communication. They're a professional organization and require a membership fee to join. However, local chapters don't always require membership in order to show up to meetings and participate in discussions.

TechWhirl and technical writer's mailing list. It's fairly high volume. I recommend reading it with an email reader that has some good threading or conversation collapsing.
posted by nita at 10:44 AM on February 9, 2007

Thank you everyone for your great advice so far!

cosmic bandito & Good Brain: How would I go about becoming involved in documenting an Open Source project? That is the sort of thing I would love to do some work on, it seems like time very well spent.
posted by tastybrains at 11:11 AM on February 9, 2007

One way to get involved in an open source documentation project would be to mosey over to Sourceforge, find a project you are interested in, and contact the lead developers. I can't imagine there are many folks over there who wouldn't start slobbering with anticipation if an experience technical writer volunteered to help them with documentation.
posted by janell at 11:33 AM on February 9, 2007

I would have imagined that careful use of find/replace would be able to sufficiently obfuscate any proprietariness while still getting your writing ability across, no?
posted by juv3nal at 12:18 PM on February 9, 2007

juv3nal, I doubt it because my company's products are fairly unique and specific and the entire scope of the document describes their functionality. I'm also not in any position to want to jeopardize my job by trying to get away with changing a few words and passing it off as something I have the right to share with outside companies.
posted by tastybrains at 12:27 PM on February 9, 2007

Fair enough, I just thought it'd be pretty easy to legally bullet-proof yourself by replacing any noun (referring to a proprietary component) or domain-specific verb with foo/bar/baz/fee/fi/fo/fum. Done properly, it's hard to imagine how someone could determine what product/functionality was being described, even knowing beforehand which company the document came from.


It's debatable whether the quality of your work would still be apparent afterwards, though, which I suppose would defeat the purpose.
posted by juv3nal at 4:55 PM on February 9, 2007