Who owns your error messages?
Ask five people on a product team who owns the error messages. You will get five answers, and at least two of them will be a shrug.
Engineering wrote them, so engineering owns them. Design owns the interface, and the message is part of the interface. Support explains them all day, so support knows best what they should say. Product decides what the feature does, and the message describes what it did.
Everyone is a little bit right, which is how a thing ends up with no owner at all.
How you can tell nobody owns them
Ownership is not a line in a document. It shows up in three places.
Nobody can list them. Ask for all the error messages in your product. If the answer involves grepping, they are not owned; they are scattered.
Nobody has read them together. Errors written by different people in different months read like different products. "Something went wrong." "We couldn't process that." "Invalid input." Individually fine, together a mess.
Nobody has fixed the one everybody complains about. Every team has one message that generates tickets. It survives because fixing it belongs to no one, and because the person who is annoyed by it cannot change it.
Why it lands on engineering by default
Not because engineers want it. Because of where the string lives.
A message inside a component can only be changed by someone who can edit that component. So the question "who owns this sentence" gets answered by your repository permissions, which were never designed to answer it. Your support lead may be the person most qualified to write that message and least able to change it.
That is also why the answer "let's write better error messages" never sticks. You can agree on it in a workshop and be back where you were in a month, because the workflow decides, not the intention.
What ownership actually needs
Three things, and the first one is not a process.
An address per message. If it cannot be pointed at, it cannot be owned. Each message gets a key, and that key is how your product asks for it.
One person who can change it without asking. Ownership without the ability to publish is review duty, not ownership. Whoever owns the words needs to be able to change them and see the result, today.
A list. Once every message has an address, you can see them all on one page. Reading them in one sitting is uncomfortable and it is the most valuable hour your product team will spend this quarter.
A reasonable division
There is no rule that this must be one person, but there is a rule that it must be someone.
- Support owns the wording of failures. They see which sentence produces a ticket, and the change is one edit away.
- Product owns the wording of the first run. Onboarding text is a promise about what the product is for.
- Engineering owns when a message appears, which is the part that genuinely is logic.
That split works because it follows the knowledge, not the file layout.
The question underneath
"Who owns your error messages" sounds like a governance question. It is really a question about your build.
If the answer requires a deploy, you do not have an owner. You have a queue.