Creativity in the Workplace
In previous posts, I've explored whether technical writing is boring. Penelope Trunk's latest post, All advice on how to manage creative people is awful, made me see the topic of workplace boredom in a different light.
Citing research in sociology, Penelope explains that "people who work are happier than people who don't because people who are employed spend more of their time being creative." Creativity, then, is an important factor in personal happiness and fulfillment. Most of us know that. But here's how you measure the degree of creativity in your work. Penelope says,
How can you tell if you are creative at work? You could just ask yourself if you like your job. It is nearly impossible to like a job if you are not solving problems that are challenging. And if you are doing that, well, that is creative.
For a more scientific gauge, you can look at your cell phone call log. If you routinely call your friends from work, you're probably not happy at work, according to research from Nathan Eagle, at the Santa Fe Institute.
In other words, one measure of creativity at your job is whether you're solving challenging problems all day. If you're not presented with these problems, then most likely you're talking on the phone instead. (Keeping yourself busy with e-mail, Twitter, IM, and other online chatter is the equivalent of talking on the phone.)
Most people consider writing to be a creative endeavor, and in some situations, it certainly is. But creativity is not just associated with writing, art, and the humanities. Penelope broadens creativity to include problem solving too.
In many ways, even though technical writing involves writing, the writing can be less creative than coding a program or creating a user interface. Technical writing can even be less creative than designing the look and feel of the online help that will house the writing. Many times writing procedural information is not creative at all, in fact. Sure, there's a need to figure out how the application works, but once you've done that, merely transcribing how to do tasks in the system can make you start yawning. There are no more problems to solve. It's mere knowledge transfer. When knowledge transfer is what you spend your day doing, technical writing loses the power of creative fulfillment.
On the flip side, because technical writing poses numerous technical challenges outside of writing, with solutions not always apparent or easy, technical writing can also be engaging. The technical side of our profession is actually what engages me more than the writing, even though I was initially attracted to the idea of writing.
I've been thinking about this unexpected reversal a lot lately because I've noticed how consuming I find technical challenges in contrast to writing. I'm drawn to problem solving with web issues, especially WordPress sites, to an almost addictive degree. When I'm working on a WordPress project, it consumes me entirely. I can easily sit at the computer for an entire afternoon or evening working on problem after problem, ignoring everything else. Building websites often includes an almost endless supply of problems to solve.
Changing how something looks is only one part of the game. Finding the additional functionality you need, figuring out the best way to organize the content, designing the navigation with usability in mind, configuring new plugins -- all of these questions and problems provide engagement with the mind. For me, coming up with solutions is a creative act that surpasses the writing of technical procedures.
Fortunately, writing only takes up a small part of the technical writer's day, as Shanghai tech writer notes. Once you've finished the writing layer of a project, there are countless other technical issues to address, everything from single sourcing the content to designing the online help skin to figuring out relationship tables in Flare. I used to think these tasks were ancillary to the core task of the written content. But now I realize that as far as engagement goes, it's the other way around. The technical challenges are the rewarding, creative part.
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.