Every once in a while, startup founders and managers decide that they need someone to create and manage their docs –perhaps after reading this letter. Some contact me to understand how they should go about hiring for a tech writer. Since I’ve already published tips for job hunting as a tech writer, I thought it would be a good idea to write down some advice for the other side, too. Here are my recommendations for software companies wanting to hire their first technical writer.
This list is the result of my experience as a first tech writer at different companies and in different roles. All the job interviews I’ve gone through the years and all the conversations I’ve had with fellow technical writers about the topic of hiring and getting hired also contributed to what you’re going to read next. I hired writers only once in my career, but I did advise many startups over the years.
Hiring a technical writer might feel strange to someone who’s not accustomed to working with documentarians. Where should I place the first tech writer, they wonder. This rings especially true in young, flat organizations with few managers and departments. I’ve seen tech writers being placed under Marketing (“they all write, right?”), product, or engineering.
A technical writer is not a plug-and-play specialist you can embed to any team without thinking. Would you hire a developer without an architecture or product strategy? Then don’t hire a writer before you’ve a documentation or information experience strategy in mind. If you don’t have a docs strategy be transparent about that, and set aside time to work on it with your first writer.
Hiring a writer without a documentation strategy in place or a sense of what docs should accomplish and how they should interface with the rest of the organization is like hiring a musician without knowing when and what they should be playing. Don’t do that. Instead, draft your docs priorities and use them to inform the hiring process and the 30/60/90 plan.
There is no such thing as a native speaker of technical English. Technical writers don’t need to be native speakers of English (whatever that means), so adding “native English” will not only estrange a sizable fraction of potential hires that weren’t born in an English-speaking country, but it’ll also signal you’re clueless about what skills are needed for great tech writing.
Technical English is a subset of standard English that uses simplified vocabulary and grammar for the sake of clarity and ease of consumption. Of course a solid knowledge of English is needed, but that’s something you’ll very easily gauge from the first interview and writing samples. Instead, hire for other skills, such as UX writing or writing for the web.
“But Fabri, the English language is our main tool”. Yes, but it’s not what makes a great tech writer. English, like any programming language, is a tool at your disposal, but it won’t do much if you don’t know how to extract information from subject-matter experts, design an information architecture, or test the features you’re going to document.
While having certifications and degrees in certain disciplines is nice to have, it should never be a requirement nor a killer question. Tech writers come from many different backgrounds, such as computer science, literature, journalism, anthropology, and so on. I’ve seen job offers that go as far as asking for math grades, which would be amusing if we weren’t talking of jobs.
If the hiring culture at your company is such that degrees aren’t a hard requirement for software developers, then don’t ask for degrees when hiring for a tech writer. Checking a docs portfolio (when available) or requiring candidates to go through a test (with or without AI assistance) are acceptable alternatives to degrees or certifications.
In the end, certifications are like driving licenses: They tell people you know what an orange light means, but they don’t guarantee you’re an expert at driving. And that’s OK, because that’s what certifications are for, to give you the basic foundations before you roam the world. When hiring a technical writer you’re entering a complex territory, so arm yourself with a map.
As I explained in Learning to code as a technical writer, coding is an enabler that should help writers in helping themselves and becoming autonomous when it comes to reading a codebase or testing a piece of software. The goal is for your first writer to rely less on engineering time and more on their own skills so they can formulate the right questions.
Tech writers can grow into solid coding associates, or devlings. In that capacity, they can support teams with first-hand testing, and even contribute to the words that make up your products, from CLI output to REST API design. Everything that contains words for humans can be improved by tech writers; the mechanisms through which that happens are circumstantial.
When hiring for your first tech writer, ask yourself what they should be editing and where. Consider adding engineering on-boarding items to their on-boarding schedule, and have engineers explain the overall architecture of your product. You’ll soon find out that writers excel at understanding the big picture and using it to discover product truth.
Getting a contractor as your first tech writer might be a good idea. I know many fantastic freelance writers out there that can help kickstart your documentation efforts. After they’re done, though, consider hiring tech writers in permanent or full time positions. The reasons for this are quite obvious: Docs are a never ending effort (“docs are never done”).
The best dev portals and docs sites out there have been created by in-house teams of technical writers supported by strong docs engineering and tooling. For example, Stripe, globally renowned for their docs, created Markdoc to support their writers: Tooling and resources followed the documentation vision and supported an already potent docs culture.
If you want to build docs at your company à la Stripe, you need a superb documentation culture. To get that documentation culture, you need writers who can forever work and thrive at your company. Hire them and make them happy. Only then the magic happens.
Your first technical writer will be a documentation architect, tool maintainer, UX writer, DocOps specialist, and product owner, all in one. They’ll set the foundations of your documentation for years to come and provide your products with a voice and tone. You should pay for that effort accordingly. You wouldn’t pay your first engineer below market, so pay your first writer well.
If you don’t know how much you should be paying your first technical writer, have a look at the yearly Write the Docs Salary Survey as a starting point. Experienced tech writers can command salaries not that different from software engineers or designers. Unfortunately, tech writers still tend to undervalue and undersell their skills: Show that you do value them through your offers.
Remember: Software is made of words and can only be used through reading other words, the docs and UX copy. If you’re not concerned about usability, engagement, support load, or your reputation, you can probably do without a technical writer or content yourself with mediocre AI generated blabber. Don’t come complaining afterwards, though!
Documentation is a shared concern to which all parts of the business should pay attention. Don’t fall into the trap of thinking that hiring your first technical writer will allow developers and product managers to stop writing and forget about documentation. Getting a writer is not about ceasing all writing activities: rather, it’s more like getting an editor-in-chief.
It’s important that you realize this: If you task your first technical writer with doing all the documentation by themselves, they’ll burn out pretty fast. Unless the product surface is small and relatively fresh, asking a tech writer to write everything is an unfair proposition. The best you can do is to support your writer into creating a strong collaborative culture around docs.
This is even more important when your product has open source bits and is open to community contributions. In a docs-as-ecosystem setting, you want to foster contributions from all sources, be they internal or external, and have writers coordinate and tend to the writing community.