A Few More Conference Thoughts

Continuing the conference conversation from here…

“Something has been bothering me about the format of the [Etech] conference. Each session is so rushed that there is little room for Q&A following each presentation. As a result, you don’t often get a chance to hear the audience’s point of view. The only way to get at this is if you force yourself on strangers in the hallway but, depending upon how you strike up a conversation, it can be hit or miss.”Ian Kennedy

More:

“I’d be willing to bet that, if polled, 90% of etech attendees would tell you that they hear the most interesting and compelling ideas and thoughts in the hallways, around the coffee pots, and out on the deck… not in the presentations. This year’s etech is big, much bigger even than last year (my first time here), and there are a lot of first-timers. You can usually identify them pretty easily– they’re the ones standing awkwardly alone, sometimes on the peripheries of conversations.”Chris Lott

One more, also from Chris Lott, on “The Name Badge Assessment”

Lott: “…you try to talk to one of the Conference All-Stars– perhaps someone you’ve interacted pleasantly with via email or IRC just minutes before– and they stare at your badge for a moment (you can almost hear the mental checklist preceding the shutdown: Google? Nope. Yahoo? Nope. Press? Nope. A-List blogger? Nope.) before their eyes glaze over. It doesn’t happen every time, but often enough to discourage input from just the people from whom interaction should be encouraged.”

More here.

On The Conference Thing: Etech, SXSW, Unconferences and Monocultures

It’s the idea that just keeps on giving. It’s been brought up before. It’ll be brought up again. And this week is going to be an interesting study in contrasts.

“I can’t think of a conference that is more insider, exclusive, obnoxiously rude, insidery (did I say they’re all insiders?) than Etech.”Marc Canter

Over the weekend, was talking to one of the women who was speaking at Etech this week, and she said the following: “Yeah, when they added me to the list, I increased the number of women speakers by 25%.” No way, I thought. Then I checked the Etech speakers list. (The list is also repeated after the jump, for convenience.) Wow. It wasn’t much of an exaggeration. By my rough count, about a dozen female speakers out of about 113 total speakers. A 9:1 ratio. Zoiks.

Why does this matter? Because conferences in this image have no edges to them. They are monocultural.

“But…but…where do we find speakers/participants for our technical conference on x?”

Here are a few dozen speakers. (By the way, to set up this Haystack took all of a couple of hours. The conversation was on Saturday, started putting speakers in on Sunday, and we were ready to rock by mid-day Monday. This thing is fun.) Click on the link above. You want a speaker on Digital Identity? Click on the “Speaker Topics” tag category and choose Digital Identity; you’ll find a bunch. Want a speaker on Product Development? Remix technologies? New Media art? They’re in there. Not sure about the credentials of these folks? Go into their profile, if they have an RSS feed, you’ll see what they’ve been thinking about lately. Want to see where they’ve spoken before? Check the “Past Talks” tag category.

Speakerswikihaystacksnap

Not enough choice for you in that haystack above? Here are a couple of hundred more speakers. No excuses.

I also don’t think it’s just the monoculture thing in conferences that is broken. In fact, I agree with Dave Winer:

“My guess is that if you swapped the people on stage with an equal number chosen at random from the audience, the new panelists would effectively be smarter, because they didn’t have the time to get nervous, to prepare PowerPoint slides, to make lists of things they must remember to say, or have overly grandiose ideas about how much recognition they are getting. In other words, putting someone on stage and telling them they’re boss probably makes them dumber. In any case it surely makes them more boring.” (This is from his unconference essay from earlier this week.)

Now, let’s compare the speakers list at Etech to the speakers list for SXSW. The ratio is utterly different, and improves from 9:1 to about 3:1. Not perfect, but hellaciously better.

Here’s what I propose: next time you choose to invest your time in going to a conference, think about what that investment of time is getting you on the following scales:

Picture_3

(There could be a number of other dimensions on here as well: geographic background, political beliefs, sexual orientation, art vs. tech vs. performance expertise, and so forth.)

Look for the un/conferences with edges. See you in Austin.

[Update]

“I found refuge in the hallways, since the ETech format is highly structured, and the sessions were all jammed.” – Stowe

“I was also surprised — it’s my first ETech — at the depressing ratio of women to men. Perhaps its inevitable that a conference that is constantly referring to its audience as the ‘alpha geeks’ would be so skewed, but it’s still annoying to me.” – Mo’ Stowe

Continue reading “On The Conference Thing: Etech, SXSW, Unconferences and Monocultures”

When Dishwashers Go Bad

Dw1Ethan needs help.

Let me rephrase that. I’ll start again.

Ethan needs our help.

A tale of woe has cast a pall over North Dallas. The story? A household appliance, gone horribly, horribly wrong. Was it because of its upbringing? An early abandonment by its parent, GE, at a young age? Those wild, unsupervised teenage years, huffing from 220V outlets, making runs to Gladewater every Saturday night with the Cuisinart and the Senseo? We may never know.

What we do know is this. We’re now in Day Two of a pending humanitarian crisis, the likes of which we’ve not seen since the dark days of The Mixmaster Incident (and related civil unrest) back in ’42.

The full story is here.

Of course, this crisis could have been averted if Ethan had home warranty. It’s not like we haven’t told him a million times. All he had to do was search “home warranty texas” and that dark cloud over North Dallas could have vanished as quickly as it arrived. But now, here he is, desperate for help.

The Head Lemur has pledged his help. Dennis Howlett is doing what he can. Kent Newsome is on board.

Ethan’s dishwasher is too far gone to be negotiated with. But perhaps, mayhaps, someone out in Dallas (Jennifer?) knows someone who knows someone who can perform an intervention. Jake, is it possible to bring in reinforcements from your neck of the woods?

The timing of our collective response is critical. SXSW is this weekend, starting in less than 48 hours, putting many people in harm’s way. And, while Texas is a big state, this menace knows no bounds. Today, Dallas. Tomorrow, Austin. By the weekend, this crisis may hit pandemic status, requiring action by FEMA. And no-one wants that.

Please help.

(Hey Ethan…the specs are good, but a better description of the problem would prolly help, too. And what’s the model # of your dishwasher?)

(dishwasher photo credit: emelin)

Microsoft Raises The Bar(n) For Hugh

Last Friday, I wrote about a different model of customer support. I intimated the days of pushing a customer through Level 1-2-3 support were numbered. In place of that model was a different approach: the suggestion that a customer would raise an issue, members of a community (both internal and external to the vendor) would swarm around it, and people would work together until the issue was resolved. It’s a belief that customer support has the possibility to be human, informal, and ad-hoc, and should be handled by the people with the skills and passion to solve a customer’s needs.

Here is a case study, where someone was encountering a fairly common problem; their wifi not working. Those of you who choose a company like infinity dish will experience this a lot less, but there will always be teething problems. It’s how these problems are dealt with that is key.

Every_day_is_frickin_1

On March 4th, Hugh posted on gapingvoid that he was having issues with his Tablet PC.

“All I wanted was to get the wifi on my Tablet PC to work properly. But of course, it doesn’t. It can’t go 24 hours without something going wrong. And the reason is Microsoft software. Of course it is. It always is.

Robert Scoble likes to say that Job One at Microsoft is to thrill customers. OK, fair enough. Get my wifi to work properly and I might start taking that idea seriously.

Any wifi mavens out there fancy trying to help me out?”

After a lot of discussion, but no action, he escalated on March 5th. (This is how “escalation” works in this model. The customer does it, not the vendor.)

“Could somebody from Redmond [I know a few of you will be reading this] please help me get my wifi working?

I spent FOUR HOURS last week at the software place trying to get this fixed and it’s still taking the piss. I. Am. Not. A. Happy. Camper.

You want to thrill customers? Fine; you can start by thrilling me. Let’s see if it’s more than just talk.

You guys like to make a big deal about the power of blogs to connect with customers, and transform your image and busines model. Again, fine, let’s see if it’s more than just talk.

Your move.”

On March 6th, they did. Hugh:

“Yesterday I posted how I was having trouble with my wifi.

Within a couple of hours I had received a personal e-mail from a Microsoft employee in Texas, a certain Keith Combs. Turns out my post had made it on to the internal Microsoft message boards, and was being passed around.

He called me up last night via Skype, and guided me through everything…

Once we had eliminated all the other possibilities, it turns out there was a problem with the router, which was easily fixed by resetting it and adjusting a few settings on the Tablet.

Et Voila! I’m happy to say, my Tablet PC’s wifi now works fine.”

Happyhappy

Hugh is a disproportionate case; his blog is widely read. Not everyone has that luxury. But the architectural pieces for the infrastructure needed to do this are already starting to fall into place. For example, what if instead of trying to take on eBay and Craigslist, edgeio searched for customer issues and bubbled them out into the open so they could been identified and resolved by a community?

I think the swarming/barn raising model of support is going to be increasingly prevalent. Adam disagrees, feeling that bad support is perhaps more simply a symptom of bad management and complacent customers.

What do you think?

“We Were Well-Paid, Latte-Drinking Vassals”

Versai’s Greg Olsen hits another one out of the park: Software’s Glorious Revolution

A couple of weeks back, GregO coined the term “Going Bedouin” that got a bit of buzz going with Om Malik and Jackson West, Stowe Boyd, Kevin Burton, the Guardian UK and others around how the current (and future?) crop of technology companies were self-organizing and getting things done with a minimum of infrastructure investment.

Now he’s taken aim at IBM, Oracle, Microsoft, Sun and the OMG, through the lens of Neal Stephenson’s Baroque Cycle, equating the the aforementioned companies with the Powers that ran the systems of Europe in the late 17th century.

(On the subject of Stephenson, just remembered these graphs from Cryptonomicon. Heh.)

GregO:

“Though I often griped, I learned to live within the structure provided by the ordained Powers. We made our treks to JavaOne, the Microsoft PDC, and other events to receive the word as written. We lived with a pace of new technology arrival dictated by the Powers and their committees of architects. We were sometimes forced to swear allegiance to one of the Powers and to purchase the requisite tools and literature from that Power in order to use their infrastructure. For the most part, we were well-paid, latte-drinking vassals.

Somewhere over the last five years or so something changed. Though I can’t think of a specific event to parallel to the Glorious Revolution of 1688, it is clear that some form of revolution did occur, and that a New System of the Software World is in the process of being established. The powers of the Old System are still around, but they no longer dictate what infrastructure and tool options are available to software developers. Today, new capabilities come into being because there is a demand and because there is someone willing to meet that demand – most often through the vehicle of an open source project, or through an Internet-based service.”

In the new software world, who is providing the illumination and Enlightenment? Salesforce’s AppExchange, Intuit’s QuickBase, JotSpot, Ning, Thingamy

Good stuff. Read the whole thing.

(disclosure: versai is a customer of cerado)

A Customer Support “Barn Raising”

(Barn raising image: Ian Adams)

Rural_wsgabrolAs mentioned here, I had the opportunity to spend yesterday speaking with the fine folks from the Consortium for Service Innovation about emerging collaborative technologies, primarily in areas of blogging, wikis and social networking. What I expected was a good, conversational session about how collaboration tools could be used to improve customer support. What I didn’t expect was to leave, head spinning with notions, with an entirely different idea on how to address ongoing customer needs over the course of a business relationship. Happily, however, that’s exactly what occurred.

Perhaps a bit of background on the current “state of the art” (::cough::) in customer support is useful to set the stage. Currently, a large number of organizations view customer service and support (that is, interactions with a customer after the initial sale) as a series of “incidents” that need to be “closed.” That is, when a customer has an issue, the customer contacts the organization’s support center, and opens an “incident” (or a “trouble ticket”) that needs to be resolved. This is very transactional, very discrete.

Customer support is also viewed as a cost center by many organizations. This causes support to be measured internally within an organization with an eye toward keeping support investment as low as possible. How to do this? Use the least-expensive resources that can be mustered in order to close the incidents, and close them as quickly as possible.

In emergency and battlefield situations, triage (another definition here) is usually performed in order to best prioritize need and allocate scarce resources. In many modern customer support organizations, a similar idea is used. In customer support orgs, this is usually referred to as “Level 1,” “Level 2,” and “Level 3” support. While the definitions vary, these three support levels are usually defined as some variant on the following:

  • Level 1: The Level 1 support team is the first point of contact in the incident response process. Customer service personnel are responsible for call handling, triage, problem characterization, and resolution of basic problems. Oftentimes, Level 1 Support answers questions by consulting lists of frequently-asked questions (FAQs).
  • Level 2: The Level 2 support team is staffed with support engineers assigned by product type. The support engineers are responsible for lab-based simulation, difficult problem resolution, defect correction or escalation management to Level 3 support.
  • Level 3: The Level 3 support team is staffed with senior analysts, program managers, and development engineers dedicated to working on the critical problems. They are responsible for confirmation of defects, including complex failures, performing interoperability studies, and enacting engineering level changes to permanently resolve any issues in released products.

(The Level 1, 2, 3 definitions above were generalized from this list from Caspian.)

From the vendor’s perspective, this arrangement makes perfect sense. Support is a cost center. Highly trained development resources are expensive. Many problems can be answered by rote, by Level 1 support (read “inexpensive”) personnel. Therefore, the logical thing to do from the vendor’s perspective is to have incidents come into Level 1 support first and only then, and only if they cannot be resolved, escalated to Level 2 and then, in very rare cases, to Level 3. It’s all very logical, rational and measurable with a stopwatch and a stats counter.

However, that’s not what customers see. Here’s the customer view of support:

Level123_2

(By the way, the graphics above and below were cribbed from the folks over at XPlane. If you haven’t seen the things that Dave Gray, Aric Wood and the team at XPlane have done around Visual Thinking School, you’re missing out.)

From the customer’s point of view, there’s a gatekeeper who is required to exhaust all (inexpensive, and ineffective) possibilities before escalating the incident to Level 2 or Level 3. If escalated to Level 2, all possibilities must be exhausted before escalating to Level 3. It’s slow. It’s inefficient. It’s maddening from the customer’s perspective.

Now, the Level 1-2-3 customer support arrangement is pretty much standard practice, at least across the technology industry. But what if there existed a better way…? (Cue Wayne’s World dream sequence music here.)

The big “a-ha” moment for me yesterday with the consortium was their idea of “swarming” around an incident. Instead of going through the rigid, rote routine of support escalation, what if there was a model that looked like this?


Support3
Instead of pushing issues through a funnel, resources
swarm to an issue to resolve it, then disband.


This idea can be described thusly:

Instead of issues (incidents) being pushed through a series of increasingly onerous screens in order to find a solution, what if the solutions were drawn to the issues?

A reading from the Book of Clue, the word according to Dr. Weinberger (p. 127):

“Here’s one example of how things work in a hyperlinked organization: You’re a sales rep in the Southwest who has a customer with a product problem. You know that the Southwest tech-support person happens not to know anything about this problem. In fact, she’s a flat-out bozo. So, to do what’s right for your customer, you go outside the prescribed channels and pull together the support person from the Northeast, a product manager you respect, and a senior engineer who’s been responsive in the past (no good deed goes unpunished!). Via e-mail or by building a mini-Web site on an intranet, you initiate a discussion, research numbers, check out competitive solutions, and quickly solve the customer’s problem – all without notifying the “appropriate authorities” of what you’re doing because all they’ll do is try to force you back into the official channels.”

Dave Weinberger nailed the fundamental aspect of this concept back in 2000, per the above, and now the members of the consortium are actually thinking about how to get it done. As important as the “markets are conversations” meme from Cluetrain is, this idea of resource swarming to resolve customer issues is equally important.

Put another way: when an incident occurs, the right people from the social network that forms the community (from inside the company, from the existing customer base, from the broader community of interested parties) will find out about the issue, collaborate using a combination of formal (e.g. FAQs, formal diagnostic processes) and informal (blogs, wikis, Skype, instant messaging) mechanisms, and resolve the issue in a real, human and adhoc manner. The right people come together with their appropriate tools and skills, and they get the job done together, and then disband and reform fluidly for the next incident.

It’s customer support as barn raising. More here.


How to get there? Some ideas to discuss…

What if we abolished the support “department?” What if individuals in the organization were encouraged to invest, say, 10%-20% of their time working directly with customers (not unlike what Google does with their engineering staff and Google Labs)?

What if people within the organization subscribed to an RSS feed of incidents, and jumped in and helped when something in their wheelhouse came across their feed reader?

What if dynamic, living profiles were set up, a la Haystack, where people within the organization could tag themselves based on their areas of experience and expertise, and be matched up with incidents that they were best suited to resolve?

What if, when those incidents were resolved, they were stored in a public knowelege base that customers could peruse, and help themselves? (Yes, there are a number of systems out there right now that do this, but they are the exception, not the norm.)