Docs team structure
Featured Voices
Usha Mandya
Docker
Aleksandra Zolushkina
JetBrains
Vinay Payyapilly, Marco Spinello
How many tech writers is enough tech writers?
Usha Mandya manages Docker’s entire documentation operation with a team of four writers. The team sits under product growth, uses a docs-as-code workflow with a public GitHub repo and Hugo, and runs bi-weekly syncs with support to identify documentation gaps from ticket patterns.
“A lot of times, documentation teams struggle to get buy-in. Luckily at Docker, leadership understands the value that documentation brings.”
Even with strong leadership support, the team carries a broad scope — front-end styling, deployment, and platform maintenance without dedicated engineering support.
Her team has started experimenting with AI agents that create pull requests from GitHub issues, and she sees AI handling more routine work, like running first-pass reviews against the style guide.
“Triaging issues, broken links, and fixes… places where you traditionally expect a writer to go and take a look — that’s where AI is taking over.”
Docker has recently deployed three agents that make this concrete: a freshness agent scans existing content and opens GitHub issues where docs need updating; a PR creation agent turns those issues into pull requests; and a review agent checks quality against the style guide before changes go out.
The leverage comes from using AI for repetitive tasks so writers can focus on the harder problems — understanding new features, working with engineers, and making judgment calls about what users need.
Aleksandra Zolushkina leads a larger team at JetBrains but faces a different version of the same challenge: consistency at scale. JetBrains has 17 technical writers across its family of IDEs. All writers share a single repository and coordinate across products.
“We don’t sit separately in our own room. I think it’s really important to make sure technical writers are fully integrated with the product teams.”
Each writer is embedded in a product team while also being part of the broader tech writing group. The result is that writers stay close enough to the product to catch things others miss.
“We get to stay very close to the product that we develop and describe. And sometimes we notice bugs that other people don’t notice because we use our IDE in a very specific way.”
The scale challenge shows up everywhere. Vinay Payyapilly at New Relic describes a 1:11 writer-to-PM ratio: “Each writer does handle a very large surface area when it comes to the product. My team makes it look like it’s just another day at the office.”
And Marco Spinello at Booking.com captures the reality of the embedded model at scale: “There’s very few of us and we’re scattered across the company. We usually have a main team to work for, and then a bunch of other teams that we collaborate with.”
Whether it’s four writers or 17, the teams that work aren’t the ones with the highest headcount. They’re the ones with the clearest systems for embedding in the product, enforcing consistency, and deciding what to prioritize when everything feels urgent.
Documentation teams come in almost every configuration imaginable — from a solo writer at a startup to 250-plus practitioners spread across a global enterprise. What the featured voices in this section reveal is that headcount, on its own, explains very little. A four-person team can outperform a much larger one; a single writer can build systems that scale across a whole company.
What actually drives quality and sustainability is how the team is embedded: whether writers are close enough to the product to catch what others miss, whether the organization has thought clearly about who owns what, and whether they have other writers with whom they can collaborate and share best practices.
That question of ownership is more urgent in 2026 than it's been before. AI is compressing product cycles, which means documentation timelines compress with them. Teams without clear structure feel that pressure most acutely, and the data reflects it. This section looks at who's responsible for documentation, how teams are organized, where they sit in the org chart, and what those structural choices mean for a team’s ability to keep pace.
Who's responsible for documentation
Technical writers lead at 55%, but Product (44%) and Engineering (39%) are close behind. Customer support (29%) is a new explicit option in 2026, selected by nearly a third of respondents, confirming that docs are a cross-functional responsibility.
How docs teams are structured
Centralized teams remain the most common structure at 35.6%, but 22% of organizations have no formal documentation team at all. The hybrid model — a central team with some decentralized support — is at 16% and growing.
Organizational structure matters for AI readiness — and the pattern holds across every dimension we tested. Organizations with no formal doc team are behind on AI-powered feature adoption (60% vs 79-81%), behind on AI creation usage (70% regular vs 79-80%), and dramatically behind on governance (26% have AI guidelines vs 47-49%). The data are clear — teams leading on future-proofing and AI have formally-organized documentation teams.
Where docs fits into the org chart
Documentation teams most commonly report to Product (27%) or CEO/Leadership directly (20%) — and less commonly to Engineering (13%), Support (9%), or Marketing (5%).
Year-over-year comparison
The team structure data has remained fairly stable from 2025 to 2026.
The cross-functional nature of documentation responsibility has remained consistent, with technical writers, product, and engineering all playing significant roles in both years.
The 2026 survey saw the addition of an “I don't know” option, which may explain the reduction in “No formal documentation team”.
Strategic implications
Organizations with dedicated docs teams ship more AI features. Companies with centralized or hybrid docs teams lead on AI feature adoption, and even companies with decentralized teams do better than companies without dedicated docs teams. Companies planning their documentation organization should consider structuring teams so docs practitioners can learn from and teach their peers.
Small teams are carrying large loads. With writer-to-PM ratios reaching 1:11 at companies like New Relic, the industry is asking very small teams to cover very large product surfaces. These teams can punch above their weight with good systems and AI-assisted workflows, but organizations should be honest about what they’re asking of their documentation teams.
Increases in engineering velocity impact docs teams. AI coding assistants are helping some engineering teams ship features faster than ever, which means docs teams need to keep pace. The same AI tools that accelerate engineering can accelerate documentation — but only if teams invest in adopting them.
