Knowledge Jolt

A friend on Twitter pointed me to a simple post from Chance Bliss.  It's only one paragraph and the title basically tells you everything: Managing projects through email sucks.  But in case that isn't enough, here is the first sentence.

There are many ways to sabotage a project, but the one I find the most effective is email.

Good stuff!  This statement can be just as easily applied to the business at large.  Email is fine for the transmission of facts and some information, but directing people and asking for more nuanced information via email is just asking for trouble.  In most cases, this just fails outright. How many times have you seen emails pinging back and forth when a simple phone call or office drop in could resolve the question then and there? 

The struggle for many people and organizations is that they see no other way to work than via email because it has become so deeply ingrained in the way of doing things.

Here is a suggestion: Instead of sending email, step back for ten seconds and reflect on: Does this need to be sent?  Can I contact the person directly instead?

I run across plenty of articles, either through friends pointing me to interesting things or via my feed reader and the interesting stuff people write outright.  As everyone knows, there are far too many.  But... here are a couple articles with metaphors that work for me.  And they are related to the interests of this blog.

Chris Grams has Three tips for escaping the creativity peloton without giving up on collaboration which uses the bicycle racing image of the peloton as the connection to collaboration.  The members of the peloton must work together, but at some point the winner has to jump out of the pack and cross the line first.  It takes leadership, shared vision, and people who are working for the win.  Chris argues the same has to happen in organizations.

The ever-prolific Robert Scoble has Coming soon: the disruptive molecular age of information in which he likes all the material out there on the web to "atoms" and the painful job of bringing those atoms together into "molecules" as something that may become more automated.  As it stands now, it takes humans time and energy to do this: kind of like I've done in this brief article.  Robert wants to see tools that help us be better at making the molecules we want to build.  The logical connection here would be to the data-information-knowledge-wisdom hierarchy, but that's not really where Robert is going.  He just wants to be able to supplement the human capability to blend and meld disparate ideas - to make it easier for people to make those molecules, rather than mucking about in the laboratory.

[Photo: "Raleigh Record" by Dave Elmore]

[This is a comment on Beyond lurking - Modes of participation from Nancy White.]

Jack, thanks for adding some great URLs. I've added yours to my blog post as well (and will continue adding and mining!)

THANKS!

[This is a comment on KM in the media - Toyota recall from Nimmy.]

Thanks for the post, Jack. Thinking about two simple ways in which such a situation could possibly be approached....

1. Processes that suggest problems/solutions from an appropriate database at the time of project documentation/appropriate project registration activity

2. Smart Enterprise 2.0 mechanisms that retrieve relevant content/pointers based on attributes/tags related to domain/challenge/expertise/region etc

There are many modes of participation in a community.  You can be the leader, driving action and encouraging others to jump in.  You can be one of the many regular people who raise their hand to do things and respond to events within the community.  And you can be one of the many more who are members of the community who only actively participate on an infrequent basis.

But even among these big buckets, there are additional distinctions.  People who have been leaders fall back into regular participant mode or even idle participant mode.  The level of engagement of the entire community changes, and the resulting mix of people in various roles changes.  Or the reverse happens: the mix of people changes, creating a change in the sense of the community.  Or both.  Or a simple change of venue causes the community to operate differently.  And for the individual, there are many reasons as to why they "lurk" beyond the first assumptions about time and fear.

Two posts in my feed reader - right next to each other - have me pondering this.  First off, Nancy White asks for References on Lurking - or as she calls it "legitimate peripheral participation" - and then there is Lurking, a Personal Story from Andrew Gent.  Andrew talks about his personal perspective about why he has gone from active community member to a lurker - an aspect that many of the lurker discussions ignore.

To answer Nancy's question, one of the first things I thought of was a Communications of the ACM article I read and wrote about a while back on Encouraging participation in virtual communities.  I liked the notion in that research that the leaders and more active participants have some role in encouraging ongoing participation - beyond the cajoling of people to get their backs up off the wall.  And then there is the Ladder of Participation, which delves into the layers of engagement on a different framework.  Jakob Nielson generated a lot of excitement in his delving into the 1-9-90 discussion, and I wrote about it too.  And finally, one of my favorite comments on the topic of "being a lurker" was in Lurking builds commonality 

... broadcast television is (was?) all about building common understanding across the populace. Everyone was a "lurker," but we were being informed, so that next-morning conversations over coffee had a common basis.

[Photo "lurking" by massdistraction]

[This is a comment on KM in the media - Toyota recall from Jack Vinson.]

This is an important point to make. We can't expect any system (whether human or technical) to be able to proactively solve every problem that might occur. My concern is always that we rely on "the database" without adding the rest of the appropriate processes around using it and making it helpful to the business.

[This is a comment on KM in the media - Toyota recall from Nathan Zeldes.]

And suppose Toyota solved this particular meta-problem by implementing some system that would, in future, raise a global alarm whenever a safety problem is detected in one geography... will that detect other systemic shortcomings in their KM culture? Seems to me that a generic system that identifies all possible process problems before their first manifestation is not going to happen. :-(

[This is a comment on KM in the media - Toyota recall from Swan.]

Jack, definitely a good example to bring out the need for knowing what we know.

Any interest in moderating a #KMers chat on the topic? Could generate some actionable ideas.

Swan

One of the original rallying cries behind knowledge management was, "If we only knew what we know."*  20 years ago that got hijacked into building knowledge bases, which didn't answer this cry.  And now we have KM 2.0, and if it is still all about the technology, it still won't answer the cry.  Here's a current media example of the inevitable result.

The recent Toyota recall and particularly the reporting of the U.S. congressional hearings on the subject turned up at least one tidbit related to knowledge management.  Today's article in the International Herald Tribune isn't published online yet, U.S. official takes heat at Toyota hearing by Micheline Maynard, who seems to be a key reporter on this topic for the NY Times.

The KM connection?  It turns out information and concerns about the sticking accelerator was known and fixed in Europe at least a year before it became a problem in the U.S.

Mr. Inaba ... acknowledged that Toyota had been aware of issues with sticking pedals in Europe for over a year before accidents were reported in the United States.

What happened?  Toyota is regarded as an advanced company with practices in manufacturing and continuous improvement that have made it one of the biggest automobile manufacturers in the world.  The Toyota Production System has been the subject of books and education around the world.  Toyota are even regarded as a Most Admired Knowledge Enterprise.

This is what happened.

Mr. Inaba said the information had been contained in a company database but that it could have been found only if a staff member had known where to look.

I have no knowledge beyond what has has been reported in the media.  This could be an isolated example or an extensive problem throughout the company.  Given this one sentence, I will leap to the conclusion that the problem wasn't discovered due to an artifact of how the business operates.  The fact that no one in the company discovered the issue in the database is a symptom.  Whose job is it to do this kind of thing?  Is it one specific person (or role)?  Is it the job of everyone in the business to seek out this information?  What is the business process when potential problems happen? 

* I believe it came from an HP executive.  It's also the name of a If Only We Knew What We Know">Carla O'Dell book.

[Photo: "Rallying cry" by joffley]

[This is a comment on Communities Manifesto from Stan Garfield from R. Gauthier.]

Thanks for making me discover the Communities Manifesto Jack. Very interesting and worthwhile read.

Roch

Stan Garfield posted an interesting Communities Manifesto that describes 10 principles of communities and goes some way toward differentiating between teams and communities.  This is all based on his direct experience in the area.  His description:

Communities are groups of people who, for a specific subject, share a specialty, role, passion, interest, concern, or a set of problems.  Community members deepen their understanding of the subject by interacting on an ongoing basis, asking and answering questions, sharing information, reusing good ideas, solving problems for one another, and developing new and better ways of doing things.

I particularly like the sense here that the community is about people sharing common interests without need for specific deliverables.  There may be a lot of reasons for those common interests in real-life communities, but the key thing that brings them together is that shared passion for their subject of choice. 

The main space for discussion has been the SIKM Leaders group that Stan created several years ago.  And that discussion has been one of the more interesting and involved on this particular mailing list.  (The main focus of the group is to host monthly live phone discussions on a KM-related topic, but discussions will sometimes bubble amongst the membership.)

And those ten principles of communities?  Please be sure to dive into the document, if you want to read more of his perspective and thoughts on these items. 

1. Communities should be independent of organization structure; they are based on what members want to interact on.
2. Communities are different from teams; they are based on topics, not on assignments.
3. Communities are not sites, team spaces, blogs or wikis; they are people who choose to interact.
4. Community leadership and membership should be voluntary; you can suggest that people join, but should not force them to.
5. Communities should span boundaries; they should cross functions, organizations, and geographic locations.
6. Minimize redundancy in communities; before creating a new one, check if an existing community already addresses the topic.
7. Communities need a critical mass of members; take steps to build membership.
8. Communities should start with as broad a scope as is reasonable; separate communities can be spun off if warranted.
9. Communities need to be actively nurtured; community leaders need to create, build, and sustain communities.
10. Communities can be created, led, and supported using TARGETs: Types, Activities, Requirements, Goals, Expectations, Tools.

Thanks for this resource, Stan!

[Photo: "Frozen 085 Marius Watz: Sound memory (Oslo Rain Manifesto)" by Marius Watz]

Chris Brogan, who I've met once or twice thanks to the active social media network in Boston, always has interesting thoughts on how and where this stuff applies.  Today he has an article that steps away from the minutia and looks forward, When This All Gets Cool

Social media are a bunch of tools. They let us see things a bit differently. They empowered new ways of working together. But they’re just the tools. When this all gets cool is when we start really turning this stuff on our own passion projects, on our bigger goals, on what COULD happen.

Software and tools are fun to play with and try out.  Check out the workshop of any woodworker or the scrap bin of an avid seamstress.  And eventually they decide on the best ways to use the tools at hand to make something.

It's the same with software (social or not).  You try out a new package, a new website, a new plug-in.  With social software, you try it with your friends - and many people hear about it from their friends and gape or scoff, depending on their own interests.  But after the trial period comes the point of really USING this stuff in real life.  Does it make sense for me?  Does it make some aspect of my life easier (not just different) and more manageable?  Does it create some new capability or capacity that never existed before?  Does it create a secondary problem that is likely to reduce its value?  Even better: does it eliminate or significantly reduce some problem ("pain point")?

Get out there and DO something!

[Photo: "pantograph pattern scraps from Carter Latin" by Nick Sherman]

And experience and knowledge are rather difficult to stuff into a database.

The discussion of expertise never fails to entertain and inform - at least for me.  I think Harold Jarche has the same sensibility, repeating some bits of conversation in his Information is free; Experience is expensive post.  The post consists of tweets and some other quotes relating to expertise, and then he closes with the title quote from @JPBarlow.

@JPBarlow Information is free. Experience is expensive.

And I think this is something that the technologists don't fully appreciate.  The technology looks shiny and pretty, so we tend to look at it and convince ourselves that it will solve the problem.  It is relatively easy to collect information (assuming it is somewhere) and make correlations about who knows what, based on authorship and social graph information.  But then taking that next step into engaging that experts on a new subject or in an area that seems to be related to what they know, that takes you out of the technology and back to the knowledge and experience that they've gained - and that companies pay for.  And it is back to the human activities.

[Photo: "Inner Experience" by ecstaticist]

I get a bi-weekly e-newsletter from the American Management Association that occasionally has an article that gives me a reason to blog.  This time it is Super Size Productivity Now: 3% Automation, 97% Leadership by Kathleen Brush.  She talks about how organizations can create more real productivity - and it's nearly all down to leadership, according to this article.

Organizations that want to supersize productivity must maintain a dual focus on automation and employee motivation. Companies will soon find that productivity that sustains organizations is 3% automation and 97% leadership. Developing motivational leaders is a two step process: (1) Exterminate demotivating practices and behaviors; and (2) address the drivers of motivation.

As you might guess from this excerpt, the article is mostly around motivation and the depressing statistics from the Deloitte Shift Index that while productivity is up, employee morale continues to drop.

One element that this doesn't address is the need for focus that management can provide - and that they often kill by sending mixed messages.  In this sense, management's job is to provide the clear signals about priority and focus.  There can only be one priority system and it needs to remain stable over long periods.  No more telling people that X is the top priority today and then asking them to shift tomorrow to Y and then again to Z on the next day.  And make sure your measurement systems don't encourage behaviors that don't support the focus. 

What is "culture?"  Patrick Dunn asks that question in Culture eats strategy for breakfast - yes! But let's be clear what culture is.  I often talk about culture as a key element of knowledge management implementations as well as just about any other large change initiative.  If the change and the culture clash, it is often the culture that wins out.  But what do we mean by the idea of culture?

From Patrick's article, I liked the bullseye drawing that suggests many different ways to look at "culture" with the center being more stable and (probably) difficult to change.  The graphic is his too, in case the formatting doesn't make that clear.

The diagram on the right is a simplified version of various theorists' views of what culture is (have a look at Trompenaars, Hofstede, Adler and others). It suggests that culture exists and operates at various levels. What's important in relation to social media is that, for example, an organisation can try to cultivate norms and behaviour in terms of social learning, and put in place the infrastructure to do so (i.e. the signs and symbols level); but if the fundamental beliefs in the organisation don't actively encourage social learning, it's all pointless.

I really like this last point.  If the fundamental beliefs are out of line with the desired change, you are in for a real challenge.  It isn't completely hopeless, but you have to be willing to dig a little deeper with your implementation.  Specifically, how does The Change (whether it is a new software or new organizational structure or ...) relate to the core beliefs and values of the organization - of the people that form the organization?  What do you need to modify about The Change to align better with those core beliefs?  How can you modify the outer rings to align better with The Change?

[Found via a Shared item on Google Reader.]

[This is a comment on Simplifying Innovation with TOC from Jack Vinson.]

Update: Another interview with Mike Dalton at IdeaConnection, Part I and Part II.

I am on a serious roll with business novels.  This time it is the newly-published Simplifying Innovation by Michael A. Dalton.  The basic idea behind this book is to apply Theory of Constraints ideas to the process of innovation.  Overall, I thought the book did a good job of putting it all together, though it may feel a bit rushed.

The interesting take in this book is that Theory of Constraints is already familiar to the main character - as applied in manufacturing.  She doesn't know where to begin in new product development and gets the assistance of an old friend from the local college, who knows TOC.  And Dalton uses this connection to present the basics of Theory of Constraints in one or two pages, rather than re-deriving TOC from scratch.  For newcomers to TOC, this could be an overly-quick introduction with the characters seeming to "get" TOC very quickly - although some of the characters are certainly hold-outs.

And the book goes through the TOC ideas in a step-by-step fashion, just as a good TOC analysis would do.  One of the first things is to identify the goal of the business.  For profit-seeking enterprises it is some version of "make money now and in the future."  Innovation is all about the "in the future" part of this equation.  And from there, one applies the Five Focusing Steps to the organization.  1. What limits your ability to get more of the goal (the constraint)?  I like how the book acknowledges that each organization is going to have a different constraint, so the prescriptions have to be taken at this high level.  In the book, one company has a constraint at the design engineering step, and a second company has a constraint in coming up with enough good ideas.  Obviously, the answers to the subsequent questions are very different, depending on the location of the constraint. 

Once you know where the constraint is, the focusing steps take you through more questions.  2. How can you get more from the constraint?  3. How should the rest of the organization align to that constraint?  4. Then consider elevating the constraint, if you still need more.  5. And don't rest on your laurels, check if the constraint has moved, and consider whether you want it to move from a strategic perspective.

A couple interesting things came out of the book, based on my own experience and knowledge.  I was somewhat expecting the book to talk about applying Critical Chain Project Management to new product development, but it didn't do that directly.  Instead, applying the five focusing steps, CCPM comes up as a technique to help with exploiting the constraint.  And the book suggests that several actions taken as part of a CCPM implementation should be considered as the higher-level application of TOC to the entire innovation process.  For example, you only need to cut out excess work-in-process if that is actually a problem in your particular environment.  And aligning the rest of the business to the constraint?  It does not mean simply "leave the constraint alone."  The rest of the business should be looking for ways to help the constraint - and the book provides a couple examples where that can be very effective. 

For people already in the TOC community some of this material may be familiar - Dalton even acknowledges as much in the introduction.  That said, it is a nice description of how the pieces can work together.  And, if you don't get it from the story, Dalton provides a decent set of end notes and a website with extra resources, including the entire end notes.  Clarke Ching published an interview with Mike Dalton a few weeks ago that provides some more context to Dalton's take on innovation and TOC.  If you don't like the business novel format, Dalton said that he's hoping to come out with a "Simplifying Innovation Guidebook" in the near future.  And Dalton has joined the Critical Chain / cmsig mailing list and has participated in a few conversations.

One last thought.  With so many of these TOC-applied-to-X-business books available, the old argument of TOC being a manufacturing-only discipline doesn't hold much water.  Certainly, Goldratt and others have known this for a long time. 

[Photo: "Innovation Depot" by Photo Denbow]

There has been a lot of discussion of the massive data set that Pete Warden has been collecting from Facebook and the initial visualization of American groupings of people, based on their friends and other profile information.  He's going to be releasing this data for researchers tomorrow - all geared around finding interesting patterns in a massive data set of hundreds of millions of users.

Of course, one of the first things that people outside the research community will want to know is what this data says about them - can it confirm what I already know or tell me something new?  We'll have to wait and see what kinds of results and fun applications come out of the work. 

But in the meantime, you can play with your Twitter relationships.  In the ReadWriteWeb article about Pete Warden, The Man Who Looked Into Facebook's Soul, Marshall Kirkpatrick writes about some of his other side projects, including Mailana and the ability to draw maps of Twitter users - one of many applications that do variations on this - by frequency of @replies.  And the first place I looked was my own network.  I like that it shows connections between people I follow - using line thickness to provide indication of communication frequency.  And then you can expand a view by double-clicking on a contact.

I poking around a bit, I can see cluster of my contact networks who represent Boston, Chicago, Knowledge Management.  It becomes even more evident when I add known connectors from any of those networks.  And there are other ways to analyze the data provided by Twitter, such as by location or words used in those conversations.

[This is a comment on Email triage - offer from GTriage from Johannes.]

So how does this seemingly nice piece of online web app mastery work behind the scenes?
I like the concept but I don't like the idea that every single one of my mails is going to be fed to some unkown parsing engine.
Since the site offers no forum or direct feedback other than a mail-adress I thought asking you might be easier!

Of the many discussions about "information overload" as it relates to email, on of the biggest frustrations that people deal with is the shear volume of stuff coming at them.  It's an easy topic for newspapers and magazines that want to talk about personal productivity. 

I hold that the best way to deal with this is to encourage people to send you email less often: walk down to their office or call them!  Of course, before these efforts are successful you still need some solutions for triaging when there is just too much.  Triage options include dealing with email at select times (instead of "always"); coming to agreement on useful subject and action-oriented writing; filtering as much of that mail into appropriate contextual folders (or GMail-style tags); and more.  I wrote about this a bit last year in Is email really so evil?

In this light, Eli Holder of Unblab contacted me with an offer to check out their new GTriage (in Beta).  It's a triage tool for GMail that watches how you read and respond to mail and adds "important" tags to email that it believes will be more important to you.  Eli has also offered to let my readers in on the beta-test, if you are interested.  There are about 25 free trials available.  Use the invite code, "jackvinson" to activate.  (No disclaimer.  Eli hasn't given me anything other than a reason to blog.  I don't even use GMail as my primary email processing, so I can't comment on how this fits into the flow.)

In triage of incoming work (email or otherwise), one of the first things you want to know is the context for that stuff.  Is it really important to deal with?  Does it need to be dealt with NOW or in the next time where you are in the appropriate context?  Does it need to be dealt with in the next 24 hours, or can it wait?  Will it require deep investigation or a quick response?  While many of these questions require that you actually read the messages, there are some likely rules to at least make the messages stand out in importance: it comes from a client or colleague with whom you have a key relationship; it comes from your boss (whether that is your life partner or the president of the company); the subject is particularly relevant; etc.

To be honest, while I use these rules as I review my inbox, my personal process is such that I get this stuff out of my inbox as quickly as I can on a regular basis.  If I cannot respond right away or it requires a more in-depth response, I set up an appointment or task to give the item the time it deserves.  This way, nothing is sitting there staring at me that still needs action from the last sweep of the inbox. 

According to Xobni statistics, I receive 40-80 messages a day, many of which are filtered away for easy skimming (and deleting).  But even so, that pales in comparison to the deluge that some people claim.  It also pales in comparison to Luis Suarez' < 20 (work-related) messages per week. 

[Photo: "An offering to the Ganges" by judepics]