Perspectives on a Career in Technical Writing: Responses from 16 Tech Comm Professionals

by Tom Johnson on Aug 30, 2010
categories: beginners • technical-writing

Students at Missouri State University asked me some questions about technical writing as a career. To provide a balance of opinion and perspective, I opened up the questions to my Twitter followers and asked them to respond as well.

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