Aaron’s Potlatch

I just read an interesting blog about email and getting rid of it if it is controlling your work life, as well as the article they refer to http://www.theage.com.au/news/essential-gadgets/when-the-inbox-is-on-the-outer/2007/09/19/1190486197735.html is also interesting.  It definitely made me envious, to have an organization that forward thinking in how to communicate.  We push a lot of things out on wiki now, but much of the organization still uses email.   In addition to the focus, I think wiki’s or other online collaboration help with other aspects of communication:

•  Wiki’s are “Permanent”, so people think about what they write more before sending it.
• Wiki’s are “Open” so people don’t write things they probably shouldn’t have to begin with.
• Wiki’s promote people to stick with the facts, and stay away from lengthy political discussion.

However, neither Wiki’s or email address some other bastions of corporate waste, Meetings!

• Decision making:  Andrew McAfee has an interesting article that recognizes decision making as separate from information itself.
• Brainstorming:  Meetings can be (although most aren’t) very effective at brainstorming.

At work, I and my team have been assigned to work on a new project, however, nobody knows what this project is supposed to accomplish. Everyone is talking about providing the “best widget/service in the industry”. Resources, and millions of dollars have been allocated, but nobody can describe why, or what the desired end goal is. Just to have a shinier fancier widget or service?In my experience, this is the wrong way to communicate, collaborate, and motivate. Companies should agree upon goals that are stated in terms of customer experience of what customers really want, and should be described in desired end result that is free of HOW to accomplish this. Couple of examples:

1. GM vs Toyota. GM (or other American auto companies) had been merrily dominating the American auto industry, but Toyota with an obsessive focus on Customer value was addressing quality issues. I can just picture internal goals/metrics at GM at the time about producing “x units” or “y cars/day”. While Toyota focused on producing happy customers. Because GM focused on an internal measurable (x units, or y cars) as opposed to a Customer metric (were they happy?), Toyota eventually won out. That focus on internal deliver-ables which are ASSUMED to be equivalent to what the customer wants are almost never right. All employees must have an understanding of what the goal is, what the customer value, see the toyota usa web site about “Customer First“.

2. Ipod vs “MP3 players”: IPod was not the first MP3 player on the market, but it did come to dominate. Other MP3 players may have had more “features”, but Apple realized that by focusing on what customers really wanted (“Good music listening experience”), they had to expand their definition beyond the “MP3 player’ and encompass some additional portions of the music experience (coolness, and the transfer, management of songs).

In both of the examples, Toyota, and GM made what I call a Proxy Association Error. That is, the Music player was a “proxy” for the music experience, and the automobile was a proxy for the transportation, people didn’t want car’s or players, they wanted music experience and transportation. Once a better proxy was found, the customers abandoned the old way for a better one. Toyota, and Apples competitors didn’t see this, they thought the “Car” and “MP3 player” were the actual thing that people wanted.

So, here are my paradigm for how to distribute work (not tasks) to a company:

1. Get the entire employee population involved in seeking to understand what customer value is (real customer value, not proxy error, the “music experience” not the “mp3 player”).

2. The goal of any work should be stated in how it should help the customer. The Goals should be distributed should be stated in terms that are free of how, and leave the wisdom of the crowds and changing winds of the marketplace open to allow a different solution that still makes the customers happy.

Examples:

“Identify the top causes of dis-satisfaction by customers, and put in place plans to mitigate them” not “Implement improvement of the invoice service”. The first leaves the ability for the employees of the company to contribute their own ideas, the 2nd doesn’t.

I am working on a new Strategic Goal planning tool which helps users create goals, collaborate on them with others, and track accomplishments, with visibility up and down the organization. It is intended to bring the best aspects of the wisdom of the crowds to helping guide a company as exist within the Open Source community.

There has been much discussion about email as a collaboration tool, and possible alternatives. These are great discussions and really got me to thinking as well. It seems email started out as a communication tool, and as other information systems become more and more common it was used more as a tool to fill in the gaps of these information systems (“hey, please review this document and get back to me”, “can you login and approve my expense report”, “did you see the stats on the so and so report?”, “the xyz system just generated a system alert, more information here…”). An over generalization is that email discussing something that has no electronic information (as was the case with most things 20 years ago) works good (not great). Email as a bridge between the gaps in other systems doesn’t work as well.

Michael Sampson discusses the importance of correct usage and people issues, and it seems to me a large influence on this is what is “IT” that you are talking about? I think much of the email in my inbox is about some other system (see diagram below “Application Context”). In this situation, the person is switching context in order to process the email, they must also go to another system or have access to additional information. This diagram holds true for people sending notification of wiki pages to people on email as well. However, using Mashups, it seems possible to take the existing tool of email and allow it to be shown within the context of another application (see diagram 2). This would require some ability to tag, or differentiate emails for a specific context (for instance, a purchase order going through the request chain could have all the emails about this shown on the same page).

I tried out the new Gliffy for these diagrams, it worked great, thank you!

Thanks also to these articles for helping stimulate my thoughts here:

http://www.innovationcreators.com/2006/09/email_is_critical_to_enterpris.html
http://www.annezelenka.com/2006/09/email-the-good-enough-collaboration-tool
http://www.grey-consulting.com/blog/2006/09/email_the_good_enough_collabor.html
http://www.michaelsampson.net/2006/12/email_vs_collab.html
http://www.mindthis.net/mindthis/2006/12/counterpoint_em.html
http://confusedofcalcutta.com/2006/09/10/on-social-software-and-consensus/
http://www.inc.com/magazine/20060901/column-freedman.html