Catalyst 4: Wiki Manager (Overlooked)
As if I wasn't already doing enough, I also started to wear another hat: wiki manager. It turns out I failed in this role, but I'll still include it here because it segues into another topic I want to explore, which is spreading yourself too thin.
At the beginning of this essay I mentioned the community projects we started up. When you work for a nonprofit organization, especially a church, which people can feel a higher cause about, community members are often willing to dedicate their free time towards volunteer projects. If the Amish can pull together a community for barn-raising, and the early saints could sacrifice one day a week to build a temple, we could pull together an equivalent volunteer workforce to build a software application.
And it worked. Community developers volunteered their time to build applications. Community interaction designers volunteered their time to build interfaces. Community quality assurance engineers volunteered their time to test the application. And even community technical writers volunteered their time to write documentation for these applications.
Coordinating the technical writer volunteers -- assigning them to projects, helping them to get started, oriented, and moving forward with documentation -- is something my colleague and I were asked to do. It was a new role we were to play.
As the emails about volunteer efforts trickled in, I helped a few writers get started. I thought I could point them in the right direction, make sure they had access, and just check on their work every once in a while. In this way, I could help oversee the writing of dozens of projects. I could expand my capability to work on more projects, leverage more help material, and eventually build a small army of volunteer technical writers that I could count on to write documentation for virtually any project overnight.
It was a naive idea. I underestimated the time involved in management, especially management of remote, often inexperienced volunteers. The first real contributor was slow to start, needed extensive hand-holding, and got offended when I edited (actually renovated) his contributions. One day he just disappeared.
I realized that I spent more time trying to manage the potential writers than it would have taken me to write the documentation myself. I also spent weeks creating the wiki skin for the projects, branding it with the same look and feel as the home site.
We didn't have a formal style guide or a specific documentation approach. The freedom that comes with the flexibility I found so liberating also proved to be debilitating to these remote volunteers. The technical writing component of the projects just didn't take off. I neglected the projects due to deadlines with other projects. I eventually fell out of touch with the project managers and community, and before long, the documentation was completely absent.
My experience working as wiki manager with these community projects led me to wonder if I hadn't come to a point where I was spreading myself too thin.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.