Chapter 3: The Types of Technical Writers

When I tell people I work for Amazon, I usually get one of two responses. Either they assume I work in a warehouse, or they often assume I'm a software engineer. Both assumptions reveal how little most people understand about how technology companies actually operate.

The reality is that companies like Amazon, Google, Microsoft, and Stripe employ thousands of people who aren't software engineers. And even within software engineering itself, there's incredible diversity. Frontend engineers build user interfaces and focus on how customers interact with applications. Backend engineers develop the server-side systems that power those applications. DevOps engineers build the infrastructure that keeps everything running. Security engineers build protections against threats. Data engineers build systems for processing and analyzing information.

But the misconception goes deeper than just the variety within engineering. Most people don't realize that technology companies need entire ecosystems of non-engineering roles to create products that customers actually want to use.

Everyone is a Builder

Andy Jassy, the CEO of Amazon, has a perspective I love: he views everyone at Amazon as a builder. This thinking transforms how you understand what it means to work in technology. Everyone at Amazon—and really, at any technology company—is a builder. The question isn't whether you're technical enough to work in tech. The question is: what do you like to build with?

Some folks build with software. We call them, unsurprisingly, software builders. They write code, design systems, and create the functionality that powers digital products.

Some build projects. Program managers and product managers identify customer needs and map out how to create services that meet those needs. They build roadmaps, coordinate teams, and ensure that technical capabilities align with business goals and user requirements.

Some build enthusiasm. Developer advocates and community managers share experiments and insights with different communities. They build relationships, create educational content, and help other developers succeed with specific technologies or platforms.

Some build experiences. UX designers and researchers build user interfaces and workflows that make complex technology accessible and useful. They build empathy for users into product development processes.

Some build understanding. Technical writers build with words. We take complex systems, processes, and concepts and build bridges between what engineers create and what users need to accomplish their goals. Documentation, after all, is code compiled by the human brain.

Let's focus on this last category—those of us who build with words—because it turns out there's remarkable diversity within technical writing itself.

The Spectrum of Technical Writing

Within technical writing itself, there's remarkable diversity in what builders with words actually create. There's a temptation—even among technical writers—to think that one type of technical writer is better or more important than another. That's not true. Each specialization requires different skills and serves different but equally valuable purposes.

Technical Writers build understanding for people trying to accomplish specific tasks with products or services. At Stripe, for example, most technical writers focused on explaining how to integrate applications with payment systems—many of those solutions involved no code whatsoever, but required understanding complex business processes, compliance requirements, and system configurations. The audience might be developers writing integration code, but it could equally be business users setting up payment flows or network engineers configuring server access rules.

Developer-Focused Technical Writers build understanding specifically for software developers who need to integrate APIs, use frameworks, implement services, or troubleshoot technical issues. They create API documentation, SDK guides, integration tutorials, and architectural explanations. This writing assumes programming knowledge and focuses on helping developers implement technical solutions efficiently. One of the most important skills for these writers is the ability to talk effectively with software engineers who serve as subject matter experts for what they're documenting. Having a solid understanding of how software engineering works is essential for success in this specialization.

UX Writers build understanding directly into products. They craft button labels, error messages, onboarding flows, and interface copy that guides users through complex workflows. These writers often work with what's called microcopy—think about the UI experience on something as small as your phone, where there's very little room for words. UX Writers specialize in creating delightful customer experiences using very few words. If a regular technical writer is a novelist, then a UX Writer is a poet—specifically, one that specializes in haikus.

Content Strategists build coherent content ecosystems. This is a somewhat new role, or one that is still evolving. Content strategists subdivide in ways similar to technical writers in general. A "general" content strategist focuses on sharing messages and stories to communities—thinking holistically about how marketing materials, product messaging, and communications work together to serve business goals.

There's another type of content strategist that I think of as a technical content strategist. These strategists not only think about stories, but they think about how to support those stories throughout a customer's journey. For example, in my role as a Principal Content Strategist at Amazon, my responsibility is not only to identify and tell specific stories to our customers; it's also to ensure those stories are supported by training and documentation. In some cases, that means partnering with training and documentation teams. In other cases, I'm working to develop solutions to help product teams—who may need to create their own documentation—create quality content.

As for what is quality content, I promise I'll talk about that shortly.

Why This Matters

Understanding these distinctions serves three important purposes.

First, it pulls back the curtain on the different roles that exist within the technical writing community. (I'm not trying to provide an exhaustive list here—there are other specializations and hybrid roles that emerge as the field continues to evolve.) If you're someone considering a career in technical writing, or if you're curious about the breadth of opportunities in technology companies, understanding this diversity helps you see potential paths you might not have known existed.

Second, for those who have to work with technical writers, understanding these different types and their unique value is crucial. People tend to lump technical writers into one group, and that's not accurate. Understanding the types of technical writers can help others decide what they really need from a writing standpoint. A writer who is great at programming tutorials can certainly try to write microcopy, but they don't have the depth of knowledge that a real UX writer has. Just like a software engineer specializing in backend services can probably help solve a problem with a React component, but doesn't have the same expertise that a frontend engineer has.

Third, we need folks to understand context. The ways in which we tell stories to customers is vast—too vast for any one group to be able to tackle. A beautiful customer experience doesn't just stem from one line of code, or even one service. And it certainly doesn't come from a single type of technical writing. A great experience for customers requires coordination across specializations. Just like a home doesn't just need skilled carpenters—you need foundation specialists, electricians, plumbers, roofers, and so on.

The Challenge Ahead

Now that we understand the breadth of technical writing specializations and why they matter, we face a more difficult question. With all these different types of technical writers doing such varied work across different contexts and audiences, how do we know if they're actually any good at what they do?

This isn't just an academic question. Organizations invest significant resources in content creation. Product teams depend on technical writers to help users succeed with their products. Developers rely on documentation to integrate services and build applications. Customers make decisions based on how well they can understand and use what companies build.

But evaluating the quality of technical writing turns out to be surprisingly difficult—much harder than you might expect. And that challenge is what we'll tackle next.