Below are the “slides” for my presentation. I’m using WordPress rather than PowerPoint. You can actually click through the images just like you can with PowerPoint (once you are viewing the image details, click the image itself to move to the next one in the gallery). If you have any feedback about anything, let me know. I created these illustrations in Adobe Illustrator. I was actually going to insert them into PowerPoint, but I realized that when you view the PowerPoint show, it resizes the images and makes them a little blurry. Plus I’m weary of PowerPoint anyway and wanted to try something new.

Note: Several people have asked if they can use some of these images for their own slide presentations. Sure, feel free to do that. You can link back to my site with attribution if you want, but it’s not required.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

What is your job title?

Eileen Potter: Senior Product Content Specialist
(in June I changed positions within my company, previous title was Senior Technical Writer)

Richard Rabil, Jr.: Technical Writer III

Susan Gallagher: Senior Technical Editor (temp)

Leisa Ashbaugh : Tech Writer

Patty Blount: Senior Tech Writer

Tom Johnson: Senior technical writer

John Paz: Technical Writer (TechWriterNinja on Twitter)

Anindita Basu: Information Developer

Chris Ninkovich: Technical Document Specialist

Jullio Vazquez: Senior Information Architect

Kim Nylander: Technical Writer

Grant Hogarth: Technical Writer

Rachel Houghton: Senior Information Designer

Kirsty Taylor: Team Leader: Technical Writing

Daniel Pintilie: Technical Writer

Kartikeya Dwivedi- Senior Technical Writer

Where do you work?

Eileen Potter : Eden Prairie, MN (suburb of Minneapolis)

Richard Rabil, Jr.: Gaithersburg, MD

Susan W Gallagher: Qualcomm, San Diego CA

Leisa Ashbaugh : Vendor at Microsoft, Redmond WA

Patty Blount: CA Technologies, Islandia, NY

Tom Johnson: LDS Church, Riverton, UT

John Paz: Carley Corporation, Orlando, FL

Anindita Basu: IBM India

Chris Ninkovich: Burnaby, British Columbia (Canada)

Jullio Vazquez: SDI, Durham, NC

Kim Nylander: SAS, Cary, NC (contractor for Greene Resources)

Grant Hogarth: South Jordan, UT

Rachel Houghton: Beaverton, OR

Kirsty Taylor: Brisbane, Qld, Australia

Daniel Pintilie: Freelancer, Brussels, Belgium

Kartikeya Dwivedi- ibruk Consulting, India

What preparation did you have for your current job?

Eileen Potter: B.A. in Advertising & Public Relations, 9 years retail operations (both field and headquarters positions; provided a great education about business, business issues, and customer relations.) Laid-off and re-careered into technical writing. After the layoff, 13+ years technical communications (User Assistance materials, SharePoint Site Admin, technical white papers, sell sheets, and other marcom materials.),

Richard Rabil, Jr.: Bachelors degree in Professional Writing. During school, did lots of journalism and freelance writing projects, plus a professional editing internship. Also worked one year as a tech writing intern before joining my current company full time. Currently pursuing a masters in tech comm.

Susan W Gallagher: 25+ years of experience as a technical writer, technical editor, and department manager

Leisa Ashbaugh: 11+ years experience as tech writer (also write marketing and technical marketing web content)

Patty Blount: 7 years in tech comm, as a writer and a manager

Tom Johnson: a bachelors degree in English and a masters in creative writing; jobs as writer/editor, copywriter, writing teacher; a fluency with technology

John Paz: B.A. English, Tech Writing track. 4+ years as a tech writer, 2 as a contractor, 2 in the simulation and training industry. My mother is also an English professor (she’s been prepping me since birth).

Anindita Basu: 10 years as a finance executive, then a switch. Just like that. Was always interested in writing though, and even in the non-TW avatar, had gravitated towards writing process manuals and instructions booklets.

Chris Ninkovich: 10+ years experience writing business and marketing communications. I graduated from the British Columbia Institute of Technology with an Associates Certificate in Technical Writing. As a kid, I used to LOVE reading instruction manuals for toys, games, IKEA furniture. Maybe that helped!

Julio Vazquez: 20+ years in technical communications in IBM, over 10 years in computer operations/programming/support. AAS in Electrical Technology, BS in Computers and Information Systems. Worked in many aspects of information production processes.

Kim Nylander: BA English, writing emphasis. Background in desktop publishing, retail, editing, photography, and 3D imaging. Working on a help desk. Writing professionally since high school. Hardware, tech, gadgetry, and gaming are all hobbies.

Grant Hogarth: BA English/Tech Theatre, 12y construction, 12y Theatre, MA Rhetoric (OSU Columbus), MS Technical Communication (Rensselaer Polytech). 18y experience as a TW.

Rachel Houghton: BA English Language and Literature, minor in Professional & Technical Writing. 14 years experience as a TW.

Kirsty Taylor: Working as a technical writing project manager, and before that a technical writer with my company. Started a B INf Tech at university, then switched after two years to a BA in Linguistics and Business German. I mushed it all together to get into tech comm.

Daniel Pintilie: BA in English and French, MS in Computational Linguistics and 6+y experience as a TW and sometimes developer/tester.

Kartikeya Dwivedi: Am a techie. Was always into Writing, and decided to make it a full time love affair. Got a freelance Content Writing jig, took up a Software Documentation and a Creative Writing Course, one thing led to another, and I found my calling. It’s been more learning on the job though.

What preparation do you wish you would have had?

Eileen Potter: Would have been nice to have had a basic understanding of graphic design, typography, and how visual design elements impact usability. Of course, now I think it would be interesting to take some user interface/interaction design classes.

Richard Rabil, Jr.: I wish I pursued visual communication much sooner and developed multimedia skills like doing screencasts, web-based tutorials, and voice-over narration. Also wished I had more experience with help authoring tools and context-sensitive help.

Leisa Ashbaugh: the 11 years so far serves me pretty well. When I started, it was a dramatic career change. I did a 9 month professional certificate program for Technical Writing & Editing at the University of Washington, and was very happy for that.

Patty Blount: Wish I’d finished my MS in TechComm before RPI cancelled their distance program for that degree.

Tom Johnson: I wish I had pursued a masters in tech comm or digital media rather than creative writing. Actually, it would be nice to be an interaction designer as well, since they’re held in such high regard in our organization, and their skills (usability, user analysis) overlap with tech comm quite a bit.

John Paz: I had a lot of the writing skills I needed after my first two years in college. I wish I minored in Tech Writing and majored in a more technical field, some IT-related, mostly because that’s what where a lot of my interests are, and because it would have greatly increased my earning potential.

Anindita Basu: I wish I knew a bit about adult learning behaviour. That would help me create more engaging stuff.

Chris Ninkovich: More knowledge about XML, DITA, single-sourcing. All that cool and hip stuff the kids talk about in the tech writing playground.

Kim Nylander: A few classes in graphic design and information architecture would have been useful.

Grant Hogarth: Project scheduling and management, UI design theory, instructional design.

Rachel Houghton: I wish I had known the “current software” at the time I entered the field. My university only taught Desktop Publishing using Quark Xpress, so I had to learn Framemaker on the job, using Frame for Unix 4.0. I wish I’d had a business minor. For this job, I wish I’d had more accounting and/or construction background.

Kirsty Taylor: For my first job, more technical understanding of telephony an IPv6, but generally, I learnt what I needed on the job. Now: knowledge in management, leadership, internationalisation/translation, and perhaps an MBA.

Daniel Pintilie: I learned a lot by working as a TW but I wish I had more time to study programming and IT architecture, project management and usability design.

Kartikeya Dwivedi: Agree with Anindita. Human factors study would have helped. Also a course in Usability.

What is your favorite task at work? Why?

Eileen Potter: I love being creative enough to solve the immediate communication “symptom” facing someone yet analytical enough to step back and determine a longer term solution that solves the true communication “problem”/ business issue. For example, someone asks for a System Limitations document but when you talk to the people who need the info, you realize that the real solution is a searchable System Limitations wiki that let’s people understand limitations introduced by combinations of internal and external tools/applications depending on the version. So, in the short-term, you deliver the Sys Limits doc as requested but you get the discussion going re: the Sys Limits Wiki (or spark better ideas from the team.)

Richard Rabil, Jr.: I love knowing a subject well enough to write about it to others and see them “get it.” Also love teaching technology to others using multimedia such as web-based manuals, screencasts, and help content embedded in interfaces. It’s also great fun to combine writing with visual design and page layout — in this way, tech writing is a really creative, rewarding endeavor.

Susan W Gallagher: editing a document: I find it both relaxing and interesting work.

Leisa Ashbaugh: Editing and writing. I like learning new technical info that I would have never otherwise come in contact with. And, I like writing succinct and complete procedure steps, and snappy marketing copy too.

Patty Blount: new media. Love researching new things like wikis, social networks.

Tom Johnson: I like creating screencasts and interactive media content more than anything else. People get the most excited about these kinds of materials. There’s a presumption that almost anyone can write, but almost no one knows how to create audiovisual materials. Most users prefer video/screencasts over written text as well.

John Paz: I like to write, but the material I write about is bland. The most joy I get is interviewing subject matter experts and discussing what they do.

Anindita: Writing. Creating movies. It’s because I love to communicate and this is what lets me “talk”.

Chris Ninkovich: Communicating with my team members and sharing ideas. I love socializing with people, and tech writing allows you to do that (believe it or not).

Kim Nylander: Learning about complicated concepts and figuring out how to explain them in plain English with illustrations (as needed).

Grant Hogarth: indexing, editing

Rachel Houghton: my favorite part is to edit, but I also enjoy being challenged to learn something new, or being able to occasionally do something different. At one job, I did not just write the documentation, but assisted in Marketing because of my Creative Suite skills.

Kirsty Taylor: I like editing, but rarely have time for it. I feel so hands off now, to when I was an individual contributor, that any time I can get my fingers in our tools, I’m happy.

Daniel Pintilie: I love creating task-oriented topics explaining step by step the functionalities of a software and adding/editing the visuals.

Kartikeya Dwivedi- I love the diverse writing work I get to do out here at ibruk. One day it courseware dev, the next day it is process documentation. So the challenge of taking up a new subject/domain, analyzing client needs and delivering customized documentation solutions is the best part of my job.

What is your least favorite task at work? Why?

Eileen Potter: providing hours estimates, defining schedules, tracking hours, anything repetitious: it is time that takes me away from my real job and I know there has to be a faster way to do it. (I understand people are just trying to estimate/track the actual cost of developing a product but I still don’t like it.)

Richard Rabil, Jr.: Being asked to “fix” poorly designed or written documents at the last minute with little to no understanding of the audience, technology, or context. Being asked to write a great product without having access to the readers / end users, and extremely limited access to the SMEs. Having to write tedious status reports and track every single task accomplished during the day. Oftentimes, I don’t do any writing or editing on the product; it’s all research, planning, or interaction with others.

Susan W Gallagher: editing source code comments: working with ascii text is tedious at best. I seem to spend more time fiddling with line length than I do actually editing

Leisa Ashbaugh: tracking tasks in various bug tracking apps, and reading/editing metrics

Patty Blount: Making PDFs. Hate them.

Tom Johnson: I hate writing documentation that users don’t need. I sometimes have to do this out of business continuity purposes — someone feels it’s important that we have a manual about how a program works, even though everyone who uses the program already is familiar with it.

John Paz: I agree with Tom Johnson above; I cannot stand writing documentation that’s not needed. I need a job no matter what, but to spend 40+ hours a week developing crap people don’t need is demoralizing.

Anindita Basu: Project Management. I hate it (no particular reason)

Chris Ninkovich: I agree with Tom as well. Nothing depresses me more than writing a useless piece just to please some manager.

Kim Nylander: Being asked to help write a document and being asked not to change the writing style, layout, or online help entry style.

Grant Hogarth: writing the same document over and over. Being “edited” by someone who has no idea what they are doing, but relies on grammar-school prescriptions and what they may have heard from someone in some previous office.

Rachel Houghton: Conditional text. Hate it.

Kirsty Taylor: I don’t hate it, but I can find smoothing the relationships between my team and other teams/individuals or my team’s concerns over issues emotionally draining to deal with.

Daniel Pintilie: I don’t like to document bugs and proofread documents written by developers.

Kartikeya Dwivedi: Unnecessary and unproductive meetings at client sites.

What skills do you consider essential to your position?

Eileen Potter: I agree with Richard below. I would also add…curiosity about the product, curiosity about the user’s business and how the product helps them, comfortable asking questions and pursuing good answers, not just the answer you were given. Able to distill bits of information and understand how they come together to provide a better picture. The ability to differentiate between developer-speak [SME input, difficult to code, proud of their technical accomplishment] and the impact it may or may not have on what the user actually cares about [solving business issue: User Assistance output].

Richard Rabil, Jr.: Master writing and style as an art and a craft. Know how to create usable visual materials, how to integrate audio and images with the text, how to do information architecture, how to research the audience, how to collect and incorporate feedback, how to negotiate with other team members, how to learn technology or complex processes and explain them to others, and how to plan for writing / editing challenges that will emerge later.

Susan W Gallagher: language, curiosity, attention to detail, technical acumen

Leisa Ashbaugh: good people skills, quick understanding of new concepts, looking for the “missing info” and of course, good writing

Patty Blount: Besides good writing? The ability to understand the technology I document

Tom Johnson: The ability to write, to create visual material, to learn applications quickly, to interact with project team members, and the ability to work extended periods of time alone.

John Paz: Good writing, which can be learned/taught. But one skill I developed that’s crucial, and some people have difficultly developing, is organization. Keeping files, documents, contacts, due dates, start dates, and other vital information organized will make your life easier in every way, and makes your data invaluable to other people.

Anindita Basu: The ability to categorise info, the ability to prise info out of SMEs, and the ability to translate the info to whatever I am writing/creating.

Chris Ninkovich: Communicating with others, thinking logically, being able to learn new things quickly. Also, a love of technology is good to have, too.

Kim Nylander: Writing skill, definitely, and also a passion for what you are writing about. Be a diplomat, evaluate all sides of a doc project, and have a good “user hat.”

Grant Hogarth: Organization, active intelligence, a high tolerance for stupidity and corporate politics, being able to “think like the user”.

Rachel Houghton: Writing skill, time management, people “management,” the ability to see beyond just your role, and how tasks from others impact what you do (and when you deliver). Not being afraid of technology or using a new software tool.

Kirsty Taylor: time management, interpersonal relationship skills, good memory, decent technical understanding (I work will all development teams in our company), managing upwards.

Daniel Pintilie: Writing skills, time and project management abilities, easiness in communicating to the SMEs, translating the technical into plain simple language, editing images, etc.

Kartikeya Dwivedi: Flair for Writing, Interpersonal skills, Communication skills, Language skills and an ability to learn thing quickly.

What skills do you think are important for every technical communicator?

Eileen Potter: In addition to the list above, realize that a “tech comm career” is a moving target and you will always be a novice, intermediate, expert at something in the Tech Comm continuum. As a result, have a life-long passion to pursue the knowledge you need for a particular moment/project in time!

Richard Rabil, Jr.: Same as above.

Susan W Gallagher: language, curiosity, attention to detail, technical acumen

Leisa Ashbaugh: see above answer

Patty Blount: assertiveness to battle the “anyone can write” mentality, advocating for users, a solid grasp of grammar, the ability to learn new tools quickly, the desire to change as business needs evolve

Tom Johnson: Same as above. I think it’s important to position yourself in the organization as being more than just a writer. It can be very easy for project managers to pigeonhole you into a documentation-only kind of role, when really you can contribute so much more, such as interface text, workflow, video, e-learning, and more. Knowing how to lift yourself out of an organizational pigeonhole is an important skill.

John Paz: Attention to detail, for sure.

Anindita Basu: Curiosity

Chris Ninkovich: If you are going to work in the software industry, know some basic code languages. Know basic HTML. Figure out XML. Learn how to write “topics”, not manuals. Learn about educating adults. Never stop adding to your “skill tool-belt”. Be prepared to wear a lot of hats in your career as a technical communicator.

Kim Nylander: Attention to detail. Watch current and upcoming trends for new skills to add to your skills bucket.

Grant Hogarth: ability to abstract principles from concrete examples, think about how the documents are likely to be used by the reader, solid writing and editing skills.

Rachel Houghton: Same as above.

Kirsty Taylor: Good communication skills, interpersonal skills, and an inherent curiosity: we can’t always rely on someone writing that design doc or telling us what to find: we have to find it and document it.

Daniel Pintilie: Transforming the complex technical world into a familiar, clear and friendly environment for the user/reader meaning that a technical communicator thinks first about the audience and the best way to convey the technical information into readable and useful information for the target audience.

Kartikeya Dwivedi: The aforementioned skills, attention to detail (which kinda grows on to you in this field).

Do you use visuals in your work?

Eileen Potter: Yes, process flows, screenshots, PowerPoint SmartArt. One area I’m trying to improve upon is designing true infographics where the text, the visual, and the concept they communicate are tightly integrated.

Richard Rabil, Jr.: Frequently. I try to use screenshots, process diagrams, icons, colors, page layout, and other such visuals as much as possible. Effective use of white space is critical too. In my experience, people learn and/or “get it” more quickly when pictures are involved along with the writing–or in place of it.

Susan W Gallagher: sometimes

Leisa Ashbaugh: Not currently. But I do think they are so important. Wish I had more training/experience in that.

Patty Blount: yes, definitely. People have different learning styles so I try to address that in my work. I use Visio diagrams to explain concepts or show system architecture, screen shots to eliminate confusion. I recently created some YouTube videos to give users who won’t “RFTFM” another vehicle for learning product use.

Tom Johnson — Yes, visuals are critical. Visual material is the most effective type of learning material, in my experience.

John Paz: Oh yes. And that’s another favorite task of mine, learning how to use graphic tools.

Anindita Basu: Not in user manuals, where I try to avoid them as far as possible unless it’s a complicated task flow or an architecture that just cannot be explained through words. But yes, in movies (where I try to avoid text as far as possible).

Chris Ninkovich: All the time. So learn how to use PhotoShop and Illustrator (or have a graphic artist as a friend.)

Kim Nylander: Some times the most effective communication is a graphic and not text. Any graphic that helps the reader better understand the content is good. Gratuitous graphics are a waste of space.

Grant Hogarth: It depends on the document. Some benefit greatly, while in others it’s just eyecandy.

Rachel Houghton: For the first time in my life, I’m not doing visuals in my documentation. I wish I could, but the screenshots and visuals are only used in the training department materials, and the training department is a separate department from the information design

Kirsty Taylor: We have some flow charts, but we stopped using most screen shots a few years ago. Internationalisation and keeping on top of thousands of screens is a big challenge.

Daniel Pintilie: Yes. I use visuals whenever is necessary.

Kartikeya Dwivedi- As they say, a picture is worth a thousand words.

If so, how are these visuals generated?

Eileen Potter: Visio, Full Shot, Snagit, PowerPoint, MindManager, MS Paint (I’m with you John!), MS Clip Art online.

Richard Rabil, Jr.: Snagit, Visio, PowerPoint, Microsoft Expression.

Susan W Gallagher: by me, either in Visio or Illustrator

Patty Blount: Visio, Photoshop, Hypersnap, Captivate

Tom Johnson: Captivate, Visio, Photoshop, Snagit, Illustrator. It really depends on what you’re creating. Often you need more than just a screenshot. You need to illustrate a concept.That’s more difficult and require some creative and technical skills.

John Paz: MS Paint (stop laughing, it does the job), GIMP, Photoshop (rarely, prefer GIMP), Visio, PowerPoint, and even Word.

Anindita Basu: Hypersnap, Viewlet Builder for basic screenshot and for movies. If I need a task flow, an architecture diagram, or some such picture, we have a dedicated Graphics department to help us make cool pictures from the back-of-napkin diagrams that I can’t better.

Chris Ninkovich: SnagIt (for screenshots), Adobe Captivate (for training pieces), PhotoShop, Illustrator, Visio.

Kim Nylander: SnagIt, Pixelmator, Omni Graffle, Concept Draw

Grant Hogarth: Screen captures, Photoshop, Illustrator, Balsamiq Mockups, wireframes, and work either contracted fopr from a graphic artist or purchased from stock.

Rachel Houghton: In previous jobs, I used screen captures (SnagIt), Photoshop, Illustrator, and MS Visio.

Kirsty Taylor: Microsoft Visio.

Daniel Pintilie: SnagIt, Visio, Photoshop

Kartikeya Dwivedi- SnagIt, Visio, Paint.

About what percentage of your time on the job is spent on writing (as opposed to researching, training, etc.)?

Eileen Potter: Writing 30%, researching 15%, planning/ meetings 30%, UI Review 15%, travel 2%, black hole of email and other time-suckers 8%

Richard Rabil, Jr.: Writing 25%, researching 25%, planning and editing 25%, working with others 25%

Susan W Gallagher: 50%

Leisa Ashbaugh : Editing 30%, Writing 20%

Patty Blount: Actual writing, 25%. The rest is research, edits, and publishing

Tom Johnson: Writing, 10 percent. Research, 20 percent. Tools, 20 percent. Meetings, 20 percent. I don’t know where the remaining 30 percent goes.

John Paz: First off, lol at Tom Johnson’s answer. Writing: 20%, Research: 30%, Planning: 20%, Meetings: 10%, the other 20% is spent doing things that don’t matter, like filling in surveys on the job.

Anindita Basu: 50%

Chris Ninkovich: Writing: 10% Research and Planning: 60% Working with others: 20% Drinking massive amounts of coffee: 10%

Kim Nylander: Writing 25%; Editing 25%; Research, planning, collaborating: 50%

Grant Hogarth: Writing 55%, image creation/manipulation 25%, editing 10%, bug logging 10%

Rachel Houghton: Writing 50%; Project Management 20%; Research 20%; 10% collaboration.

Kirsty Taylor: 5-10%, and that’s probably project plans and reports, not the real guts.

Daniel Pintilie: 30%. The rest is research, planning and interviewing SMEs.

Kartikeya Dwivedi- 40% for a solo project. Would differ on multi person projects though

Approximately how much of your time is spent collaborating with others?

Eileen Potter: At least 30%

Richard Rabil, Jr.: About a quarter of my time. This includes working with SMEs, managers, and if possible the end users or readers.

Susan W Gallagher:: 10%

Leisa Ashbaugh: 20%

Patty Blount: We are shifting to Agile; about half of my day is spent with others now.

Tom Johnson: Probably 20 percent. I should collaborate more than I do, not just with other project members, but with users.

John Paz: not nearly enough. Less than 10%, almost exclusively during meetings.

Anindita Basu: the remaining 50%.

Chris Ninkovich: 20%

Kim Nylander: Probably 20% collaborating (with Research and planning taking up the other 30% mentioned above)

Grant Hogarth: very little at my current job — a lot at others.

Rachel Houghton: 10%

Kirsty Taylor: 75%

Daniel Pintilie: Depends on the project. Sometimes very much, sometimes rarely.

Kartikeya Dwivedi- A good 30 %

In what ways do you work with others (technicians, designers, developers, editors, users, technical illustrators, etc.)?

Eileen Potter: read project wikis from developers, share docs & meeting spaces via SharePoint, meet w/ internal SMEs (product managers, client consultants) for creating speaking abstracts and presentation materials, team members for editing and feedback. Marketing for more complex graphics. Email for more detailed q’s; use IM for quick bits of info; share desktop with people in global offices.

Richard Rabil, Jr.: Work with SMEs (such as developers, business analysts, CEO, managers) to get the “big picture” business goals, to brainstorm on how to convey a story or message, to get specifics on how a technology or process works, and to get feedback on accuracy, etc. Work with other writers and designers to craft the product. Work readers or end users to understand their needs and processes, and to get their feedback on initial drafts or prototypes.

Susan W Gallagher: work with developers to get information and have them perform technical reviews on completed material; occasionally collaborate with other writers.

Leisa Ashbaugh: Meetings with service management team, hallway conversations, technical reviews and questions via email

Patty Blount: Developers (email) to gain product understanding, product management for project planning information and product marketing to reach customers. We are only now starting to use collaboration tools like SharePoint and wikis to share information.

Tom Johnson: I work with these other roles on a regular basis. Interaction designers often need help with interface text. I often go to developers to ask questions about functionality. Quality assurance engineers are helpful to clarify bugs. And users are key to other kinds of information, such as the tasks they perform, the language they use, the kinds of help formats they need. I can outsource technical illustrations and editing to another department, but I often don’t do this because it takes too much time.

John Paz: Mostly to obtain data I can’t get myself. Or to have an expert proof something I researched. My manager has to proof my docs before they go to the customer, and my customer can sometimes reply back with suggested edits.

Anindita Basu: With the dev team (to get the most of the info coz they’re the SMEs), with the QA team (coz they catch bugs, come up with workarounds, and have slightly more “customer” focus than dev), with editors (for doc structure and language), with info architects (for doc organisation, to decide what kind of materials will be produced, to troubleshoot production issues), with managers (because they write our appraisals ), with other writers on the team (to generally toss ideas about, gossip, and share jokes no one else gets)

Kim Nylander: I work with system administrators to document the procedures specific to supported operating systems and hardware. This material is then organized and presented on the group’s wiki. I also edit/write documents and create illustrations for other groups as requested.

Grant Hogarth: interviewing SMEs, discussing bugs with QA, and trying to keep Project Managers apprised of what is going on. I’m the sole writer here.

Rachel Houghton: Attending release team meetings weekly, attending release deliverables (working with printer/customer delivery), I’m in an Agile environment, so my I have two team members within 10 feet (the other half of the team is remote). I provide information to the training department as I receive it about new features: there’s often a disconnect between engineering and training: I’m the bridge. I’ve been asked to review the text for clarity in new dialog boxes, and I’m invited to sit in on feature demos and development meetings.

Kirsty Taylor: Most of my work is with others: liaising with project managers, development managers, my team, development team members, product management. I’m working with them to ensure their content deliverables are being created, dates/scope is negotiated, translation requirements.

Daniel Pintilie: As a freelancer, I work mostly with SMEs and request information about the product and I take part in some testing.

Kartikeya Dwivedi- Do my own edits, illustrations and process flows. Developers are the SMEs, and my interactions with them are to understand the application and point out usability issues. Have been trying to get direct end user feedback, or get in personal touch but that’s a losing battle for now. In my current process documentation jig, I am arranging mock ups for processes and it is helping BIG time.

What are your major sources of complaint and satisfaction on the job?

Eileen Potter: Sources of complaint: tech writing deadlines never slip although the deadlines of all other depts do, thus TW is regularly compressed. Source of satisfaction: I like helping other writers or employees when they are struggling w/ tools or content; I’m currently enjoying writing across all product lines in my new position.

Richard Rabil, Jr.: Sources of complaint: Working over time, dealing with last-minute stressful projects, not really knowing how effective the final written or design product is, not being able to use the latest technologies (I wish I could use more graphics, audio, and interactive media), not given enough time to do quality writing and design. Sources of satisfaction: Using the written word to make a living, working with a great team of intelligent people, seeing when a written or designed product gets high approval, being acknowledged as a good writer whose opinion matters, and getting positive responses from readers.

Susan W Gallagher: Satisfaction is from interesting work and good people to work with. Only complaint is that there is sometimes not enough interaction with others on the team

Leisa Ashbaugh: satisfaction for me comes when others appreciate my work. A simple “thanks” makes my day. Complaint: crazy, broken systems for tracking complex work items.

Patty Blount: Complaint: I request reviews, get no feedback, release content and then get a flood of complaints that the guide is wrong. Satisfaction: When customers take the time to notify the company that the documentation helped them.

Tom Johnson: Major sources of complaint: loneliness, sedentary-ness, feeling that no one uses the documentation, being required to create old help formats rather than interactive media, underbudgeting from project managers (so I don’t have enough time to create good help), being excluded from the product creation process until near release or even post-release. Sources of satisfaction: Empowerment with tools, exploration of new media and forms of learning, interacting with project teams in IT environments, stable work with good pay, low-stress, freedom to innovate.

John Paz: Complaint: My work doesn’t matter and is excessive to requirements, I live in constant fear I’ll lose my job. Satisfaction: technical writing is projected to have 15-30% job growth over the next decade. Complaint: I rarely get to do any of the cool stuff I worked on during undergrad. Satisfaction: I get to learn new things all the time, I get to work under tight deadlines (otherwise I slack off), and I get to write for a living (invaluable).

Anindita Basu: Major source of complaint: UI changes, code changes much after “decided” freeze dates. Major satisfaction: Overhearing someone say, “Heh! It’s there in our docs. Just go to this page … and then ask me only if you still don’t understand”.

Kim Nylander: Complaint: Being told, “I don’t know why you bother. No one reads the manuals any way.” Sigh. Have had that attitude amongst coworkers at several past positions. Satisfaction: Getting an email saying “We have documentation for that now on the wiki…” or “Did you see this article…?” Having coworkers who come in and say “hey I had this idea for a document…”

Grant Hogarth: Satisfaction: hearing that a doc I wrote helped clinch a sale, knowing that I’ve done good work, even if others don’t really recognize it. Dissatisfaction, being treated as just an automated typewriter, one that has no idea of what might improve the product or process.

Rachel Houghton: Complaint: hearing the old “no one reads the manuals anyway”: when my help feedback system clearly shows that the users are accessing software help (and which version too). Satisfaction: currently, it’s knowing that I’m providing an extra value to the team and getting recognized for going above and beyond when necessary.

Kirsty Taylor: Complaint: Working with some of the negative aspects of significant downsizing over the past 18 months and trying to keep my team together and focussed, regardless of what might happen around us. And when dev managers try to tell me how to write doco/what standards to use. Satisfaction: I have a darn cool team who’ve made some great innovations in the past year or two: things that we’d been trying to get to for years with single sourcing. I love working with I18N and translation, it really complements my linguistic and German experience.

Daniel Pintilie: Complaint: Having to explain why I do my job and why is important because not all the people in IT business know, requesting feedback without answer and having no certainty that the deliverable complied. Satisfaction: working with different people, learning new things every day, interviewing interesting people often and sometimes a thank you that counts a lot.

Kartikeya Dwivedi- The grouse is to quantify our work and commercials, as out work is not something completely measurable. So, it is mostly a time taken and money asked complaint.

Satisfaction comes with finishing the project, and by going that extra mile for the client, give them more than they asked for. And yes, repeat business

photo by Valerie Everett

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

I have only a small quote at the end. In one of my responses about tools, I must have mumbled Camtasia in a way that sounded like Fantasia. (But I admit the latter sounds like a more fun tool to use.)

The article includes excellent research and information for breaking into technical writing.  For those looking to break into technical writing, I also have an entire section on my blog dedicated to this topic. Breaking into Technical Writing (as a Student or Transitioning from Another Career) lists more than a dozen links with information on how to transition into technical writing. If you have more to add to my list, please send me them.

As a side note, the DICE writer who interviewed me is interested in moving into technical writing himself. So if you know of a company near San Jose, California looking to hire a new technical writer with excellent writing skills, let me know and I’ll put you in contact with him.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Last week I gave a presentation to BYU Idaho students entitled 7 Steps to Getting a Job in Technical Writing. This is a recording of my presentation. You may remember a lengthy post I wrote on this same subject, 7 steps to getting a job in technical writing, as well.

Although getting a job is the focus of the podcast, I also talk about what technical writers do, how they approach a project, how they decide what to create, and how they generate ideas for tasks. Specifically, I talk about about a project people can work on at tech.lds.org. People can start writing help for the project here.

In listening to myself give this presentation, I realize that I have a breathless energy to my voice. As weird as it sounds, “breathing” while I’m presenting is something I’m working on. I don’t know if I need to simply pause and relax more, or if the mic is too sensitive and is picking up every tiny breathing sound and magnifying it. But if you have suggestions, please let me know. Also, you may hear typing noises in this podcast as well as the panel. That’s a student taking notes on a laptop.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Note: In a couple of weeks I’m giving a presentation to Brigham Young University Idaho students with this post’s topic (getting a job as a technical writer). My presentation is part of their annual professional writing conference. Oct 09 update: Here’s a recording of the presentation.

Last week on Twitter I asked my followers what advice they would give to students on finding a job in technical writing. Here are the responses:

plaindocs: Show that you are interested in learning about everything!

seeb: don’t know if i would advise students on a job on technical writing – would be technical communication..more encompassing!

floldun: Advice: emphasize what you can do for the company, and know what they need (read and ask around), instead of what you want.

AndreaJWenger: Students: identify your one greatest strength (writing, tools, tech, or whatever) and promote yourself as an expert. #techcomm

mleeuw: Networking gives job seekers the best chance of finding jobs with the proviso that one needs to be in the right location.

kirstyt: Network. Meet tech comm managers. Got both my gigs through meeting the mgr elsewhere/knowing other tech comm staff.

FeliciaRenee: Do as many internships as you can before graduating.

heidilhansen: A tip for students is to apply at Tyler Technologies, but seriously online portfolios w/samples is best & knowledge of TC field.

larry_kunz: One piece of advice for #techcommstudents: Always be curious, like a reporter or a detective.

altmilan: start by asking yourself “how do people get hired?”, and then asking yourself how one goes about finding this out.

jaycie622: Advice to students: Persevere! Keep putting out resumes and don’t give up hope.

Wordtree: Take an existing guide and rewrite it so you have something for your portfolio.

skry: I began tech writing via science journalism. Built a writing portfolio there. Offered to write software doc for coders.

All good advice on how to get a job. Some of the advice is reflected in my recommendations below. Here are my seven steps for college students to get a job in technical writing.

Step 1. Learn the Basics of Technical Writing

Before you can create a stunning portfolio or market yourself to companies as a technical writing intern, you need some grounding in the basics. If you’re in a college that offers a degree in technical writing (usually a degree in English with an emphasis in technical writing), by all means do it. If I were doing it over, I would actually double-major in English and graphic design, or English and computer science. Some students prefer to get domain knowledge, such as in accounting or engineering, and then supplement that knowledge with writing skills.

Whatever your situation, learn the basics of technical communication. For starters, learn how to write well. Learn grammar. Learn to analyze an audience, create personas, approach documentation from a task-oriented perspective. Learn to number your steps, keep your topic titles parallel, and be brief and concise. Learn to write useful instructions rather than obvious statements. Learn when to use screenshots and when to omit them. Learn the strengths and weaknesses of different help formats, such as wikis versus quick reference guides versus video tutorials. You can’t do anything without first grounding yourself in the fundamentals.

You may not learn all of these concepts in your program. If not, you can supplement your program with some instruction from professionals in the field. The Society for Technical Communication (STC) has an excellent certification course from well-known professionals. You can also read the Intercom and Technical Communication Journal. If you don’t have money to join the STC, connect with someone who is a member and ask to borrow back issues. Read blogs and books published by professionals in the field (here’s a list of foundation books). However you do it, get a solid education. This is critical before you can move forward.

Step 2. Get Real Experience Doing Technical Writing

The second step in getting a job in technical writing is to acquire some real world experience by actually doing technical writing. At many companies, employers want someone with experience because the employer plans to point you in the right direction and then let you work independently, rather than providing training. They want to be sure you can manage any situation, and if you don’t have experience in a corporate environment or know what you’re doing, employers may not trust your ability to get the job done.

During your summers as a student, volunteer as an intern at an IT company. Many times positions may not be advertised, but you can join your local STC chapter and ask other writers if they would accept some free labor from a volunteer for a few months.

If your professor assigns you to do documentation projects, see if you can find real projects at actual companies. Again, through your STC network or other contacts (such as through listservs or local companies), you can connect with professionals who can open opportunities for you to do real documentation.

Connecting with someone you know (or a chapter mentor) is the best route, because he or she can give you direction and feedback. However, you can also get real experience on your own. Many open source or community-based projects have need for documentation. Here are a few:

• Open Office
• LDS Tech
• WordPress
• GNU

When you work on one of these projects, you may find that it’s not a typical essay assignment. It will require several weeks of time before you can understand the application, determine an approach that will work with the audience, figure out the tools you’re using, and create a finished product.

Step # 3. Learn Some Tools

Tools are a major part of a technical writer’s world. You’re in charge of designing, laying out, and publishing all your content. Most employers want to you to know certain core tools, or at least to be tool savvy enough to learn their tools. Here are the four types of tools I recommend that you learn.

Learn a help authoring tool, such as Madcap Flare, Adobe RoboHelp, or Author-it. When you document a complex software application, you usually need a powerful help authoring tool to create an online help file. Of the three, RoboHelp is probably the easiest to learn, but there is no industry standard now.

Second, learn a page layout tool, such as Adobe InDesign, Microsoft Word, or Adobe Framemaker. I use page layout tools when I’m creating quick reference guides. Depending on your technical writing role, you may be creating pamphlets, brochures, newsletters, or short guides with a lot of design elements. The page layout tools give you a lot of control over the display, position, and layout of your text and images. (Okay, maybe not Microsoft Word, but you can do some page layout with it.)

Third, learn a graphics tool, such as SnagIt, Photoshop, or Illustrator. You’ll need a graphics tool to capture and modify screenshots, add arrows, or create diagrams showing concepts. SnagIt is the easiest to learn and will probably work for most situations. Try to learn SnagIt’s quick styles.

Finally, learn a video capture tool, such as Camtasia Studio or Adobe Captivate. Although video tutorials aren’t always common help deliverables, when you add this to your mix, you significantly expand what you can offer. Video tutorials are also how a large number of people learn software.

Technical writing positions aren’t always the same. You may be in a company that uses DITA, or one that has a content management system in which you author content, or a company that has some other method for authoring (perhaps they use Visio heavily). Even if you don’t know the exact tools the employer wants, if you have technical aptitude with a variety of tools, such as the ones I listed above, that aptitude may be enough to convince the employer you’re qualified.

To learn tools, go at a slow pace. Try learning them an hour a day over the course of several months. You don’t need to master the tools; just be somewhat familiar with them and be able to produce something using them.

Some students have asked whether they should substitute open source tools for the commercial tools (for example, Gimp instead of Photoshop) because open source tools are the only ones they can afford. I do not recommend this substitution. First of all, it takes a huge investment of time to learn some tools. Second, some employers are so bent on you knowing a particular tool, it’s not worth the risk to put so much effort into a tool they probably don’t use.

Step 4. Put Together a Portfolio

The portfolio is the most important work you can put together when looking for a job. A good portfolio can make up for years of experience. You can have 20 years of experience as a technical writer, but if your portfolio is uninteresting or doesn’t sell yourself, you won’t get the job. Conversely, if you have just 1 year of experience but have an impressive portfolio, you might have a better chance of getting the job.

There’s a reason that putting together a portfolio is step four. You can’t put together a good portfolio until you know a bit about technical writing. For example, if you just jump right into the portfolio and start creating samples that show a full screenshot with each step in a generic Microsoft Word document, your portfolio will be poor and will work against you. You need some theoretical grounding before you can create worthwhile documentation. You need real projects before they are convincing. And you need some knowledge of industry tools before you can create an attractive-looking design.

When putting together your portfolio, keep the following best practices in mind:

• Include 10-15 samples, covering a variety of formats and writing situations. For example, include quick reference guide, a user guide, online help file, video tutorial, newsletter article, release note, magazine article, and any other format you can think of (including some college essays, perhaps).
• Provide a web-based version of your portfolio. Employers may want you to leave the portfolio with them, and some may require you to submit the portfolio through email, so you’ll need a link to a website with a digital portfolio. I recommend a self-hosted WordPress site for this. See “Developing a Web-Based Portfolio” by Steven Kendus for more tips.
• Provide a brief paragraph introducing each work, the situation, purpose, and tool you used to create it.
• Make sure your portfolio samples are free of typos or grammar errors. The employer won’t be able to review the accuracy of your steps (which is probably the most important component of help). What’s left is to focus on the way it looks and reads. Make the layout professional. Clean up the writing so that it’s flawless and graceful.
• Include your transcript in your portfolio. Employers will be curious to learn what courses you’ve taken that qualify you to be a technical writer. Additionally, if you’ve done well in these courses, it will show your aptitude.

Most likely you won’t have a ton of writing samples. If you completed step 2 (“Get Real Experience Doing Technical Writing”), you’ll have a few samples you can show. But you probably need more. Here’s a great tip from Barbara Block in “Finding That First Job.” Can you document how to do your job? (You have a job, right? ) Are there concepts and tasks to master? Steps to perform for each of the tasks? Your current employer might appreciate this little handbook you create, and it can be a perfect addition to your portfolio.

When you go to an interview, always bring a portfolio of your work to leave with an employer. (Don’t expect to really get these back, by the way.) The employer will want to peruse your writing both before and after the interview. Know also that a portfolio provides perfect talking points during an interview.

When I was looking to break into technical writing, I brought a portfolio with about 15 samples to the interview. I later learned that it was an article I wrote about protein that impressed one of the interviewers (who had a PhD in biology). I also had a sample online help file that I created with RoboHelp as well. I beat out 5 other candidates without having any actual technical writing experience. Trust me — the portfolio is key.

Step 5. Start a Blog

Next to a strong portfolio, an engaging blog can also win over the hearts of your employers and get you a job. I cannot restrain my enthusiasm here when I talk about blogs, because in my experience, having a good blog can be your ace card that wins the game for you.

A few weeks ago, a friend of mine at another company interviewed several candidates for a position. He searched for information about the candidates online and was startled to find that almost none had an Internet presence. Zilch. It’s somewhat creepy, in this day and age, with Twitter, Facebook, blogs, and dozens of other social media sites, to find that someone is isolated from all of them, a stranger to the world wide web.

While there are various social media options, a constantly updated blog is the key one. Twitter can just be chatter, but your blog shows depth and engagement. A blog – focused on your profession – can showcase your creativity and knowledge. A blog brands you as an industry expert and reveals your awareness about the latest trends and topics in the field. Employers love to review blogs because it allows them to get to know you better. You’re no longer a piece of paper sitting in a stack of other pieces of paper. You’re a lively writer with an engaging mind and a bit of style.

Penelope Trunk, one of my favorite bloggers, writes a blog called the Brazen Careerist, centered on career advice. In her post, “Blogging essential for a good career,” she explains,

A blogger puts himself out in the world as someone who is interesting and engaging — just the type of person everyone wants to meet.

In another post, she writes,

The reason that people who blog have great careers is that bloggers are always thinking about issues in their industry.

She’s right. When I meet people at conferences, bloggers are always interesting. For example, I remember meeting Darren Barefoot, a prolific Canadian blogger, at Doc Train West a couple of years ago and thinking how smart and approachable he seemed.

Your blog will portray you as one always thinking about issues in the industry, one who keeps up with the latest trends. If your style is friendly and conversational, employers may also perceive you to be a good fit. These are key qualities that you want a company to think about you, and it rarely comes across in a resume.

Robert Scoble, practically a public figure on the web, explains:

Your blog is your resume. You need one and it needs to have 100 posts on it about what you want to be known for. (“If you are laid off, here’s how to socially network“)

Scoble recommends that you only blog about what you want to be known for, or the direction you hope to go. For example, if you want to drive cabs, let cabs be the dominant focus on your blog:

If you want to drive a cab, you better go out and take pictures of cabs. Think about cabs. Put suggestions for cabbies up. Interview cabbies. You better have a blog that is nothing but cabs. Cabs. Cabs. Cabs all the time.

There are about 20 reasons why blogs can help you in your job search. Recently a student in college wrote me to ask for advice on finding a job. Motivated by my blog, he had started a blog as well. I encouraged him to keep up with his blog. About two weeks later he wrote,

I was contacted a week ago by an IT company, World Wide Technology, Inc., and offered an intern position! Before the interview process, one of the managers took the time to look at my blog. He told me that he was impressed with what I was trying to do with it, and he found it interesting. We ended up talking for at least twenty minutes after the interview about communication-related concepts. It was the best interview of my life. Just earlier today I received a call, and I was offered the position! — Brian Kennedy

To recap: When employers read your blog, they start to perceive you as knowledgeable. When you have several posts a week, they perceive you as passionate. If you have an engaging writing style, you’re perceived as likeable. When employers google your name, your blog usually appears at the top of the list. Your blog helps you almost every step of the way.

Now, one warning about blogs. In order for blogs to make a positive impact, you have to steer clear of the following pitfalls:

• Don’t post inappropriate pictures of yourself
• Don’t express views contrary to your potential company’s views (for example, avoid incendiary political posts; actually, just avoid political posts)
• Keep your blog focused on the field of technical communication
• Avoid badmouthing previous or current employers
• Don’t use abbreviations such as gr8 for great or cu for see you.
• Don’t blog with sloppy grammar
• Don’t write excessively about your job search, because it tends to look a little pathetic.
• Don’t blog with the idea that no one will find what you’re writing

Always remember that blogs aren’t anonymous. Blog responsibly by exposing your full identity. Include your blog on your resume, right next to your contact information. Remember, your blog is an asset not a liability. You want it to promote it because it brands you as an expert.

Step 6. Move to a Tech Hub

You’re young. You’re almost out of college. Where are you going to live? If you want a job in technical writing, you probably need to live in a major city. Most technical writing jobs are located in places where there are IT companies. The more IT companies, the more technical writing jobs.

Indeed.com shows you trends for IT jobs by location.

Locations where the most IT jobs are posted

It’s no secret here. The top locations are New York, Atlanta, Chicago, Houston, D.C., Dallas, San Francisco, Boston, Austin, and Los Angeles — all major cities.

Last year, Doug Davis wrote an article about where the most technical writing jobs are. He identifies a similar list of cities:

San Jose, California ( Silicon Valley)
Boston, Massachusetts
Seattle, Washington
Washington, D.C.
Minneapolis/St. Paul, Minnesota
Chicago, Illinois
Atlanta, Georgia
Denver, Colorado
New York, New York
Houston, Texas
Dallas/Ft. Worth, Texas
Philadelphia, Pennsylvania
Portland, Oregon
Los Angeles/Anaheim, California
Raleigh/Durham/Chapel Hill, North Carolina (Research Triangle)

The most recent STC Salary survey database (from 2008) maps a geographic distribution of technical writers and finds the following:

The states with the most technical writers are California, Texas, Massachusetts, Virginia, Michigan and Maryland. Only Wyoming seems to have not reported technical writers.

Where the technical writing jobs are in the U.S.

According to U.S. News, the 10 best places for tech jobs are Atlanta, Boston, Houston, Huntsville Alabama, New York, Phoenix, San Diego, San Francisco, Seattle, and Washington D.C.

I recommend moving to a major city that appeals to you. If you’re really adventurous, you could even move to India. But seriously, location matters. I know that I’ll never live in a rural area such as Wyoming because there aren’t many technical writing jobs there, as beautiful as Wyoming is.

Moving to a new location, however, is harder than it looks. Rarely will a company hire you from afar. When I was living in Florida looking for a job in Utah, the remote location turned recruiters and employers off immediately. Fortunately my wife’s family is in Utah, so while I was vacationing in Utah, I interviewed for a handful of positions here. Then it wasn’t such a problem that I was currently residing in Florida, and a good company eventually offered me a job.

Note: If you think moving to a new city is difficult fresh out of college, try uprooting yourself with three kids and a mortgage payment on a house in a recessed economy. Also, forget about landing that contract position in another state and working remotely from home – it just doesn’t happen with entry-level writers.

However you manage to do it, go where the jobs are.

Step 7. Volunteer for a Position in the STC

If you really want to get serious about moving your career forward, volunteer to be president of your local STC chapter. When I did this at the Suncoast chapter, it did a few things for my career that I didn’t expect. First, it made me extremely visible. Suddenly I was the one making announcements on the listserv, greeting everyone at meetings, organizing and planning programs.

Second, being president also put me in contact with more than a dozen professionals in the area who befriended me and gave me good advice. I’m thinking especially of my friendships with Mark Hanigan, Pam Treme, Mark Lewis, Karen Bachman, Becky Siebenthaler, Kelly Schrank, and about a dozen other people who I got to know precisely because of my participation in the STC.

The STC won’t necessarily find you a job, but it will put you in contact with professionals in your area who can let you know about open positions, recommend you, and give you advice about companies and career paths. Probably the greatest value of the STC, above all else, is the networking/friendship aspect. Not just networking with other professionals, but with professionals in your area.

To get involved in the STC, don’t just show up and ask if anyone knows of any jobs, and then leave when you find out there aren’t any. This happened more than a dozen times while I was Suncoast president. If you do this, your involvement in the STC will backfire. It’s through service that you build relationships. And those relationships are what guide you toward fruitful paths in your career.

Conclusion

To recap the seven steps:

• Step 1. Learn the Basics of Technical Writing.
• Step 2. Get Real Experience Doing Technical Writing
• Step # 3. Learn Some Tools
• Step 4. Put Together a Portfolio
• Step 5. Start a Blog
• Step 6. Move to a Tech Hub
• Step 7. Volunteer for a Position in the STC

You can’t accomplish any of these steps overnight. But if you’re an ambitious student, with a couple of years left in your program, you can line things up so that when you graduate, you aren’t sitting at your parent’s house without a job. Instead, you’ll be working away at your first job as a technical writer, engaged in a new project, learning new tools, interacting with colleagues, and blogging about it every night.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree