Confluence as a Knowledge System is like Democracy for Political systems: the worst ever, except for everything else that was tried. As much as I'd like to replace it, it did everything we needed and was better than any alternatives that we considered for both tech/non-tech teams.
The solution we had was to give one Space for each team/department in the company: one space for Customer Support, one for Engineering, Data Scientists, Business Analysts and Operations/Management. Each team lead was responsible in ensuring that other teams from the company could find the information needed, but aside from that we let each team organize itself.
The only hard rule was the one I stated above, everything else came somewhat organically. Managers and Business Analysts, for instance, still preferred to work in Word/Excel, so their pages was mostly just placeholders for Office Docs and attachments. This was fine by me, as long as they could always respond quickly with the right file/link if someone else in the team asked for something.
> The solution we had was to give one Space for each team/department in the company
This is the single biggest tip I would give any company who uses Confluence. For some reason, most companies I work for that use Confluence insist on using minimal separation of Spaces. I.e. IT in general has a Space, and my team has a folder nested 6 folders deep in some path that I can never remember and have to bookmark.
It makes search effectively useless. If I search for "X api documentation" I get 10,000 results ranging from meeting minutes that some unrelated team put up that just happen to use those terms, to pages from other teams documenting how they use the API.
A Space should be treated the same as a Jira project. If I had my way, I would create a Space every time we created a Jira project.
And my biggest request for the Confluence team would be better markdown support (I should be able to indicate that I want to type Markdown without having to click through a giant list), and a way to set up a space to sync from Markdown files stored in Git. Some of us don't want to use the WYSIWYG editor, and I would love to be able to use an MR review process for documentation changes before they go live.
From Steve Yegge's famous Rant about Google not understanding platforms:
So one day Jeff Bezos issued a mandate. He's doing
that all the time, of course, and people scramble like
ants being pounded with a rubber mallet whenever it
happens. But on one occasion -- back around 2002 I
think, plus or minus a year -- he issued a mandate that
was so out there, so huge and eye-bulgingly ponderous,
that it made all of his other mandates look like
unsolicited peer bonuses.
His Big Mandate went something along these lines:
All teams will henceforth expose their data and
functionality through service interfaces.
Teams must communicate with each other through these
interfaces.
There will be no other form of interprocess
communication allowed: no direct linking, no direct
reads of another team's data store, no shared-memory
model, no back-doors whatsoever. The only communication
allowed is via service interface calls over the
network.
It doesn't matter what technology they use. HTTP,
Corba, Pubsub, custom protocols -- doesn't matter.
Bezos doesn't care.
All service interfaces, without exception, must be
designed from the ground up to be externalizable.
That is to say, the team must plan and design to be
able to expose the interface to developers in the
outside world. No exceptions.
Anyone who doesn't do this will be fired.
Thank you; have a nice day!
I think about that a lot when designing any system, machine- or human-centered, that needs to communicate with a disparate group of entities. Encapsulate the implementation details to those who are closest to the actual information and have enough power to take action, and make the contact interfaces very explicit. This alone will get you 85% of a functional system. The rest is just selecting actors in your system that know how to cooperate and understands these boundaries.
The biggest problem is that "everything else that was tried" wasn't from experts who truly understand information management, nor has our industry learned patterns from other industries that also have similar problems.
I'm trying to do that work now. It's not even that I don't think it can be done in confluence or wikis in general, but rather we don't have a great methodology in organizing it.
I am afraid I won't be able to help you much there. Every place I saw trying to come up with a grand top-down scheme to organize documentation failed.
Too much structure, and people will wait until they have all of the details needed to start contributing, or they will not contribute unless it's "their job". Too much flexibility and they don't know where to start.
I found that it was always better to let documentation and knowledge sharing follow the same principles as code: let it come bottom-up, see what patterns emerge and only worry about structure when the current practices hit a bottleneck. But then again I never worked on any project that I had hundreds of people directly depending on the documentation, so it might not work as a strategy for larger-scale organizations.
The solution we had was to give one Space for each team/department in the company: one space for Customer Support, one for Engineering, Data Scientists, Business Analysts and Operations/Management. Each team lead was responsible in ensuring that other teams from the company could find the information needed, but aside from that we let each team organize itself.
The only hard rule was the one I stated above, everything else came somewhat organically. Managers and Business Analysts, for instance, still preferred to work in Word/Excel, so their pages was mostly just placeholders for Office Docs and attachments. This was fine by me, as long as they could always respond quickly with the right file/link if someone else in the team asked for something.