When the author leaves, who owns the article?
· 2 min read
Articles keep being read after their authors move on. Make sure the care for them does not leave too.
In brief
Many of the most useful knowledge articles were written by people who have since changed roles or left the organisation. The articles keep being read, but nobody keeps them up to date, and review reminders go to inboxes that no longer exist. This article explains why the problem is so common: most knowledge processes tie ownership to a named person, and people move on while their articles stay behind. Nobody decides to let the article go stale. It simply drifts, one unanswered reminder at a time. It argues for separating the author, who wrote the article, from the owner, who is accountable for it being right today, and for giving ownership to a team or role that outlasts any individual. It suggests practical habits, including a regular check for articles with inactive owners or authors, making reassignment part of leaving or changing roles, and asking whether an article with no sensible owner still needs to exist. It closes with one question to test any article people rely on: if it were wrong tomorrow, who would fix it? If the honest answer is nobody in particular, the article already has a problem, even if it is still correct. Knowledge is only as trustworthy as the care behind it, and that care should not leave with the person who wrote it.
Somebody wrote the best article in your knowledge base. It is clear, it is accurate, and it gets read every day.
Eighteen months ago they moved to another team. Last spring they left the organisation. The article still carries their name, and nobody has looked at it since.
This is one of the quietest risks in knowledge management. Articles do not stop being read when their authors move on. They only stop being looked after.
Why it happens
Most knowledge processes tie ownership to a person. That feels natural, because a person wrote it, and people take pride in their work. But people change roles, go on long leave, retire and resign. The article stays behind, and the review reminder goes to an inbox that no longer exists.
Nobody decides to let the article go stale. It simply drifts, one unanswered reminder at a time.
Owner and author are not the same job
The author is whoever wrote it. The owner is whoever is accountable for it being right today. Keeping those two ideas separate solves most of the problem.
An owner can be a role or a team rather than a named individual: the payroll team, the service desk lead, the network manager. Roles survive the people who fill them.
A few plain habits
- Give every article an owning team or role, not just an author.
- Run a regular check for articles whose owner or author is no longer active, and treat that list as work, not as a report.
- Make reassignment part of leaving or changing roles, alongside handing back the laptop.
- When an article has no sensible owner, ask whether it still needs to exist.
The question to carry
For any article people rely on, ask one thing: if this turned out to be wrong tomorrow, who would we expect to fix it? If the honest answer is "nobody in particular", the article already has a problem, even if it is still correct.
Knowledge is only as trustworthy as the care behind it. Make sure that care does not leave with the person who wrote it.
Next step
Tell us how your organisation handles articles when their author moves on, in the Knowledge and self-service conversation on ESM's Exchange: https://exchange.esm.institute
Tags: knowledge management, service management, ESM
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
How should the service desk handle a Microsoft 365 outage it cannot fix?
4 min read
Deploying AI is the easy part: who runs it once it goes live?
5 min read
How do I compare help desk tool pricing before rolling it out across several departments?
4 min read
Turning 'not helpful' into a fix
1 min read
Test after every change, or find out from users
1 min read
Designing a knowledge portal people want to use
1 min read
Related articles
How should the service desk handle a Microsoft 365 outage it cannot fix?
Treat a supplier cloud outage as your own major incident: log it once, tell people early on a channel that still works, update on a rhythm and review your dependency afterwards.
Deploying AI is the easy part: who runs it once it goes live?
Only a third of large enterprises have met the business case for their main AI programme. New research points to a gap in who runs AI after launch, and what leaders can do.
How do I compare help desk tool pricing before rolling it out across several departments?
Compare help desk tools on a full year's cost for your real agents, approvers and requesters in every department, not on the headline monthly price.
Turning 'not helpful' into a fix
'Not helpful' is free, honest feedback, and most of it goes nowhere. Turn that click into a fix.
Test after every change, or find out from users
Knowledge changes fail quietly. A short, repeatable test after every change finds the problem before your users do.
Designing a knowledge portal people want to use
Most knowledge portals are built for the people who run them, not the people who arrive with a problem.