A wiki “hierarchy of needs”: Support on a sliding scale

[#1]

When someone wants a wiki space, but can't commit resources to help manage it, then what? When there’s only one of you, but thousands of users and pages, how do you prioritize?

When I inherited the admin role for a new wiki space, I had a lot of questions.

• What percentage of my time should be spent on the new space?
• Who else was contributing content?
• How much content needed to be imported?
• Who else should have admin superpowers?
• How would this change in the future?

The answers changed weekly at this early stage, so I needed a manageable approach, and fast.

Scaling support was already a familiar concept to me from my prior corporate communications role. Our small team couldn't provide full-service communications support to every group, site or department. We decided what flexible "service tiers" we'd offer, and to whom, based on their size, complexity and needs.

Maslow's hierarchy of needs came to mind, too. As basic levels of human needs are met, greater self-actualization becomes possible. This could be true for a wiki space, too: the more time or resources to manage it, the better it could become. I used Maslow's model as the basis for my "wiki hierarchy of needs."

If the levels, priorities, and example tasks in my model don't reflect your own space's daily reality, that's okay. Every company, space and audience is different, and priorities change over a space's lifecycle. What's important is the idea of prioritizing based on how much time and people resources are available; this is one framework for doing that, and what I did as a space admin as this young wiki space evolved. Here's the basic model. Each tier includes the tasks in the tier above it.

Critical Few: "No one has any bandwidth" to help manage the space.
When I started, two people were handling access and permissions and had created the main areas of the page tree, and that was about it. Aside from access, here I'd prioritize backups and responding to IT (ignore at your own peril). At first, contributors fended for themselves in a Wild West wiki.

Low resources available: Volunteers or a small team of people who keep an eye on things.
At first, the new space took about 15% of my time. I redesigned the home page to let everyone know the new Sheriff was in town. Here I prioritized structure and functionality, cultivating the secondary branches of the wiki page bonsai tree, and importing fundamental content. I wrote documentation guidelines--what goes where--including a "law and order" section. I improved search boxes and added labels to every new page with future functionality in mind.

Medium resources available: Estimated half-time attention and management.
I spent several months dividing my time about 50/50 between two projects. Here I prioritized content curation within an established page tree. I began to check for out-of-date content now that the space was more mature. I fixed broken or ugly pages and removed placeholder and obsolete pages. I surfaced recent edits, comments, and featured pages, and posted current news on the home page to encourage participation and engagement. I continued to build relationships with, and build out sections for, subject matter experts. I calendared out maintenance tasks and began building self-help or DIY resources.

High resources available: Full-time or nearly full-time curation.
Here's where I am today, as the new space ascends in importance and the other needs less oversight. Now I'm focusing on content, usability and education. I have some bandwidth for reporting and metrics, and for proactive improvements and redesigns. Believe it or not, I read every single page edit and comment via email to understand what users are working on, confused by or initiating, so I can offer help. I communicate regularly to the labs about knowledge resources and recognize key contributors. With the greater organization in mind, I have created and shared templates, self-service resources, and example pages. I'm about to launch a second round of a "Wiki 101" training series that's open to all Confluence users, not just my labs.

Using this model helps me balance essential wiki space tasks with the other tasks and priorities that compete for my time and attention. I feel very lucky that it's my job to proactively make an important knowledge resource better and more useful. Our developers are happier, too, knowing that someone has their back regarding documentation, responds to their suggestions, and has their best interests in mind.

I would love to hear how others would prioritize essential space admin tasks, or how they've learned to do what's most important with what's available.

[Jessica]

This is great, thanks for sharing! When I was managing a Confluence site I took a similar approach where the strategy was to empower space owners as much as possible. I built a Wiki 101 and 102 and made sure how-to and articles were easily available and discoverable.

I hadn't seen put together like this before though and think it is super helpful!