Have to agree. Without a clear set of standards on how to structure things, it ends up being chaos very quickly. We had a PM for a while, who gravitated more to

Have to agree. Without a clear set of standards on how to structure things, it ends up being chaos very quickly. We had a PM for a while, who gravitated more towards QA, and when they got ahold of Confluence they went crazy (in a mostly good way). We had so many great "How To" articles on how to perform various tasks in our system form an internal user perspective, all authored by the same SME. Unfortunately, given their affinity for testing things, the How To docs starting taking on that QA perspective and everything ended up in a QA "space". Sure, it's easy to move them around, but there wasn't a clear cut way on how to separate the "How To" from the "QA" - and then they left. Since then, people add things when managers say "make sure that's in Confluence" and it ends up getting placed in the areas they're most familiar with, not necessarily where it should be. Add in the aforementioned lack of standards and no two documents look the same. Then we started using Confluence for devs to write Test Plans and QA to execute them - and now it just makes my brain hurt whenever I have to go in there. Some of it is a cultural problem: we're email and Teams heavy and so much of our "documentation" is buried in those tools. So then we adopt something like Confluence to move our knowledge base to that, but finding stuff in Teams is a nightmare (posted in another thread on that). So now rather than having one tool to rule them all, we just have another half-baked attempt. We're monolithic for the most part, so I'm not sure Backstage would help us, but the article mentioned Stack Overflow for Teams, so maybe that would? (insert relevant XKCD here on competing standards)