Beyond documentation: tech writers as strategic enablers

Overview

The recent Write the Docs Berlin conference led me to reflect on the evolving role of technical writers. Here are some thoughts on how I think the technical writer role is evolving into one of “strategic product enabler” and why this transformation matters for organizations.

We’re everywhere

We’re everywhere: in your code, in your applications, in your APIs. We’re quality control. We’re project managers. We’re user advocates, trainers, strategists, designers, maintainers, collaborators, problem solvers and educators.

Let’s be clear: technical writers are not spell checkers and grammar enforcers. That perception perhaps persists in some organizations, but it fundamentally misunderstands our role. If that’s what management thinks we do, they’re missing the strategic value we bring. Tooling - both deterministic (for example, Vale, Markdownlint, etc.) and non-deterministic (LLMs) - can handle typos, spelling and basic grammar, when implemented well.

We create and enforce style guides, and we can now automate much of that. Vale can enforce organizational style rules, and there’s even a Vale MCP Server that integrates prose linting directly into AI coding assistants.

The role of a technical writer has evolved significantly over the years. While it was never just confined to just writing manuals or help files (or at least it shouldn’t have been), tech writers increasingly play a crucial role in shaping user experience and ensuring that information is accessible, clear and useful. Tech writers are evolving into strategic product thinkers who design information systems that drive user success.

From output to outcomes

At Write the Docs Berlin 2025, Stephan Delbos from Mews shared some great insight that captures this evolution. His team made a critical shift from measuring traditional engagement metrics (page views, completion rates) to focusing on user activation - driving actual behaviour change that delivers business value.

“We’re not in the business to produce content. We’re in the business to benefit the business,” Delbos explained. His unified Product Knowledge Activation team now owns company-wide objectives and can directly demonstrate impact: certified trained users open 15-16% fewer support tickets and each deflected ticket saves the company €7.

This represents a fundamental mindset shift from output-focused to outcome-focused work. Tech writers aren’t just creating deliverables; we’re creating levers for change.

The AI-augmented reality

The rise of AI is fundamentally changing our role, but not in the way many may have feared. According to the 2025 DORA State of AI-assisted Software Development Report, documentation quality becomes even more critical as AI systems now consume our content directly. We’re writing for a dual audience: humans who need clear explanations and machines that require structured, unambiguous data.

Documentation is no longer just reference material - it’s become runtime interface. When an LLM consumes your API documentation to generate code, or when AI systems use your knowledge base as executable tools, documentation becomes part of the product interface itself. The distinction between “docs” and “product” has collapsed.

This shift reinforces a key insight from recent AI The Docs conferences too: strong documentation foundations matter more than ever. AI can amplify onboarding, personalization and discovery, but only when built on clear structure, high-quality writing and well-defined information architecture. Rather than replacing documentation practices, AI is raising the bar for them.

Diana Breza from Kong demonstrated this evolution nicely at her Write the Docs Berlin talk. Her team built custom tools that extract code snippets from documentation and test them exactly like users would - copy-paste workflow included. The result? 91% accuracy in AI chatbot responses and 81% helpfulness ratings from users.

“Technical writers need to be testing the products,” Breza emphasized. “If there’s only one thing you take from this talk, I hope it’s this.” We’re documentation creators and quality engineers, ensuring content works in an AI-mediated world.

AI tooling is also augmenting writers themselves. As Tom Johnson observes, AI is making experienced technical writers significantly more productive - in his case, about twice as fast as before. But this isn’t just about speed; it’s about capability expansion. Where previously a writer might need a week for a complex user guide, AI-augmented workflows can deliver quality drafts in days.

However, this acceleration requires “prompt engineering” - a non-obvious skill that many technical writers may still struggle with. The most effective practitioners might use 20+ different AI prompts and interactions working through a single page, applying years of editorial judgment to calibrate outputs. Engineers might have patience for a single AI attempt; experienced technical writers iterate until the content meets professional standards.

This reinforces why strong documentation foundations matter more than ever. AI amplifies existing expertise rather than replacing it.

Knowledge engineers and information developers

Tech writers are becoming knowledge engineers and information developers. We design content experiences that work across multiple interfaces - web portals, chat interfaces, API docs, and embedded UI microcopy and help content. Each interface has different constraints and user expectations, requiring us to think systemically about information architecture.

The words you’d use to describe a tool to a human might not match what an LLM needs for accurate interpretation. This isn’t just a formatting challenge - it’s an interface design problem requiring product-level thinking about both human and machine needs.

Modern technical writers now face what Cherryleaf’s Ellis Pratt calls “the dual audience problem”: creating documentation that serves human consumers (who need clear explanations and context) and machine consumers (who may need different language, metadata, or structured formats) simultaneously.

Pratt’s recent post: “Documentation product management: Does the AI era demand a new discipline?” suggests we need documentation product managers who can balance human expertise with AI acceleration while owning business metrics and driving cross-functional coordination.

Content as strategy, not just support

Dave Koelmeyer from IDEXX captured another crucial evolution in a recent Behind the Docs podcast episode: “When people move between different portions of your digital experience and don’t feel it’s consistent, it diminishes trust. And when people don’t trust the content they call support. Or even worse, they don’t - because they give up and churn.”

This highlights how tech writers have become guardians of content consistency across entire digital ecosystems. We’re not just supporting products; we’re actively shaping user trust and business outcomes.

The homogenized content experience

Modern tech writers orchestrate homogenized content experiences that span:

  • Runtime documentation that AI systems consume during operation
  • Multi-modal content optimized for different access patterns - users don’t just read documentation linearly on a website anymore
  • Automated quality assurance that prevents content decay (see also Docs as Tests)
  • Cross-functional collaboration that embeds documentation in development workflows

We’ve evolved from the margins to the centre of product development, user experience design and business strategy.

Leading the way forward

Write the Docs Berlin made clear that successful organizations recognize documentation quality as a foundational capability that underpins all technical practices. I think that tech writers who embrace this evolution - from content creators to strategic product owners - will find themselves at the heart of their organizations’ success.

This shift requires product-level accountability. Forward-thinking tech writers can now own business metrics like time-to-first-successful-API-call, documentation-driven conversion rates and feature adoption velocity. These are product success metrics, not just content quality metrics.

Successful teams can gain the organizational authority to influence product decisions: “This feature is too complex to explain clearly - let’s simplify the product,” or “We need to delay this release until the information experience is ready.” This represents a fundamental elevation from content creation to strategic product ownership.

As Maximilian Rosin noted in his talk on theatrical theory and software documentation, we work in a world of representation and metaphor. Our job is to write truthfully about products that exist purely as digital constructs, helping users engage with computer illusions to achieve real-world effects.

That’s not just writing. That’s strategic communication design for the digital age.


The technical writer role continues to evolve and I’m sure it will keep changing in the future. I was highly inspired to write this post after watching Fabrizio Ferri-Benedetti’s talk at Write the Docs Berlin - Failing Well: A Practical Guide to Growth for Technical Writers.