Knowledge Jolt

I received a review copy of Leandro Herrero's Homo Imitans: The Art of Social Infection: Viral Change in Action.  This is another installment in his series on the Viral Change concept. At heart, it is a unabashed call to people responsible for creating change to stop the stand-and-deliver mode of operation and look to creating the key underlying behaviors that are the desired result.

To create change we have to move people to a new way of acting with each other (behaviors).  The concept behind Viral Change is to make those behaviors infection: spread, copy, reinforce, and spread more.

The title comes from the wide body of research that shows how people learn by imitating one another.  In particular, it is behaviors that are imitated through an organization or community.  There have been a variety of studies that show people with good and bad health behaviors tend to mimic each other.  And the same can be found in organization.  When people model desired behaviors, these get reinforced by the people around - especially when that reinforcement is in the form of explicit thanks and organizational story telling.  Those same good behaviors vanish when they are ignored or opposing behaviors are rewarded.  Classic example: asking people to be collaborative (whatever that means) but rewarding people for individual / heroic efforts.

The book and writing are in Herrero's usual casual and comfortable style.  I thought it was more discursive than previous books - more information to set the stage and describe why he suggests that Viral Change should be done in this way.  That is neither bad nor good, just different and noticeable to me, having read the previous installments and expecting faster-to-consume segments.

As is typical in my reading, I draw connections to many other things.  There were elements of the idea of tribes in that people use behaviors and other norms to reinforce tribes.  This can be both good and bad.  Viral Change is looking for those behaviors that create the desired outcome.

I could see thinking about child-rearing: one of the refrains is that children need consistent direction from their parents.  Having direction that is unclear is very confusing to children.  It's confusing to adults as well.  Create clear behavioral direction and link that to your reinforcement mechanisms.

Herrero brings in the ideas of push and pull, which naturally makes me think of the Theory of Constraints work I have been doing.  I also think of the recent books by Hagel, Pull, and Denning, Radical Management, which both look at creating pull within organizations to move the organization in new directions.  Connected to this thought of pull, I latched onto Herrero's discussion of "what gets attention, get multiplied" when thinking about creating visual status boards for project teams.  When they can't see what is going on, it is difficult for them to know where to focus.  But when things are visual, the teams can have a different conversation about the status of their work.  Herrero mostly focuses on using stories to help spread the word and reinforce, but I think visuals can be quite powerful as well.

An important element of the methodology behind Viral Change is exploiting the network of people in the organization (or society).  And that then reminds me of many of the social network analysis thinkers, Anklam's Net Work in particular, as Herrero makes many references to the simple fact that work gets done through the network, rather than via the hierarchy.  (Yes, I know a hierarchy is a form of network.)

Having just finished the book, it was top of mind in the SIKM Boston meeting this morning.  The topics in the book seemed particularly relevant to our conversation.  The idea of you-will-do-this dictates came up over and over again. (They don't work, except in extreme cases.) I also liked hearing about "centers of excellence" that seem to get ignored or left behind.  This relates to some of the topics Herrero discussed in relation to moving the change from something simple and small to something that becomes viral.  It has to grow from a small cluster to more and more of those clusters.  Not one-to-one-to-one (Chinese whispers), but one to many to many to many.

There are many little tidbit winners throughout the book.  Too many to catalog.  I suggest you pick up a copy, if the above has been intriguing.

The local weekly in our area has a piece on multitasking by a local psychiatrist and author, Dr. Blaise Aguirre, The myth of multitasking. The article centers around helping kids do better in school, but he also summarizes a lot of the recent research on the topic in less than a thousand words.  I particularly like this quote:

Worse, we waste time when we multitask as it takes four times longer to do two tasks effectively than it takes to do each one individually.

While there is no additional attribution (it's a newspaper after all), this is in line with my observations.  And how often are people doing only two things at a time?  Note that this is talking about tasks that require attention and focus, not the more automatic tasks that can operate in the background.  People often use the term "task switching" to be clearer about which variety of multitasking is being discussed.

Look at organizations where people are dependent upon one another to get things done - just about every organization.  Working in a multitasking (or task-switching) mode makes it look like everyone is busy, but that isn't what people need.  People need to FINISH things.  Multitasking in this way ensures lots of stuff is happening, but it doesn't get things DONE.

The take away?  Please learn how to say, "No" to attention-sinks from yourself and to your colleagues.  Finish what you've started, and then move to the next thing.  You will be surprised.

Just don't ask me how long it took for me to get everything in place to write this simple blog entry.

[Photo: "Myth" by liquidnight]

No, I am not suggesting measuring knowledge work from the perspective of "productivity."  This link suggests a way of monitoring the health of a knowledge work organization.

James Slavet has an interesting set of Five New Management Metrics You Need To Know on the Forbes technology blog.  Rather than look specifically at throughput, he suggests some internal metrics that might be leading indicators.  These kinds of ideas are geared towards organizations that have more knowledge workers - people doing work that you can't SEE.

1. Flow State Percentage.  What percentage of the day are people able to FOCUS and get stuff done?  Slavet suggests it is going to be incredibly low, and I can't help but agree.  If your business relies on people doing design, or coding or intense documentation, it won't be very successful if they keep getting pulled away from that work.
2. The Anxiety-Boredom Continuum.  People like some anxiety to keep them on their toes, but not too much.  I'm not quite sure how you would measure this, other than getting a sense of people.
3. Meeting Promoter Score.  Just like the net promoter, how do people perceive meetings in your company?  While killing meetings altogether is attractive, maybe making the ones that are necessary more interesting and useful could be just as valuable.
4. Compound Weekly Learning Rate.  How much are your people learning?  Do they keep learning, or are they getting stuck?
5. Positive Feedback Ratio.  How much are people providing each other with positive feedback vs negative?  I would ask if they are taking the opportunity to provide ANY feedback.  Slavet suggests that the ratio of positive to negative interaction needs to be close to 5:1 - a number from John Gottman's analysis of interactions amongst married couples.  Clearly "feedback" is different from "interactions," but the concept still fits.  Negative feedback and interaction can create a death spiral.

What do you think of these?  How might you use them?  Comment here or on the original article.

Dilbert is often entertaining, though sometimes frustrating in his response to the world.  Sunday's comic had me laughing from the first panel, and I think Asok's response is right on.  What is your response when you see this opener?

Go ahead, have a look at the response.

I read this to my kids and asked them if they understood the problem.  After a little prompting they could see how it might just be a problem to focus on 25 things.  But how many times have phrases like this come up in your organization?  "I have to focus on everything!"  Really?

The whole point of "focus" is that you look at one thing.  Ideally, you keep looking at it until it reaches a sufficient resolution.

This is one of the reasons I like systems thinking and Theory of Constraints.  The idea is to take a look at the system and look for the one place where a change will have the biggest impact.  Sure, you can try to fix everything, but most organizations don't have the time and money to do that.  So, given that limitation, maybe it would be a good idea to find the area where a change will make the biggest difference.  Make a change, step back to see if it is working, and decide what to do next.

Teleos and the KNOW Network have announced the Latest MAKE Summaries (Most Admired Knowledge Enterprises) with the awards for North America, Europe, Asia and Global.  The summaries are PDF's available through their website.

The global winners this year are

• Accenture (Ireland)
• Apple (USA)
• APQC (USA)
• ConocoPhillips (USA)
• Fluor (USA)
• Google (USA)
• Hewlett-Packard (USA)
• IBM (USA)
• Infosys Limited (India)
• McKinsey & Company (Global)
• Microsoft (USA)
• POSCO (S. Korea)
• PwC (Global)
• Royal Dutch Shell (the Netherlands)
• Samsung (S. Korea)
• Schlumberger (France/the Netherlands/USA)
• Siemens (Germany)
• Tata (India)
• Toyota (Japan)
• Unilever (the Netherlands/United Kingdom)
• Wikipedia (Global)

Interesting to see the range of companies.  Several have been in the awards lists previously.  The summary reports give some hint as to the categories in which the companies took the honors.

Here is a new way to reach Inbox Zero.

LinkedIn had a top article with the story of Tech Firm Implements 'Zero Email' Policy for internal emails.  The claim in the story is that Atos, a French company, is going to phase out email for internal communication and shift to instant messaging and other more appropriate tools.  The CEO is quoted in the article as saying he hasn't sent email in three years.

I guess this means we are starting to see whether we can live a life without email, as Luis Suarez has envisioned.  And there is this discussion from Adam Britten about a conference topic along the same lines: Can a Workplace Survive without Email?

Michael Krigsman has a nice summary of an academic article he found about project management, Six lessons for intelligent project management:

Traditional approaches can isolate project goals from business outcomes. The solution is bringing project managers closer to those working in lines of business.

Be sure to jump ahead to page 2 for details around the six lessons.  Here they are in brief:

1. Having staff wait for work is better than having work wait for staff.
2. Multitasking is more prevalent and more harmful than anyone thinks.
3. Eliminate “apple polishing.”
4. Don’t overdefine the tasks.
5. Be aggressive about business improvement.
6. Provide a holistic view for all team members.

I love these.  I've touched upon all of these over the years in this blog, and these are certainly elements of discussion with clients in project organizations.

I particularly like the wording of #1.  The belief that "idle" people is an evil to be eliminated means that organizations jam more and more work into the system - generating item number 2: multitasking.  And with so much work in the system, people have no idea what is important or what should be worked on next: they just have a long list of things to be done and work on the things that they enjoy (or that are associated with the current yelling project manager).  This means that all those other tasks associated with all the projects that have been jammed into the system just sit there, waiting for someone to pay attention.  Project-based organizations don't succeed by having lots of projects running.  They succeed by finishing projects that their customers want.

Idleness is not always a waste in project environments (or manufacturing environments).  The waste happens when valuable work sits idle, waiting for people.  Be careful how you define these things.  Be careful what you look for.

[Photo: "No Idling" by Rob Friesel]

I picked up Christopher M Avery and co-authors' Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility based on a recommendation that I, sadly, did not record.  For anyone interested in collaboration and communication and intentional living and relationships this is an excellent resource - I recall that the person who recommended it had a similar feeling about the book. The book is ten years old, but it doesn't feel dated. These topics are perennially important.

The short summary: I am responsible for the success of any venture in which I choose to participate.

I love the paradoxical title - there are a lot of these paradoxical elements throughout the book.  Or maybe these are more examples of uncommon common sense.  To succeed in teams, I must bring the desire and motivation for the team to succeed.  It is not the team's responsibility to create that success, it is mine.* This has a number of implications, such as looking for a shared vision with the people on the team.  One of those paradoxes again: acknowledge my own self-interest in the success of this project, and then seek to understand how your self-interest will be satisfied too.  Ask "what's in this for you?"  - not just looking out for myself, but also looking out for how we can all achieve our personal goals while achieving the goal of the team. A lot of the discussion throughout the book was around how the individual skill of teamwork can be parlayed into success for the team: building upon integrity, trust, collaboration.  All these ideas revolve around intentionally acting and living in my world.

Avery has a chapter on Trust that resonated with me.  Trust is built by my extending myself first.  If I wait for you to take the first step, then it may never come.  Avery also acknowledges that if that first step doesn't produce the hoped-for result, that it is my responsibility to re-evaluate what I want from that situation.  I also liked the discussion of how to repair the situation after the inevitable broken trust - what do I need to do when I break an agreement I have made?  This was a great example of how to make amends with clear instruction on how to go about clarifying with myself first and then repairing the relationship.

There was also a lot of discussion of collaboration throughout the book. Of course there was - that's how teams succeed right?  Again, though, Avery emphasized my responsibility to make collaborations work.  Whether it is the trust element above or a discussion about how I approach relationships.  Am I seeking to "win at all costs," or am I looking out for you too?  I particularly liked his framing of the familiar competition vs. collaboration thinking.  To his mind, these things aren't opposites - in fact, he sees them in a reinforcing loop: competition creates the need for collaboration, which creates more competition.  The opposite of collaboration (win-win) is mutual harm (lose-lose).  Competition is win-lose and the opposite of that is lose-win: martyrdom. Avery discusses that what many people think of as competition is merely aggression: make the other guy lose, but I don't necessarily win.  The key to successful collaboration from the individual skill perspective is the idea of a shared goal, a shared way of getting there, and a shared understanding of how that goal meets everyone's interests/needs.

So, if teamwork is an individual skill, what does that say about teams themselves? Teams are there to Get Something Done.  And it is that Something around which the team should gather - not around friendships.  That said, the team cannot succeed without a shared sense of the collective task and what that collective task means for the team members.  How will their skills and interests be employed and grow as a result?

What about "bad teams?" Ah, but since teamwork is an individual skill, this means that when I say the team is "bad," I am saying that I am not exercising this skill very well.  "Bad" is a perception in this case - and I have the power to change that perception both through changing my mind and through changing my behaviors.

As always with my reading habits, I see how the book ties together other threads I have in mind.  One is that there seems to be an obvious connection to Stephen Covey and his Seven Habits thinking.  That book is clearly about the personal, but it also talks about leading the intentional life.  And Stephen Covey is deeply linked to the ideas of Dale Carnegie in my mind - and those ideas are buried throughout the discussion in this book.  I also saw a lot of connections to the ideas of Networlding - networking around a shared interest and bond, rather than around people.  And more recently, my friend, Ben Wechsler, has launched his You, The Inspired Thought Leader series of videos that feel spiritually connected to the thinking in this book.

The book is very easy to read - and I'd imagine it's easy to reference back to specific pages as well. The chapters are broken into 1-3 page sections where Avery discusses a topic and then closes with a personal and team challenge, and nearly all of the sections close with an example or story related to the topic of the section.  Avery has an active business promoting the concepts in this book, http://www.ChristopherAvery.com/.

Personally, I felt a bit of friction reading this book. I was in a little conflict in a personal relationship, and I could see how the individual behaviors discussed in the book were missing in my response to that conflict. As I stewed in my conflict, I had to laugh at myself and my reactions. It isn't about the other person at all. I have to remember that whenever I am upset or troubled, there is something inside me that is creating that reaction.

* Yes, team success is your responsbility too, but if I don't contribute, why would you?

As most people know, today is Thanksgiving in the USA. It's a day for gathering with family and friends and food. It's also a day to reflect on what we have in our lives and be grateful. Here is an abbreviated list for me.

• Family: I sit here on the train with my family as we go to visit more family. Joy.
• Friends: People in my close circles and those I only "see" virtually all add to my life.
• Work: Yes, work. I really enjoy helping people get things done, and the people I work with make that all the better.
• Health: Sure this varies, but it great to have what I have and get to share with the people around me.
• Hikes with the kids.
• Bike rides alone or with friends / family.
• Books. Letters on the page (or screen) always entertain and educate.
• Music. Our home is often engulfed in music, whether playing over ear buds, or our Sonos, or piano practice. Recent purchase: Miles Davis' A Kind of Blue because my son is learning the piano part to "So What."
• Food: Whether simple or fancy, it's always fun to prepare and eat with friends ands family.
• Life.
• Love.

What are you grateful for? Today or any day.

Pick your methodology. Are you aiming for a massive change to a new state RIGHT NOW? Or do you want the new state to appear over time? Is your first step that of a child or a giant?

I've come across this idea in a couple places. Essentially, it's a way of thinking about a management methodologies: what is the underlying philosophy of the methodology? Do you have to create a Big Change to get started with the concept? Or does the concept start where you are with a goal of getting better? I suppose this is some version of a conflict between Start Big or Start Small. How about some examples to clarify?

There is a kerfuffle brewing online between the Scrum and Kanban communities, arguing which approach is "right." Beyond the specifics of the discussion, I saw a comment that was to the effect of "Scrum starts with the ideal scenario" and "Kanban starts where you are." The differences in the philosophies were boiled down to the thinking about how to get started - how much enforced change will there be? The terms "evolutionary" (Kanban) and "revolutionary" (Scrum) are used to discuss their approach to change. (I don't know enough about Scrum to say whether this comment is an accurate reflection.)

Another thread of discussions has to do with Lean and Theory of Constraints. I know enough about Lean and plenty about TOC to see where they have a lot of strong similarities and overlaps. Being underdogs, the TOC community has written a number of intelligent articles that compare the two, mostly favorably. Of course, TOC usually smells better when written by the TOC aficionados. But the connection to my observations here is that I have seen people argue that TOC is "easier" because it doesn't require the kind of transformation required by Lean. That TOC can start small and build to ever-greater success, while Lean has to start with the end-state and effect changes that take you there.

And to add some humor, I have seen people argue almost the reverse about TOC and Lean: That TOC requires a mental shift - such a radical way of thinking about the business - that it is often easier to get people started with the Lean way of thinking, as it is more familiar to how people have been trained. This was most definitely the case with the Viable Vision projects that Goldratt Consulting were selling: implement such radical approaches to operations and sales that the competition couldn't possibly get you. In either view, TOC talks about the Process of Ongoing Improvement, so it is definitely not a once-and-done mindset.

I would guess there are similar arguments in many other methodology communities. I appreciate that people are at least thinking and talking about the philosophy behind these approaches. Having just written about Cynefin, I have the thought that the slow-but-steady approaches might be working in an emergent domain, while the Change Now approaches might be working in a best practice or good practice domain. The trouble with saying this is that I am fairly sure no approach is all of one mindset vs. another.

All this is to say, think about how you are approaching your problems. Check your assumptions about the situation. Check your assumptions about your proposed fixes. Are they compatible? Is there another approach that is better in this circumstance? Warning: don't get stuck in analysis and thought experiments. I prefer to lean towards action, particularly once I have some agreement to move. Observe - Act - Check: repeat (pick your favorite improvement loop).

[Photo: "#ds307 big red and small red" by rosipaw]

Bill Dettmer, author of a number of great TOC books, including The Logical Thinking Processes (my review), has brought together his long view on systems thinking in general with Dave Snowden's Cynefin Framework in a new article, Systems Thinking and the Cynefin Framework: A Strategic Approach to Managing Complex Systems (pdf, local copy - it will be posted to Dettmer's website in a few weeks). From the abstract:

Systems and their external environments can be classified as simple, complicated, complex, and chaotic. This taxonomy is known as the Cynefin Framework. It provides an orderly way to evaluate the interaction of organizational systems, their external environments, and the myriad of management methods and tools available to decision makers. A significant number of organizations today qualify as complex. Their environment may change in short but irregular, unpredictable cycles, requiring the organization to adapt internally accordingly to avoid degradation. But the majority of available management methods and tools have been designed to succeed in simple and complicated domains, not complex. The failure to identify and understand the underlying assumptions about these methods made this limitation inevitable. That is about to change.

And the reason this "is about to change" is that the Cynefin Framework provids a better way of thinking about our situations and the assumptions behind various management methodologies.

The first half of the paper provides a lot of background, both for management thinking & tools in general and then on the Cynefin Framework specifically. Dettmer talks about management tools in their evolution and some of the assumptions that underlie them: like the assumption of analytical thinkers that the whole can be understood by understanding all the parts. This overview and that of the Cynefin Framework were very familiar to me. I've been listening and reading Snowden for many years, but it was good to read Cynefin from a slightly different perspective that Dettmer brings to it.

The interesting-to-me material resides in the second half of the article: thinking about the implications of Cynefin for management thinkers and people who deploy management tools. The short version is something Dettmer highlights as he summarizes Cynefin:

Consequently, the tools and methods that work well in the simple and complicated domains tend to be less effective (or completely ineffective) in the complex and chaotic domains.

Cynefin gives us a way to look at the world and ask questions. Where does my current situation fall in the framework? Be careful not to categorize here, as the lines between the various elements of the framework are blurry, and it is easy to shift from one region to another - sometimes without noticing. What would it take to shift the current situation into another region? What would make it become more chaotic? What might push the situation to something in the complicated or simple regime? Would that be a good thing?

And not only can you look at the current situation with these questions, but the common responses can be considered in this light too. Does approach XYZ work best in a simple domain? Then don't try to use it when your situation is complex or chaotic. For example, process mapping with the intention of taking action against that process (for improvement) only make sense when the process is relatively stable and understandable.

Dettmer picks up a number of management tools and looks at them in a Cynefin light. He takes up the Logical Thinking Processes from TOC, Boyd's OODA (observe, orient, decide, act) Loop, Brainstorming, and then some of the tactical approaches as a group. He also tries to show how each of these approaches covers slightly different ground from the Cynefin perspective. Of course the do. It's important to remember this - and to see this as it applies to your own situation.

People have been thinking along these lines - using Cynefin to help think about their interventions - for some time. It came up in the Kanban training I attended last month, where we were encouraged to think about how the Kanban methodology fits into environments where it is being deployed. Kanban is a simple-seeming idea, but the concept helps organizations sense and respond in a way that fits more into complex environments. And I have seen people taking up the Cynefin call in a variety of perspectives. I even see on the main Cognitive Edge website that guest blogger Bob Williams has been thinking in a similar direction, such as in Sensemaker, Evaluation and the Logic of Interventions. Dave Snowden has been saying some of these things too, but it is always good to have other people interpret and re-interpret the ideas into slightly different contexts. It helps to strike more nerves - hopefully the right way.

Following up on my Not interested in yesterday post from a few weeks ago, I have another reference to Manager Tools. This time is is their Project Management Drumbeat Meeting (Part 1 and Part 2). And this time, I am not totally in sync with their recommendations - though I suspect there is something underneath that I appreciate.

The basic guidance they provide in Part 2 is "hold your team to their deadlines." If they don't hit a milestone, don't let them slide. Get a new commitment and hold them to that - and that new commitment gives them much less time, since they should have been working on the first one already. The common assumption here is that as long as every task is on track, the project will surely come in on time.

Arghhh!

The problem is that it just takes one task to go off the rails - maybe. And any kind of human-centric activity is sure to have variability, which means that some work is going to take longer / shorter than expected. That's the nature of variability. Projects are linked networks of tasks, so a delay on one task will ripple through the network. Of course, people know this, so they plan for it. They add padding between the individual tasks ("slack," anyone?); they pad their task estimates (and then waste the padding by starting late or not reporting early finishes); they multitask across many activities and projects; etc. Even when management try to trim the estimates, there is plenty of wait time embedded in those task estimates.

That "maybe" up there? Along with the built-in knowledge that "everyone pads," there is also the fact that projects are networks of tasks, not just a simple chain of events. There are multiple paths that weave through projects. And it is only the longest path (or the longest resource-dependent path for CCPM fans) that you really need to worry about. When there are delays on that road, it affects the whole project. When there are delays on the other roads? It depends on how tightly they blend with the main road. Is there slack at the integration point? How much has been consumed?

Here is my problem with management-by-milestones: it treats all tasks with the same level of importance, when we know that isn't true. There needs to be a way to ask people to move as quickly as possible without berating them for missed internal milestones. It is the overall project that project teams should be worried about. The individual tasks are one way to get there. How can we help each other get there as quickly as possible while still meeting scope and budget requirements of the customers?

Another example of the ill effects of holding people to milestones is the negative reinforcing loop of "schedule chicken." (I am sure The Manager Tools guys would go ballistic at the thought of this.) Schedule chicken is where no one admits their part of the project is slipping until it becomes inevitable that one person has to admit problems. And then everyone breaths a sigh of relief that they weren't the person to admit it. And by that point, it is often too late to do anything about it. Have a look at the 2:00 mark in this set of clips from HBO's miniseries From Here to the Moon.

I've been reading and thinking about innovation for quite a while, so when someone mentioned Eric Von Hippel's Democratizing Innovation (published 2005), I had to take a look. The book is a combination of academic writing (reporting Von Hippel's and other's research with plenty of references to studies and research and correlation factors) with connections to the wider thinking about innovation and communities. Personally, I could have done with a little less of the academic style.

The basic concept of the book is that innovation cannot be considered the domain of research institutions or companies - if it ever really was. Innovations (significant product improvements and entirely new products) come about through many, many sources. Rather than focusing on the innovation processes, Von Hippel focused on how innovations arise from people (or businesses) that actually use the products. One of the big elements behind Democratizing Innovation is that these things aren't happening in isolation (and if they do they get repeated by many individuals separately), but that the ability to share and communicate within specific communities has gotten so easy that it only naturally pushes innovation out to the edges: where people who actually care can do the innovations.

The book's examples range across a number of disciplines. This kind of innovation might be seen in sporting enthusiasts who modify their equipment, come up with new ways to use the equipment (new techniques), and then modify again to support those uses. Or surgeons who need new tools to conduct new operations. Or entire communities of software user-developers who contribute to the development of their tools. Or the steampunk movement who create groovy equipment, evocative of the Victorian area and share the ideas and designs with one another. Sometimes these innovations become commercial products, and sometimes they stay within the community as post-commercial modifications. There were some interesting comments about companies that believe they were the source of the innovations that were provably developed by users first and several years later became commercial products.

Since I tend to see a lot of connections between innovation and knowledge management, I was pleased to see a number of things in this book that highlighted those connections. One was that a lot of information / knowledge about how things are used are embedded in the environment in which it is used. It's tacit. Acknowledging this is a key to seeing the importance of taking advantage of innovations that occur at the "bleeding edge" of user innovation examples. It is these examples that may become more common over time - and therefore likely candidates for commercialization. Von Hippel highlighted the difference here between customer-requested improvements and innovations by what he calls "lead users" who are doing new and unexpected things with the products and services. There were also connections to the importance of networks and connections amongst people. There was an example where the research into innovation looked for experts through what I would call a network analysis technique: who is more expert than you on this topic. Another obvious connection into KM and networks is the draw of communities of practice in enabling and spreading innovative practices and designs. And this of course leads back to the tacit knowledge embedded in context and use and community of users.

With all the discussion of user-inspired innovation and my reading this book electronically, I had to wonder about user participation in things like ebooks. I wonder what the errata process would look like for books if the collection of readers were allowed to participate in the process more explicitly. This isn't quite the same as innovation, but the idea is related.

Note: This was my first "serious" read in ebook format (Kindle app on iPad). I'm not yet sure if I like reading nonfiction in the electronic mode. I tend to take lots of notes and like to mark pages that have said something interesting to me. The Kindle application lets me highlight and take notes, but in this first attempt the novelty of the technology has somewhat gotten in the way of spontaneous note-taking and writing down of ideas. We'll see how it goes for the future.

I was listening to the Stanford DFJ Entrepreneurial Thought Leadership seminar with Mårten Mickos and I heard him say something interesting. And he heard it from someone else.

The 70-20-10 rule (paraphrasing): Of your customers or your constituency, 70% of them are fairly ambivalent about anything you do. 20% will love what you do. And 10% will hate it. And while the 70% don't have strong feelings about what you do with your product, they pay attention to how you treat that minority of detractors.

The implication is that if you treat your detractors with respect, the 70% will be more likely to stay with you. This sounds like a very short version of what John Kotter and Lorne Whitehead wrote about in Buy-In (my review). Rather than shooting down your detractors, be respectful and find ways to direct their criticism in the right direction. But also be careful not to let them take you down the trail into the complaint either.

Here is the podcast with Mårten Mickos: Believe in Something Bigger Than Yourself

In this lecture, Mårten Mickos shares the benefits and challenges involved in building businesses in the open source and cloud computing spaces. As the CEO of Eucalyptus Systems, Mickos identifies a vision for the future of his industry and shares entrepreneurial lessons gained from leading MySQL AB from its startup origins to becoming one of the largest open source companies in the world.

This is a fun podcast to listen to. Mickos clearly loves what he does.

I have come across several items on collaboration that have continued to rattle around in my brain, so I thought I would pass them along.

The first is an entertaining info graphic from the folks at Central Desktop on the 9 Types of Collaborators, looking at various collaboration personae: The Stealth Ninja, The Executive, The Socialite, The Skeptic, The Tastemaker, The Dinosaur, The Siloist, The Expert, and The Ringleader. (Strangely, when I first looked at this graphic, I read "soloist" instead of "siloist" for the seventh entry.)

In conjunction with the collaboration info graphic, Charles H Green (The Trusted Advisor) sent me a link to another info graphic on How Trustworthy Are You that describes a number of elements of trust, including the Six Trust Types of people: The Expert, The Steward, The Doer, The Connector, The Catalyst, and The Professor. I particularly liked the additional analysis around which of these types are most common (The Expert) and the ranking of trustworthiness of each type (The Expert is 5th, The Doer is 1st).

And finally, there was an article in the Nov/Dec 2011 issue of KMWorld, Rich options expand the collaborative horizon, by Judith Lamont. She describes several examples where organizations took advantage of their collaboration software to solve real problems. It's always a challenge in this kind of writing to capture both the interesting results AND the technology. It's often far too easy to only talk about the technology.

Minor update: Added local links to the graphics and a category.

I am deeply interested in the Theory of Constraints' tools and techniques, so it's a pretty sure thing I will pick up any book that comes out of that community. This time it is Behind the Cloud, by Jelena Fedurko, an excellent guide to building and critiquing the Evaporating Cloud, a classic element of the TOC Thinking Tools. If you are curious and want step-by-step instructions with examples, this is the place to go.

What is an Evaporating Cloud? Trying to make a decision and feel stuck between two options? Or is your organization struggling with the classic don't spend money but then overspend to "hit the numbers." Or any number of personal Do X or Do Y decisions. Evaporating clouds are a way to think about the problem and uncover more information about the situation to assist in resolving - evaporating - the problem.

The goal of creating a cloud is to come to some kind of resolution. If you aren't interested in resolving the conflict, there is no point in drawing the cloud.

In the context of most of the traditional TOC training for manufacturing or project management, the cloud is used to help describe classic conflicts that managers find themselves working within: Do X or Do Y - and they usually find themselves swinging between extremes or devising a compromise that doesn't quite satisfy anyone. These are problem-solving clouds, usually associated with deeper struggles faced by an organization (company, family, society). Daily conflicts can also be cast in the Evaporating Cloud model - conflicts certainly come up in the daily life of people: deciding among a pair of actions, or conflicting actions being driven by different people.

The conflict cloud has a very specific form, and all the elements have a meaning. The boxes and arrows have a use, and there is a hidden aspect that I had forgotten. I'm not an expert, but this book has certainly helped shore up my understanding. The basic reading of the cloud is usually left to right, though you can reverse it to make sure it is clear. In order to satisfy the goal (A), I need both B and C. In order to satisfy need B, I must do D. In order to satisfy need C, I must do D'. However, D and D' conflict (I can't do both of them at the same time). The piece of reading these clouds that I had forgotten is that not only do D and D' conflict, but they also jeopardize the opposite needs: If I do D, then C won't be met. If I do D', then B won't be met. Of note for clouds, the needs in B and C are not the only needs associated with the goal in A. They are the needs that are creating the conflicting actions D and D'. Finding these sometimes takes a bit of work and discussion to understand the full situation.

Here is a classic example from either project management or manufacturing: Get the project/product out on time by holding people on overtime or hiring subcontractors, vs. Keep costs under control by disallowing overtime and subcontracting. This usually shows up as "no overtime" until it gets too close to the deadline and then it is overtime like crazy to make it happen. Manufacturing organizations often see this as "end of the month syndrome" as they have end-of-month ship dates. I have seen many clouds with Do / Don't Do as the conflicting actions, but this is only a subset of possible conflicts. You might have Deliver on Time vs. Deliver Full Scope. Or Take the new job in a new town vs. Keep looking where you are. Or Add more detail to project networks vs. Make less detailed networks.

In addition to the basic reading of the cloud, under each of the connections are a set of assumptions. The why behind the statement. This is where the analysis happens: evaporate the cloud by invalidating the assumptions that hold it together. It's sometimes difficult to build the basic Cloud, but the underlying assumptions are where things really get interesting, and where a deeper conversation really pays off with the people involved. Developing the assumptions sometimes comes right out of the conversations - the story people tell about the situation. In other cases, it may take a lot of asking why to understand the situation better. Behind the Cloud provides four basic checks to validate assumptions, plus two others to validate the D-D' conflict assumptions. This element seemed to take up a large part of the book, possibly because it isn't as heavily emphasized elsewhere. In the case of the example cloud here, the assumptions to look for have to do with the way work is managed in the business: what is creating the situation that you end up in the conflict.

One thing I've always wanted - and this book doesn't provide it either - is a catalog of "classic" cloud formulations. The challenge is that even for standard conflicts, the specific situation is different for everyone. But the archetypal clouds apply in many, many situations. I'd love to see a cataloging of these and the common places where the clouds are evaporated.

I always enjoy listening to / reading David Allen's take on the personal world of getting things done. He has a knack for bringing new light to ideas I've heard before. In one of his recent Productive Living newsletters, he talks about the Gestalt idea that The way out is through and provides this simple reminder:

You can only do one thing at a time, so at any point in time there is going to be a huge backlog of "work." Much of what we must do, to gain comfort and control in our knowledge-worker worlds these days, is clarifying what all that work is, objectively, in a format that provides an easy overview.

There are always more things to do. Rather than continually bemoan the fact that the backlog exists, find some mechanism to "gain comfort and control" over what you are doing today and what you are NOT doing today.

If change is so constant, why do we take the tried-and-true techniques to change management?

Dave Gray takes this familiar sentiment - that change has become a constant - and takes it in a different direction. Change is changing

Change is accelerating, to the point where it will soon be nearly continuous. Periods of sustained competitive advantage are getting shorter, and there are a host of studies that confirm that this. It’s not just something that is happening in technology, either. It’s happening in every industry.

Rather than going down some old familiar paths in a discussion about change and change management, he suggests that the whole field needs to rethink what it does. Change management as a means to get you from State A to State B becomes much less important when you are already at State Y and seeing new States coming by every other week.

Dave suggests that rather than one "change" to manage it is an entire portfolio of moves that the organization is trying. And it is that portfolio that should be managed.

This puts me in mind of a couple ideas that are running around these days. One is Dave Snowden's sense-and-respond ideas built into the Cynefin framework. He is also a big proponent of safe-to-fail experiments: give something a try, make it quick and cheap, see where it goes, and redirect as you learn new things. This then brings to mind the ideas around John Hagel's The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion and Stephen Denning's The Leader's Guide to Radical Management which both advocate using ideas borrowed from Lean / Agile communities of fast iterations toward a goal that isn't completely obvious at the outset.

The discussion on Dave's post is extensive too. Not everyone agrees, which is just fine. There probably is still room for Big Change initiatives, but they need to be balanced with the small changes that are happening all over. A portfolio view of the whole picture could be the right way to go.

I often enjoy the Manager Tools podcasts for their sensible approach to the world of work. One of their recent entries has been on "Project Meeting Reporting" Part 1 and Part 2

Effective managers are really good at managing projects. Projects provide a focus, an attention, that often regular responsibilities don’t. ... So why aren’t we all a lot better at them? ... One thing we CAN do is be more effective at teaching and handling project reporting.

Their essential message is that the first thing managers should ask of their people is a report on status, not the effort. Is the work complete (or progressing) as expected? Then talk about the future prospects: are there any speed bumps or concerns? After that, then the stories about how hard people have worked (effort) are acceptable.

They make the point that project status reports are all about the future, not about what already happened. Yesterday is gone, and whether you did a great job or someone got in your way is mostly inconsequential to what needs to be done to make the project speed along its path from today onward.

Note to my knowledge management friends: Yes, I know that we need to pay attention to what we've done in the past so that we can learn from our mistakes and our successes. For the immediate needs of the project team, that doesn't help much.

Dan Pontefract has a great come-back to the idea of "digital natives" - particularly that the younger generations are somehow more attuned to being good at technology for collaboration. Introducing the Digital Learning Quadrants | trainingwreck

Let us agree, therefore, that regardless of age or situation, the learning process is one in which any learner can utilize formal, informal and social means to actually learn. It has nothing to do with generational divides.

This intro is fairly straightforward: he's calling hogwash. The thing I enjoyed about his article is that he provides a better framework for thinking about being online and collaboration. He pulls a 2x2 matrix (copied here) out pitting interest in participation with online access, providing a different way of thinking about the situation. I suspect it would be different again if you switch out access and went with technology-comfort. This might get you too close to the generational discussion though.

With Pontefract's main argument, there is a deeper sense that the types of situation coupled with their perspective is much more interesting than simply looking at generations. As we all know, there are plenty of "adults" who have been online and tech-savvy for years. (Ahem, my first web pages were in 1995. Hours on the modem in the early 1980's.) And there are plenty of "kids" who don't have access or interest (hard to believe). More importantly, though, to Pontefract's discussion is their interest in collaboration and participation in their environments. Are they people interesting in learning alone; learning with collaborators in the same room; or learning with collaborators strewn across the globe? How much more do I learn and grow by having the opportunity to interact with people everywhere - people who explicitly express interest together.