What technical writers actually do at startups

Depot has a technical writer now. Of course I searched for “technical writing at a startup” while I was writing this post. I found a video that promised I could become a tech writer in one hour or less. You’re probably thinking, “If I watched that video and then got a job at a startup, what would I actually do there?”

Tech writers at startups are in their element

A tech writer at a startup is a stellar model for how large docs teams should relate to other functional departments within much bigger companies (but rarely do). In bigger companies you’ll often find needless layers of approval and access control, dysfunctional processes, and competition for resources getting in the way of the work.

Tech writers at startups can research the company culture and implement:

• All their opinionated best practices for docs.
• Hyper-efficient ways of working with the rest of the organization.

This freedom lets tech writers move fast and stay flexible. For example, at Depot, I can brainstorm video ideas for a conference, review a huge docs contribution from Support, create a new doc requested by a Solutions Engineer, and write a blog post. All in the same week.

A (partial) list of tech writer scope at a startup

Founders take note: 50% of the things tech writers do save other employees time and the other 50% make customers happy. (Source: trust me.)

• Understand and think: About users and products (use them!) and content at the company. Don’t skip this step.
• Advocate for users: A result of all that thinking should be extreme user empathy and focus.
• Write about writing: A style guide, blog writing guidelines, content philosophy, and content frameworks.
• Create a contribution culture: Help other people write useful content. Make sure any processes reduce friction for engineers to contribute to docs.
• Work with Engineering: Be the first user of new features or products.
• Work with Support: Help to put their troubleshooting know-how into the docs where users can find it before they need support.
• Work with Solutions Engineers: Create resources for customers so the SEs don’t need to copy/paste info into emails or messages.
• Work with Marketing: Contribute to blogs, videos, and newsletters to help reach developers.
• Write docs: A classic tech writer all-time-favorite.

The scope is big, and we’ll talk about a few of these areas. First though, you might have noticed something about this list of things technical writers do at startups: most of it is working with other people. (Don’t worry, introverts should still apply.)

Reciprocal relationships are a magic wand

You’re unlikely to find apathetic people at a small startup. Startups I’ve worked at have been full of passionate, intimidatingly smart people who actually care and also LOVE TO HELP.

One of the things they care about is docs, even if they don’t always have time to think obsess about them as much as technical writers do. At Depot, I found initiatives in progress to improve technical content before I even got here:

• Our new support engineer is creating troubleshooting docs in our support tool to move into the docs. And thinking about ways to help users find the info faster.
• A software engineer started implementing Vale, a prose linter, for the blog. Now we can work together to do it for the docs too.

Reaching out to these folks was natural, energizing, and will no doubt lead to better docs.

The tech writer works across the whole organization to build reciprocal relationships. These relationships make the job of creating content so much easier for the technical writer.

And the technical writer, by providing guidance, support, and truly useful docs, improves the day-to-day for everyone else too. What does this reciprocation look like? Frameworks for writing release announcements, quick turnaround on PR reviews, being responsive to internal doc requests, early feedback on feature usability, helping distill ideas into blog topics.

Now let’s dig into just a few of the things from the tech writer’s scope, in practice.

Create a contribution culture: a big challenge

A contribution culture is one in which everyone at a company feels welcome and capable (and maybe even compelled 😈) to contribute to the docs. Tech writers can foster a contribution culture at big or small companies. You might think it’s easier at a startup. Not always.

Without founder or leadership buy-in, contribution culture is a tough go. If contributing to the docs isn’t part of the product release, also sometimes called the “definition of done”, then you’ll get sporadic and unequal contributions from engineering.

Another success factor for engineering contributions is a docs-as-code workflow. Engineers can contribute docs the same way they contribute code. On the other hand, docs-as-code is the biggest barrier to contribution for less-technical teams.

Contribution culture has a high chance of success at Depot because the founders want it.

With leadership buy-in confirmed, here’s how I approached contribution culture in my first week:

Engineers can write docs.
Engineers contribute to docs regularly. <- is this currently aspirational? find out.

Investigate:
- What causes friction today?
- What is the current process?
- Can docs be part of each product/feature release?

Goals:
- Engineers write docs for features and updates:
  - ideally the docs are in sync with the release
  - but a fast-follow will work for now
- Engineers and Support Engineers write docs during or after support rotations based on frequent customer queries/problems:
  - they can also create an issue with enough detail and context for someone, like the tech writer, to pick up later

TODO:
- talk to all Engineers about docs, contributing, any blockers
- write up and share a very lightweight process
- integrate into [PROJECT_TRACKING_TOOL]
- test it out and iterate

Work with Marketing: no AI-authored blog posts

One marketing thing tech writers help with is blogging. The technical writer's role is editor and coach, getting posts ready for publication.

Luckily, at a startup, you can make choices about quality and how you work. Here's one we made at Depot: all our blog posts are written by humans. They're home-made, sometimes literally hand-written, and lovingly born from topics that interest us.

Quality is an obvious reason to not use AI for writing blog posts. We want developers to get something from our posts. It’s difficult to articulate, but the slippery way a lot of AI-generated content glides across your mind without any lasting benefit is just not… good. Let’s not put more of that out there for models to consume.

Another reason to avoid using AI to write is that writing helps you understand your own opinions and ideas. Writing helps you think better.

You can try using AI to review and refine after you’ve worked through the hard stuff. I’m experimenting with feeding Claude a detailed version of our blog guidelines, a bunch of context and caveats, and then asking for suggestions on already completed drafts. Maybe 20% of Claude’s suggestions are pretty decent. The goal is to save time, but not be lazy about writing. And I freely admit the irony of using AI at all to help with our actually authentic developer content.

The bottom line

The tech writer scope included 9 things. Each one is almost a job in itself. And there’s always more to do; I didn’t have room to include them all (while still following the 7 plus or minus 2 rule).

If you're a tech writer considering a startup, expect to have multiple roles, pivot constantly, and build relationships across the entire org. If you're a founder hiring a tech writer, expect them to improve everyone's day-to-day while making customers happier, as long as they have your buy-in and the autonomy they need to do it.

At a startup, challenges and opportunities are pretty equally balanced. But if you really care about developer education and docs, and you want to shape how a company thinks about content from the ground up, there’s nothing quite like it.

FAQ

Related posts

Andrea Anderson

Technical Writer at Depot