Last week, I joined a very interesting webcast (organized by the folks at opensource.com) on motivation by Daniel Pink, author of Drive and A Whole New Mind. Pink’s thoughts about motivation, how it’s changed, and how organizations can motivate their employees offed a lot of food for thought. You can read the tweets from the webcast, and a recap of the webcast.
During the webcast, Pink mentioned an interesting way that software development shop Atlassian motivates its employees. It does that through FedEx Days. A FedEx Day:
is time set aside for developers to work on whatever they want with a skew towards our products. We tend to run “FedEx” with a fairly open format where you can do whatever you want as long as you can somehow relate it to our products. We have expanded it such that we set aside 1 1/2 days for the developers to complete their ideas. We start after lunch on a Thursday and work until 4pm Friday when we present what we have to everyone.
With FedEx Days, Atlassian is motivating employees to become more engaged by doing work outside of the boundaries of their jobs. It gives them a greater sense of purpose.
When I heard Pink talking about that, it sounded a lot like something done at Google called 20% time (hence the title of this post). Google encourages employees to work on personal projects 20% of the time. Those projects can be speculative, wacky, or visionary.
During Daniel Pink’s webcast, I started asking myself can this be applied to technical communication? The answer is yes and it has been done (more on this soon).
It’s just a matter of being able to set aside that time and how you use it.
Because I don’t jump all over the latest trends and tools in the tech comm world, I sometimes get labeled as old school or as a dinosaur. And that’s one of the nicer things that’s said about me …
It’s not that I’m afraid of technology or of change. That just bad thinking, pure and simple. But I do take a measured approach to just about everything. Simply because a new tool or technique promises to make my job easier, to write documentation by itself, to make me more charming, and brew me a perfect cup of green tea doesn’t mean I’m going to swallow those promises whole. I like to investigate. And, for the most part, those promises have fallen short. Sometimes far short.
Take, for example, screencasts. I like screencasts. I’ve used them. I’ve recorded them. I’ve written about them in this space (use the search box in the top right if you don’t believe me). But, like anything else, screencasts have their strengths and their limitations.
Anyone who writes for a living has been hit by writer’s block, or something like it, at one time or another. That includes technical writers, too.
What do I mean by writer’s block? A mental log jam. Acertain mental paralysis that stops us from putting words on the page, from developing effective procedures and diagrams and overview information. It’s frustrating and can be worse than annoying.
Over the years, I’ve had a few bouts of writers block in one form of another. Thankfully, each of those bouts weren’t incredibly bad but they were enough to put a dent in my productivity and to jeopardize a deadline or three.
I’ve tried a number of things over the years to get around writer’s block. Some worked. Most didn’t.