Standing in the street trying to hear yourself think

Onno Benschop onno at
Tue Jul 7 22:57:22 UTC 2009

On 03/07/09 11:44, Andrew Sayers wrote:
> when someone comes to you with a problem, first 
> fix the presenting problem, then fix the second-order problem that 
> caused it, then the third-order problem, and so on back to the original 
> source.  Although this significantly increases the amount of work per 
> issue, it's more than offset by the reduction in the number of issues.

This approach speaks to me in many ways. As the manager of an IT
help-desk for 5000 seats in the mid-90's I instigated a regimen where
user problems were fixed by users. The way that worked is that the IT
professionals were discouraged to just "click and fix" a problem, they
had to explain to the user what caused the issue, how they got
themselves into the problem, and how to dig themselves out.

This met with lots of opposition.

    * Users were upset that phone calls took longer than "click and fix".
    * Management was upset that call queues were escalating and that
      number of resolutions processed were declining.
    * Helpdesk staff felt unloved because they couldn't just be a hero
      and fix the problem.

It has been said that I'm a stubborn person and I persisted. After 3
months, something really interesting started happening. The number of
calls to the help-desk started declining. Initially management thought
it was because users were so fed up waiting that they stopped calling
us. Further investigation indicated that users were having less
problems. They were more confident, more knowledgeable and more able to
help themselves. The kinds of problems we started seeing on the
help-desk were meta-problems, not "click and fix" problems.

What I don't know is how to translate that into a global community that
has an insatiable thirst for support.

It seems to me that emails to this list alone show an increasing trend
towards support style questions. We could coordinate a response effort,
say, emails coming in on Monday are dealt with by one person, Tuesdays,
by another, etc. Spread the load among several "sign-posters". How
scalable this is across the community, I'm unsure.

IIRC there is a company in the Netherlands (I forget its name), that
decided that more than 15 employees was too many. Keeping track of each
other becomes too hard, being social with all colleagues is too
complicated, accounting becomes a means in itself, etc. If the company
grows to that size, it's sales territory is split in half and the
company is split in half. Rinse and repeat. We could do a similar thing
with IRC channels, though I don't know if that would result in users
flocking to the single place where people are responding - we see it
today where people come into #ubuntu-server because "no-one's responding
in #ubuntu"

I have a fair amount of experience speaking to large groups but I've
been trying to think how I might apply those skills to teaching a class
of say 1000. How do you do such a thing on a mass scale? IRC is a useful
tool to talk to lots of people online, but it's hardly useful as a means
to show someone what's on the screen now and what it means. It also
requires that students have a set-up where they can follow along in real
time. Using electronic white boards, or webinars, or streaming video all
feel pretty clunky to me and hardly the way to help so many.

I've also wondered if 5 minute vod/pod casts might be a way to help
solve particular issues. The argument for is that it's a digestible
chunk of "monkey see, monkey do", but all the FAQ's and wiki
documentation to date doesn't appear to stem the flood of questions that
seem to already have an answer, so perhaps the teaching needs to focus
on "how to help you help yourself".

The individual comments in this thread are heartening and indicate to me
that there are others thinking about this. What I don't know is if the
proposed methods can scale more than a single order of magnitude, which
is not even close to being enough to deal with a bell-curve that is
heading this way.

It would be really productive if we can come up with a process that
leveraged the size of the community, but I'm yet to figure a way that we
can "pass it on".


Onno Benschop

Connected via Bigpond NextG at S31°54'06" - E115°50'39" (Yokine, WA)
()/)/)()        ..ASCII for Onno..
|>>?            ..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219 8888   -   onno at

More information about the Ubuntu-devel-discuss mailing list