Software technical writing is a dying career (but here’s what writers can do to stay in the software game)

By Jim Grey (about)

I had lunch recently with a fellow I worked for several years ago. He gave me my last job as a technical writer and my first job as a software tester. He’s currently leading product development at a different software company. “Times have changed,” he said. “I don’t have any technical writers anymore. These days, I want the UX to be good enough that documentation isn’t needed.”

A few days later I had a drink with another former boss. I managed testers and technical writers while I worked for him. Since then, he’s started his own consulting company. “Technical writing is dying off,” he said. “It’s all about clean, engaging UX now. I have talked to more than a hundred startup and small software companies as I’ve built my business. Almost none of them have technical writers, and almost all of them have UX designers.”

Wild
Smart tech writers see the writing on the wall.

It’s clear: companies are leaning into good user-interface design and stepping away from online Help systems and printed/PDF documentation.

It’s a relief. Nobody wants to have to read something to learn how to use a software product. When usage falls right to hand, users are happier and more likely to use the product more. Good UX really can reduce the documentation burden.

My last company had mighty good UI design. One technical writer worked for me, and she kept up with about ten developers. In past companies with lesser UIs, I needed one writer for every four or five developers. It took more words to explain those products’ cumbersome usage.

Admittedly, the latent technical writer in me wants to holler, “Users need instructions for even the best designed products!” Some interactions are incredibly hard to design well enough to forego usage instructions. And users will always need usage reminders for seldom-executed tasks.

But the writing is on the wall. If you’re not finding fewer technical writing job openings yet, you will soon. Fortunately, your skills transfer to other jobs in software development organizations. You will need to build some new skills for many of these jobs, but you might be able to land that first new job without them and build them as you work.

Tester or quality assurance engineer

Testers explore software systems looking for bugs. In some shops, they write and execute detailed test cases; in others, they explore based on high-level test charters. The goal is to report, usually by writing bug reports, on the level of quality the developers have delivered so that decisions can be made about when to ship.

Technical writers routinely find product bugs. At my last company, my lone writer routinely found really important bugs. The VP of Engineering even noticed: “She finds outstanding bugs,” he said. “It must be because she thinks like a user.”

When I shifted into testing 15 years ago, I designed my tests in much the same way I designed online help: by first asking what tasks users would perform in the system. Then I set about making sure those tasks worked. You can do this too. You’ll have plenty more to learn about testing, but this is a great place to start.

Existing skills you will use: Creating and articulating mental models of software systems. Exploring software to discover how it works. A basic understanding of how software is built and delivered. Writing.

But build these skills: Database skills, especially writing queries. Light coding or scripting, to help you automate tests. System administration, to help you better understand and manipulate the environments the software lives in. (Don’t be daunted. I’ve seen many writers surprise themselves when they quickly start to learn these things. It’s as if they soaked up technical abilities by osmosis, just by being around lots of people who have them.)

Product owner, product manager, or business analyst

All of these jobs involve understanding customer needs and translating them into user stories, specifications, or requirements that the developers and testers use to build software. They may involve building a vision for what a product needs to be to meet its market’s needs. These people usually work closely with developers and testers to make sure the vision is realized, and to resolve implementation challenges.

Existing skills you will use: Understanding of customer needs. Creating and articulating mental models of software systems (though, in this case, often systems that have not been built yet). Writing. A basic understanding of how software is built and delivered.

But build these skills: Negotiation, as you might need to manage expectations of customers, the development team, and sometimes even management. Estimation and project management, as you might have to participate in sizing work and projecting delivery dates.

Various UX roles

The UX field includes a number of jobs that, together, create the way the software works and feels for the user. Typical titles include UX Designer, Information Architect, Visual Designer, Interaction Designer, and Content Specialist. These roles involve work such as creating wireframes of screens, designing user workflows, performing usability testing of prototypes, interviewing users and sometimes even shadowing them as they work, writing field labels and error messages, and choosing typography.

This might seem like a real stretch for a technical writer. But my experience is that writers often have innate insight into bad UX: if it’s hard to write about, then it’s hard to use. I find that technical writers can often extemporaneously evaluate product usability and give very useful ideas on how to improve UX.

Existing skills you will use: Interviewing. Understanding of customer needs. Creating and articulating mental models of software systems. Writing.

But build these skills: This depends heavily on the role, but: Design, in general. Graphic design. Usability testing. Prototyping.

These jobs crackle with career growth. But if you’d rather stay true to writing, you can shift into marketing communications, instructional design, or even good old-fashioned business writing (policies and procedures, disaster recovery plans, and the like). My town’s biggest employer is a pharmaceutical manufacturer; lots of software writers here have shifted into validation writing, which is an FDA compliance activity. You might even be able to move into writing technology articles and books; I’ve done a little of that. And some software technical writing jobs will likely always remain in regulated industries, and on government contracts, and for highly technical products.

Nostalgia for my former technical-writing career makes this a sad passage for me. But I think this trend toward effective UX is better for the user, and gives writers good paths for growth.

Advertisements

73 thoughts on “Software technical writing is a dying career (but here’s what writers can do to stay in the software game)

  1. I suspect what is happening is more a rightsizing of technical writing than a dying off of technical writing. The reason is that – while some software apps will never need documentation, there are other products such as enterprise-scale applications and APIs that will need documentation for the foreseeable future.

    The present article, though, is very good. As a technical writer with 9 years’ experience, I have been charting out some of the career paths it outlines. I haven’t been worried about being downsized as much as I have been interested in moving ahead.

    Like

    1. Well, I hope you’ll excuse the blogger a little clickbaity titling of his post, Ryan. You’re probably right, Ryan: the profession is just shrinking to fit a new level of need.

      You’re wise to consider moving ahead, not because there’s anything wrong with tech writing but because there’s so much else a skilled, curious, and driven person can do. A bunch of years ago I ascended to a manager role for a tech-writing team, and realized I had hit a ceiling. I switched to QA after that.

      Amusingly, almost everywhere I’ve worked since as a manager or director of QA, I ended up managing the tech writers, too, because it pretty soon becomes apparent that I can.

      Like

      1. Ho ho! I am definitely not above a little clickbait. 🙂

        My first few years of tech writing were not my favorite. It was really when I got into freelance/contract work that I started getting quick exposure to lots of concepts, investing in learning new approaches, and so forth. With this, of course, came increased satisfaction. Now, with a broader skill set and more experience, I’m better able to drive my career rather than drift downstream. That, in itself, also adds to the enjoyment of the thing.

        What I really appreciated most in your post (did I just write that?) is the discussion of career directions. It’s very validating to me because that is pretty much the list of options that I’d jotted down in a Google Keep note somewhere. And the job move that I am about to make takes me into one of those paths and brings with it an attendant pay hike.

        So even if tech writing isn’t going anywhere, that doesn’t mean tech writers can’t. 🙂

        Like

        1. I think it comes down to how you see yourself. Like the railroads in the early 20th century, as trucking began to rise: they failed to recognize they were in the transportation business, not just the rail business. They didn’t adapt.

          Like

  2. I’m not convinced that good GUI can make documentation obsolete… That’s a receding horizon. As GUI advances to become more self-documenting, the complexity of applications will grow to outstrip that self-documenting effect. There will always be super-simple apps, sure. But innovation demands an increase in complexity.

    I think the nature of technical documentation is changing significantly. If I read, “The FOO button foos a bar. To foo a bar, click FOO” one more time, I might commit a violent crime. But there’s plenty to be discussed with new technologies. Plenty to do with context (HOW do I use this in MY situation), process (WHAT does this actualy do?), dependencies (WHAT do I need to make it work?), and so on.

    OTOH, I fully agree that the value a tech writer brings to the table has to do with more than producing pages. We do indeed need to redefine “technical writing” in ways that capture this value. I don’t mean that we need to invent yet another euphemistic job title (information architect, information engineer, user assistance specialist, etc. — Feh… The term “information architect” also makes me want to commit a violent crime). I mean that every technical writer needs to look hard at the situation and add value where it’s needed. So in that regard I completely agree with your post.

    Like

    1. Good UX really doesn’t obsolete documentation — but companies are choosing to do it anyway. And it pains me to say this, but I don’t think people want to read documentation anyway. I do everything I possibly can to avoid it, and I wrote it for 12 years!

      Perhaps agile methodologies provide a platform for tech writers to spread their wings, given agile’s “all skills on board this team” ideal. “I can do that” can come from any team member.

      Like

      1. Of course people don’t want to read docs. Nobody wakes up in the morning and says “I’m gonna read some cool Help today”. By that token, nobody wants to use software, either. People wake up and say, “I’m going to accomplish X” — if they need software to accomplish it, they use software. If they need to read docs to use the software, they read docs.

        Yes, we want to move as much information onto the surface of the product as possible. But some products are just too complex. If all we needed to do in life was manage To Do lists and read restaurant reviews, we probably wouldn’t have developed smart phones with these apps built into them. It’s all the complex stuff we do that has yielded technology to make the simple apps possible. So I just think it’s a mistake to base our thinking on the model of simple apps… It’s a siren song.

        Liked by 1 person

        1. Where I work now we use a performance-support tool that walks users through complex tasks, and occasional users through all tasks. I love that. It is just the right amount of “documentation.”

          Like

        2. Hi Jim… I just put together a way for a walk-through provided by a 3rd-party javascript lib to consume DITA tasks. So I can now create my documentation in DITA and the GUI can consume it directly. For our product I think we’re going to go all the way with this… Get tooltips, inline GUI text, expanding explanations, walk-throughs, and other content straight out of the DITA. Then we can link from that to MORE, which opens up a full-blown help client. And of course, we can put out a PDF of the same content.

          Like

  3. i am surprised to see ‘content strategy’ missing from the post, and in the comments. There are different content silos in an organization – marketing content, customer support content, technical content, and product UI content. All these combined are always a part of the larger content strategy of a business, regardless of its scale, size, and audience.

    Even for technical content, if we cannot measure its value and use for the business (ROI), it is useless. So, we are at a point to see convergence of content strategy, content marketing, customer service, and technical writing. There is no workaround but to accept it.

    Like

    1. I found that the various content silos in my last org kept overlapping a little, duplicating and wasting effort, and that an overarching content strategy would have clarified that and made us more efficient. Good thought.

      Like

  4. Sadly for consumers, the move to better UX is far from universal. That’s good news for technical writers, though. I certainly agree that technical writers have transferrable skills – that’s something we are talking about at TCUK 2015 (www.technicalcommunicationuk.com)

    Like

    1. Sure, I just logged into the paycheck portal for the company to which we outsource our payroll and holy cow what a nightmare UX that is. I still want tech writers to think about what they do in more abstract terms, to help them pivot into positions that let them grow in their career in ways that straight tech writing doesn’t allow.

      Like

  5. I never supposed anyone actually read the technical manuals I used to write, even while I was writing them.

    So I find it much more satisfying, now, to use more or less the same skills (or aptitudes, at least) to make a greater and more direct impact on the quality of the products I work on as a UXer.

    If anything, I think your article might underplay the extent to which tech writers can become great UXers. After all, tech writers and UXers do the same thing, in different ways – they both try to help users achieve their goals.

    The best UXers I’ve worked with all seem to have writing of some sort in their backgrounds. There may be some kind of personal bias effect at play there, but I do think the focus on user goals, the experience of understanding and distilling complicated concepts, the skills to describe them and the honed empathy and intuition needed to set up and manage a dialogue with an audience all transfer directly into the field of UX – where I think they can be more profitably applied.

    Even if they’re not forced into it, I wish more tech writers would make the move into UX.

    Like

    1. So I’m going to admit that I underplayed the UX side because I’m not as familiar with it. I know testing extremely well because that’s the path I’ve been on for 15 years now. That’s why testing got the most airplay! Maybe you could write a post about transitioning to UX for tech writers. That would be very valuable.

      Back in the 90s, I saw UX (which back then was just called “usability” or “user interface design”) as a career path for me and tried to move into it, but at least where I live the market just wasn’t ready for it and I couldn’t make it work. That’s a lot of why I ended up in QA.

      Like

      1. Interesting, I had the same problem mid-90s. Had to wait until UX became more of a ‘thing’.

        And, yeah, that post on moving from tech writing to UX is on my ever-growing list of blogs I must get round to writing.

        Like

  6. I actually think “tech writing” (in the most traditional sense of the word) is a part of UX. Definitely some transferrable skills there. While I agree that traditional tech writing is going the way of the dodo bird, I do believe technical writers can deliver content that is much more meaningful than a description of product UI or single-sourced help that’s a repeat of a manual.

    Targeting content to users’ goals and showing them how to use your products to achieve their goals is still important, whether that content is on the screen, in a book, or on a help window. Scenarios and workflows are a much more valuable form of technical content that go hand in hand with UX and product usability.

    Like

      1. Actually, where I work the opposite is the case. We see increased credibility for tech pubs, and increased reliance on the tech docs to clarify the message.

        Like

  7. I think that cool apps that go on your phone don’t need much documentation. Enterprise-level business software (I work for a company that produces medical billing software) still requires tons of documentation. Our biggest product has over 20,000 wiki topics. Beyond that, there is always the back end. I spend a lot of time on data dictionaries, and I know more than a few writers who make their living documenting APIs..

    Like

    1. Great point about API documentation. I hope a lot of that is automated though. That’s dreadful stuff to create from scratch. As for medical billing software, if 20k Wiki topics are needed to navigate that UI, I’d say that there are serious design problems with the UI. If most of those Wiki topics are about business process and procedure, then that makes more sense.

      Like

      1. Business processes are a big part of it. You have to remember as well that enterprise level software doesn’t turn on a dime. and that medical billing is heavily regulated. Just adapting to the affordable healthcare act, HIPAA requirements and the new ICD-10 billing codes, requires major efforts both in programming and documentation. Upgrading the UX comes secondary to making sure that federal compliance rules are met.

        Like

  8. I’m a hybrid writer who has moved between marketing, usability and straight tech. I’ve settled into a role that many companies are calling UX Writer. I’m attached to the UX Design team and solve for UI problems that can’t be solved through design- meaning, in some cases, a process or product may be so complex that it becomes impossible to solve exclusively with design. Through contextual help I can give the user what they need to understand where they are, what is required, and offer additional information that will allow them keep moving and successfully complete their task. I love my designers and have formed tight partnerships with them. They block their designs with space for me to offer my 2 cents at various stages throughout the project. I let them know they can come to me when they feel stuck or know that something can’t be solved with design. Then we pair up and discuss how we’ll divide and conquer the problem. I also collaborate with engineers and get clarification on product specs and intended behaviors, then produce the basic user help that is attached to our product. Check out some profiles on LinkedIn for people with the UX Writer title and see what they do.

    Like

    1. Thanks for this tip. Seems like you’re banking on your usability knowledge and filling gaps with words when design won’t cut it. Seems like a great thing to transition into.

      Like

  9. After 18 years in the tech writing business (with a BA in professional writing), I gave up. I became bitter and frustrated by the ridiculous deadlines, the “oh you can be my writer, webmaster, and artist” attitude, the lack of respect, and the horrible pay/upward mobility. I finally went back to get my MBA in marketing. We’ll see how it goes….

    Like

  10. 1. A lot the content is still there, it’s moved to a different place. If the content for assisting users moves into the UI, does it stop being help? Do developers become better at writing because it’s on the screen instead of on a Help page?

    A number of companies are making the technical communicators responsible of all of the words – those in the UI as well as the screen, so that they are written or checked with some skills in this area.

    2. The content is changing because the users, sales model and products are different to those of 30 years ago. Technical communicators need to adapt to those changes.

    3. They telling a developer “a well designed API doesn’t need documentation”, and “no-one reads API documentation”, just for fun :).

    Like

    1. YMMV, but my experience has been that professional writers are not used in UX writing. But even if it were, those are far fewer words than any Help system or big fat user manual I ever wrote.

      Others here have pointed out that developer-focused documentation, such as API documentation, remains a need; I agree.

      Like

  11. I live in Spain, where 1-2 years ago nobody knew what a Technical Writer was. The number of companies looking for technical writers is still low, but steadily increasing. I know because I routinely search for job opportunities in networks like LinkedIn. This career may be dying in some markets, but I do not see the same trend in continental Europe.

    Like

      1. The demand for IT professionals here has been high during the last 15 years. I’m not sure if it’s bigger now than then, but it’s very high indeed.

        I tend to think that IT companies in the Operations and Development businesses are realizing now that they need experts in UX, UI, and Technical Writing. In that aspect, we’re clearly behind countries like USA, Ireland or UK.

        Thanks for your post, it is always interesting to see other’s point of view.

        Like

    1. Hi Jorge.. I live in Spain also. In Gijon, actually. Are you a native English speaker? Anyway, what I almost always do is work for companies in the US. I’ve also found work programming authoring tools or XSLT.

      Like

  12. I’ve been hearing that tech writing is dying since I started in 1974 … and I’m still here doing better than ever.

    When the Macintosh add with the floating-down leaflet of “all you need to know to use a Mac” appeared on TV, my boss called me in and said that was what he wanted. I told him he couldn’t afford it because of all the work involved to create a better UX. That is still largely the truth. Many companies are not able to do the designing, testing, and development necessary to have an easy to use system

    Another big change is in the types of apps and the types of users we have today. Users are, by and large, more experienced today – to pick an obvious example, they know how to drag and drop with a mouse unlike their predecessors 25 years ago. They are used to apps that change overnight – when they see a new Gmail feature that didn’t exist yesterday appear without any information about it they can figure it out. The apps are, for most users, much smaller than they used to be. You used to get applications that did lots of things, now you get apps that do only one.

    I work for a company that builds the software that runs clinical trials – creating, setting up, testing, collecting, and reporting terabytes of data over 10+_years and thousands of subjects for just one study that costs upwards of a billion dollars.. Needless to say, the UI – which is in many instances one of the best designed I have encountered – is not intuitive and needs not only documentation but training to understand and use effectively. My company is not alone.

    So yes, tech writing isn’t the same as it used to be, It’s changing like it always has. But it’s a growing profession – the BLS is looking towards 10% annual growth in the need for tech writers. But we need more skills and use different tools than we did 20, 10, even 5 years ago. And my friend Rick Lippincott said “We explain things” and people still need things explained to them. I don’t see that changing.

    Like

    1. John, thank you for your thoughtful comment. You’ve added valuable perspective to this discussion. I believe my thesis is true largely in B2B software — companies that make software that large enterprises use to run their businesses — and in B2C software like the various social media sites. But there are clearly subdomains in which tech writing remains extremely relevant.

      Like

  13. I don’t know basis for this write-up. Software development is as much as a dying career given the numerous declarative frameworks available. Software testing is as much as a dying career given the intelligent automated testing tools available. But writing will always stay – because even the frameworks that describe declarative software development or the tools that automate tests need documentation!
    Technical writing or user documentation or user assistance will always be there. Although it has to be contended how many writers will the industry require in the coming years. There will never be robots that can write as well as humans. There can never be a perfect user experience that does not require human user assistance. Then there firmware, hardware, middleware – not just software. Then there are different sectors such as pharmaceuticals, law, healthcare, defense – all of them need product information. And by the way I am a software developer – a technical architect currently, former chief technology officer with a start up. I have worked for companies such as Intel, Maersk, Capgemini, and recently IBM.

    Like

    1. In the part of the country where I work, I have watched the tech writing jobs dwindle sharply. Where a team of 20 developers used to be supported by four or five writers, that’s shrunk to about one writer today.

      I am absolutely not seeing a reduction in software development jobs. There are far, far more of them in my area now than 20 years ago.

      I disagree that test automation has taken away tester jobs. At least, that’s not what I’m seeing. Where I’ve worked, automation only creates rote regression tests that largely were not being executed anyway.

      Like

      1. I agree that the engineer/writer ratio has changed dramatically. I don’t think that means tech writing as a career is dying. I think a big contributor is the death of paper. Pubs departments used to be gate keepers for the release schedule — Docs had to be complete about a month before ship, and that set the date for feature freeze. This is no longer true… If the docs are not embedded in the product, then you can publish AFTER product release. This dramatically lowers the cost of late documentation, which means you can safely raise the dev/writer ratio. That’s just one example — the point being that technology has CHANGED the tech writing career, but I’m not willing to say it has killed it.

        And a tech writer who CAN support 20/1 (and actually add value) can feel as sure about her job today as her analog did back in the days of 5/1. Possibly even MORE sure, because that writer is supporting even more people.

        And do the math… If there are 4x the dev jobs as there were 20 years ago, then there should not have been a net reduction in tech writing jobs, right?

        Like

        1. Pardon me for a somewhat clickbaity title to this post. Sure, there will always be some tech writing jobs. Past commenters have argued correctly that demand in some parts of the industry has not changed. But I don’t think that’s true in most of the industry, despite increased demand for developers. Where I live and work there are simply fewer tech writing jobs to be had despite explosive growth in software development. Many software shops simply have no tech writers at all, at least around here.

          Like

        2. My experience in NY and Silicon Valley is a bit different. As a tech writer, I have no problem finding work. And I have rarely been in a situation where everybody hates the tech writer. Maybe the industry is more vertical where you are, or maybe all the work is app dev within the enterprise??? With all due respect, I wonder if you’re over-generalizing?

          (Just because you say “With all due respect”, that doesn’t mean you can say whatever you want.

          With all due respect, yes it does!)

          Like

        3. Here’s the crazy thing. This blog is mostly about delivering software (project/program management, quality). Yet this off-topic post about tech writing is by far the most popular post here. It gets 80% of all views and has since the moment it went up more than a year ago. It’s the post that just won’t quit.

          I think it’s in part because of the clickbaity way I titled it, but also because I think it’s tapped into some angst in the industry over tech writing’s future, as relates to job availability.

          Absolutely, other parts of the country and other parts of the industry might be seeing different things. I do have some limitations and biases in my view, mostly around having spent my career in Indiana in software companies that make software for mostly large companies.

          Like

        4. Well, tech writing in general suffers angst. I think a lot of tech writers carry chips on their shoulders because they feel intimidated in a sea of engineers. They like to say they do something engineers can’t do… Communicate clearly. That’s hogwash of course, but they need to believe it.

          Another source of angst is largely in old-school management. Like I pointed out earlier, pubs used to be the gate keeper of the schedule. Not no more… But old-school managers still want to wield that kind of power… Hence deep angst.

          More… Tech writing is kind of low on the food chain. It doesn’t generate direct revenue. Unless an organization is committed to the improved experience docs CAN provide (sadly, not necessarily provide), then a tech writer always feels impending doom. If and when the axe must fall, it usually falls on pubs.

          I’m on a campaign to make sure writers get beyond all this, identify true VALUE they can add, and get to it. So whenever this topic pings me, I take a look…

          Yeah, it’s funny how much attention you got with this. A tech pubs blogger found it and pointed at it… The rest is history. And somehow, a year later, people still find it. Do you get paid per click? 🙂

          Like

  14. I am not sure with CUD’s comment on “Tech writing being low on the food-chain”. I am a prolific software developer. Even after years of trying, I cannot write a decent page explaining the workings of a design, architecture, component or whatever. Writing is a beautiful skill that people such as Jim Grey are trying to downplay. Jim Grey is all for testers and is stating that testing is a skill. I don’t consider testing to be a skill at all. I would rather hire a software developer, who can double up as a tester, with some extra pay. But can I hire a software developer or a tester who can double up as a writer? Yes and No. Most probably no. Because either you are a writer or you are not. I would rather hire talented writers who can visualize, have decent technical skills to explain my product. Great documentation has done wonders to the brand equity and recall of products of champion organizations such as Google, Microsoft, IBM, Yahoo!, Intel. Great documentation has also fostered customer confidence in the manufacturing industry. So for me testing is absolutely not a skill – it is more like a fill-in. Software development does not require a lot of skill (it requires practice). Technical writing demands in-born writing skills.

    Like

    1. If you think testing is not a skill, then you have never worked with a skilled tester. I have. It’s astonishing to see the bugs a really good tester will find. There is a mindset and a skillset that goes with testing that, in my experience, most developers don’t have.

      Additionally, I in no way downplay the importance of writing as a skill here. I was a professional tech writer for 12 years and know very well that this is a skill. And while there are born writers, many non-writers can learn it — I did.

      Like

    2. When I said TW is low on the food chain, I meant in terms of company bottom line. Face it, if you don’t have a product to document, then what good is the documentation? You could say that it isn’t a product UNTIL it’s documented, but you’d be in a minority. When the company starts up, tech writers are among the last to be hired — Where I currently work I contracted at approx 20 hours a month for two years before they agreed that there was enough to warrant full time. (I had to do much more than produce pages, I can tell you.) And tech writers are among the first to be laid off, should things get that drastic. This is just a fact of life.

      As for skills… There’s nothing more mysterious about writing text than there is about writing code, or testing code. These are all skills, largely centered on information management, even if they focus on different points of that spectrum. Writers aren’t born any more than programmers are, or public speakers are. You grow up with interests, and you develop them… or not. Some of us develop them enough to claim a professional level of skill. The range of information management that we happen to call software development is so great, we need division of labor. That doesn’t mean one category of skill is somehow superior to another.

      Like

  15. At the startup as a CTO, I found it difficult to hire a writer for a year. Because my requirement was a writer capable of design, instructional design skills. The product was complex, and needed really good visual-textual user assistance. Therefore, if people like you come up with non-researched content such as technical writing is dying, then this will only dissuade good technical writers, or the talented ones from picking up this profession. The industry needs them – and needs them badly.

    It will indirectly hurt product companies, and indirectly hurt the customer, and indirectly hurt the product’s brand recall, traction in the market. So support your claims with statistics. And testing is still as per me not a skill at all – simply because software development is not. I can vouch for the fact that all that software development requires is some extra knowledge, and practice. Software testing is really a very very very poor cousin of software development.

    And by the way, my co-founder previously was a technical writer turned software developer. He was a technical writer after his MS degree in the US for about 3-4 yrears before he went to Mexico and got involved in datawarehousing. He learnt business intelligence, and BI programming. He is now a prolific data engineer, but with a difference. His technical writing background allows him to be an excellent communicator. He has impressive imagination skills. And of course, he sniffs those bugs out with ease.

    Like

  16. Up until about a year ago I was mentoring technical writing students and workers who certainly did not feel their careers were over. Most of them were undertaking writing projects outside of anything software or system related. I had writers documenting the configuration of high tech medical equipment, processes behind engineering and military projects, legal writing, content blogging, business processes, and so on. In these roles the accuracy, clarity, brevity etc that all makes for excellent technical writing are still very relevant. It’s a shame that institutions suck as Sheffield Hallam University, who offered a very broad degree course, have closed their courses.

    Like

  17. Agreed, obviously. But career switching has its own challenges. I’ve got several testing certifications, but no testing jobs on my resume. I’ve got development experience and have written multiple books about programming, but no title of “developer” on my resume. That seems to be the main hurdle. I’m getting a software engineering M.S. so that I’ll have a piece of paper attesting to my competence as a developer. In the meantime, I’ve gone back to my career as a full-time author — but even book publishing, as we knew it, has gone away.

    Like

    1. Yes, the best bet frankly is to shift from TW to something else within a company you already work for. You are a known quantity within that company and you have the best shake at a new opportunity. That’s how I moved from TW to QA: Dave at M2M knew what I was made of and gave me a chance.

      Publishing as we knew it *has* gone away and I say good riddance. The tech publishing that’s worthwhile has shifted to self-publishing, such as through Leanpub.

      Like

  18. This “post that will not die” and it’s vibrant discussion has helped me figure some things out, thank you very much for it. I was a high-tech technical writer for 10 years before I was hired about 10 years ago into a very large company as a “KCS” tech writer. As you may or may not know, KCS (Knowledge Centered Support or Service) is a service methodology whereby the “knowledge” that is gained by customer service personnel when they resolve customer issues is captured and put into knowledge base articles, which are then published so they can be reused by customers as well as other customer service personnel.

    This company has hundreds of highly technical products and thousands of support engineers. Of course, it was quickly discovered that most support engineers are not the best nor the most willing technical communicators. So, a team of tech writers was put together who were responsible for editing the “raw” articles and making them usable and useful to the intended audience. I was the last member to join that team (at least in the US). About 5 years after I started there, this company decided that it really should pursue the “true” KCS methodology. True KCS has no place in its process for the “KCS tech writer” role (and in fact seems implicitly if not overtly hostile to the need for writers/editors in general). It is meant for service personnel to create and publish their own articles, only focusing on “accuracy” and getting the content “out there” ASAP. This of course meant there was no real raison d’etre for our team.

    So, like any good group of tech writers, we evolved (I mean those of us who remained did, because of course, after the change our number was reduced substantially). We became more focused on training programs, mentoring, and consulting for the service engineers. We trained them in technical writing, KB article development, and knowledge management, and became responsible for administering, maintaining and reporting on the knowledge base. We became “knowledge managers” instead of technical writers. Then at the end of last year, I too was “reduced”. I was told it was for “strictly financial reasons” after the company merged with another very large company.

    Since then, I have been of course job hunting but also casting about a bit trying to figure out the next chapter of my career, and this post and its discussion have given me many ideas. KCS is a sub-discipline of Knowledge Management and I am certified in both, and both have the potential to dramatically impact the performance of a company. But as a business function, I have found that both KCS and KM also seem to share some aspects to tech writing, in that their benefits are not always easily quantifiable, at least initially. So, KCS and KM professionals, meaning those who can help implement a KCS or KM strategy in an organization, are like technical writers not often perceived as a real need (and thus not truly respected) by the powers-that-be in many companies. This is evidenced by the fact that there are far fewer KM/KCS jobs out there even than tech writing, which is why I have been looking again for technical writing work and how I ended up at this post of yours.

    I am a very “technical” technical writer, and I agree with previous commenters that there ARE technical writing roles out there. I also agree that most of the roles I am seeing in my area are for API docs and other such technical roles, which is probably the logical place for me to end up. Although, I had been thinking I wanted to transition to a different type of role even before I read your post. I have some experience, training and interest in business analysis, and UX designer is highly interesting to me as my docs have always been very “visual” and user/process-focused. And, I see multitudes of jobs out there for those roles. But for either of those two options, I find myself in the unenviable position of being a senior-level professional who is trained and quite capable but with no samples to back it up. That is, I might be able to get such a role if I take a relatively junior role and a 30% pay cut (of course, 70% is better than 0% I am getting now).

    Anyway, thanks again for this, and apologies for the blog-length comment. I’m a writer. 😉

    Like

    1. Whenever there’s a push to have non-writers create content like you describe, I shudder, because that usually means it’s going to be crap. It’s funny: I think very clearly that tech writing is not a growth career. But I also think that writing is an enormously valuable skill. I can’t always reconcile this break in my internal logic.

      Like

      1. Exactly, which is why we started focusing on basic technical writing training/mentoring, i.e. teaching the support engineers “how to fish”. We had some success in mitigating the “crap” by doing this, but even with good training it still came down to the rule of thirds: A third would really get it, a third would start to get it but would lose it if they didn’t immediately apply it (which many did not), and a third would not get it no matter how good the training.

        I also have done a great deal of thinking over the years about the “value” of writing as a skill, and I think it really comes down to whether a company appreciates the value of quality, whether in writing, coding, or any other technology/business skill. Producing quality work requires time and skill, meaning money. As one of the earlier comments indicated, producing a simple, elegant and intuitive software interface is not so simple. It takes a LOT of skill and effort, as does producing truly valuable documentation that educates users to be self-sufficient and is more than “click this, now click that”.

        Appreciating the value of quality work requires a long-term view of the Big Picture. It means understanding that producing high-quality, well-documented software will both save and make the company much, much more money in the long run than will producing buggy, poorly-documented crap for a lower initial cost that then sends your subsequent support and maintenance/”redevelopment” costs through the roof.

        Such a long-term perspective seems to be in very short supply at the C-Level at most companies these days, and especially in public companies where they are “graded” by The Market every three months and therefore pressure their lower-level managers to focus only on meeting their next quarterly goal.

        Like

        1. What I’ve come to realize is that companies don’t want writing, they want solved the problems that writing can solve. They are willing to take a reduction in quality when it is exceeded by the attendant reduction in cost. Frequently it seems cheaper to hire one or two writers to coach roomsful of non-writers because they have fewer FTEs that way. But the truth is that having non-writers write costs too, by taking away from what they would normally be doing. But that reduction in FTEs is intoxicatingly compelling.

          Like

  19. *Yes I know, “it’s” -> “its” and “has” -> “have”. I just love it when I add a lengthy comment in a forum sure to be seen by writers, and start it off with a grammar faux pas or two. 😦

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s