Shared understanding – two stories

Here are a couple of stories I’d like to share on the idea of shared understanding. The first, a conversation between me and my son, Zeke, highlights the importance of being aware of and understanding the context of a situation from different people’s perspective. The second, a story about a friend of mine, shows the importance of ensuring shared understanding in a shared context and how easy it can be to not have it.

You know the way home, right?

My son, Zeke, and I were in Milwaukee for the Midwest Gaming Classic. As we were walking from the hotel to the car getting ready to head home on Sunday morning, Zeke asked me, “You know the way home, right?” A reasonable question, and one that I could honestly answer with yes. Which was the right answer, though as it turns out that was not the question he was actually asking.  What Zeke was really asking was, “Can we listen to the radio on the way home?”  A little background may be in order.

map

On the drive up to Milwaukee I used Google maps on my phone, connected to the car audio system, as a navigator to get us from home to the hotel. Because I wanted the navigation to come through the audio system, we were limited to listening to music or podcasts (or other apps) from my phone and couldn’t listen to the radio. So when Zeke asked if I knew the way home, he was really wondering if I needed to use Google maps to get us home. If I had said, “No, I don’t know the way”, then he would have known that we wouldn’t be able to listen to the radio, and if I said “Yes” then we could listen to the radio. (If you’re wondering, we listened to a couple Premier League soccer matches and the first half of the Cardinals / Braves game.)

Because of our long history (nearly 25 years) together, I knew that he didn’t care whether or not I knew the way home. He knew that if I didn’t, I would simply use Google maps as my navigator. I did know that he cares about what we listen to in the car, that he prefers to listen to talk (usually NPR) or sports over music, and that he usually watches Premier League soccer on TV on Sunday mornings. So understanding where he was coming from allowed me to answer the question he was actually wanting an answer for. It’s probably worth noting at this point that Zeke is autistic and, while able to communicate verbally, has some unique challenges and methods in his communications. Developing this shared understanding has been critical for both of us to understand each other.

DO NOT LET GO, YOU ARE NOT ON BELAY!

Some friends were out rock climbing. It was an especially nice weekend, so there were a lot of people out taking advantage. There was one route my friends wanted to attempt so they waited while another pair were climbing. While most of my group of friends were relaxing and just generally hanging out, one friend – we’ll call him Dave – was watching the other pair climb. And good thing he was.

nwaHCR

When a climber reaches the top of a route on lead, he will typically clip directly into the anchors and go off belay so that he can fix a rappel to get back down. Sometimes, though, he will set some gear and run the rope through the gear so he can be lowered down and the next climber can then top rope the route. In this case, the climber did neither; instead, he down climbed to the last piece of protection he had placed on the way up, apparently with the expectation that his belayer would then lower him from that point. The belayer, however, was not aware of any of this, having expected that the climber had gone off belay at the anchor. (I think you can see where this is going.)

Dave, my friend, was watching all of this and saw that 1) the belayer had taken the climber off belay and 2) the climber was getting ready to let go of the rock and lean back to be lowered to the ground, which meant that 3) the climber was just about to plunge to his death. At which point Dave shouted at the top of his lungs, “DO NOT LET GO, YOU ARE NOT ON BELAY!

The route this pair was climbing was an overhanging 5.11c, meaning that this was an experienced pair of climbers (5.11c is hard) and that when the climber is on the top half of the route the climber and belayer cannot see each other. The typical exchange when the climber gets to the top and clips into the anchor would be for the climber to shout down, “Off belay” (to let the belayer know that they can take him off belay) and the belayer shouting back up, “Belay is off” to make sure that the climber knows he is on his own. In this case, the climber shouted something down, the belayer thought it was “Off belay”.  The pair thought they had a shared understanding of the situation, but they obviously did not. The climber had broken from the routine, while the belayer was following the routine because she didn’t know of the climber’s change.

Fortunately for this pair, and everyone at the crag that day, Dave’s warning was in time and successful in stopping the climber from letting go and leaning back.

The point?

There is no real definition of what “shared understanding” entails; it’s more of a “know it when you see it” kind of thing. These two stories, hopefully, show what shared understanding might mean in different situations; one being a situation where two people are coming from a different context and one where they are coming from the same context.

Would love to hear some of your stories about shared understanding, or the lack thereof.

 

Advertisements

Labels, standardization, and missing the point

The problem with putting a label on something is that it becomes all too tempting to commoditize anything that uses the label, to standardize until everything in that label can be turned into a checklist or piece of software. My first real experience with this was with Knowledge Management. So much promise when I first came across the concept and started practicing it in the late ’90s, it wasn’t long (early ’00s) before KM was mostly synonymous with document/content/information management. An inherently complex endeavor well suited to navigating uncertainty was turned into an attempt to capture knowledge as if it were some static thing, to turn every situation into something that can be solved with a past best practice.

I also saw this in my personal life, as I learned more and more about autism and the lives of autistic people. As the parent of an autistic son, I had a lot to learn. The most important lesson I learned was, “If you’ve met one autistic person, you’ve met one autistic person.” And yet, it seemed as if everyone was trying to make me believe that all autistic children were the same, that the “cause” of their autism was the same, and that if I would only do [insert some craziness here] then they would no longer be autistic, or they would be better able to cope, or whatever. Ooh, look, there’s a label, let’s come up with a way to standardize that and get people to use (aka buy) our method to do something with it. Though there may have been some sincere interest in help parents help their kids, mostly it seemed to be about profiting from the situation without worrying about actually understanding the situation.

More recently I’ve been learning about Agile. When I read the original Agile Manifesto I couldn’t help thinking, “Exactly.” This is how I’ve approached most things throughout my career, even though I’m not a developer and don’t work in an “agile shop”. But then I dig deeper and realize that Agile is apparently no different from that early experience with KM. A great idea corrupted by people interested not in the ideas themselves, but in somehow profiting from those ideas. Methodologies and frameworks and do it this way exactly you can’t mix and match because if you do then it is not [insert framework]. And oh by the way you need to take this certification course and take the test because if you don’t then no one will hire you.

OK OK, probably a bit harsh.

All is not lost when it comes to Agile, at least from this beginner’s mind. (I’ve kind of given up on KM.) Ideas such as Modern AgileAgility Scales, and others give me hope that I’m not the only one that thinks this might be the case. I don’t know nearly enough about all of the hundreds (thousands?) of frameworks out there to say that I can use any of them, but I do understand and apply an agile mindset.

I’m still working through these ideas. Would love to hear your thoughts.

Jurgen Appelo – Complexity vs Lean the Big Showdown

Lean software development promotes removing waste as one of its principles. However, complexity science seems to show that waste can have various functions. In complex systems things that look like waste can actually be a source for stability and innovation; Lean software development preaches optimize the whole as a principle, and then translates this to optimization of the value chain. However, I believe that complexity science shows us a value chain is an example of linear thinking, which usually leads to sub-optimization of the whole organization because it is a non-linear complex system.  — Jurgen Appelo

Exactly. Somewhat reflects my own thoughts and is something that has been on my mind quite a bit of late amidst an organization and projects hell bent on removing not just the optimum amount of waste from a process but removing all white space from the environment in pursuit of maximum efficiency toward the achievement of what they already know how to do. (breathe, Brett…)

As I wrote in KM vs LSS vs CPI, too often “improvement” is seen as requiring a single, all or nothing approach. When, in fact, improvement and optimal performance comes from a mix of techniques. Sometimes waste is a hindrance, and sometimes it’s where you find the gold.

 

Organizational forgetting

I wrote the following back in November 2005:

My early days in Knowledge Management included a lot of time developing, deploying, and getting people to use “knowledge repositories.” (At least trying to get people to use them.) A worthwhile endeavor in some regards, I’ve always had misgivings about the whole idea, at least how it has been implemented in most cases. The cheapness of mass storage these days, and the way we just keep everything, has nagged at this misgiving over the past couple of years.

I finally realized one day that the problem has become not, “How do we remember all this knowledge that we’ve learned?” but rather, “How do we forget all this knowledge we’ve accumulated that we no longer need so we can focus on what we do need?”

That post also included a reference to memory and forgetting in the human mind, taken from the book The Trouble with Tom by Paul Collins:

Memory is a toxin, and its overretention – the constant replaying of the past – is the hallmark of stress disorders and clinical depression. The elimination of memory is a bodily function, like the elimination of urine. Stop urinating and you have renal failure: stop forgetting and you go mad.

explored this idea a bit further in March 2007, where I added the following to my thinking:

In the context of mastery, especially of something new, it is sometimes hard to know when to forget what you’ve learned. You have to build up a solid foundation of basic knowledge, the things that have to be done. And at some point you start to build up tacit knowledge of what you are trying to master. And this, the tacit knowledge that goes into learning and mastery, is probably the hardest thing to learn how to forget.

Sometimes, though, it is critical to forget what you know so you can continue to improve.

And yet again in June 2009:

I’m at a point now, though, where the project is going through significant changes, almost to the point of being a “new” project. My dilemma: How to “forget” the parts of the old project that are no longer important and start with an “empty mind” to build up the new project without the baggage of the old.

In his book Brain Rules, author John Medina writes, “It’s easy to remember, and easy to forget, but figuring out what to remember and what to forget is not nearly so easy.”

I was reminded of this train of thought today when a colleague shared a link to a TEDx talk by Pablo Martin de Holan titled Managing Organizational Forgetting, based on a paper of the same name published in the MIT Sloan Management Review. If you read my quotes above, I’m sure you understand why this opening paragraph from the paper grabbed my attention (emphasis at the end is mine):

Over the last decade, companies have become increasingly aware of the value of managing their organizational knowledge, and researchers have investigated those processes extensively. Indeed, the ways in which organizations learn and have stocks of knowledge that underlie their capabilities can be a powerful tool in explaining the behavior and competitiveness of companies. Yet something is missing in the current discussions of organizational knowledge: Companies don’t just learn; they also forget.
Pablo Martin de Holan 

There is a lot of great info in the paper (about 12 pages worth), but for now I’ll just mention the two modes of forgetting – Accidental and Intentional. Obviously, you will want to limit the former and maximize the benefit of the latter. At the risk of a giant spoiler (you should still take the time to read the full paper), de Holan summarizes nicely:

Some companies forget the things they need to know, incurring huge costs to replace the lost knowledge. Other organizations can’t forget the things they should, and they remain trapped by the past, relying on uncompetitive technologies, dysfunctional corporate cultures or untenable assumptions about their markets. Successful companies instead are able to move quickly to adapt to rapidly changing environments by being skilled not only at learning, but also at forgetting. Indeed, as companies work to increase their capacity to learn they also need to develop a corresponding ability to forget. Otherwise, they could easily be learning counterproductive knowledge, such as bad habits. The bottom line is that companies need to manage their processes for forgetting as well as for learning, because only then can they deploy their organizational knowledge in the most effective ways for achieving sustained competitive advantage.

I really wish I had come across this paper back in Winter 2004 when it was published. I’ve got a lot of catching up to do.

And for those of you interested in the TEDx talk, here you go.

On knowledge and (organizations as) knowers

Been giving some thought to the concept of knowledge and knowing in the context of organizations and knowledge management. These two paragraphs come from separate trains of thought, but are related so I decided to post them here together. Definitely needs a bit more reflection and development. What do you think?


The terms “tacit” and “explicit” are typically used when referring to different types of knowledge (in the context of knowledge management efforts). It seems to me that “unconscious” and “conscious” might be more appropriate / accurate? In that explicit knowledge is that of which you are consciously aware of while tacit knowledge is that which lies “below the surface” and which you use without having to be aware you are using it. Need to cross reference this with what I’ve been learning about Liminal Thinking….

On the subject of “knowers”, could the organization itself be considered a “knower”? Not the sum total of the knowledge that resides in its members or files, but a knowing that emerges from the connections and interactions of that knowledge. If so, how would that change how we approach KM?

KM vs LSS vs CPI

A coworker posed a question today on one of our internal discussion areas looking for thoughts on the differences between knowledge management (KM), Lean Six Sigma (LSS), and Continuous Process Improvement (CPI). I know a little about KM, not so much about LSS and CPI, but took a stab at a response anyway. Here’s what I came up with:

  • KM is about things you don’t yet know how to do or that you have never done
  • LSS is about doing better that which you already know how to do in the way you already know how to do them
  • CPI is about finding better ways to do what you already know how to do

Each has its place, depending on what you are trying to accomplish, it’s not an all or nothing proposition. Just as organizations need a good mix of structure and fluidity, they need a mix of sustaining and improving on the things that are necessary and learning new things. And, yes, I’d say that there is some correlation between these, where the infrastructure will typically benefit from increased efficiency (LSS, CPI) and operations needs the ability to learn and grow (KM).

Unfortunately, “all or nothing” seems to be the default approach of many as they try to improve an organization. But just as the means of keeping the human body healthy is different and distinct from learning a new language, the processes and tools we implement to keep our organizational infrastructure healthy differ drastically from the way we interact with our operational environment.

A better analogy may be the training of an athlete. The athlete trains both body and mind together towards a single goal, building up from perfecting the basics (LSS), learning how to combine the basics into effective combinations (CPI), and ultimately pulling on this past training and effective interpretation of the environment in which they are performing to achieve something they had not done before (KM).

How would you describe the differences between KM, LSS, and CPI?

 

Is there a problem here?

Solving a problem that you know has a solution may require knowledge, but it is knowledge that already exists. Unfortunately – or, if you prefer, fortunately – many of the problems that are worth solving, that need to be solved, don’t come with that level of certainty.

In his book, How Life Imitates Chess (which, by the way, I highly recommend), Garry Kasparov has this to say about uncertainty:

Knowing a solution is at hand is a huge advantage; it’s like not having a “none of the above” option. Anyone with reasonable competence and adequate resources can solve a puzzle when it is presented as something to be solved. We can skip the subtle evaluations and move directly to plugging in possible solutions until we hit upon a promising one. Uncertainty is far more challenging. Instead of immediately looking for solutions to the crisis, we have to maintain a constant state of asking, “Is there a crisis* forming?”