Jason Fried, co-founder of 37Signals, says that American employees need to reduce interruptions. And there are certain technologies that can help.

Instead of knocking on a colleague’s door or calling over the cubicle wall to air out an idea, Fried says, we should be using a chat tool to flag him so that if he is heads-down getting his “real work” done, he needn’t feel obligated to engage in our latest Big Idea.

Fried believes his company’s chat application (BaseCamp) is the answer to interruptions because unlike calling over the cubicle wall, chat tools allow  coworkers to decide whether they want to engage now or later. If my colleague doesn’t have time right now to humor me, he can ignore my request until he does.

Fried is right in saying that it’s hard to put off or ignore a knock on the door or a call over the cubicle wall. Where he’s wrong is in the assumption that the right to ignore an immediate request doesn’t extend to the telephone. Actually, ignoring an instant request to talk is what voicemail is for. Even a call from the boss can go to voicemail if I’m in a meeting with our customers or our community contributors. Most of us won’t leave many people hanging to satisfy one person, even if that one person is our boss. And most bosses I’ve encountered are humble enough to agree that they’re not more important than a meeting room full of people. I’d guess that most employees are just as likely to ignore a phone call as a chat message.

The most telling aspect of Jason’s post is his assertion that unplanned requests for instant feedback can be fueled by arrogance. Such a request says “My agenda is more important than yours, so drop what you’re doing and listen.” Calling meetings on short notice or popping up at a colleague’s cube just anytime to air out ideas are bad habits.

I say this as a repeat offender. In my early days in management, I was entirely oblivious that my interruptions were bad ones. Even today I welcome cubicle interruptions from coworkers and instigate them myself. What Jason’s post helped me see is that when I want to brainstorm a new idea off the cuff, I need to do it first through chat so people can choose whether to engage now or wait till they are at a stopping point later in the day. Or even tomorrow.

Lately, I’ve been airing out more ideas using chat first. But I needed someone to call me out virtually in order to reinforce why this is a good idea and why I need to make it a more consistent part of my work ethos. So thanks, Jason, for hurling that stone into my glass house. I need that once in awhile.


hot off the line

Krispy Kreme doughnuts are such a success that fans camp out overnight for a store opening as if it were the release of a new Star Wars movie. In Creating Customer Evangelists, Ben McConnell and Jackie Huba attribute this success partly to the fact that Krispy Kreme stores feature their stainless-steel assembly line as part of the “experience.” This mystique — this feeling that the shiny Krispy Kreme machines are making something for you right now — makes Krispy Kreme special. The doughnuts are warm because they popped out of that magical machine not yesterday, not a few hours ago, but right this minute.

I think wiki evangelists can learn from this.

Wiki content, by its very nature, is fresh. Contributors add hundreds of edits and scores of new articles per day. Most wikis have special pages that link to the newest edits, but these special pages are buried. Many wiki communities run projects where multiple authors play various roles (researchers, subject matter experts, copy editors, etc.) and assemble articles in a process resembling an assembly line. On an active wiki, you can bet something was authored just minutes ago, like a doughnut Krispy Kreme dropped fresh out of the oven and handed to you while still warm. And yet most wikis don’t make this just-out-of-the-oven freshness obvious.

While a MediaWiki site’s New Pages or Recently Edited Pages section shows the latest edits, driving customers to these articles wouldn’t be effective marketing because most of the articles listed there are stubs. They’re not among the wiki’s better articles. But something I’ve noticed in FamilySearch Wiki is that when an article hits a certain number of edits — say 100 or so — it starts to become pretty engaging.

Sure, sites like Wikipedia have sections for Featured Articles and What’s New, and these are certainly worth creating on any wiki. But wikis need a feeling of every-minute freshness long before their contributor communities hit the critical mass required to maintain Featured Articles or What’s New sections. Newer wikis need a programmatic way of featuring not just new content but new, mature content. Featuring content that has not only received recent edits but that has also received enough edits to make it interesting gives  customers a feeling that there’s a quality article coming off the line each hour or even each minute.

So the question is How can our wiki automagically show a conveyor belt full of well-written articles — a list of articles which are pretty engaging and which have reached that threshold within the last few hours or minutes? Should a wiki have a frame that lists the subject lines and first couple sentences of such articles? Could the frame be called something like “New Edits” or “Recent Writings?” Is there an easy or bot-driven way to include such a pane in a wiki, particularly in a MediaWiki site?

What do you think?

I have a learning to share with those of you who are interested in…

  1. best practices regarding community governance and how to run a community writing project efficiently;
  2. how the U.S. Census and U.S. Vital Records wiki writing teams on FamilySearch Wiki are doing;
  3. an executive decision made yesterday which should help our the U.S. teams avoid unnecessary re-work.

Until yesterday, I didn’t understand why Wikipedia leaders are wary of a straight vote to decide issues. Now I understand why they value consensus significantly higher than majority, and why sometimes it’s even necessary for Jimmy Wales to make a ruling as “Benevolent Dictator” <g>.

According to U.S./Canada research consultants, a lot went well in Sprint 1. They built a meeting area, started standup meetings and post-scrums, started learning scrum through practice, and learned a lot about communicating and working as a team. One thing that consultants felt could be improved, though, was that we need to churn less and execute more. Part of the excessive churning was caused by often reconsidering what information to show in an article and how it should be presented. Should we lay out census links to different sites in a table or in paragraphs? Should we include only one type of link to an Ancestry.com census, or include three links leading to Ancestry’s Library account access, personal account access, and Institution account access?

Wiki teams do most things democratically. So when we have an idea of how to lay out an article, we present it to the team for feedback before replicating our idea on, say, 50 state census pages. The decision to replicate the idea across many pages hinges on a vote. In the beginning of Sprint 1, we were basing decisions on a majority vote. That’s fine when you want to get an initial decision on whether to replicate a new idea across 50 pages. But we learned that once an idea gains initial majority support and is replicated across many pages, it’s time to forget about majority votes and start thinking about consensus.

So why does majority rule bow to consensus after a stylistic idea is implemented? Because the opinion of the majority changes constantly. Projects gain new authors over time. In our census project team’s case, new research consultants began to be freed up from other assignments, making them available to work on the wiki. So in this case, an idea to include three types of links for Ancestry.com censuses based on the different accounts a patron might be using won majority approval initially, and was implemented over 50 pages dealing with census records in various states. But as the project team gained members, the majority shifted the other way. The majority opinion now was to include only one Ancestry.com link for each census, and have that link lead to another page where links to the three kinds of Ancestry.com accounts would reside.

If approved, this new decision would force us to redo all the 50 state pages we’d done on the census, as well as forcing us to create 50 new pages with the various Ancestry.com links. We’d done this kind of back-and-forth revising on two other issues during the sprint, and it was killing our forward progress. It seemed like every time the project gained another one or two contributors,  the majority opinion on some style/layout issue would change, and we’d end up reworking a lot of articles. This waffling and constant re-working of articles was bad for morale and performance, so something had to change.

That’s when it hit me: Wikipedians have expressed reservations about straight votes and majority rule. And although I don’t remember them really saying <why> straight votes and majority rule don’t always work, experience was teaching us the “why.” If all a community needs to force a stylistic change over many pages is for the majority opinion to turn, all one needs to do is to bring in more contributors to change the vote. Thus the majority opinion on a hot issue will change back and forth many times as new contributors (voters) engage the project. One possible solution might be to demand that only one vote takes place on each issue, or to require that an issue can have only one vote per year. However, limiting the frequency of votes on an issue can stifle essential changes that have incredibly broad support.

That’s where consensus comes in. Once initial majority has been reached on the style/layout/information of a large body of articles, it’s time to discontinue rulings based on majority and start requiring rulings based on consensus. After we’ve written the first draft of 50 state articles, a 5% shift in majority opinion should no longer compel us to change all those articles. That is inefficient – it forces change too frequently. After a collection of 50 similar pages has been written, if the community wants to change how the articles are presented, they need to reach not just a majority, but a consensus. A consensus shows much stronger support for change, and will tend to prevent rework except in cases where change is essential.

So what percentage of the vote is needed for a consensus? Wikipedians say it varies according to the issue. But what we’re trying in U.S./Canada is a 70%/30% split. If we’ve written 50 state census pages a certain way and someone wants to change the style, they need 70% of the voters to agree with them before the change will be made. Hopefully this will quell a lot of unnecessary re-work of articles while allowing changes that are essential and truly supported by the bulk of the community.

Today Sunir Shah, founder of Meatballwiki, tweeted that “Realizing a truth makes us *want* to act even if we don’t. Users are most prone to discovery just before they take action.”

If users are most prone to discovery just before they take action, they take action right after discovery. (Um, sure, Mike. Duh. So what?) It follows, then, that if community builders want to convert their site’s reader/consumers into contributors, their best shot is to do it at the very moment when the user sees the value of the site. So how can community builders know when that moment is occurring in the user’s mind?

Thousands of people register on FamilySearch Wiki without ever contributing content. There’s no good reason for this — registration doesn’t open doors to greater functionality — but there it is. It seems an easy thing to assume that registered users should be more easily converted to contribute content than, say, unregistered users.

There’s a mantra in marketing that it takes less energy to retain a current customer than to win a new one. And Web 2.0 mavens like Ben McConnell of Creating Customer Evangelists say that going the extra mile to dazzle customers is what converts them to evangelize a product.

Sunir mentioned that one way to know when the customer understands the value of the site is when he “starts taking actions that fit the mental model.” The only such action our customers do that our system reports to us is registration.

….So why don’t we dazzle them at the moment they register?

I don’t mean we should try to dazzle them with some automated message from the system. The idea an automated message would dazzle anyone is laughable. But human interaction? That’s different. I can’t think of a Website that has ever tried to engage me with human interaction at the moment I registered. That would knock my socks off. Is there any better way to show users they’re valuable? Is there any better moment to get their first impressions of a site, see which parts of the value proposition they are catching, and discover and walk them through the barriers that would otherwise prevent them from contributing? Using this method a high percentage of newly-registered users could be converted to contributors in a matter of minutes.

Obviously, this method of conversion is labor intensive. It doesn’t scale. However, given the reports that the lion’s share of Wikipedia edits are made by a core of a few hundred authors, a method of converting consumers to contributors doesn’t necessarily have to scale very much. In our case, it would amount to less than ten thousand chats or phone calls a year. To an organization like ours that has a sizeable call center, that’s not such a big deal. And there’s no reason we’d have to contact every new registrant — consistency in user experience is wildly important when you’re giving something to customers, but when you’re trying to help them give to you, there’s less need for consistency.

What would the call or chat sound like?

  1. Thank the customer for registering.
  2. Ask the customer whether she registered in order to contribute information.
  3. If the customer would like to contribute or isn’t sure if she has enough expertise to do so, help her contribute something simple.
  4. Ask the customer about the projects she’s working on that relate to the purpose of the site. Guide her to information on the site that will help her do a project.
  5. If the site fails to produce the content the customer wants, guide the customer in creating a request (wiki stub or forum query) for that content.
  6. Thank the customer and terminate the call.
  7. Monitor the forum thread or wiki stub. If the requested content doesn’t appear within 24 hours, gather it, post it, and notify the customer that it’s there.

You just created a customer evangelist.

Folks who hear about the new family history research advice wiki at wiki.familysearch.org want to know two things. First, What is a wiki? And second, How will the wiki deliver more of the genealogical research advice I need?

What is a wiki?

Wiki. A short, sweet, strange word whose form matches its meaning — a Web site you can edit without being a programmer. A site where average people like you and me can write things to help other people. A place where we can share information and even collaborate on articles that make us each look smarter than we are alone. A paradise for people who seek information. A wiki community can deliver and revise more research advice information for more users in more languages.

Challenges in the traditional approach

To see the potential of FamilySearch Wiki, it helps to explore the challenges an organization faces in offering free research advice worldwide when they try to do it the traditional way. Continue Reading »

Our wiki scrum team is now testing Semantic MediaWiki, a tool that will improve the wiki’s search and browse experience by bringing further tagging (and resulting meaning) to our articles. To understand the power of such a tool, one must understand the concept of the Semantic Web. One of the simplest descriptions I’ve found is Chris Gledhill’s “The Semantic Web — A Muggle’s View.” Below are a few quotes that explain the Semantic Web in a clean metaphor:

“The web is like a vast library in which the books are completely randomly arranged, each book has a predefined space on the shelf but there is absolutely no categorisation. Search engines such as Google act as librarians to help us find the resources we want, but in a most bizarre way. A web search engine is like some sort of autistic genius with an immense memory and perfect recall of the words in each book but absolutely no idea what they mean.”

“So instead of being able to ask Google to direct us to the section on advanced bungee jumping techniques or DIY space exploration, we have to think of some words that are likely to appear in the books we want and then wade through all of the irrelevant rubbish that happens to contain the same words in the hope of finding something useful.”

Having explained how the primitive Web works, Gledhill goes on to explain the Semantic Web:

“In information science… an ontology is a formal (and rigorous) description of all of the entities, relationships and rules within a particular domain of knowledge. The magical bit happens when you have created an ontology in a particular field. It then becomes possible for computer software to make logical inferences from real world information to ‘discover’ new facts which have not been explicitly encoded.”

Gledhill ends by predicting which fields will likely embrace the work it takes to create the semantic context that will allow their information to be more useful and findable. The Semantic Web, he says, “will be welcomed in any commercial field where the economic advantages of standardisation outweigh the benefits of confusing the opposition, punter [beginner user] or regulator.”

Recently someone mentioned that she wishes I posted more often here. Me too.

But until that happens, if you want to learn vicariously from the Web 2.0 books I’m reading, see my Twitter page at http://twitter.com/MTRitchey. When I read a Web 2.0 book, I mark it up quite a bit. Then each workday, I transfer my book notes to Twitter. When something strikes me as extra profound or as needing some synthesis into learnings and action items, I transfer it from Twitter to this site and start expanding.