Tuesday, March 23, 2010


I remember a few times throughout my childhood when a teacher would extol the virtues of writing for oneself. Whether it was taking notes, doodling, "mind-mapping," creating notecards from individual ideas, or simply writing down all the ideas that came into your head, there were always a few key messages:
  • You don't have to worry about remembering it anymore. A related Chinese proverb is, "the weakest ink is better than the strongest memory."
  • Once you get your thoughts down, you can physically/visually rearrange them to fit your goal (remembering them, making sense of them, etc.)
  • Writing down your thoughts helps you to find gaps in your reasoning or explanations, reinforce your opinions, and clarify your message.
This is all well and good, but ultimately, writing for yourself and yourself alone only serves to make you better. A noble pursuit, to be sure, but by making a simple tweak, you can get much more bang for your buck, not only increasing the positive effect that writing has on you, but broadening that positive influence to everyone you work with as well.


The goal I'm most excited to pursue over the next few months is a "documentation strategy" I'm going to assemble and present to my team. It's goal, in short, is to supplement the lifeless, monolithic spec templates we use here and encourage easy, simple and succinct publishing with a minimalist template. The focus is on publishing as opposed to writing because the benefits of having easily editable documents to collaborate over and record decisions and ideas are just too numerous to ignore.

It's not going to be easy - I need to develop and sell a strategy that isn't too "open" (I can't just tell my teammates to write clearer, more succinct documents without delivering something that they can use, like samples and templates) and isn't too "closed" (introducing another monolithic template and more hard rules defeats the point), all while convincing everyone that what looks like more work actually results in better quality with less effort. I have a whole lot of ideas and there are a few specific ones that a few specific, important people want to see, and so I need to make sure those get a good treatment as well.

I'm not going to get into heavy details in this post, but I am going to be writing about this more as I put this strategy together and figure out how to make it work for my team. Actually, one of the primary reasons I want to continue to write about this and show my work in progress is one of the reasons I want to introduce a strategy like this in the first place - it leads to greater collaboration and higher quality work. These two fellows from Google have some great insights about collaboration and showing your work to others, and how it leads to better quality work, faster. They talk about it in the context of version control systems, but these ideas outline one place I want to go to with this idea.

No comments: