Christmas in Tennessee

Merry Christmas! Dean and I are on the road visiting family, so we won't be updating the blog much this week.

We had a little adventure getting home for the holidays this year as United Airlines cancelled our flight and failed to provide us with anyway to travel before Tuesday (Which is um, after Christmas...). The entire story is pretty long and probably boring - the short version is United Airlines has quite possible the worst customer service ever. They also have one of those annoying speech recognition phone systems, which is particular irritating because you feel compelled to yell a string of explitives at it, and then it talks back to you and says "I'm sorry, I didn't understand you..." We ultimate ended up buying a last minute ticket with Delta Airlines and it still took three trips to the airport to retrieve our luggage.

But we finally arrived and Christmas with the fam was fun as always. We wouldn't want you all to miss the experience of celebrating Christmas in Tennessee, so we posted a picture of us hanging with Elvis on Christmas. Cheers!

Sonos!

Dean got to open his Christmas present early this year - a Sonos whole-house audio system, and a new set of Focal/JMLab speakers to play music in the living room.

Having made Dean spend all our hard earned savings on boring furniture over the years, I decided that instead of more uphostery Dean could buy a sweet stereo system for Christmas. I did some research and discovered that audiophile geek was a specific sub-genre of ubergeek - and I was a total n00b. Lucky for me, Anthony was an audio zenmaster in a former life. Sonos, litle grasshopper. Sonos.

Dean and I visited our local stereo geek store (Tweeter) on Sunday and picked out our Sonos bundle. Next we needed speakers, so we could play our music in the living room. Enter the speaker room. Two comfy chairs, an array of CD/DVD players and amplifiers, and a wall of speakers. The sales person gave us a demo - the Polk sounded nice, the Infinity solid but a little crisp.. and the Focals sounded like a glass of expensive french wine. C'est épatant! The speakers were a bit more than we wanted to spend... but as luck would have it, last year's model of speaker was on sale for 40% off - making them the same price as the Polk speakers. Sold! (2006 was a good vintage).

Like all good Chrismas gifts, the best ones are as fun to unwrap as to use. First, we set up the speakers. Did I mention these babies are très magnifique? They weigh a ton. Dean says this is a sign of a good speaker. I say, this is a sign that Dean will be carrying them in from the car.

Having set up our speakers, it was time to unwrap the Sonos. As I mentioned before, I am a total stereo n00b. The Sonos was blindingly simple to set up. The entire set comes in a cute little box and setting it up is as easy as plugging cord A into Tab B and pressing the on button. Setting up zones was easy, and the software we installed on our computer was even savvy enough to find our music library automagically. Brilliant.

The Sonos is so well designed, its worthy of its own blog entry where I can rave about it. That will have to wait until another day, I have audio heaven to visit now.

Shyness and eye contact

Dean and I just completed a circuit of holiday parties this weekend (one Christmas, One Jewish - we just have to attend a Kwanzaa festival and I think we'll be good).

So here is my thought for the day - I've always been an extrovert, and I love a good party for the people watching. One thing I noticed this weekend made me want to do more research. Do shy or introverted people make less eye contact because they are shy? Or is it the lack of eye contact that makes someone shy (because as they develop conversation skills, they fail to connect with people because they are not making eye contact?)

The psychology of this fascinates me. Must research. Results will be posted later (probably after New Years)

Simplicity Sells Out

It's a rare occasion when I disagree with such pundits as Joel Spolsky and Donald Norman, but this is one of those times. As covered on Slashdot, they now say that simple designs are inferior to complex ones.

Donald Norman wrote two articles on the subject. The first article makes the claim that simple doesn't sell; given the choice, most consumers will select the product with more features and more options. To his mind, the market has resoundingly refuted the notion that less is more. But is this a matter of common wisdom or market failure?

When you buy a product for the first time, you're never quite sure whether it will do the job. Economists call this situation one of "imperfect information". I'd argue that in cases like this, consumers tend to overbuy. They think, "I'll take the Swiss Army knife over the Petit Chef knife because hey, one of the blades is likely to work." It's called Satisficing. You might not get the right thing, but at least you'll have something.

But you'll find that the opposite is true among experts who know what they're buying. Mechanics and surgeons, for example, will have an array of tools, each crafted to do just one simple operation. They know the right one to use for any given situation. The complexity of a multipurpose thingamajig is likely to get in their way.

You'll also find that folks who are very wealthy -- for whom buying decisions are less risky -- will also choose products that do one thing and do it well. It's why a good watch can command a price of thousands of dollars, when feature-crammed smartphones sell for much less. They both tell time. The accuracy is roughly the same. But less can be more.

Norman's other article takes issue with Google's simple user interface. Google's search interface appears to be a clear case of less is more to most people. Norman feels that the interface is worse, because Google's many other features are "hidden" on other pages, while Yahoo and MSN have their features up front, right where the user can get at them.

Assuming the user can find them, of course. Here, Norman makes a common mistake, and one that should probably be the subject of another blog article. A web site is not a software application. Everything that ends in "google.com" is not part of the same product. Google's philosophy appears to be that each tool should stand on its own, like a of screwdrivers. Each feature is individually addressable through a its own URL. Yes, you can get to these through a menu. But Google's innovation is to put the Google search, the thing most Google users want, front, center and uncluttered. If I want Froogle, I'll go to Froogle.com. If I want maps, then http://maps.google.com is the place to go.

Joel's simplicity article argues that if "simple" means "has less features" then your product is doomed to fail over the long term. I agree with him on this point. But he understates the value of doing one thing well. And adding more doodads to gadgets is not the way into most people's hearts. The humble teddy bear outsells the most amazing interactive storytelling synchs-with-my-computer-using-firewire audio-animatronic stuffed entertainment companion, despite its lack of features.

As one contributor to the Slashdot discussion of the anti-simplicity articles noted (and as Paula commented not too long ago) Joel himself took issue with the notion of more features being better in his article on Choices=Headaches. Simple generally means easier to learn and easier to use. And for most users, that can be a very compelling feature indeed.

Solving what you can't touch.

We're working right now with my government program to try to achieve "synergy" (I hate that word...) between different programs that are working on related goals. For example, getting the collaboration program to coordinate with the network bandwidth program and both to coordinate with the data center hosting program. It sounds easy, but in big organizations the hardest thing to do is to coordinate different groups.

The issues are not technology related at all - they're about program schedules, culture, information exchange, and building relationships. Except, somehow we're convinced what we need is ... more technology. Lets just implement service oriented architectures! that will fix it! How about a search engine? If we could just search better we would work together better!

All silly.

It is not a technology problem we have. If it were, it would be solved. It is easier to solve problems with real, tangible things. Technology problems are tangible, and discrete. I can build a better search engine. I can make all my applications communicate with an XML webservice. That part is easy. The hard part are the non-tangibles. Who gets my priority? What information should I share? How should I communicate?

Abstract thinking is hard. Which is why we should all do more of it.

Simplicity sells

I'm a copycat. But I love the point being made so I'm repeating it. Simplicy sells.

Joel on Software wrote last week about the "9 ways to turn off" your next version of Windows. Macword wrote about how Microsoft is messing up the Zune because they're making it more complex instead of simple like the iPod.

Good grief - even the economist gets it. The point is, customers don't really give a flip what makes sense to YOU, they care about what is best, easiest, and simple for them. Duh.

Bond, James Bond.

Dean and I have returned from a fun holiday weekend with the family. Grandmammas turkey dinner was yummy as always, the girls beat the boys in charades; and the turkey hash the next day was even yummy again, and Georgia won a nail-biter of a football game over Georgia Tech.

The Thrasher clan also headed out to see Casino Royale. It may be the best Bond film ever. It was certainly the most riveting 144 minutes of movie I've seen in a while. None of that goofy go-go gadget arm invisible cars and such that populated recent films. The Bond girl isn't flat for once (character wise! she still has boobies!); Bond is gritty in a Steve McQueen kinda way; and Daniel Craig dispels any rumors that you need to be a brunette pretty boy to play James Bond. In fact, he's the second sexiest blond I've ever seen! teehee

Wiiiiiiiiiiiiiiiiiii

Dean and I bribed Gordo and family with half a dozen glazed donuts so we could check out their new Wii. Having now played the Nintendo, I predict the Wii will come out ahead in the console wars. I don't even have to play the PS3 orXbox 360. Despite the goofy name, the Wii is fun, cheap and accessable. Microsoft and Sony may battle it out for the "hard core gamer" crowd (males 18-35), but this Wii thing will be selling to the masses. Lots and lots of masses. And that includes the female masses. First, the Wii includes making your own "Mii", which is remarkably similar to The Sims, an already breakout hit with the ladies. Second, the controller looks just like a remote control - which makes it very accessable to the first time gamer. That and the entire thing is cute! This means the wii is gonna be a hit with just about everyone else under the age of 18 - and probably a few those 18-35 folks too. I mean face it, its just fun to jump around your living room. (though unfortunately, I'm too big to do somersaults on the couch like Ruben and Link.)

Change happens.

Dean and I both have strategy meetings going on this week, so we've both been thinking about corporate vision and strategy. Gordon sent over a great link to Survival is not enough by Seth Godin. I haven't read the book yet, but he makes some great points. Like most business books though, half the points are worthless; the rest are case studies. Good of Mr. Godin to bulletize his to book for me though, saves time.

Here is my even shorter synopsis of his short summary:

• Change happens. Technology has caused change to happen faster than it used to.
• Corporations that don't change, get defeated
• Companies that introduce a different product to market quickly may find that they can create a 'runaway' success
• People (bosses and employees) fear change. Change is different, and human instinct avoids differences, prefering habit. But not changing is actually worse. (ed note: See "Who Moved My Cheese")
• Change presents opportunities for individuals, and for companies to grow
• Companies need to have a culture of "Change equals opportunity" rather than "Change equals death" (or change equals risk?)
• Companies should try to 'evolve'. Change is constant. Better to create a culture of change than to create a 'change plan'. A change plan is an oxymoron.
• A company that has a culture of change, attracts individuals that seek change, opportunities, and new capabilities.

I'm published!

So my company now has a corporate blog, and my first article on it just went live! So without further ado, please visit TOWER Software and read my article about the importance of metadata.

Humans are fault tolerant.

Here's an autoblog thought from last night's dinner conversation*:

Dean: You know what most software gets wrong? Its not fault tolerant. Computers need perfection.
Paula: ... but humans are fault tolerant.
Dean: Yeah - exactly. You can flub your words, misspell, whatever, and humans figure it out. This is why people like google. I can type in micsrosoft and it still lists www.microsoft.com at the top of the search results.
Paula: That's also why I like google maps. I can type "Krispe Kreme, Washington DC" and Google finds me the nearest source of hot doughnuts. Mapquest has better directions, but I have to always type the street address... ok now tab to the city text box... crap, VA is at the bottom of the state dropdown box...it's too hard.
Dean: This is where everyone goes wrong in software design. They expect smart users. But people are dumb and lazy. That's why they prefer humans to machines. Humans are fault tolerant - computer software should be too.
* unfortunately, since autoblogger is still run by pet monkeys who type our conversation up, this is heavily paraphrased. Spelling and grammar errors are the fault of the monkey.

Speaking Too Soon

Two weeks ago, Gordon posted the sunniest column about the dreaded developer Death March I've ever read. It offers some great advice about how to survive a ridiculous project with crazy deadlines.

It was also written one day too soon.

My response is three weeks too late.

These facts are related.

Night Owls

I'm not a morning person. Neither is Paula, though she can fake it with enough coffee. A key attraction of our trip to Spain is that the country is populated entirely by night owls.

The daily rhythm of life in Spain apparently goes something like this:

8:00 am      Wake up
9:00 am      Eat breakfast
9:30-ish     Arrive at work
2:00 pm      Eat lunch
4:00 pm      Disappear
7:00 pm      Drinks and tapas
8:00 pm      Shopping
11:00 pm     Dinner
1:00 am      Bed?

So you can plan on four or five small meals scattered throughout the day, all served later than you might expect. This may be partly due to Spain being pretty far back in its time zone. It certainly stayed light very late when we were there in Sepetember.

Note that all times shown above are approximate. One of the striking things about Spain was the absence of clocks. It's hard to picture a British or German town without its large clock tower. In the United States and Canada, practically every bank has a scrolling sign that displays the time and temperature. But in Spain? It's not important. If you listen carefully, you might hear a church bell ringing, but that's done only to signify that time is passing, not what time it actually is.

Most shops don't list hours of operation. You can tell which ones that cater to tourists, because they bother to post small signs saying "Back soon". Don't take it literally. This may mean five minutes or two hours. The sign is just to reassure those with an overdeveloped sense of punctuality. Time, in Spain, just doesn't matter as much.

We found this totally relaxing, especially coming from America's uptight east coast. We're five hours behind London, darn it, which makes us five hours behind. And by golly, we'd better stay three hours ahead of those nuts in California. And that takes work. The planet doesn't turn itself, you know.

Speaking of relaxing, we were never able to figure out why all the shops and restaraunts closed around four or five pm. We used it for naptime. A siesta seemed appropriate, especially if we wanted to go all night. We're Night Owls, but we're a bit out of practice.

Spain is not Mexico

Travel is good mental exercise. It forces you to re-evaluate your assumptions about people and places. It also helps refine the way you look at home when you return.

One of the reasons why Paula and I picked Spain was that we each had a passing familiarity with the language. Of course, when I say "passing familiarity" I mean that we've driven past the endless billboards on Interstate 95. We've also consumed our fair share of tequila and nachos. We figured that we'd at least recognize enough words to get us fed, drunk, and to the nearest washroom.

We knew, of course, that Spain is not Mexico. But as much as we prepared ourselves for that, our brains were still buzzing from cognitive dissonance throughout the trip. Paula has relatives in San Diego and had visited Tijuana. I spent many holidays and an entire summer once with my relatives in Las Cruces, and have vivid impressions of Juarez.

It was worse for me than for Paula, I think. The part of Andalusia we visited reminded me very much of the American Southwest. It was, after all, where they filmed the Spaghetti Westerns. So while the language was similar, and the countryside and climate were familiar, everything else was dramatically different.

We were somewhat prepared for the food. We love tapas. It was one of the main reasons we chose to visit Spain. But it was strange to sit in restaurants, listening to the language and reading the menu, and knowing that there won't be a tortilla in sight. I don't believe we saw a single item containing corn on any menu, anywhere. Corn is native to the Americas, as was the potato, but while the potato was in evidence, corn was shockingly absent.

We were not prepared for the wealth of Spain. Our experience of Mexico is sadly limited to marginal border towns. It's hard to break the link between that and Spain, onetime ruler of the largest empire on earth, gateway to the wealth of the New World, and master of the seas through the Spanish Armada. One look at any of Spain's magnificent Cathedrals shows you that this was once the mightiest nation on earth.

Of course, we're comparing Madrid and Seville, present and former Spanish capitals, to shaky border towns in the hinterlands of Mexico. A comparison between Mexico City and Madrid might be more fair. But that was our experience, and probably one shared by quite a few Americans that visit.

Autoblog

I was just noticing how its been a while since either Dean or I wrote on our blog. Our laziness has a few good explanations*, we have each been spending brainpower writing for our respective internal corporate blogs, and we've been traveling around quite a bit. The truth is, we talk about bloggable subjects all the time - we just never get around to blogging them. What we need is autoblogger™! Autoblogger™ is a hand widget that records all our conversations, senses intelligent dialog**, automatically does a speech-to-text conversion on our chat, and posts a draft to blogspot for us.

Of course, given today's speech to text technology, what would really happen is we would say something like "What we really need is a tool that converts our speech into text and posts it online for us" and what we would get is "slutty feel, he need essay fools that desert our speech and boast daft incline forests." But I'm still waiting, maybe Google*** will do it!

* excuses
** coherent
*** Hint hint, Mikal!

Hola, seniors and senioritas!

Paula and I took a vacation to Spain a few weeks ago. It was an amazing trip. We began in Madrid and ended in Seville, with a stop in Grenada along the way. Ten days to see the sights, learn the history, experience the culture and savor the food.

Why Spain? Well, we wanted to go somewhere in Europe. Spain seemed like a fun, warm place to go in the early fall. It was also a place that we hadn't heard much about. We see so much of Paris, Berlin, and London in movies and television. We wanted something different. Many of our friends and coworkers loved their trips to the Iberian penninsula. It was an easy decision to make.

I've got so many fascinating things to blog about our trip I'm worried I won't be able to write about them all. I certainly can't show you the pictures, because the film isn't developed and our home computer just melted its motherboard. So, you'll just have to use your thinking caps and imagine all that during my next few posts.

Three gallons of abstract thought

A few days ago I found myself saying to a coworker, "we need to make the compliance sell." The company I work for makes software that helps comapanies and government agencies manage information. With the collapse of Enron and the advent of Sarbanes-Oxley, compliance with information management rules and regulations is a big deal.

We talk about compliance a lot at my company. We consider it a major reason why someone would buy our product. It's in all of our marketing literature. But I suddenly realized that I have no idea what it means.

"Compliance" isn't a thing. It's a state of being. We can't sell compliance because you can't buy compliance. You can't buy happiness either. Try walking into a store and asking for half a pound of Zen.

So when companies promise a smile in every box, or satisfaction, or romance, or the "being part of the legend", what they're really talking about is how you'll feel after you've purcahsed and used their product. They want you to visualize how you'll feel, the end result, the ultimate goal.

For luxury goods or impulse buys, this strategy works. If you make chocolate, selling "satisfaction" makes sense. Customers can see how one leads to the other. They've had chocolate before, so they know what it's all about. If you make motorcycles, spreading "the legend" makes sense, because we've all seen the movie. It's asking customers to connect the dots in a visceral, Pavlovian sort of way. The word "performance" should start sports car buyers salivating.

But what about products that require more serious thought? Does the approach work? At some point, someone will ask what "increasing transparency" or "harnessing synergy" means. How does your product or service do that?

And you'd better have a short and compelling answer for them. Because nothing grates more than a company that sells "peace of mind" presenting you with some of the most complicated and stressful decisions you'll ever make. Or firms that promise exclusivity to you -- and everyone else with a few spare bucks.

Hierarchy vs Social Network

Today I am writing more about this self-tagging vs peer tagging thing, because I think there is a balance to be had between the two models.

IBM has in their organization a system for expert location that I imagine many companies have, the giant staff lookup that includes tags designating expertise. The traditional staff directory is not new - thats been around in paper format since the dawn of the industrial age. But IBM being well - Big Blue, has added an expert tagging and context aspect to their staff directory that ecxceeds the average staff lookup system. Called IBM Bluepages (aka Fringe Contacts), users can view that person’s reporting chain (who they report to and their boss’s boss and so on, all the way up to the CEO), their peers, and the person’s direct reports. The system also provides duel tagging - self tagging, and 'corporate' tagging. Here’s a screenshot. (props to Library Clips, my source for this).

A good system has both - a Peer Tagging/Reputation system AND a self-tagging system.

The trick to making all this metadata work though, is to overcome the maxim "People are Lazy". The only thing that makes an expertise system (such as IBM's Fringe Contacts) valuable is currency.

At my last company we had a similar system. It was a home grown application that ran inside of our coporate intranet and was connected to the staffing system. It would designate what percentage of your time was devoted to what projects, What the project team was, who reported to who, and what internal teams supported the work. It also included tags for the technologies on the projects, linked those to the ones you were working with in your job function, and had a separate section for you to 'self tag'. Every three months, or every time you changed a project, you had to go into the system and update your expertise tags (and you got a really annoying nag email every day until you did). The expert tags worked a lot like Monster.com resume submission - you listed the technology or expertise area, years of experience with the technology, level of expertise, and last time you "used" that technology. Every time your staffing assignment changed (even if it was from one task team to another in the same project) your profile was updated on the project. It was both authoritative, and augmented by additional self-tags.

The context of this was great - at one point I joined a project team of a system that had evolved as a project over the past 5 years. It was my job to update and enhance legacy code for the application. By going into our staffing system, I learned that there was someone in the LA office still with the company who had been the lead developer on the project. I reached out an made a connection - which led to some hidden documentation and a great brain to pick anytime I needed to ask "Now why would the developers have chosen to do it that way?"

The system was also great for finding that hidden expertise in companies. Often times, companies act as though your expertise only began when you walked in the door and became an Acme, Inc employee. Of course - this is rarely true! Most people have a varied background, and just because you are no longer working in a certain area means you lost your expertise in it. Once upon a time I was a Perl Guru, and since I was tagged in the expert system as such I even got the occasional Perl question from random developers in the office who could see that while I wasn't the most current Perl expert, I WAS sitting just down the hall... Which is probably one of the more insidious problems in companies today: How to find the expert next door.

Continuing my praise for the self tag - something used most on the resumes, in the list of keywords and skills we all write up about ourselves. This of course has its limits, because people lie, abbreviate, and neglect their resumes. That too falls under the metadata trap of people lying. I don't mean people are all evil - I've 'lied' on my resume. No, I didn't make up degrees I didn't have. I left things off. On purpose! At a certain point in your career, everyone falls into this trap - My internship as a recieving clerk in a deparment store has little relevance to my career as a technology consultant. And I do in fact know a little PL/SQL. But ask me to leverage either of those expertises and I will deny, deny, deny to know them! Fortunately, this is a acceptable white lie, and an interesting quandry system for expertise location. Peer tagging is good, but self tagging creates the chance to "opt out".

So now, in my dreams I'm wishing for a mashup of Fringe Contacts and Qunu...

Proposal 101: ATFQ

I've spent several hours this weekend working on a proposal for work. It's a rush job, as many proposals are. But this one was in bad shape.

I have high standards in this regard. I used to work for a firm that did a lot of government contracting. They had responding to RFPs down to a science. My job was to manage the final assembly of the proposal, including all its forms, attachments, slides, spreadsheets, pictures, and other paraphenalia. This meant that I had to study the RFP closely and make sure that the final response conformed to all of the requirements.

My responsibilities included the mechanical aspects of the proposal: page counts, font sizes, whether the graphics matched the captions, etc. But the editors I worked for were concerned with the technical approach. One in particular used to scrawl "ATFQ" in flaming red pen next to the margins of questions. He would refuse to do any editing on a question that had ATFQ written next to it. One day I asked him what it meant, and why he was so insistent about it.

"It means" he said dramatically, and somewhat more crudely, "Answer the Freaking Question!" It's the best advice I've ever had for responding to RFPs.

Answer the Friggin' Question

The most imporatant thing to remember about responding to an RFP is that your audience is really, really bored. They've probably read three other proposals before yours, and all they really want is an easy way to separate the good proposals from the bad.

You want to make your answer as concise as possible, so that they can tick their mental checkbox that your product or service satisfies the requirement. In round two, you can always refine your statements and expand upon your answer. But for the first look, your job is to make it easy for the reviewer to put your proposal in the stack of "compliant" proposals.

This means that your response to each question in an RFP ought to come in the very first line of your answer. If possible, it should come in the very first word.

For example, if an RFP asks this:

Does your gizmo conform to the Phoom 2.3 specification for advanced wuzzle?

Your answer should not begin:

Since 1872, ACME Corporation has manufactured advanced fizzlers to the highest standards of nazblad quality, in accordance with our mission of serving the needs of the gibbler market better than our competition and for a more reasonable price....

Your answer should begin:

Yes, ACME gizmos are compliant with the Phoom 2.3 specification.

See how much better the second answer is than the first? A lazy reviewer only has to read the first word to know everything he needs to know in a first-pass review. Later, he can read the entire first sentence, first paragraph, or extended essay if he wants more detail. But he doesn't need to do that. You've ATFQ'd in his mind, and everything else is window dressing.

Make it Obvious

I deliberately used nonsense words in my examples above, because frankly that's how most technical RFPs look to the average person. What's a wuzzle? What's the Phoom specification? Not only might you not know what the words mean, but chances are the person who assembled the RFP document doesn't know either. They're just parroting some phrases they heard the other day. It sounded important, so it went into the RFP.

Chances are, your answer is going to be just as difficult for a nontechnical reviewer to evaluate. What's the gibbler market? What's nazblad quality? So the idea is to make the those first words or sentences clear enough that a layman can make one of the following determinations:

1. The respondent answered yes.
2. The respondent answered no.
3. The respondent gave a qualified answer.

That's all that's necessary for the first round.

When you don't know what you don't know

Lots of asyncronous dialog about my Qunu, the 'push-to-talk-to-an-expert' company, post going on this week. The Qunu team wrote some well thought out comments back to my critique. And Dean had a really good point to make about my last post on Qunu, . When it comes to needed expert advise on a subject, bulletin boards are a actually better. Why? Peer review. If you ask a technical question on the bulletin board, both the question and the answer are public. So if someone gives you bad advise, it tends to get corrected. And it should be faster, because in theory the first person who knows the answer to your question responds. However - Dean points out the true value of the free-form talk - when you don't know what you don't know. This is where google, search engines, and many expert locators fail. Its easy enough to find the answer to a question when you know the question. But its not uncommon as a knowledge worker to need to know something that is well outside your area of expertise. And when you are working outside your area of expertise, its hard to know where to start, or even how to ask the question. And thats where something like Qunu really comes into play: the chance to engage an expert in an extended dialog.

Can you Talk to an Expert?

As part of my job as government consultant and collaboration guru I support a XMPP/Jabber pilot program. I'm also busy thinking about the subject of expertise location, since its a big concern for a 'corporation' as large as the 5-million plus strong US Department of Defense. So naturally I have to talk about a company that involves both of those things - Qunu. Qunu provides a Folksonomy-based categorization of expertise and a XMPP-based chat (instant message) tool that lets people with questions connect in real time to people ("experts") with answers: http://www.qunu.com/en/buttons.html

What I find most interesting about this tool is that it enables synchronous ("real time") expertise. The web already does a great job of providing asynchronous (time-delayed) expertise through bulletin boards, articles, corporate websites, and blogs like this one. Even Google answers, which promises live researchers to answer your questions (for a small fee) only delivers a not-quite-real-time response in 24 hours or less.

This real-time question is an interesting capability because it better replicates the process a lot of people follow right now - a phone call or a conversation with someone they know and trust who is an expert in the area of concern. The new feature here is the ability to first FIND someone who has an expert, and then initiate that conversation right away.

Cool idea, but it raised more questions than it answered for me. I think they still have a lot of flaws to work through:

• Self-Tagging Bias- just because you say you are an expert doesn't make you an expert
• No Trust - Online trust is the currency that drives person-to-person interactions online. There is no way in Qunu to peer review the experts, or rank the advise you got. Can you imagine ebay without the rating system? Slashdot without karma?
• Dumb questions - Have you ever worked a help desk? If so, you realize that 95% of questions are repeats of questions you've answered before. Where's the mechanism for participants to say "You idiot! RTFM!"
• Expert Overload - if you really are an expert, you're likely to be a busy person. So, I suspect this system self-selects to bad, unbusy experts only
• No Reward - people volunteer their time for a lot of things. But for most folks, they want something in return. For Google answers, it's cash. For the open source community it's reputation. Sure, there are people who just contribute for entertainment, or for hubris. But enough to sustain a business model?

Not to rain on Quru's parade - its one of the more novel thoughts I've seem come out of the philosophical question of "what could you do if chat were as standard and ubiquitous as email?" But its still not my silver bullet for locating and leveraging expertise. darn.

Wiki Resolved

As part of the continuing series of posts about my company's SDK Wiki, I've decided to lay out the arguments for and against it being publicly readable.

Those of you that followed the link above know which side ultimately got the better of the argument, but I think it's important to discuss the pros and cons of the decision. Our company is likely to see similar debates in the future, and if your employer is anything like mine, you're likely to experience them as well.

The Debate

The arguments for moving the SDK wiki to a login-only setup essentially boiled down to two concerns. First, that we were giving away our intellectual property. Second, that the information posted to the site could result in damage to the company's reputation or to litigation. Let's examine each objection.

The intellectual property argument was that one of our competitors could take the information on our SDK wiki and reverse engineer features of our product. In recent years, our industry niche, Enterprise Content Management, has seen serveral waves of mergers and consolidation, and the competition is quite fierce.

I suppose the hesitation is understandable, but the SDK Wiki was really more of an extended user manual than anything else. If a competitor wants to reverse engineer our product from a manual, well, good luck. It'll take them years. In the intervening time, I hope we'll have moved on to something better.

And as one senior executive pointed out, our competitors already have copies of our software and manuals. If they were serious about taking our product apart, they would have done so already. The only people we'd be protecting our IP from are our partners and customers -- legitimate users of our product.

What of the second point, that damaging information could be posted to the site? We'd already configured the SDK Wiki so that users have to log in to edit, so presumably no user can post information there that we hadn't approved. As for the content itself, we monitor changes regularly, so it's easy to fix if something goes wrong. So even though litigation or the potential of lost sales would be costly, it's not a very likely scenario.

On the other hand, what of the potential to increase customer loyalty through providing more and better information in a timely fashion? Or improving relations with our partners by making it easier to work with our product? Or helping to inform trade analysts? While these benefits are hard to quantify, they more than compensate for the risks, in my view.

Ah, the skeptics asked, why couldn't we couldn't simply provide all those people with a login? Why does the SDK Wiki have to be public to achieve those objectives?

Well, the main reason is that we don't really know who "all those people" are. We sell our product to large organizations, but we might not know who within those organizations uses the product. The same logic applies to our partners. We simply don't know which users need logins in advance.

We could allow them to sign themselves up, but as I mentioned in my previous wiki post, Internet search engines won't be able to index the content. Since many people use a search engine as their primary way to navigate the web, they might never find our site. Even if they do find the site, they won't know what sort of great stuff is posted there until after they sign up.

In the case of our partners, there's an additional incentive. These systems integrators, consultants and resellers often work with a variety of products. They already have a bewildering array of logins and passwords to manage. Most will opt out of signing up for yet another technology website, unless they're certain they need it.

Chances are, they'll look somewhere else for the information first.Perhaps they'll go to another website, one that we don't control, and who knows what they'll see there? At least if they come to our site, they can get the answers straight from the source. So it's potentially less damaging for us to make our content widely available.

The Decision

On balance, the arguments were strongly in favor of leaving the SDK Wiki publicly viewable. So after a month behind closed doors, the wiki has re-emerged with a stylish new look. We added a few disclaimers to highlight pages still under review and established a more formal monitoring process. I'm really happy with the final result.

And as frustrating as the ordeal was, it's made me appreciate two things. One is that this information management thing is hard, even for a company that does it for a living. I have a much better understanding of the work our customers go through to implement our ECM product now. I'll listen much more sympathetically to our customers as a result.

The other thing is that I work with really great people. It's been a challenge to deal with everything that's happening at our company lately. You can sense the frustration in a previous wiki post. But the folks at my company are awesome.

And I'm not just saying that because they let me win this one.

What is this Expert Location thing?

Maybe this has happened to you before: You are one of those fabled 'knowledge workers'. You realize that you really need to know about a certain subject. We'll call that subject FooBar. You look in your corporate knowledge base (you do have one, right?) and you find a document there with 'FooBar' in the keywords list. Unfortunately, you know nothing about FooBar, so you can't really tell if this is the latest thinking on FooBar, or what this whole FooBar thing is about, what all these FooBar buzzwords really mean. Maybe you just need to talk to the person who wrote this document and learn more. What you need is a FooBar Expert.

But how do you find that expert? Theres been a lot of ink spilled on that very question, but I'm not sure anyone has found the holy grail of expert location. I've been thinking about the subject myself (heck, just the other week someone accused me of being an expert on expert location!) . And I figure if fingers are getting pointed, I should share my thoughts on the subject.

So what makes an expert? There are a lot of definitions of “expert” out there, but I like this one: “An expert is someone widely recognized as a reliable source of knowledge, technique, or skill whose judgment is accorded authority and status by the public or their peers.” I like that definition because some key ideas – wide recognition, reliability, trust. I think each of those concepts is worthy of its own discussion, so I'll just start at the top - recognition. How DO we find that FooBar expert?

For computers, recognition is done through some form of people tagging. While there is certainly a lot to be said on how humans tag expertise in their head, for now we'll stick to how computers can aid in finding experts. If you think about it, there are a couple of ways for an expert location system to tag experts: Creator (Self) tagging, Expert Tagging (i.e. A librarian), Machine Tagging (i.e. Entity Extraction), Social Tagging (i.e. Folksonomy, group, or "Peer" tagging).

Each type of tagging has its pros and cons:

• Self tagging isn't a bad approach necessarily, but the typical definition of expert tends to be "a widely recognized and trusted source of knowledge"; so being self-tagged instead of peer-tagged has its flaws (hubris!). On the other hand, no one else tends to know what you know better than yourself.
• Expert Tagging comes from the library science way of defining things. The benefit is (one hopes) an independant certification of what one knows. Expert tagging can also come implicitlly in a corporate environment from organizational structure. If you are the lead or even a member of the FooBar group, you're assumed to be a FooBar expert.
• Machine Tagging is an emerging concept, but not a new one. Intelligence analysts (aka spies) have been using machine-based tagging to connect people with what they know through all sorts of intelligent (pun intended) algorithms. The basic concept is that you can pull key words (usually called 'entities') from text (newspapers, audio transcripts, overhead phone calls, and so forth) to connect the content of what is being said to the person doing the talking, the person they are talking to, and the person they are talking about. Its a great approach for finding a needle in the expertise haystack, and as a result organizations spend a lot of money on tools that find quality connections. However, it assume you have a lot of hay (and a lot of dough) to work with.
• Social Tagging is probably the most common "non-computer-aided" way to tag an expert. Back to my definition - an expert is someone widely recognized. Social tagging the traditional way comes from professional groups. First, you have the groups that certify expertise. This can be anything from the American Bar (lawyers) to the Institute of Electrical and Electronics Engineers (IEEE - Engineers, naturally).
  In academia, you also find a ranking system - citations. The value of papers written on subjects and ones expertise credentials are boosted by the number of your peers who cite your work as a source for theirs. Those who are considered experts in their field are those whose work is more frequently cited (the same is arguable true of blogs).
  Expertise in other fields can also be through informal referral networks - especially in fields where people don't write or obtain certifications for a living. Using general contracting and contruction as an example, people maintain personal networks and evaluate expertise based on performance. All plumbers are certified through a variety of trade guilds and professional groups. But that may not be the only measure of expertise. One might be considered an expert plumbler if 9 out of 10 general contractors recommend you to fix leaky pipes - and in many fields the personal trust outweighs the formal titles.
  Is there a weakness to social tagging? Of course - first it requires people to contribute to the classification of other people (People are too lzy to tag themselves, will they really tag others?); second it assumes that others are a good judge of what it is you know.

There is a lot more to be said on the subject, but thats a start. After all, its not like I'm an expert on this.

Hubris and Lockdown

This is a continuation of my previous post about the SDK wiki. We had decided that the best way to document the development tools that came with our ECM product was to create a wiki site. We stood it up in December 2005.

It worked well. We were improving the quality of our documentation, because our developers and technical support teams worldwide could help maintain it. We were reducing the volume of calls coming into our support line. We were helping to advertise the capabilities of our product. You could say it was the victim of its own success.

At the start of the project, we'd sent out an email or two to staff about the effort. During the next few months, we quietly promoted it to select partners and customers. It proved to be a valuable resource for those that knew about it. A few customers even thanked us for making the information available. The information had always been in the documentation that shipped with the product, of course, but in today's Internet Age, if it isn't online it doesn't exist.

Six months after going live, we announced success. We posted a note to the site itself and sent out an email to staff. By this stage, the technical teams were doing most of their documentation for new features on the wiki itself. We thought the concept had proved itself.

Midnight Raid

Then, when the corporate homepage was redesigned in the middle of 2006, we decided to include a link to the SDK wiki. It was the link that caught the eye of a few reactionary folks in the company. I recieved an IM in the dead of night from one of the members of the R&D team: "They're going to shut the SDK wiki down!"

Ok, I'm being a bit dramatic. Everything sent to me from the R&D team arrives in the dead of night, because R&D is in Australia and I'm in North America. But it was still a shock.

Frankly, I'd expected one of our other experiments to have caught the attention of management first. On the heels of the wiki success, we'd decided to create a separate wiki site regarding the best practices for implementing our software. It, too, was publicly viewable, and much of the content was still under construction. We were using that wiki as a way to both aggregate knowledge about our software deployments, consolidate lessons learned, spur discussion and debate, and publish good ideas. Radical stuff for a company that had been afraid to mention the word "product" on its homepage.

Or it might have been triggered by the new online user forum, where customers could post questions and recieve public answers about our product. This was also controversial, because the company maintains a listserve for this information. The listserve had fallen prey to abuse from time to time, so I could see how the idea of an online forum might be met with resistance.

But the SDK wiki? What sort of problem could that be? Our first reaction was disbelief. What on earth could be the problem with posting our API documentation online?

Social Leper

The wiki was locked away behind a registration and login scheme.

Yes, that sounds relatively mild, but it's actually the kiss of death for many websites. The only sites that survive a login scheme are those with compelling, known content. The New York Times can get away with it. Everyone is familiar with what sorts of content a newspaper has to offer. In the case of the New York Times, most folks have an idea of the quality of that content as well. But a site describing the features of an API belonging to a little-known software firm? It might as well be invisible.

And it is invisible to the most powerful eyes on the Internet: Google. When locked behind a password, no search engine can index the site. Since almost everyone uses a search engine to find content on the Internet, making these search sites blind to your website is the modern day equivalent of becoming a hermit.

So it's not something to be done lightly. Why was it done? That's the subject of the next post.

Grabbing at Straws

I promised I'd talk about the efforts to get the SDK wiki going at my company. I'll leave out the name of the company but I just can't tell the story without talking about the business it's in. My sense of irony wouldn't permit it.

You see, my employer is in the information business. Its job is to help organizations manage content-- as loaded a term as you'll find in this Internet Age. By content, I mean records, documents, audio, video, and other forms of stored knowledge. Not the stuff in people's heads -- nobody can help with that -- but just about everything else.

We make software that helps governments, companies, and other organizations, manage their information. It sounds simple, doesn't it? Actually, it's very hard. This story helps prove that point.

I work on the technical side of this firm. I was hired to help assist our customers and partners user our Software Development Kit, or SDK. It's basically a set of tools that allow folks to customize our software application.

We faced a few challenges with these tools. The main challenge was that most people didn't know these tools existed. Quite a few were uncertain as to how to use the tools. Others had trouble troubleshooting things they had constructed using the tools.

Compounding the problem was that the company is a global organization. The folks best positioned to talk about the SDK were in Australia, where our company and its R&D team is headquartered. Our other customers, particularly those in North America, had to deal with intermediaries. (That's me.)

Or they could have read the manual, the documentation, or the sample code that shipped with the product. But who does that nowadays? Nope, for most of our customers, the best option was to call or write an email to our helpdesk.

The problem was that email and phone calls don't scale well. We needed a way to capture the questions and answers, a way to refine our documentation and samples, and a way to get the word out about our tools. And we needed to do it fast. We're in a competitive industry with a lot of big players.

Wheteher due to inspiration or despiration, the API Support guys (including me) and the R&D folks turned to a tool that might help us solve the problem: a public facing wiki, driven by the Dokuwiki engine, that would allow all of our employees and partners to contribute to our knowledge base.

It sounds like a great idea, doesn't it? In the next few posts, I'll tell you how it played out.

Wiki Wackiness

As I mentioned two posts ago, I've been heavily involved in an effort to get my employer to embrace new communications channels. Key among these being a wiki containing documentation for our SDK, an online user forum, and a best practices site for our partners (and ourselves).

These efforts have hit a roadblock; hopefully a temporary one. It's tough work moving a conservative company in a staid portion of the software industry to embrace new things.

I've been pouring my thoughts onto these corporate sites. I've invested a considerable amount of time in them. I'm understandably proud of them, though I admit they've still got a long, long way to go. Those of us who set these sites up realized we were taking a risk, but even though we'd mentally prepared ourselves, it was a rude shock when they were locked down one day for corporate review.

Over the next few days -- possibly weeks -- I'll be chronicling the whole saga here. I'm still debating whether to list the name of the company. I've decided to keep all the key players' names secret, unless they tell me otherwise.

It won't be nearly as much fun for me as talking about computer games, movies, books, and other things. But someone else may find it entertaining, in that slow-motion car accident sort of way.

Another addiction?

I'm staring at an unopened box of HeroClix right now. It's a gift from my brother-in-law. He's a fan of comic books and board games, and this is a hobby of his. Now he's sharing it with me, but I can't quite bring myself to open the box to see what the game's like.

Every geek takes comfort in the thought that somewhere, there is an individual more geeky than himself. We all laugh at the Comic Book Guy while secretly fearing we're just as bad. For that reason, most of us geeks have secretly decided which cult classics and bizarre sub-cultures to avoid.

My wife, a cognitive science major, is proud of the fact that she has never watched an episode of Star Trek. Until very recently, I, an avid computer gamer from way-on-back, had never played an MMORPG. We both liked the fact that, geeky as we were, there were some lines we hadn't crossed yet.

I now play World of Warcraft, at the urging of a few insistent coworkers. It was a mock struggle. I spent several months doing my very best Cameron Frye impression from Ferris Bueller's Day Off. Eventually, I caved in, and I've been having a great time, despite being one step closer to the Comic Book Guy.

I imagine I'll have a great time with HeroClix as well. But for a guy who already hangs Star Wars posters in his living room and still has a few Weird Al Yankovic cassette tapes lying around, I'm drifting dangerously close to the social pariah stage.

At least I haven't joined a troupe of Renaissance re-enactors.

Yet...

Where have I been?

So I realized that I hadn't posted a darn thing to my blog for about nine months. I blame my job.

I didn't want this blog to be about work, as so many blogs are. I wanted it to be a break from work. I wanted it to be a place where I could discuss my hobbies and other activities. Unfortunately, I haven't had many other activities lately, apart from Ultimate Frisbee and that unfortunate World of Warcraft addiction I've contracted.

I work for a software company that's facing some stiff competition. We're an interesting product of globalization: a small, global firm. We've got offices on three continents and roughly 200 staff.

Previously, each regional unit ran its own shop, but as our industry consolidated, we've had to start acting more and more as a single entity. It's proving to be a very, very hard thing to do. Headquarters hasn't really come to grips with the problem and as a result, those of us in the field have been groping for our own solutions to urgent problems.

So I've been embroiled in efforts to set up various wiki, forum, and blog sites in a desperate attempt to improve internal and external communications. So I've actually been authoring an awful lot of articles. They just weren't posted here.