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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.