For clarity, I'm going to use the term quality coach (QC), though in your world you may prefer Quality Advocate (QA), but personally I find that gets confused with Quality Assurance and often people default to that term.
Imagine you or your company has decided to transition to a Quality Assistance model, the one that has software developers owning their software testing. What does this new world look like? And what does this QC do? How will you know if a QC is doing a good or great job?
These are not easy questions to answer making it hard to create job descriptions. This is partly due to the newness of the role, but also QC tasks are difficult to quantify. They don't necessarily have concrete outputs in the form of artefacts. A Quality Coach focuses more on delivering outcomes, one being that a team is able to deliver quality features with minimal assistance. A heuristic for a successful quality coach? They're not needed by the team any more.
Regardless, creating a job description is a useful exercise. It helps drive clarity in your thinking about the role, and is a useful method to communicate how this role differs from a traditional software tester role.
The following is a process I used to help clarify the quality coach role.