Posts Tagged collaboration
This article originally appeared as a TWiki post in November of 2007, a companion to another article titled Why We Need Forums.
Blogs are a place to record musings. Often these consist of interesting links they just went to, with commentary on what they thought when they read it. These little thoughts don’t tend to be enough to merit an R&D meeting to share, but are valuable for others in Development to read.
The blog has these unique features:
- Low-risk thought preservation: Blogs provide a place to record thoughts that may be worth eventually developing into a TWiki page or a presentation, or may not be. You don’t have to decide now, but the thought is preserved and can be pulled up again, potentially to help form the basis of later decisions.
- Low-cost brain share: Others are interested in what thought leaders are thinking about, and blogs provide them a way of keeping up on this without having to bug them in person.
- Only needs one: Blogs don’t require a critical mass of participation to be successful – only one motivated individual is needed.
If forums are a natural place to ask, blogs are a natural place to say. Forums are group-oriented in that many are asking questions and many are answering. A blog is a more focused medium: even if there are comments, they are off to the side with the author directing the main flow of discourse.
Blogs don’t replace documentation, TWiki, or training. It’s more for informal thoughts and musings. (Though sometimes thoughts that were originally musings may grow into something more later.)
If blogs are implemented at [our company], only a few developers – say five to ten – are likely to blog regularly. This is to be expected – the power of blogs is not that everyone must participate, but that there is value even if only a few participate. Thought leaders are likely to read each others’ blogs and post thoughtful comments from time to time. This networking will be a help to the company and aid the professional development of the participants as well.
Blogs are a good way to preserve and promote the kind of long-term thinking that our company needs from its current and up-and-coming thought leaders. In this paper I have tried to give convincing reasons for making blogging available. Are there other barriers I did not speak to?
— DanielMeyer – 28 Nov 2007
I created this write-up in November 2007, but now for the masses:
1. When Forums are Better than Email
Forums are a good mechanism for asking and answering questions, for several reasons:
|Searchability||Questions and answers are in a single easily searchable place.||Email is a lot more difficult to effectively search.|
|Preservation||Forums preserve years of questions and answers.||Emails are only around until you clean out your mail folders.|
|Availability||Available to all developers.||Private to each individual, so the answer that one person gets does not benefit others who may later have the same question.|
|Efficiency||Once an expert answers a question he/she can say “search for the thread about yyy“||Expert must write up answer again|
|Updateability||The answer to a question may change over time – either because a mistaken notion is corrected, or because things are different now than they were when the question was originally asked. With forums, searches will show such updated answers.||You save the original answer, which may be out of date by the time you refer to it.|
|Accountability||When an expert answers a question on a forum, it is informally reviewed by other forum participants. Another expert can post a correction, or even a non-expert can say, “Are you sure? I thought it was this other way because…” This feedback to the answerer may result in a “You’re right, I misspoke. It’s really this way…” Thus errors are corrected and the whole group learns.||When someone gives an answer by email, he or she may have been thinking incorrectly about the issue, but there’s not a good way to tell.|
|Audience||Forum participation is on a self-selection basis, and participants are able to check the forum at their convenience instead of being interrupted with an email. Those who join later are able to catch up on the history they missed by browsing older forum posts.||It’s hard to send an email to just the right people. In addition to the initial choice of whom it’s appropriate to send communications to, when someone is added to a project later and communications are by email, they miss out on decisions communicated earlier.|
|Helping New Hires||Forums provide a place where new hires can ask their questions in a way that benefits other new hires and contributes to the body of knowledge generally||New hires’ questions may bog down their go-to expert.|
|Community||When you participate in an active forum, you gain an appreciation for both those who take the effort to answer questions and those who ask good questions. These people are from different teams, sometimes different divisions. You’re growing together, and there’s a greater shared identity.||This is not the case with email.|
TWiki and Forums both have their place, because they address two different needs. TWiki is a good medium when you want to write up a paper about a topic, but it is not good for quick questions and answers.
Forums can help with knowledge transmission and frequently asked questions. Someone might ask, shouldn’t knowledge transmission be dealt with more officially using training classes, and shouldn’t frequently asked questions be dealt with by creating FAQs and other documentation? Yes! Let’s make use of training and documentation wherever it makes sense. In fact, browsing the forum postings may help us to create more helpful FAQs as we see the truly frequently asked questions, and needs for developer training as we see frequent areas of misunderstanding. This can help us concentrate our internal documentation and training efforts where most needed.
Forums do have an Achilles’ heel: there has to be some critical mass of people who believe in the forum concept – who make it their practice to take their questions to the forum and answer what questions they can on the forum. If this critical mass is not there, the forum will not be a valuable enough resource to draw others in. (It’s a combination of seeing others’ questions answered and seeing regular activity on the forum that helps others take the step of asking their first question on the forum.)
The immediate challenge I see for the adoption of forums is that we, as a body of developers [at my company], are not used to asking questions in a way that preserves the answers for ourselves and others – it’s not that we’re against it, but we take no thought for it. (Look at the near zero traffic Unit Test mailing list, for example.) It’s just not in our culture yet. There would need to be some sustained encouragement of the idea, maybe for 6 months, to get developers in the habit of contributing questions and answers to the forum, otherwise the forum(s) would be in danger of being simply ignored.
Even with training, documentation, and TWiki, some mechanism is needed for the day-to-day questions. For the reasons listed above, we need to find a way to move away from email and toward forums for these day-to-day questions — for the company’s sake as well as for our own development.
- We also ask in person. Though in-person questions do suffer from many of the weaknesses listed in section 1, asking in person is often important. An expert will often throw in other tidbits of wisdom along with the requested answer when someone is standing there, which they might not do to a written question, and there are other mentoring aspects of in person conversations that make it well worthwhile. Email has the most of the drawbacks of face-to-face communication with few of its benefits. I am not suggesting that we move away from face-to-face communication.
— DanielMeyer – 28 Nov 2007
Theoretically, if you have a (T)Wiki, you shouldn’t need a blog, because if you have something to publish internally you could just create a page on the Wiki, right? Or if you have mailing lists available, you shouldn’t need forums should you?
In practice, though, I find that having or not having a tool that feels natural to use affects how often I actually go create a post. Examples: musings on designs, thoughts about ways we might want to solve certain problems in the future, things we figure out with the technology… Twiki pages feel more formal somehow, and a blog feels better suited to jotting down quick thoughts.
You can disagree about individual perceptions. For instance, you might say, “Twiki is fine for half-baked thoughts and non-thoroughly-vetted ideas!” — but if a potential author feels a mismatch between the message to publish and the medium through which to publish it, it can be a barrier to creating that post. (It’s hard to measure how many posts don’t get created because of such friction, but I contend that the issue exists! I think it’s sort of a pies-aren’t-the-same-size thing.)
The important thing to realize here is that you can save work by blogging. Many people have figured out that this is true of Wiki: rather than explaining the same thing over and over, you put your explanation in Wiki once, and you’re done. From then on you can just point people to it.
But Wiki doesn’t feel like the right medium for the kinds of things that go into blogs. Blogs are often more spontaneous, more exploratory, and people have different expectations about them. That’s not to say Wiki isn’t wonderful — it is. And there’s certainly some overlap between what people put in the two, because blogs and wikis are (today) the primary mechanisms for persistent communication, by virtue of having the lowest friction. Given that we have only these two models for self-publishing today, both of them are going to be stretched a bit as people try to figure out how to make them work for N types of communication. But for some things you write, your blog is clearly the right venue.