Skip to content

The joys of being a Wiki Administrator

Every now and then I celebrate my job as Wiki Administrator and my workplace to my friends. I’ve praised our workplace, my job description, our work community and the products I am allowed to work with every day. In this post I’ll try to explain what makes it so wonderful.

First of all, let me clarify that I don’t live for work. My life contains more than just my job, even if I do like working. I don’t read e-mail at home. I don’t work on weekends unless changes are needed that cannot be implemented during production hours. This doesn’t happen too often – only once every few months. I log every single hour I work and all extra hours can be converted to paid leave later on. Thanks to this policy I have a splendid 7-8 weeks of paid vacation a year instead of the 5 weeks that are the legal norm in Finland. Not a bad tradeoff if you ask me.

Otherwise I work according to office hours. I come to work between 8.30 and 9 AM and leave between 4 and 5 PM. I work 35-42 hours a week, usually a bit more than the required 37.5 hours but not by a lot. The longest week I’ve worked must be about 50 hours, but this has always been due to system upgrades that have to be performed outside regular working hours.

I don’t really experience work fatigue. I always go to work with a cheerful attitude and stay a bit longer than the others so I can enjoy a couple of hours of uninterrupted work in a quiet environment. I often start planning my work as soon as I’ve woken up, and after I leave work I still process the events of the day in my head and already start planning my next day. Note that I don’t do this obsessively or because I have constant deadlines to meet, but because I am excited about the next day and the possibilities it brings. The expectation is always positive – I can’t wait to implement my plans, challenge and improve myself!

What does a ”Wiki Administrator” do?

So what do I really do for a living? This is difficult to explain because most people have such different levels of understanding about the IT industry and especially my field… wikis, online collaboration, corporate collaboration, communication, knowledge management… Some things can be explained in layman’s terms, but others simply cannot be understood unless one works in the IT industry or at an office in a mid-to-large-sized corporation where some sort of wiki or intranet exists (and the person uses it).

My job title is ”System Administrator” though that’s so unspecific that I prefer ”Wiki Administrator”. My responsibilities are most simply defined as: maintaining and developing our company wiki. ”Our company” is an IT service provider situated in Helsinki, Finland. We provide expert services (meaning: phone support, on-site support, server hosting, workstation deployment and maintenance, software tailoring, consulting) for mid-sized companies that have between a few hundred and a few thousand workstations or between a few dozen and a few hundred servers. We have 150 employees at the time of writing, and a bit under 100 of those work in my unit, IT infrastructure services.

The purpose of the wiki in our company has been ever evolving. Currently it houses the technical documentation about our clients’ IT infrastructure, processes, key personnel and other production documentation. It also holds knowledge base information about solving IT problems in general, team sites and internal operating instructions. To sum it up: pretty much all the daily documentation that is needed to work as an IT support professional.

Our wiki product of choice is Atlassian Confluence, an enterprise wiki. The main benefits of an ”enterprise” wiki are:

  • It can be connected to the corporate user directory, such as Microsoft Active Directory. No separate user management is necessary.
  • The page structure is hierarchical in nature so content can be planned.
  • The content of Office files can be viewed and edited in-place without downloading, opening, editing and uploading files constantly.
  • Content can be imported from Microsoft Word files including images and formatting.

These are only a few of the numerous benefits, but the most important aspect is that professional support is available seven days a week. You can be confident that problems can be solved in a timely manner without hampering corporate operation.

Btw: I love open-source

It’s wonderful to work with open source technologies. The wonder stems from the people working with open source. Their attitude to work is so enthusiastic and sincere. These are the technologies and associated communities I get to enjoy in my work:

Atlassian Confluence

Atlassian Confluence

  • Atlassian Confluence (source code is available to license holders)
  • MySQL
  • Java (albeit with conflicted emotions)
  • CentOS Linux + Apache Tomcat
  • HTML, CSS, web development in general
  • Notepad++

Okay, but what is it in practice?

So that’s a lot of background, but none of the above really says anything about my average day at work. So let me elaborate on my responsibilities a bit more. I am responsible for, among other things, making sure that:

  • The wiki stays operational during production hours (7AM to 9PM weekdays, 9AM to 6PM Saturdays, 12PM to 9PM Sundays)
  • The wiki infrastructure stays operational, is backed up and can quickly be brought back online when problems arise
  • The wiki supports daily operations by providing working documentation quickly and easily
  • The wiki grows and develops according to the needs of the corporate environment as the organization grows and matures

In practice the two latter responsibilities take the majority of my time. I constantly monitor the development of our organization. I make adjustments to content management tools or create new ones in order to facilitate daily support work. This means staying on top of changes to processes, management, personnel, organizational hierarchy, communication tools, ERP tools etc. I need to meet with lots of different stakeholders, collect feedback from users… And then use all of this information to plan the future of the wiki as a production support tool as well as a development tool.

We’ve had the wiki for about two years. I was there since the first workshops with the consulting firm that showed us the ropes. I even wrote my thesis about enterprise wiki adoption while we were launching the wiki (unfortunately not publicly available because of NDA content). My role has constantly evolved along with the role of the wiki; currently I spend perhaps 40% of my time maintaining the wiki and 60% developing it.

My calendar is usually rather empty. My superior doesn’t guide my work too strongly – priorities are checked every two weeks but that’s about it. My work is mostly autonomous… Or rather the environment dictates the direction of the wiki and therefore the content of my work. But I am the best (and only) judge of that direction. No one can tell me how the wiki should be developed in order to best serve the purposes of the organization. I typically have between 1 and 5 scheduled meetings per week. Often the meeting revolves around building documentation for a specific subject, and I advise someone on the content structure.

But just as often the meetings are about instruction. I arrange between 20 and 30 semi-formal group training sessions a year and perhaps 10 smaller, informal tutoring sessions a month for individuals or teams. The wiki changes constantly as the organization evolves, so personnel needs to be coached on an ongoing basis. A new tool might be introduced to the wiki. A process might change. The user interface might get some sort of update. Often the only reason for a tutoring session is that we have a new employee and he/she doesn’t necessarily know what a wiki is or how it is supposed to be used (especially in our organization). Our company is growing at a steady pace and new wiki users must be trained frequently.

On a related note, we suffer from a deficit in documentation specialists – people who know how a wiki works, how to write for the web, how to link, how to format technical documentation for optimum legibility, how to write in plain Finnish, how to use images… The skillset required is complex. These skills are very necessary but the time to teach and especially use these skills is scarce. The ”real work”, ie. supporting the clients, takes so much time that perhaps only 20% of the documentation effort required is actually achieved. Then again the situation could be worse. I believe most companies achieve only 0-5% of the required effort for ”excellent documentation”. I certainly won’t complain about my situation – we have plenty of eager learners after all, probably a couple dozen out of our 100 department employees. And the people I work with are really smart, talented and ambitious. It is wonderful to work with such a crew.

No, really: What do you DO?

All this and I still haven’t told you specifically what I do every day? Okay, here are some concrete examples of tasks I perform on a day-to-day basis:

  • Monitoring wiki content events. Who created what and where? What was the quality of the created content? Does it need attention? Quality assurance?
  • Monitoring out-of-date content. How many pages are out of date (have not been edited for a year or more)? Should they be updated or archived?
  • Monitoring Confluence-related news. Have there been platform updates? Plugin updates? New plugins? What functionality do the updates or new plugins bring? Do they have dependencies? What news is there on content management, knowledge management, intranets and wikis? How can we make use of all this information?
  • Controlling platform stability. Has the system been sluggish or crashed lately? If yes, then why? What can be improved? What are users complaining about? Fixing bugs, reporting issues, creating and maintaining tools for analysis.
  • Updating the platform. Testing and implementing Confluence and plugin updates, logging changes, announcing changes to users and training them accordingly.
  • Planning and implementing new content. Meeting and consulting with others about new content areas and integrating them with the whole. Consulting about content planning both internally and (sometimes) externally.
  • Managing wiki content as a whole. Maintaining and developing a content strategy. Occasional content inventory. Planning and revising structure, naming conventions, appearance and usage guidelines.
  • Creating and maintaining usage instructions for the wiki. Everyone needs to be able to use the features of our wiki efficiently and understand what we use it for.
  • Training and tutoring. Ongoing usage support. Solving daily problems and answering daily questions. Preparing regular announcements and training sessions. Personal tutoring as needed.

Sources of inspiration and contentment

As you can gather from the rather lengthy description above, my job as Wiki Administrator is versatile and involves collecting, processing, reformatting, utilizing and re-sharing a lot of information. This is fortunately also one of my strongest suits. My wiki career began by writing documentation into the wiki about on-site support working methods, processes and tools. I worked in on-site support for two years before becoming a full-time wiki administrator and during that time I supported our clients on-premises by helping with workstation, printer and mobile phone problems. My job required a lot of guides, checklists, problem solving resources etc. I was excited by the speed and ease of creating content in the wiki. Soon I was the de facto wiki expert, and here we are. :)

There are plenty of other skills I can make use of in my work. Developing the wiki with a sense of direction requires constant communication with other stakeholders. It requires being able to put yourself in the position of the user and understand his/her problems and needs. The purpose of the wiki is first and foremost to facilitate daily work, and in order to achieve this goal you must identify the pain points of daily operation in different teams. I’ve always been good at that. Before I had the position I have now, I was constantly frustrated by seeing the problems but not having the tools to fix them. There was simply no tool or method for making real changes in tools and working habits.

Changing working habits is, of course, a challenge of its own. If you have ever tried to accomplish cultural change within a group, you will know what I’m talking about. There is always resistance to change. There are those who will not change until they absolutely have to. But achieving change is also difficult because most people will resist change if it makes work (even temporarily) more difficult. Bringing about permanent cultural changes demands time, dedication, optimism (even faith), energy, willpower, communication skills, psychological skills… This has been and always will be the largest challenge I face. It is frustrating sometimes to realize that if I have an idea today that will make working a bit easier for everyone, implementing it might take six to twelve months. And it often does.

I think we had been using the wiki for a full year when we reached a major milestone: 50% of our unit finally used it daily or almost daily. The greatest adoption accelerator turned out to be having a branded theme. When the UI was customized so that the wiki finally had some personality yet fit into our company culture, it was no longer ”*sigh* yet another attempt at changing documentation habits in the company”. After all, there had been three or four earlier attempts at launching a company wiki. No, this was now a real system with purpose and direction. People started believing that this will become a significant, important tool.

About a month after launching the new theme, our unit had a workshop where the goal was to identify the pain points of our operations and come up with ideas for solutions. Nearly all ideas utilized the wiki somehow. ”Let’s put it on the wiki” was the phrase of the day. Suddenly the wiki was the de facto tool for operations development. Since that day, growth has been unrelenting and only a few months later I left my post in on-site support so I could focus on wiki development full-time.

In spite of change resistance and the sometimes unbearable delay in achieving change, I’m truly happy with my job. Few people are able to utilize almost every skill they have in their work. Few people have the freedom to plan their day and week independently without external pressure. Few people can come to the office at their leisure, say at 10 AM, without being reprimanded. Well, as long as the system stays operational and my support is available for problems and questions during office hours.

The gist

I love my job! The most wonderful thing about it all is the feeling of actually accomplishing change. The challenge of it all is what makes the accomplishments feel so rewarding. I know that not just anyone could have achieved the changes that my work has made possible, because I never lost faith. I’ve persistently executed my vision despite all obstacles. I have been able to build a system that, to a great degree, guides the work of 100 people in the organization and makes their work easier. We have thousands of pages in the wiki, a third of which I have personally contributed to. I have personally built the theme by studying the structure of the UI, through trial and error, even though it took me six months and 180 hours of work. I have documented an incredible amount of systems, tools, processes, teams, clients and other topics. I have single-handedly trained over 150 people to use the wiki over the course of 1.5 years.

A few years ago I could never focus on any one subject for more than a few months at a time. I lost interest quickly. This is the first subject in my life that I have been able to focus on for a year and a half without tiring and without giving up. There have been setbacks, but they have never lasted longer than a few days. I have never accomplished anything this concrete in my life, and I have never been so proud.

I only hope that you, too, may one day have such an inspiring occupation.

Articles in this series

Confluence logo