Wednesday, December 16, 2009

Building a portfolio

This is the text version of my presentation at the STC India annual conference at Bangalore last week. It is a long post.


What is a portfolio? Let's see what the Compact Oxford English Dictionary has to say.
That's four meanings but for this blog post, we're interested in #2. Just like a set is a collection of well-defined objects, a portfolio is a collection of objects intended to show your ability in the field of technical communication. But why is a portfolio needed in the first place? Well, for one, because job ads ask for it.
A portfolio shows writing and editing capabilities, ability to create different document types, and experience with tools of the trade. A portfolio is your business card - it plays a large role in determining whether you get that interview call.

Now, the question is - why do you need to create one? Don't you already have a portfolio? Here are three questions that I've been asked often, and my response to those questions.
  • Can’t I use samples from my present workplace?
    Nope. We work for hire and the employer owns every piece of work that we produce in the course of our employment. Let's look at it from another angle: Let's for a moment assume you work in a car factory. You are on the shopfloor, along with your colleagues, building a car. When the car's ready for delivery, can you drive it away and park it in your garage, claiming because you built it, you own it?
    We cannot use any of the work that we do at our workplace anywhere outside your workplace unless our employer tells us to. Or, permits us to.
    Now, let’s face it – how many of us want to walk up to our manager and say, "May I use this Demo, that I created, as an item in my portfolio?"

  • If I remove all proprietary information from the pieces, can I use them?
    Nope. Think back to the car example. Assume that the car is factory-painted yellow and has a dancing fairy affixed on its bonnet. So, if you spray-paint the car green, and throw away the fairy, is the car yours? Not at all. Not only does it still belong to your employer, created at the employer's workplace using the employer's resources, it's now been tampered with without the employer's permission!

  • Can’t I send the URL of my blog as a sample of my writing?
    Heck! Since when did a blog become a sample of technical writing? Anyone can write. Even poets can write. Let's assume John Keats has a blog. Instead of writing something like this (the "desired" format)
    he would've written something like this:
  • When I have thoughts WordPerfect may cease to be I only have to press the CtrlF4 key And behold my docs high-piled in charactry Within Microsoft Word's own new domain Held like rich garners the full ripen'd grain That can be cut, copied, and pasted again Their shadows, with the magic hand of chance I only have at the Standard toolbar glance For selections to move on the page and dance Of the wide world I stand alone, and think All it takes is a DELETE key, and ding My words, all selected, to nothingness do sink
    So, no, your blog might not really contain the writing samples that a potential employer would like to look at.
So, what do you do? This:
  • Arm yourselves with the required resources
  • Create a portfolio of writing samples that are relevant to the technical communication field
  • Showcase the portfolio to prospective employers
Let's look at these three points one by one.

Arm yourselves
  • Learn how to write technical documents. Unless you know how to write, you cannot write that which is to be written.
    Learn how to write techdocs. About doing your research and gathering inputs. About what kind of information to include in your document and what information to leave out. Learn how to write in a structured manner. Learn about information chunking and how to categorise your material into conceptual, procedural, or reference documents and topics. Learn to visualise the kind of reader who would be reading your document and tailor your writing for that reader and that kind of audience. Become familiar with the basic documents that a technical writer is expected to work with, and learn about what goes into those documents – the purpose of those documents, the structure, the content. Before you actually begin to write, learn how to write.
    Then, write. Review what you've written, correct your errors, write some more. And, get someone else to critique your writing. What should you be writing on? We'll come to that in a moment but in the meantime, use pen and paper and write (many companies administer their impromptu writing tests on pen and paper. Even today.)
  • Get ourselves a writer’s toolkit. See this list of free-to-download-and-free-to-use tools I've used myself. After you've made yourself a workbench with these – or similar – tools, familiarise yourself with them. You don't need to learn every feature and every little detail. It is sufficient if you know what all the tool can be used for, and if you know how to use it to do what you want to do.
    After learning the tool, go back to your pen and paper writing samples, and redo them with these tools.
  • Work on some projects. See this list for suggestions on where to go looking for real-life projects outside your paid job. Why should you volunteer to be a technical writer for these projects? For one, it demonstrates your commitment to the profession, and your ability to work with teams that are geographically distributed. Also, it is a live, real-time, hands-on example of documenting a live, under-development project – and therefore, it demonstrates your ability to understand an application while it is still not complete, interact with coders and understand requirements and specifications, AND plan and deliver the kind of output that's best suited for the project.
Create a portfolio
Here are some suggestions of what can go into your portfolio.
  • A How-To procedure document
  • A specification, explaining how something should work
  • A quick-start guide
  • An installation guide
  • A reference book, like an API guide or a glossary
Reviewers like to see at least one example of an information type for a specific purpose and audience - for example, installation and administration guide, user guide, tutorials or learning material, multimedia. The tools you use for creating these samples is not important; what is important is how you analyze the needs of your audience and how you tailor your information to meet those needs.
If you are being interviewed for a junior level, do have a sample that has user instructions for a simple task.
If you are someone with a couple of years of experience, try to have a sample of an installation guide. In particular, a configuration guide.
If you’re someone who is more experienced, it might be a good idea to show that you can translate a use case document, SRS or FSD into user instructions. Your volunteer projects can contribute to all of the examples that I listed above. An appliance that you use at home lends itself very easily to a User manual. An activity that you taught someone in your family becomes material for a procedure topic or a tutorial. A roadblock when you were learning a tool can be turned into material for a troubleshooting guide or an FAQ. There are no limits, really. Just use your judgement and create the samples for your portfolio.

Showcase it
Now that you're ready with your portfolio, show it to the world.
  • Introduce each sample by giving some context. This is important because you would, in all probability, be showing an excerpt, not a complete piece. Mention the principles you used for creating the sample. This is important because they demonstrate your ability to figure out why you did what you did. Highlight some of the challenges you faced. State the constraints, and mention what could've been done to work around them or overcome them. Keep the introductions as short as possible.
  • Create a soft copy of your portfolio (burn it on a CD - not many employers are willing to risk using virus-philic pendrives) and carry it to your interview.
  • Constantly review, and add to your portfolio. Over time, weed out weaker samples. Samples should showcase the breadth of your experience and expertise. Like I mentioned earlier, for someone at a junior level, simple task topics are fine but as you gain experience, try tackling more complex topics and also other modes of delivering content. For a non-text example of Help, see this video.
You're now ready with your portfolio of samples.



    List of tools
  • Content authoring tools: OpenOffice Writer, GoogleDocs
  • Image manipulation tools: IrfanView, GIMP
  • Publishing tools: Microsoft HTML Help Workshop, HelpMaker Help Authoring Tool
  • back

    Pro bono projects
  • http://sourceforge.net/
  • http://contributing.openoffice.org/writing.html
  • http://www.gnu.org/doc/potentialauthors.html

  • Why a video sample? Because a large proportion of the population are visual learners.
  • back

 

9 comments:

Smita Anil said...

Hi,

I attended your session at STC and it was great. Thanks for all the helpful pointers.

Hoping to be in touch with you and learn a great deal more.

charleshurwitz said...

I've also used samples from projects that I have done from companies that went bankrupt (not because of poor technical writing)

Anindita said...

Smita: Thanks! I only recounted what I myself had done. Glad to be of help :)

Charles :)That's an interesting insight.

Vishnu said...

Why should a beginner or wannabee technical writer have a portfolio? A good English test can reveal whether a person is suited for the job or not.

I do not agree that blogs cannot be used to judge a person's writing ability. If a wannabee technical writer is a tech-savvy person, he or she can create a blog and post articles on it. Alternatively, the blog can be used to assess the writing quality of the candidate.

It is ridiculous to hint at a condition that all technical writers should have a portfolio. This is because technical writing has more to do with on the job training and learning, rather than simply carrying forward what you have learned in one company. The type of writing varies from domain to domain and from company to company.

There is nothing that 'special' in technical writing that requires a doctorate or a foreign university degree. If a person knows how to write well, have a liking for software, and willing to learn, then he or she can learn on the job and excel. Technical writing is not that 'complicated' or 'rocket science' as it is made out to be, except in certain domains. Wannabees, please do not get scared.

fishman said...

I think that the idea of not using work that you did for previous employers is ridiculous. Whether you own that work or not, you did it and it's proof of your abilities and experience. I'm not saying that you should upload the whole PDFs to your website but perhaps use a screenshot and case study of the work done. Providing the work isn't covered by a non-disclosure agreement, I see no problem with taking a copy along to a job interview for discussion. In my experience, if you ask for permission, employers are happy to allow this.

Anindita said...

Hi fishman,

Your mileage may vary but employers (read, managers) around these parts are usually the last person to know if a person is quitting for another job - they're never told by their reports they're quitting till the very last minute. A request like "May I show this as my work sample" will usually be met by hostile silence by a manager, and presumptions that the employee is looking for a job change.

This entire blogpost is from the perspective of a regular, full-time employee, not a freelancer - who is usually free to show samples of work from previous assignments.

Kamal Raj said...

Hi Anindita,

I find this post very helpful. Thank you for sharing this information.

Regards
Kamal

Anne said...

@Anindita,

This piece was just wow! I had so many questions about producing writing samples and I often took the path widely travelled, which was definitely wrong.

Thanks for all these tips. I need to start preparing my portfolio now :)

Anonymous said...

Hi,
I worked for a US company with a research and development facility here in New Zealand. We were "allowed" to use for our own purposes (eg portfolio) any piece of tech writing we wrote provided the application tied to the piece had been released. This is fair and gets around the issue of the employers rights especially applications still in development.
I enjoyed your site. Keep up the good work.