We are building a tool (Katara: https://katara.io) to help with this exact problem. It gives you a structured way to catalog everything in your organisation while enforcing consistency and ownership.
Confluence is a good tool for writing documentation but it gives you no way to enforce that every page of a certain type contains the same information, and it is super easy for a page to get orphaned/outdated without anyone knowing.
Katara sits on top of all of your tools and helps you manage it all.
You start by using Katara to model your org structure, i.e what teams do you have, who belongs to which, and how are they connected. You then create layouts that let you specify for a given type of page what information you expect and in what form, e.g. All product pages must link their API docs, their Jira board and their Figma project, ect. Every team page must contain getting started guides, a link to their support Slack channel, a mission statement, ect.
Then you create pages which are instances of those layouts, e.g a devops team page, product pages, feature pages, ect. Every page must be owned by a team (not an individual) which is backed by your org structure. If a team is disbanded or there is a reorg it’s not a problem, the pages are automatically reassigned (or you can reassign them manually). What’s really cool is that if a page is missing information it will create a task for the owning team to fill it in. You can even retroactively go and update layouts to require that every page of a certain type now contains new information, and all the teams that own a page of that type will be notified.
We essentially want to be the source of truth for your organisation. You still use Confluence to write/store docs, Figma to make design files, Jira for tickets, ect. We just sit on top and help catalog it all. There is no silver bullet to knowledge management but we make it easy to enforce knowledge sharing best practices in your org without a huge coordinated never ending manual effort.
Keen to chat if you are interested, we are looking for pilot customers at the moment :)
Oh good another competitor haha. I really like the way you worded the scaling issue, couldn't agree more. When I release it I'm hoping you're still in a shouting mood.
Maybe "Here's how I plan to rectify it" would have worked better... putting that aside you Jedd are in luck! Scribe isn't just any candidate, it's the candidate (If I can get enough people to throw money at me so I don't have to go get another job). I'll have a look at DekiWiki and Mindtouch tonight. What did they offer in terms of structured hierarchy that other tools don't? Also interested to see what this scriptable extensibility is.
I do agree that getting Enterprises to buy into my tool over Confluence will be really difficult, and until then I'll struggle to help you, but I'm lining up as many talks with people that can make that call as possible to see what I would have to do to make that a reality. One thing you might find interesting is that I plan to make Scribe free for public wikis, so while it might take some time for your team to use it, it might be useful to you if you do open source work? And if you like it enough maybe you can recommend it to your team, who knows!
I'm glad to hear I wasn't the only one experiencing this. When using the Scribe feature I mentioned to mdeeks if anything becomes outdated that was under your purview you will see it at the top of your feed. Didn't want to go down the notification route because I was worried you would get 100 notifications and just learn to ignore them
These are really great suggestions! I have been thinking a bit about ownership and accountability. The author thing is a good idea. Currently I was thinking that when you hover over a given block (e.g. paragraph, table, ect) you would see icons on who created and edited it so you would know who to ask if something wasn't clear.
As for #2 I fully 100% agree, I was going to work that into the Scribe feature (ability to have if-this-then-that actions) so you could say If this document is older than x days mark it as outdated for example.
I am quickly learning I need to spend more time wording things appropriately haha. To be clear it doesn't integrate with Confluence in any way, shape or form. Scribe is really a direct competitor to Confluence. But it will fix all the deficiencies that Confluence has.
Valid point, I've probably been reading a bit too much marketing focused material, figured the title would get more attention (which to be fair it did get you to comment). However I really do believe that tools like Confluence become terrible user experiences as your team grows. The wiki quickly becomes a black hole, documentation becomes hard to find, you have no idea if anyone read or found your content useful and outdated documentation becomes the norm. You could attribute this to the team or the company culture but I think it's more to do with the tool not giving you the primitives you need to do the job well.
Hey could you give it another read? I've added a bunch more detail about what the product actually does to try and tackle these problems. Thanks for the feedback, I somehow completely overlooked the fact I didn't tell you what it did haha
Cheeky, but all is fair in business I guess. I had a look at every product I could possibly find (Notion, Confluence, Slab, Bear, CodeStoryApp, Evernote, Dropbox Paper, Google Docs, GitHub Wiki, Quip, Guru, Slite, Coda... listing them out makes me anxious) and made sure to incorporate what I thought were really smart product decisions. From Slab I really liked the table of contents and having the search bar up the top left, I can't say much more was included in Scribe that doesn't exist in every other product tackling this space though.
Sorry, that could have been clearer. I meant the practice of pair programming, including user stories in Jira tickets (to explain why the ticket exists in the first place) and tests for your codebase to help others understand how the code operates.
I agree that a wiki will never be truly up to date, however I do think it's possible to build in mechanisms that tell people what is and isn't up to date. For example if a code snippet you include in your document changes (i.e. it's updated in GitHub) then the document should be either marked as outdated or in need of review.
As for discoverability you are right, it's definitely hard. My idea here is to allow people to create teams on the fly. You then have a feed that your team members and manager can push content to and manage.
Oh the numbers didn't mean anything, I was just trying to make it easier to read. Will see if I can reword it to make it clearer :)
As for them not being a problem with wikis, I think they are if you look at the wiki as not just being a collection of documents but as being a living breathing knowledge base. Interaction and collaboration are important to encourage if you want people to feel like their documents are actually being used. Even a simple clap button like Medium has would go a long way in this department. Insights into how your document is used would help show you how to refine the document, and also feeds into your work being valued. Plus it might really help managers gain a better understanding of the knowledge gaps that exist. Documentation becoming outdated is a reality that I feel most tools out there ignore, but addressing it is really important in having people trust what they read (I know my trust in my teams documents dropped off pretty rapidly after I kept finding them to be outdated). The last point was more of a thought I had two hours ago haha, and again really ties into having a living breathing knowledge base people can trust and want to use.