How to Get Engineers to Contribute to Documentation

Most help center content at SaaS companies is maintained by one or two people who aren't engineers. Engineers ship the features, but they don't write the articles explaining those features to customers. The standard advice is to change that by getting engineers to contribute. Having talked to dozens of support and knowledge teams, we think the advice is well-intentioned and mostly wrong. The teams doing this better have stopped asking engineers to write and started capturing what engineers already produce.

Your help center is always behind your product because the people building the product aren't the ones documenting it.

Gerald Weinberg, the psychologist who spent decades studying how programmers work, observed a structural truth that hasn't changed since he first wrote about it: engineers are evaluated on shipping code, not on the number of pages of documentation they write. Stack Overflow's 2025 developer survey found that 68% of developers use technical documentation as their top learning resource, which means they consume docs constantly but rarely produce them. The same survey found that roughly a quarter of developers now use AI to help create or maintain documentation, up significantly from the year before. The tools are changing. The underlying dynamic is the same: asking engineers to also maintain a customer-facing help center is asking them to do a job that sits outside their evaluation criteria, their skill set, and their daily workflow.

That doesn't mean their work has nothing to do with documentation, but the handoff between what engineers know and what the help center says is broken.

The bottleneck is transfer, not writing

One technical writer described her week at a company with around 700 employees: she writes the internal release notes, external release notes, updates internal documentation, updates external documentation, and leads the monthly release training for the entire company. She is one of two writers, and the bottleneck she described wasn't that she couldn't write fast enough. It was that she couldn't find out what had changed fast enough.

Sometimes, documentation writers spends four to five hours a week just figuring out what needs updating before writing a single word. The help center gets updated eventually, sometimes that same week, sometimes not, and in the meantime Slack has the answer and the help center doesn't.

"I'll be honest, we don't have a single Slack channel where it says this was just launched."
Knowledge manager, edtech company

At another company, the support lead described the pace of change as something she couldn't outrun:

"They push multiple times a day, all throughout the day. There hasn't ever been a [time when] the help center matches what our actual product is doing today."
Support lead, SaaS company

And at another, the backlog was growing faster than the team could work through it:

"It just keeps getting backed up, backed up... the more the release notes channel takes off. It's only gonna take off more because we just hired two new engineers."
Support lead, creative operations platform

Hiring more engineers makes the documentation problem worse, not better, because every new engineer ships more features that the same one or two documentation people need to track.

Why "just get engineers to write" fails

The advice to get engineers involved in documentation comes from a good place. If you look at engineer: they know the product best, so they should be the ones explaining it. In practice, it runs into three problems that the companies we talk to describe in nearly identical terms.

The first is that engineers don't want to do it, for rational reasons. Their performance reviews, promotions, and daily priorities are tied to shipping software.

The second is that engineers write differently than customers read. A product manager at a data intelligence startup told us what he needed was "a simple way to document without formal writing." He was willing to share what he knew but not willing to structure it as a help center article. The documentation engineers consume daily (API references, README files, code comments) is different in tone and structure from the customer-facing articles a help center requires. They read docs all day and can still find it unnatural to write one for a non-technical audience.

The third is that the ask disappears into the backlog. Even when engineers agree that documentation matters, the task competes with shipping deadlines, bug fixes, code reviews, and sprint commitments. One engineering team at a webinar platform went from shipping 20 features in a full year to 15 features in a single quarter after building a new AI product. Their support team was already stretched thin. Adding "write a help article" to the engineering sprint was never going to work at that velocity.

What Uber did differently

Uber's documentation lead, Stephanie Blotner, took a different approach that's worth looking at because it starts from the same reality: engineers won't voluntarily sit down and write articles.

Her team's first move was to stop framing documentation as overhead and start framing it as a solution to a specific pain engineers already felt. If she noticed one engineering team constantly answering the same questions from other teams, she showed them exactly how an article could stop that. Her framing was direct: documentation exists to solve a specific problem, and the team should be able to name that problem before they start writing.

Her second move was structural. Every new engineer and engineering manager at Uber attends a technical communication course during onboarding. The course is about an hour, taught by a tech writer or a fellow engineer, and focuses on three questions every document should answer: who is the audience, what was the issue, and how was it solved. The goal is to give engineers enough of a framework that when they do produce something, it's usable.

Her third move was cultural. She identified what she called "Doc Stars," people across the company who already cared about documentation, and celebrated them in a newsletter she sent to engineering teams. This created visible recognition for something that was otherwise invisible work.

Uber has the resources to build a formal program around this, which most SaaS companies with 200 to 500 employees do not. But the principle Blotner articulated applies at any scale: how do you make the knowledge engineers already produce available to the people who maintain the help center?

Engineers already document. They just don't call it that.

Every Jira ticket that describes a change contains information a knowledge manager needs. Every Slack thread where an engineer explains a workaround is an unpublished help article. Every PR description that says "moved the settings toggle from Account to Billing" is a signal that an existing article is now wrong.

The problem isn't that engineers don't document. They document all the time, in tickets, in Slack threads, in PR descriptions, in internal wikis, in release notes channels. The problem is that none of that makes it into the help center without someone manually going through every channel, finding the relevant updates, figuring out which articles they affect, and rewriting the content for a customer audience.

This is the problem a growing number of tools are trying to solve in 2026. Red Hat open-sourced a "Code-to-Docs" tool in April that analyzes code diffs and generates documentation pull requests. Mintlify's writing agent watches codebases for user-facing changes and drafts updates. The pattern across all of them is the same: instead of asking engineers to write, extract documentation from the engineering artifacts that already exist.

Pageloop takes this approach for customer-facing help centers specifically. It connects to Jira, Linear, Slack, and GitHub, watches for signals that published articles need to change, and drafts updates when it finds them. When a Jira ticket closes that touches something a published article documents, Pageloop surfaces that article and writes the revision. When a Slack thread surfaces a question with no matching article, it flags the gap. Engineers don't change their workflow. The documentation happens as a byproduct of the work they're already doing, reviewed and approved by a human before it goes live.

What smaller teams can do this week

If you don't have a documentation program, a "Doc Stars" newsletter, or a tool that watches your engineering signals, there are still things that help based on what we've seen work at the teams we talk to.

Ask your PM to add three lines to the Slack message they already post when a feature ships: what changed, who it affects, and what the customer will see differently. That turns a message the PM was going to write anyway into something the knowledge manager can work from without spending an hour reverse-engineering the ticket.

Pick one channel and make it the source of truth for customer-facing changes. The teams struggling most are the ones where product updates are scattered across 12 channels and buried in threads. The teams doing better have a single channel where every customer-facing change gets posted, even if it's just a one-liner with a link to the ticket.

Stop asking engineers to write articles and start asking them to review drafts. An engineer who would never write a help article from scratch will spend five minutes confirming that a draft someone else wrote is technically accurate. The draft can come from the knowledge manager, from an AI writer, or from a template filled with information pulled from the ticket. The engineer's job is verification, not authorship.

Treat documentation as part of the release, not an afterthought that happens a week later. One company we spoke with described the shift this way: shipping a feature without updating the docs is like shipping a feature without writing tests. It feels faster in the moment and creates more work downstream.


Image courtesy Art UK
The Jetty at Trouville, Eugène Louis Boudin (1824–1898)