Can I be a technical writer? And at what price?

December 15, 2020 10:05 PM

Recently, an acquaintance recommended me for a position as a technical writer for a short term project his company is engaged in. The project is very technical, involving specialized machinery and some programming documentation. While I have plenty of experience working as a writer, my niche is academic writing (mostly textbooks). I'd like opinions about whether I am qualified to do this and how to determine what I will charge.

Essentially, I would be polishing API documentation and creating a manual for an industrial device. I do have some (very basic) programming experience, and I have used APIs for my own personal projects. Still, my intuition is that I may not be the best match for this project. However, many of my friends assure me that I'm just prone to self-doubt. I lean towards accepting the project as a way to expand my skillset, but I'd like to hear other comments or suggestions.

Next, there is the question of pricing. The company wants me to provide a cost estimate for the entire project. I frankly have no idea how to do so given that I typically bill hourly, and this particular niche is so new to me. Again, I'd appreciate thoughts or recommendations.

posted by anonymous to Work & Money (13 answers total)

I do not know exactly what you should charge, but I *definitely* beleive in you. If you can write textbooks, you can write programming documentation. Just ask the folks responsible for the api and the speciallized machinery all the questions to make sure you understand how things work to your own satisfaction and bang on. Always be expanding your skill sets! <3

Charging hourly or by the half day is good i think, and to start figuring out an estimate, maybe just sketch out the process you'll need to undergo- reading current documentation, figuring out the questions you have, asking the questions to the horses mouths, synthesizing that into writing, and then editing that work, doing a pass with the client, and making a final edit all seem like steps in the process that you should be charging them for. estimate what that will take, tack on 30% for underestimates and start there?
posted by wowenthusiast at 10:28 PM on December 15, 2020 [1 favorite]

Coming from a fellow author and coder, you are definitely qualified, especially if you have played around with APIs. The best quality you can bring to documentation is asking layperson questions and ELI5 and "as opposed to what?" As a writer you will probably be able to explain things better than whoever wrote the Android SDK documentation, for example, that we programmers struggle with making sense of.
posted by johngoren at 1:37 AM on December 16, 2020 [1 favorite]

If you're roughly as technically adept with this thing as the people who would be using what you write -- or really a step or two less adept -- then you're equipped to be useful here. The value of a tech writer exists in their targeted non-understanding, not in their understanding.

As far as billing hourly versus for the project, I dunno really, but if you need to make a risky bid, bid on the high side unless you need this to feed yourself.
posted by away for regrooving at 1:42 AM on December 16, 2020 [1 favorite]

However, many of my friends assure me that I'm just prone to self-doubt.

Your friends are correct. I got a job as a technical writer for a biotechnology company with nothing more than a creative writing degree under my belt. You're much better suited to this than I was then.

The key is curiosity. As long as you pursue asking "why" and really seek to understand what's going on with the project, you will be fine.
posted by rocketman at 6:09 AM on December 16, 2020 [3 favorites]

First, I'll echo other folks and say I believe in you. You can do technical writing. I recommend picking up a good book on technical writing or at least skimming a few blogs on the topic to see what the expectations are vs. academic writing. Each type of writing is different and you'll want to pivot to adapt to the project.

A few questions I'd ask if I was considering this project:

- Do they want a reference manual or a use case-centric manual? Should you be walking the reader through specific scenarios and explaining how to do them, or should you just be documenting all the features and leaving it as an exercise to the reader how to use the product? Do they want both?

- Do they have previous manuals they consider successful? Ask to see them and see if that looks like work you'd be comfortable producing.

- Assume this is going to require some kinds of technical diagrams, etc. Who's producing them? Are they available now?

- You say it's a "short term" project. Just how short term, and how quickly will you need to turn this around?

- Who's reviewing the work and have they done this before? This is important because you don't want to be trying to hit the ever-changing expectations of a committee.

- Is the product finished or close to it? You don't want to be on a short-term project with tight deadlines and find that you've written 75% of the manual around its API to learn that the API has changed dramatically.

If you can look at previous projects they consider successful I think that'll give you a much better idea what the deliverables would be and how comfortable you'd be creating that work and how long you think it'd take you. Take that and consider the review process and the time that you have to deliver the project.

If you charge $100 an hour for writing, etc. and you think it'd take 50 hours to write and edit, you'll expect to spend X number hours revising, add an upcharge for extra reviewers or a nebulous review process, and add an additional upcharge if this is a rush project.

Also, if you are quoting a price for the whole thing instead of hourly, make sure you get paid part upfront. And get something in writing, with a kill fee if the project goes south, or whatever.

I would get answers to all of these questions, and pay attention to not just the responses but whether they seem to appreciate being asked or annoyed at a lot of detail. That may tell you a lot about how the project is going to go. In my experience, asking these types of questions up front weeds out clients that are going to be really difficult to work with and/or have unrealistic expectations and/or vague expectations.

All that said, you may find that the manual is a "check the box" deliverable and they won't care very much. That's not great for the users of the product, but it would certainly give you a lot of freedom in getting your feet wet on a technical writing project.
posted by jzb at 6:27 AM on December 16, 2020 [9 favorites]

It may help if you can dig up some examples well written technical manuals of the type you are needing to create. I found this page of style guides and examples, for instance. If you are used to writing text books, then I don't think there is any massive gulf of knowledge you have to cross: just have a style goal to aim for. You should be selling yourself as a writer - not as an apprentice, discount technical writer.

In terms of pricing for the work: one major unknown is the availability of subject-matter experts. These are the people you will need to get hold of to complete your task. You need to add in plenty of time to be chasing these people down, interviewing them, editing material they provide to you and doing any final reviews. Assess the extent to which you will need to be an editor as well as an author.
posted by rongorongo at 6:32 AM on December 16, 2020 [1 favorite]

I've been a technical writer, and I've hired technical writers, including ones that documented APIs and SDKs.

If you have solid writing skills then you are already way ahead of most people, and if you've written textbooks then you already are a technical writer. If you have had *any* exposure to, and OMG actual experience using, APIs then you are gold dust. Tech writers who can document APIs are some of the most sought-after tech writers (along with finance and medical) because the combination of strong writing and strong technical skills is a really rare nexus.

jzb makes some very valid points and please ask all of the questions they suggest, but yes you absolutely can do this, and yes you absolutely can charge a decent amount for it. Not sure what the US rates would be, but if a "standard" tech writer documenting a front end charges (for example) $50 an hour, you can definitely charge $100 an hour for API documentation.

(Handy hint: If you want to do contract work in the future, when someone asks "Can you write [x]?" then you say "Yes", unless [x] is far enough outside of your skill set that you can't possibly learn how to do it.)
posted by underclocked at 6:38 AM on December 16, 2020 [6 favorites]

I am a technical writer who writes grant proposals for scientific research projects for my company - stuff that people with PhDs are trying to figure out, I mean, no way in hell I could understand the things I'm writing about. But understanding it isn't my job. Making sure it's readable to people who do understand it is.

You got this. Your expertise is supposed to be the writing; they're the experts in the technical aspects, they can't do the writing, that's why they hire you and dump a bunch of info on you which you will transform into readable things. Others will edit your work for technical accuracy - there will be a review process, and if there isn't one, you will institute one to make sure your writing doesn't accidentally misstate things. This is the way it's done everywhere.
posted by MiraK at 7:29 AM on December 16, 2020 [2 favorites]

You can do this.

I took a technical training course, and in the email that I sent them afterwards to demand a refund, I offered to do better. They took me up on it, and for a year or so I was proofing the written materials for their five-day training courses.

I didn't do a technical edit, but I looked for grammar, formatting errors, inconsistencies, and the like. The native English speakers delivered the worst stuff, and the English language learners delivered the best. *headdesk*

They paid me a few hundred dollars for each one -- which I later discovered they passed on as an expense to the instructors, who eventually refused to pay it.

I also proofed a friend's book before it was published, and he was told it was the best manuscript they had ever received. (I did this one for free because he is a good guy.)

With that experience, I maintain that anyone who can write in a conversational tone and not make technical mistakes will be in the top tier of technical documentation-writers around! I'm an English major working in IT, and poor writing & communication hurts every project that doesn't prioritize it.
posted by wenestvedt at 7:34 AM on December 16, 2020 [3 favorites]

I made the jump to formal technical writing after doing journalism and marketing/PR-type copy for years. You are probably fine.

Remember, your job isn't to know the technical things in and out (and, actually, newbie-level questions are good things to cover!), it's to essentially interview the people that do and distill that into something useful. So something like "Can you walk me through what this code is doing?" or "Okay, so I understand correctly, you said this call is asking the database server to update every 20 seconds?" is actually a good thing to be asking.
posted by Ghostride The Whip at 7:36 AM on December 16, 2020 [3 favorites]

Re: what you should charge - EFA suggests an hourly rate of $61-70 per hour for STEM writing. I would suggest a higher rate for software companies, more like $85-$100 per hour. If you're in a big city/tech hub, go higher. e.g. in Silicon Valley I would charge $150 per hour as an independent contractor for a large (100K+ words) project.

There is no way you can quote them a rate for the whole project without defining the scope of it. You can ask for a meeting to define the scope of the project, after which you will be happy to give them an overall estimate. You can quote them a flat fee for the initial consultation, say, $250. This would cover your time: 60 minutes meeting + 60 minutes to develop a quote + 30 minutes meeting prep.

At the meeting, you can gather information about the scope of your work. Your final estimate to them will be based on:

- How much documentation is there to "polish"? How many words, how many pages? EFA says developmental editing for STEM/medical/tech writing is generally charged as 1-3 pages per hour.

- What do they mean by "polishing" the API documentation? Define their objectives, eg, do they want proofreading, editing, reformatting, managing and/or organizing content library, layout, formatting, publishing (which then would include testing to see if your documentation is being rendered correctly), developing documentation release notes, perhaps even developing a content process for them? Some of this falls under developmental editing, but other pieces would need extra time estimates from you.

- What is the system which you are developing the manual for? What should the manual cover? Can they show you a manual for a comparable piece of equipment? Base your time estimate for the manual on that page count/complexity. EFA says 1-3 hours per page.

- What's the project process going to be like on their end? Who is managing your project? How many meetings every week? What do the development and review cycles look like? ---> count all these meeting hours + meeting prep hours + meeting report development hours towards your time estimate.

- What's their approval process like for the content you develop? You might want to add in a line item about
extra charge rates if they ask for major rewrites at a late stage, outside of the agreed-on internal approval that should happen in chunks throughout the project.

- Add 15% extra hours for things that go boom.

- Tot up the hours, multiply by your hourly rate, and that's your estimate.
posted by MiraK at 8:29 AM on December 16, 2020 [1 favorite]

For a while we had a consultant who worked half-time. She would talk one-on-one with our developers, and then dump her notes into our documentation templates. They would review, and add actual code snippets. Eventually someone decided she was too expensive, and our documentation almost dried up.

I get misty about those days with Sharon The Writer and the golden age of internal documentation.....
posted by wenestvedt at 8:50 AM on December 16, 2020 [5 favorites]

This is a big difference between academic and technical publishing. In academic writing, you're supposed to be one of the world's foremost experts on the subject. In tech writing, you aren't expected to be a subject matter expert at all — just the person who translates someone else's expertise into writing.

The question I'd be asking if I were you is what access you'd have to subject matter experts, and whether spending time working with you would be made a part of their job. If working with you is essentially unpaid overtime for your SMEs, it's going to be hard to get anything done. If it's something their supervisors will ask them to budget time for and expect them to take seriously, you can be more confident that you can do this.
posted by nebulawindphone at 9:22 AM on December 16, 2020 [2 favorites]