Making Your Living as a Technical Writer (AWP Career Services Web Series)

Hi, I’m Woody Lewis. Today we’ll talk about making your
living as a technical writer. I’ve been a digital media producer, applications developer, and solutions
architect, working at Cisco Systems, IBM, Yahoo, and Stanford University. Most recently I worked at Time Inc., on a team that included technical
writers using the latest tools. As it turns out, I wrote an article in September 2005 for the AWP Career Advice article
series, called “Technical writing: Growth Industry
for Sharp Minds.” At the time, we were at a first phase of
transition from the traditional model of this
business. The reaction to this new process produced an
evolution of approach to job-seeking. I personally experienced this. Technical writing covers a lot of ground. The Society for
Technical Communication defines it as communicating about
technical or specialized topics communicating through technology or
providing instructions about how to do something regardless of the task’s technical nature. Why technical writing? Today’s technology
encapsulates a series of narratives. Creative writers make good storytellers.
A significant portion of technical documentation is anecdotal. It’s an industry in thrall to its
practitioners. That last set just gets mangled in many traditional technical shops. Open-source
frameworks emphasize publicly available information
requiring more writers to communicate that information. Financial security is a big reason that shouldn’t go overlooked for
creative writers considering technical writing. Given the entry-level salaries for
academic jobs these days, technical writing offers a measure of financial security and also opportunities
for advancement. Many industries hire technical writers– high-tech of course, specifically
software companies and companies called vendors that sell
platforms to corporations; financial institutions; medical and healthcare organizations; manufacturing companies; general
businesses; academic institutions; and nonprofit
organizations. A creative writer brings strengths to technical writing,
specifically a sense of craft. We really can’t overlook the importance
of the discipline we acquired in our an MFA programs because it’s not
a universal trait. We have a sense of narrative and
a sense of unity, knowing the whole that results from
assembling the pieces of a narrative. We have patience, and we have imagination. The ability to visualize is not
widespread. There are challenges that we face as
creative writers when considering a career technical
writing. The culture is different. Both the traditional culture involving
development teams working on large projects, either software-related or product-related, and the so-called agile process, which we’ll discover later, can rely on new talents that you wouldn’t expect to have in a writing career. Another
challenge is the narrow focus that sometimes exists in a very intense
technical project rendered by a team that does not have a widespread view of life. There can also be
an ad hoc process where the organizational details change
from day to day. And I think most important– a measure of technical fluency, which is
not as imposing as it might sound. The idea that one person knows
everything is an idea whose time has come. Even
the most accomplished developer or programmer cannot know
everything these days. But I think the challenge a creative
writer faces is knowing where to start in acquiring technical knowledge.
Generally, the way to succeed in technical writing
depends on certain attributes. Personality cannot be
overemphasized. I think the idea of an independent creative writer working in solitude, as
we all like to do, is somewhat antithetical to the idea of a writer working on a team. Yes, there is technical proclivity, which is important not so much for
specific technical details, but for the idea that you are
receptive to technical ideas and you have somewhat of a technical orientation– not, again, a technical background with
an engineering degree per se, although those that have that background
might have an advantage, but a receptivity to technical ideas. Being a subject matter expert is
definitely an advantage. There are a lot of companies that look
for people with specific experience in financial services, in healthcare, and academic areas, and I think cultural flexibility also, not in the sense of diverse cultures per
se, but the culture of technology in general
really does not exist in parallel with many of the academic cultures we’re
accustomed to. Finally, knowledge of tools I think is important, although this is also a moving target.
There are so many new tools being produced every month that above all the knowledge of currency of these tools is
most important. Entry-level salaries for technical
writers probably look very attractive to people
considering academic careers. These are numbers from, which is one of several widespread trackers of financial information for entry-level salaries. We see that for a
person with zero to two years experience, there is a curve that on the low end touches what might be considered a high-level
academic salary number, I think, going up to a medium level for many corporate jobs, and then tailing off
on the high end to, I think, some very generous salaries. These
are jobs that typically do not require much management, and I think this is
important also for someone first starting out in technical writing because a creative
writer really might not be a manager unless the idea of being an editor is driving
the decision. Certainly there are editors in technical writing, but I think the
idea that an entry-level writer really is going to be taking instruction from a manager who might
also function as an editor. Salaries for experienced technical
writers are clearly higher, and they’re really on par with salaries for a certain class of
actual programs for application developers. Typically in this case there is a
certain degree of managerial responsibility, although the experienced technical
writer might be reporting to a manager or unit head, but the idea
of working on a team and using a broader base of experience than entry-level certainly factors into the
higher salary. One example job listing on LinkedIn from a financial institution shows the importance of making that
cultural adjustment. The idea that you’re going to be
creating and managing technical end user and regulatory
documentation alone shows the different facets of
this type of job. Technical documentation is different than regulatory documentation,
and financial institutions especially, along with health care institutions,
require writing that covers this whole range of subject matter. We see mention of agile and waterfall
development environments. We’ll cover those shortly. But the whole
idea is that these are differing development
environments that represent that transition from
traditional that I mentioned earlier. This particular position shows five years’ experience as a requirement.
Certainly that’s always flexible–I think the idea that the business itself is going to know the individual
they think will succeed. And here we also see mention of tools such as Microsoft
Office, SharePoint, and others. I’m going to
recommend familiarity with several broadly-based
tools in widespread usage. There is no way to
know all the tools that you might encounter I think being familiar with those tools and
certainly doing research before any interview or
conversation is important. Another example listing also from LinkedIn, from a technical company, shows, under qualifications, knowledge
of HTML, CSS, and JS. Now these acronyms are part of the framework that any technical writer will encounter.
HTML is familiar to most of us, and the actual use of HTML is really not the essential requirement
here, but knowledge of that and how it interacts with CSS, or cascading style sheets, and JS or
JavaScript. Again, this is not to imply that these
are skills that need to be fully built out
by the technical writer, but there are things that really make it easier to produce the documentation,
and I think the idea that HTML is something we all know or at least
might have encountered should give us some comfort and
certainly the idea that the other frameworks, such as
JavaScript, really are these days more prevalent as descriptors of what’s
happening in the technical process, and certainly the idea to communicate
with programs when necessary to learn how specific pieces of code or, you know, programming languages might be used
is essential. Again, though, I think at the bottom of
this job listing, the idea that the ideal
personality has an open, positive, can-do attitude–
that sounds a little hokey to someone who’s
used to creative writing, but it really is a case
of going with the flow and understanding that the
organizational culture–and we’ll talk about culture later– has a large part to do with success. The
enterprise we define, for the sake of technical writing, as
any organization, whether it’s a corporation, an academic
institution, or a nonprofit organization, that produces
a product or service. Within that enterprise, we define three
areas of functionality: development, which is the actual software development or programming process, which
we break down in traditional and agile; product; and marketing
communication. Traditional development was known by some as the systems
development life cycle, or software development life cycle by
others today. The so-called waterfall model of sequential design began with
requirement specification, design implementation (or what we call coding), testing, installation, and maintenance. The
waterfall metaphor has to do with the flow from one portion of the process to
another in an orderly fashion. Traditional development bears in mind the user’s manual that we
all know and love, and producing that manual involves
studying the product during and after development cycle, interviewing the constituency that
produces the product– the developers, the product managers, the
marketers–writing and editing drafts, using desktop applications to integrate
content and layout, and finally delivering the product for
physical and digital distribution. In the old days, meaning about ten or
fifteen years ago, technical writers used a program
called FrameMaker to actually produce print-ready
documents for user manuals. These are the kinds of user manuals that we’re used to seeing,
in this case user guides for hardware, which really points out the idea that
technical writing can relate to specific products and not just software. Taken to the
extreme, these user manuals require a large measure of layout expertise, some which will actually come from
designers or artists on the project, but this is really a more traditional
example of what we used to encounter. Certainly
it still exists, and there are jobs that imply an awareness of this
kind of format, but the more prevalent jobs today are not focused on this type of output.
The agile development process began with something called the Manifesto for
Software Development. In February 2001, a group of well-respected application developers and solutions
architects in Silicon Valley created a statement in response to a number of issues arising in engagements
large and small on various projects. Their statement that the traditional element of processes and
tools was less important than the idea of
individuals and interactions–less important than
working software. Certainly comprehensive documentation
was important, but the idea that the end goal was to
produce software in collaboration with the customer as
opposed to the traditional idea of build it and they’ll come, which was a
function of contract negotiation. The agile process involves responding
to change, which is antithetical to the idea of
following a plan in sequential fashion with little or no flexibility for change. As such, the
interaction between technical writers and developers became that much more important. The
developer discovers and builds out feature sets, or the different pieces of functionality.
Today, a technical writer working in an agile
framework is expected to build out epics to describe the interaction with
those feature sets. Within those epics, the writers expected
to develop stories that show the breakdown of the feature
sets into components that fit a developer delivery schedule. That schedule is broken up into periods called
scrums, which facilitate actual development team activities called sprints, and these are
tracked along a delivery schedule that drives developers
towards the goal. Adapting to change is another important
part of the agile development process, as
opposed to reacting to change. That’s very important and, again, a
feature of the personality needed to become a successful creative
writer in a technical writing field. The interaction between technical
writers and product managers is also very important. Product managers
deliver the high-level feature design that technical writers incorporate into a product design document. The feature
details, the actual workings of any particular
piece of functionality, are recorded in a technical design
document and also in wireframes that are produced by the UX or user
experience staff on a development team. Wireframes are documents that show the skeletal
structure of any particular webpage or interface component of a product. The annotations relate to specific areas of the
interface or webpage where there might be a question about how
the web developer or application developer builds that
functionality. In this case, annotations are very important because they comprise a blueprint for application development. Marketing
communication is the last piece of this framework involving interaction between technical
writers and staff. The marketing staff produces features according to a priority of
perceived customer demand. Technical writers on occasion are called on to produce user-friendly
ad copy, perhaps in conjunction with an ad agency.
In addition, online help copy–not just the Frequently
Asked Questions or FAQs on websites, but detailed user-friendly instructions to support the ad copy are essential. And
then finally, that Marketing communication content
sometimes is revised as a result of contract negotiation or
managerial decisions. But again, this is another element of flexibility in the idea of technical writing. There is a publishing ecosystem at work in technical writing. Ecosystem itself is a buzzword you’ll
find and you’ll hear a lot– so again, the need to adapt to that
culture. Project management tools, generally
speaking, are broken down into collaborative and issue tracking and code revision or document revision systems–in this case,
Confluence, Jira, and Github. Content management
systems facilitate what we call workflow or the
structured writing and editing of documents in a context of collaborative team
activity. Confluence is a standard wiki-based platform that facilitates communication among members of the team. You can see
the different dashboards and user-directed functional areas that
allow collaborative publication to a central
space and controlled workflow. In this case, Confluence can track a project that might result in the end product of a separate
free-standing document or a document on a webpage or series of
webpages, but the actual workflow itself, the
collaborative publishing, the editing, and the iterating through tasks resides in the Confluence web platform. Jira is what we call a project-tracking
war issue management platform, and what it does is present a framework to
identify specific issues, and in my experience this includes
topics or subjects that were open to revision, and then
tracking the progress of the writer to accomplish documenting
those different features. And this again is something that fits
into a managerial process that’s part of a culture of organizational team
play. Github is a version control system
that’s really become a standard for programmers
as well as some technical writers. It’s an online
resource that allows users to upload different versions of documents,
including the actual files containing programming code as they’re rendered and as they’re revised. As such, there’s a way to control
versions and also to do what we call branching and
tagging–creating different, not just edited versions but flows within a document. This is not
something that technical writers will use as much as application developers, but
certainly awareness of this tool will be part of any successful approach to a technical writing job opportunity. WordPress is probably the most popular content
management system. It’s in widespread use by individual
bloggers as well as teams. In 2009, I wrote five pieces for the technology
blog Mashable, which is in widespread use today, read by a lot of people, and I was part of
a team of dozens writers using the WordPress platform. It’s got a fairly intuitive interface, and you really can configure the extent
to which any user has control over editing, copying, and revising. Drupal is the most popular open-source content management system with extended
functionality. By that I mean that it’s got a number of different modules. In fact, they number into the thousands, produced by open-source developers. These are
developers that contribute their work to a common platform, and the modules can
be used for all sorts of customizable workflow and to extend functionality in a website. The interface
is not as intuitive, and there’s a whole cottage industry
around documenting Drupal functionality
workflow, but it’s definitely something to know
about, if only on a first degree of familiarity. A
strategy to win, I think, is most important in looking for
a job in technical writing. Prepare your knowledge, taking what you
learn in this presentation, in your reading from day to day, and what
you hear from people that are in the business or
groups that get together to meet. There are meetups.
There are a number of organizations in many cities where just the chance to be in a room
and hear technical writers talk is really valuable. Preparing online
samples of your work, I think, is essential. Even if you’re starting out and you’re
doing something on the basis of a theoretical piece of technical writing, it’s important
to have that online presence. Branding yourself by creating a blog, whether it’s on Tumblr, your own blog,
or on the site, it’s essential to have that because
people need to see that you’re part of the framework that you want to
describe and document. And it’s all about promoting yourself.
This might not be an easy concept for the typical creative writer who
might be accustomed to solitary effort, or the solitary writer that’s gone to
social media but still doesn’t have that tendency to
promote. That’s essential, in a very orderly
manner. And the idea of using sources of work to promote
yourself is most important. LinkedIn is something that’s discussed very frequently as far as
the pros and cons of using a job networking platform. Personally
I’ve really, since 2009, not used any other means or channel to procure all the full-time and contractual
work that I’ve done– I’ve received. There are other sites such as Indeed and that are good reference points for job
opportunities. But I think the idea that you need to go beyond the sources of job listings is also very important. Again, networking, even on Facebook, to the extent that you
encounter people that you know that, beyond that particular framework, can help you in your search. Internships. Certainly there are a number of other
organizations, particularly nonprofit organizations, that look to the idea of people breaking in, improving their talent and their output in a context in which they’re also
learning and helping the organization to learn and grow. Internships are always a good
way to break in. We had a couple of questions that came when we announced this
screencast. So I’ll just go through what we got from a couple
of people. The first set of questions involves what we all want to know
about getting into the field. “How would someone best position
themselves to enter the technical writing field?” Well, I think a summary of what we’ve
talked about so far is most relevant–really acquiring the
culture and the personality to go along with a reasonable learning process involving
the basic technical ideas, knowing what HTML is, knowing what JavaScript is, on a high level. I think
that’s a good way to not only out dilute the discomfort of hearing those terms, but also in
improving your skill set. “Is it about the writing or about
the tech or both? How technically involved does someone
need to be to succeed as a technical writer?” Well, again, this is an open-ended
question. I had the fortune of being an application developer as
well as a technical writer, so the relatively deep skill set I had was beneficial, but I
think the most important thing to say is that
it’s not essential to be that technically proficient.
You need to have some proclivity, as I said earlier, and attributes, but the idea is it’s about the absorption, which is to say that it’s about both the tech and
the writing, but more importantly it’s about the open-mindedness to approach tech in a
way that facilitates the writing. And this leads into the last question: “Do you find it difficult to move between
technical writing and creative writing, or is there a happy medium? Does the writing you do for work ever impact your creative output, and if
so how do you overcome that barrier?” Well, this is the large question. I’ve
been known to say that I go between the left brain and right
brain aspect in my writing all the time. And I
think the answer is that there’s really not a happy medium. I think it’s driven
by the various projects you might be involved in both on the technical side
and creative side. On any given day, technical writing or
application development might challenge my creative output. That’s a
very honest statement, and I overcome it by seeking balance in another part of my schedule. There’s really no other way around meeting
the short-term demands of a project deadline in either space, and I think the thing to
remember is that getting balance–and this is obvious to
some but not to everyone– is the key to making them both work.
Another question is: “I am graduating with an MFA from a
certain program in January. I would like to be a
technical writer in the finance sector, but I am a 56-year-old female with limited
work experience, outside of six years in banking and
part-time jobs. I am doing an internship with a
non-profit, writing the manual for their new software. How else can I get experience to break
into a completely new field at such a late age?” The answer to that is
that you are getting really good experience
now doing an internship with that nonprofit. As I mentioned, that’s a
traditional area– traditional in the sense that people now
working in the agile framework have been doing this for years. And certainly the idea that you’re
doing this today right now in my mind does not work against you; it works
for you. I would caution against thinking
about how late you are to the game. You know,
there’s no need to go into, at this point, the idea
that working in a field is a function of your
talent and your willingness to learn. What I would
specifically say as well– that your experience in banking would be
a possible foundation for financial writing, in a technical sense– that I would definitely inventory your
skills, modify your resume and LinkedIn presence if you have one–and I
think that would be essential to get one, because the other thing about the online
resources–this is extremely important– is that they are mined by recruiters looking for the use of certain
keywords. That’s something really important to
emphasize, is that everything today is online. If you’re not online in some way with at least a summary of
your talents and skills, if not an actual listing, then you’re not taking advantage of the
potential of the job market. So I think, to
summarize the answer to this question, you’re getting the experience right now. It’s not a new field because you can incorporate
what you’ve done If the banking you did during the six years was not the only specific functional thing–if
the part-time jobs revolved around one other industry–
certainly emphasize that as well, because the more bullet points you can
have on your resume and the more keywords you can have, the
more likely it is that you’ll get some positive feedback and actual
interest as far as jobs. Next year is a year for growth. The economy is
certainly poised to generally grow, and specifically technology and areas dependent on
technology have an even brighter future. I think
technical writing is something that every creative writer looking to do something outside of academia should
consider, and certainly it’s something that is going to grow in importance because
the area of technology itself is growing. There are more products. There are more applications and more
frameworks. And we need more talented writers to tell the story.
Thank you.

14 Replies to “Making Your Living as a Technical Writer (AWP Career Services Web Series)

  1. I have a 4 year degree in Technical writing but failed to get an entry level tech writer position. I am currently working as an editorial assistant and I have been working for 7 years. What must I do to get out of the job I am doing and get into a technical writing job?

  2. Thank you for your professional presentation. Well executed on my journey in becoming a 21 century, Technical Writer. At the tender age of 54!

  3. Great advice for beginners. I'm researching how to break into the field leaving creative writing for technical.Lots to learn but I'm on it! Again thanks!

  4. Thanks…
    An Excellent Presentation!
    Thanks… again.

    Learn, Grow, & Be Successful!
    Clg :)!

  5. Thank for this video. Good starting point for a 25 year old just graduated college student in silicon valley who is looking to start a career in technical writing.

  6. Awesome descriptions of how a creative writer can bring value to the technical and technology field. I am sold and want to break into the field! Thank you for making this video. Extremely helpful.

Leave a Reply

Your email address will not be published. Required fields are marked *