Tag: KM

Sometimes reinventing the wheel is exactly what you need

~ g BRETT miller (he/him/his)

Don’t reinvent the wheel.

The argument for not re-inventing the wheel is often one of efficiency. The wheel has already been invented, it’s a commodity; just get the cheapest wheel you can find, a wheel is a wheel.

An argument for re-inventing the wheel is one of effectiveness for the job at hand. What would vehicles today be if they were restricted to using the “original” wheel?

But wait, you say, an iteration of the wheel isn’t a reinvention of the wheel, it’s just an improvement, a “re-imagining”. The people who went from solid wheels (of rock, perhaps) to hollow wheels with spokes weren’t reinventing the wheel. Or were they?

Consider the tracks that were developed for heavy machinery and armored combat vehicles. These are not “wheels” in the traditional sense. Those vehicles would not be possible if the wheel had not been reinvented. Would we have been able to send humans to the moon if we hadn’t reinvented the wheel?

I think where most people get bogged down on this is the question of form over function.

If what you need is an actual wheel, a circular object into which you can insert some sort of axle and then place a chassis of some sort onto that axle so that the resulting vehicle can move from place to place, then what you have is not an issue of invention but rather a question of selection: pick the right wheel that already exists for the job, maybe modify its form slightly to meet your needs.

If, on the other hand, you have a need for a means of providing locomotion for an as yet not designed or built system of some sort, then limiting yourself to a “wheel” that has already been designed may be overly limiting. And reinventing the wheel may be exactly what you need to do.

Spotify, song pairs, and the future of work

~ g BRETT miller (he/him/his)

Listening to Spotify today, I start with Pink Floyd‘s classic Meddle. After the album completes, Spotify takes me off to “radio” based on the album. I love this feature, btw, I’ve discovered a lot of new music this way. Inevitably this includes more Pink Floyd, which is – of course – awesome.

On comes Brain Damage from Dark Side of the Moon. As anyone who is familiar with this particular song knows, it is actually just the first part of a two-song series that includes the album’s closing track, Eclipse. (To be sure, DSotM is really just one long song, but I digress.) So of course I’m expecting Brain Damage to seamlessly segue into Eclipse.

Nope.

Continue reading “Spotify, song pairs, and the future of work” →

Shared understanding – two stories

~ g BRETT miller (he/him/his)

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.

 

Labels, standardization, and missing the point

~ g BRETT miller (he/him/his)

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 Agile, Agility 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

~ g BRETT miller (he/him/his)

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

~ g BRETT miller (he/him/his)

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.

I 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.