Who Should Write Release Notes in an Engineering Team?
The feature ships. The PR is merged. The deploy goes out. And then someone, usually in a Slack message that arrives at 4:45 on a Friday, asks: "Who is handling release notes?"
The engineers look at the product manager. The product manager looks at the technical writer. The technical writer looks at the support team. Nobody moves. Eventually someone writes "Bug fixes and performance improvements" and calls it done.
Release notes keep falling through the cracks because no one has decided, in advance, who owns them and what the handoff looks like. That is a sequencing problem, not a people problem. The answer to "who should write them" depends on what your team is optimizing for, but the more important question is whether you have a process at all.
Here is the short version: the person closest to the customer should own the final output, and the person closest to the code should supply the raw material. In most teams, those are different people. The gap between them is where release notes go to die.
The Five Models Teams Actually Use
Engineers writing their own release notes is the most common default, and it makes a certain kind of sense. They know what changed. They have the context. The problem is that engineers write for engineers. A note that says "Refactored authentication middleware to support OAuth 2.0 with PKCE extension" is technically accurate and practically useless to the person who just wants to know they can now sign in with Google. The Conventional Commits specification and tools like GitHub's automated release notes can generate changelogs from commit history, which is a genuine improvement over nothing. But a changelog is not a release note. As the Keep a Changelog standard points out, changelogs are for humans, not machines, but they are still just chronologically ordered lists of changes. They are the raw material for release notes, not the final product.
Product managers consolidating input from engineering is the model that tends to produce the clearest customer communication. PMs sit at the intersection of what shipped and why it matters, which is exactly the perspective release notes need. The cost is time. PMs have to chase down engineers for context, and the information they get is often incomplete. When a PM misunderstands a technical detail, the resulting note can be wrong in ways that are hard to catch until a customer calls support about it.
Technical writers owning the process end-to-end is the highest-quality model, when it is available. A skilled technical writer embedded in an engineering team can improve communication, maintain consistency, and free engineers to focus on building. The bottleneck is headcount. Most teams do not have a dedicated technical writer for every product area, and when writers are spread thin, release notes are usually the first thing that slips.
Support and customer success teams translating engineering output into customer language is underused and often quite good. Support teams know exactly what confuses users. They have read the tickets. They know which changes will generate questions and which ones will go unnoticed. Clear release notes reduce support volume and improve customer satisfaction, and the people who feel that impact most directly are often the ones best positioned to write for it. In fact, research on self-service support shows that comprehensive documentation can remarkably reduce the volume of IT support tickets. The downside is that support teams are already overwhelmed, and asking them to also own documentation is a good way to ensure it gets done badly.
The hybrid model, where engineers draft and another role edits and publishes, is what most high-functioning teams land on eventually. Engineers provide structured input as part of the PR or ticket workflow. A PM, writer, or support lead shapes that input into something customer-facing. The model works because it respects what each role is actually good at. It fails when the handoff is informal, because informal handoffs produce knowledge loss and inconsistent output. As teams scale, engineering knowledge disappears without intentional knowledge-sharing systems and structured documentation.
What Each Model is Actually Optimizing For
The right model is the one your team will actually follow. A perfect process that requires heroic effort every release cycle is worse than a good-enough process that runs automatically.
The Part That Matters More Than Who
Most debates about release note ownership get stuck on the "who" and skip the "how." The real question is whether you have a structured workflow that captures engineering context at the source and routes it to whoever is doing the writing.
When engineers document changes in a consistent format as part of their normal workflow, the downstream work gets dramatically easier. A PM shaping the narrative does not have to chase down context. A technical writer validating accuracy has something to work from. A support lead translating for customers is not starting from scratch. Empirical studies on pull requests show that effective PR descriptions—which capture the purpose and code explanations—are highly valued by developers for preserving the rationale and history of changes.
Research on software release notes consistently finds that the quality problems are not primarily writing problems. They are process problems: inconsistent input, unclear ownership, and no reliable mechanism for capturing what actually changed and why it matters. Furthermore, studies on release notes patterns indicate that apps with longer, more detailed release notes tend to have higher average user ratings. Fixing the writing without fixing the process is like editing a document that keeps getting overwritten.
Anyway. The through-line across every model that works is the same: treat release notes as a structured workflow, not a writing assignment that gets handed to whoever is available at the end of a sprint.
Doc Holiday pulls release notes directly from your engineering workflows, giving whoever owns the final output a structured, accurate foundation to work from. Whether that is a product manager shaping the narrative, a technical writer validating accuracy, or an engineer who just wants the basics handled automatically, the process structure is already there. You are not rebuilding it every release.
