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.
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.
“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.”
Aleksandra Zolushkina
JetBrains
“I'm embedded in the engineering team, I’m in their Slack channels. That’s the way to keep docs in sync — you have to be where the information is.”
Gareth Brinn
Gravitee
“We are a centralized team, but the writers themselves are embedded into multiple teams within Docker. They go to standups and planning meetings, but we come together as one technical writing team.”
Usha Mandya
Docker
“We have a massive team of technical writers — more than 250 right now, across the globe.”
Sandeep Medikonda
ServiceNow
“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.”
Aleksandra Zolushkina
JetBrains
“I'm embedded in the engineering team, I’m in their Slack channels. That’s the way to keep docs in sync — you have to be where the information is.”
Gareth Brinn
Gravitee
“We are a centralized team, but the writers themselves are embedded into multiple teams within Docker. They go to standups and planning meetings, but we come together as one technical writing team.”
Usha Mandya
Docker
“We have a massive team of technical writers — more than 250 right now, across the globe.”
Sandeep Medikonda
ServiceNow
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.
“Working with engineers? Give them repo access. Working with product people? Give them a WYSIWYG editor. Meet contributors where they are. And enforce standards programmatically.”
Manny Silva
Skyflow | Doc Detective
“When engineers know there’s a writer in their standup, they start flagging documentation-relevant changes themselves. It changes the culture.”
Gareth Brinn
Gravitee
“Where do you put tech writers? This has been a perennial issue — I’ve been bounced between multiple teams throughout my career. I'm seeing more and more people putting them in developer experience teams, which I think makes the most sense.”
Chris Chinchilla
Supabase
“Here at PostHog, our small teams own their products — and docs is one of our products. Our executives often attend our planning meetings because they care deeply about the Docs team's work.”
Sarah Sanders
PostHog
“Working with engineers? Give them repo access. Working with product people? Give them a WYSIWYG editor. Meet contributors where they are. And enforce standards programmatically.”
Manny Silva
Skyflow | Doc Detective
“When engineers know there’s a writer in their standup, they start flagging documentation-relevant changes themselves. It changes the culture.”
Gareth Brinn
Gravitee
“Where do you put tech writers? This has been a perennial issue — I’ve been bounced between multiple teams throughout my career. I'm seeing more and more people putting them in developer experience teams, which I think makes the most sense.”
Chris Chinchilla
Supabase
“Here at PostHog, our small teams own their products — and docs is one of our products. Our executives often attend our planning meetings because they care deeply about the Docs team's work.”
Sarah Sanders
PostHog
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%).
“I use a 60-20-20 capacity model for my team: 60% dedicated to your core assignments, 20% for additional projects we've identified as a team, 20% for professional development. The ratio can shift, but it's a good starting point.”
Sean Huck
Adyen
“We also function as a scrum team so that we are able to identify fires sooner in the cycle and flag them when we see them.”
Utsav Banerjee
New Relic
I talked to someone recently whose entire docs team was laid off. And then a person from another team was like, ‘Hey, you’re now in charge of this thing. Figure out how to make AI do it.’ And there was no infrastructure even set up.
Bekah Hawrot Weigel
Virtual Coffee
“The ratio of writers to product managers is something like 1:11. Each writer handles a very large surface area. My team makes it look like it’s just another day at the office.”
Vinay Payyapilly
New Relic
“I use a 60-20-20 capacity model for my team: 60% dedicated to your core assignments, 20% for additional projects we've identified as a team, 20% for professional development. The ratio can shift, but it's a good starting point.”
Sean Huck
Adyen
“We also function as a scrum team so that we are able to identify fires sooner in the cycle and flag them when we see them.”
Utsav Banerjee
New Relic
I talked to someone recently whose entire docs team was laid off. And then a person from another team was like, ‘Hey, you’re now in charge of this thing. Figure out how to make AI do it.’ And there was no infrastructure even set up.
Bekah Hawrot Weigel
Virtual Coffee
“The ratio of writers to product managers is something like 1:11. Each writer handles a very large surface area. My team makes it look like it’s just another day at the office.”
Vinay Payyapilly
New Relic
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.
