Everything, Everywhere, All at Once: Tags
Tags aren’t… dangerous per se. But they often appear more valuable than they are.
I can’t tell you the number of systems where I’ve immaculately tagged everything--dozens of categories with dozens to hundreds of entries. I can tell you how often I’ve searched by tags, and that number is zero.
Well, it’s probably above zero; but it’s near zero.
Great At Work covers this phenomenon. The takeaway is don’t gather data until you have a question. That means, in this case, don’t tag until you know how you will use it. Because, more than likely, you won’t.
If hierarchy is single inheritance and links are composition, tags would be mixins or multiple inheritance of small interfaces. And annotating your objects with every mixin you can think of--because maybe someday you’ll use it--is work without any reward.
How should you use tags to organize your Confluence pages? I don’t know. But I do know how you should find out. With the PARA+JD and MOC system described previously, wait for a problem it cannot solve. Then, and only then, consider whether you can solve your problem with tags.
We’ll go into several patterns people use with tags. You can consider this list when you run into an issue that perhaps tags can help solve. Tags are that port on the bottom of the original Nintendo that had grand dreams of all kinds of peripherals but was never used for anything.
Revenge of the Hierarchy
Tags’ most significant strength is also their greatest weakness. Tags are non-hierarchical. That means they can help you categorize things across your documentation that are cross-cutting and don’t fit into the hierarchy cleanly. This heterarchy can be good!
They’re often not as good as direct links in a MOC. They also tend to get polluted quickly.
The folder hierarchy’s simplicity is that you’ll see PARA at the top and up to ten folders of ten folders underneath, all with clear and logical names. They’re cohesive. Tags are not cohesive, and they’re all top-level. So if you try to navigate by tag, you’ll see a list of perhaps hundreds of tags: some with only one entry and no rhyme or reason as to what any of them mean.
You can simplify this, though, by using hierarchical tags. You can use a dash to make up “fake namespaces” in tags. (Obsidian supports / slashes, but Confluence is happier with - dashes.)
So rather than looking at some of the patterns people use for tags and adopting one and only one (e.g., “tags mean this”), you can adopt multiple uses of tags. They can all stay away from each other with hierarchy.
For instance, let’s say you want to go whole hog and annotate pages with keywords to help search for topics. You can adopt this tagging scheme; add “keyword-” to the beginning of every tag. (Or “topic-”).
Examples might be “topic-onboarding” or “keyword-data science.”
Did you get the Memo?
Page authors and maintainers can use tags to assign statuses to pages. While JIRA is probably a better tool to track the status of projects themselves, perhaps you want to mark a page as a draft or with a version. You can tag it with “status-draft” or “version-a.” Many tools support the idea of drafts and versioning. However, yours may not, or it’s not precisely your desired workflow.
Perhaps, for instance, you want to peer review your documentation, so you use a manual “status-unreviewed” tag so that people can easily search for documentation that needs review.
Intersectionality
Tags work best when they intersect. In other words, maybe you mark the type of a document–“type-minutes” for meeting minutes. Tags allow you to search for all meeting minutes within an area quickly. Or maybe you annotate a key client, “client-Enron,” and want to find all minutes with Enron, say for some litigation you’d like to avoid.
Remember, wait for a use case before you start using tags. Consider hierarchies as a way to protect your current tags from future tags and your future tags from your existing tags.
Remember My Password
If you want to collect pages you like easily; you can always use some personal tags. For example, if Charlie wants to remember a page about Go, he might tag the page with “personal-charlie-go.” (We’re assuming only one Charlie works at this company).
IOU MOC
Tags can serve as placeholders for eventual MOCs. You can tag all the pages you’d like to organize one day so that you have a place to click to find them all as a primitive MOC.
Tags and Templates
Tags often make certain things more automatable; so you should use design thinking when considering how to use them. Using tags without having a user is a product without a buyer.
Since tools can add tags (like template buttons on Confluence) and use tags (like an embedded query in Confluence), they become a great way to get various parts of your tool talking to one another.
Annotating meeting minutes with “type-minutes” can be time-consuming. However, having a template for meeting minutes that you’ve already annotated with that tag is effortless.
Similarly, having a dropdown table of recent meetings on your team’s MOC for people to get caught up on what they missed is labor-intensive. But it becomes automatic if it’s just an automated query on the tag (and a timestamp).
Where do I Even Begin?
All this can seem daunting. But, as the saying goes, any problem that exists is made better with more layers of abstraction (except the problem of too many layers).
I mentioned previously that you might start organizing your Confluence pages by talking with your team about what the PARA+JD breakdown looks like for you. Then, you may start trying to move things over. One more pattern that can help keep the work manageable is the inbox.
Let’s add one more folder to the top, the inbox. Don’t know where a doc goes yet? Why, it goes in the inbox.
Having a default place for new or unorganized docs to live allows you to segregate your friendly, clean system away from all the sloppy bits. It helps people easily find what needs organization. It will enable people to jot new ideas down without thinking about where they belong.
Indeed, you can move your whole current doc tree into a folder called inbox, set up some empty PARA+JD folders, and call it a day. That’s the seed crystal from which the rest of your documentation system may grow.
Hire A Librarian?
Let’s say you set up a Confluence page of onboarding about Confluence. In other words, required resources for new hires to read and reference material.
Maybe it includes this blog, some resources on PARA+JD, hints and tips on creating links, tags, and other power tools in your documentation tool of choice. It could even include a few quizzes and challenges to prove completion and application of the knowledge.
This training means everyone on staff can do the basics of documentation. This idea is what we call the “militia” approach. You need to do some work, so you do basic training of some citizen-soldiers, and they all share in the burden.
You can also regularize the work–bring in a dedicated professional whose whole job is to do this documentation. The two go hand in hand, much like the Army and National Guard work together.
Hiring a professional to manage Confluence or your documentation tool may borrow more from library science skills than technical writing. However, you’d expect a potential hire to have organizing and copy editing skills since they’d probably be doing both.
Naturally, they’re going to be more effective if they inherit something that’s already broadly organized; but they may push things in a direction away from simple PARA+JD to something more formal. They have the skills and tools to do this. PARA+JD is just a straightforward way to train people and probably the simplest thing that can possibly work.
A librarian should also be trained (or come in with) a product mindset. After all, when a user can’t find something in the documentation, it will be the librarian who’s now asked, “How do I foo the bar?” A great hire here will treat these questions as user stories, helping indicate to them where the documentation is weak and can be improved. Sure, they can help someone find what they’re seeking. But they also need to think at a higher level of abstraction: is our training weak? Are the docs too complex? Are we missing things?
How to Collaborate Between Toolsets
Okay, you’ve got a documentation system; but you need to work with a partner outside your organization who doesn’t have one or has a different one. Or, maybe you’re trying to get PARA+JD adopted, and you’ve only managed to organize your team’s documentation.
How do you work with others?
You can think of at least three maturity levels here. The level that applies to you will depend on your circumstances.
You might push to use the same system if there’s a strong history of a shared relationship and interest in streamlining things. This plan is probably the apparent approach. We find where we’re duplicating effort and get everything inside a single place in Confluence or wherever. This approach is the highest level of maturity; but you must have a strong foundation for this to work.
It may be better to have your various MOCs point at each other. So they use SharePoint, but you use Confluence. No big deal–have your main project MOC point to their SharePoint pages and your Confluence point back (assuming you work out all the permissioning).
If this is only a single project, the amount of cross-linking shouldn’t be too heavy of a burden. If things have to point back and forth often, work on building the social foundation necessary to reach a new maturity level.
If they don’t have a documentation system or aren’t willing to work with you, the lowest level of maturity you can handle is simply linking to their stuff in your MOC. This approach should require very little cooperation on the other party’s part (other than the permissions to view their stuff, which one would assume your team already has).
So, start with linking from your MOC. Try and sell the other party on the idea of linking back. Scale this up with more and more MOCs. Finally, merging the MOCs into one tool may make sense.
Sort, Don’t Search
Most documentation systems out there are heavily underused. That’s a shame because documentation is one of the few ways we can grow human capital and be more productive. We share knowledge, lessons, and information. Documentation can be a core tool of a learning organization.
A huge reason for this is that the search functionality on many documentation systems isn’t reliable enough for people to use that as their default path. Their default path becomes asking a question in Slack.
We’re not going to be able to fix search. Internal docs are just not built like the web or email. Instead, we need to re-discover our roots and organize our content like we used to.
The Projects-Areas-Resources-Archive system is a straightforward way to organize, as is the Johnny Decimal system. They combine effortlessly and can scale from a small team of a few people to hundreds of people working on many projects. The Map of Content (MOC) technique helps flesh out the rest, providing a well cross-linked documentation foundation to add more and more information.
New hires will be able to explore things and learn how to better search for them later. Missing docs are easier to spot. Duplication is easier to prevent. Much like a hash function, a good organization scheme means every document has a bucket to which everyone can agree it belongs. This system is relatively easy to train others in and can self-perpetuate.
P.S. There Are Other Ways
While writing this post, I saw this pop up on Reddit as an “opinionated way” to organize Obsidian (a personal knowledge system) for software engineers and managers. You can use most of what you apply to Obsidian in organizing your Confluence pages. If you see something you like, try adopting it!
We’re on a mission to make jobs suck less, one software management tip at a time. We need your help!
Do you want to stay up to date on the latest management tips to help your team stay productive?
Click “Subscribe to the Soapbox” below for more!
.png)