Jim McGee 18:14

I had an insight many years ago when I was trying to understand why it was that we weren't seeing take up of the system, the knowledge management systems we were deploying. What was, why weren't we getting knowledge sharing? Why wasn't it happening? And what I realized in the shower one morning, where all best ideas occur, I got it. I knew who the lazy SOB was, wasn't doing the share. It was me six months ago.

Jim McGee 18:49

I wasn't sharing with myself. I wasn't paying attention to what I needed to do when I did it. And so I couldn't I couldn't find my own work. And I can't find In my own work and on the other knowledge workers in your organization can't find their own work.

Jim McGee 19:22

How do you, you know, how do you name it so that not so that Greg can find it later, so that I can find it later?

Jim McGee 19:27

And the sharing takes places, the sharing if you look at the social dimension of knowledge sharing in most organizations, it all starts with a conversation or a phone call. You never find anything useful going directly into the knowledge management system. Never. You always find something useful talking to someone who will point you to - and we keep thinking of that as a bug, not a feature.

Jim McGee 19:59

But that's really the only way it's going to work.

Jim McGee 21:37

So again, you want actually to route those search requests through the conversation. So you know, social networks, both inside and outside the organization become another important part. You want to be able to connect the work product, to its creators to its editors. Partly for assigning credit and metric kind of issues, but more because I need to be able to go talk to you about your document, in order to make sense out of it.

Jim McGee 23:37

I think one of the actually one of the one of the opportunities in electronic digital environments we work in today's it's possible to create, to capture most of that context because a lot of that discussion now takes place, by way of email by way of, you know, by way of, you know, or ideally in a in a space an organized in a way that you can you can look at it as opposed to the only thing you have to see is the final document because that's the only thing that system captures. Now those traces are available. The question is what do you do to capture and make them make them available?

Jim McGee 25:13

Alan Kay - one of my favorite smart people in the world, as you know - has this quote, which is at least I've always seen it attributed to Alan “How you look at a problem is worth 80 IQ points”. Right. And that's kind of what the opportunity you know, that's why making work observable as a simple step is so important. Right? If you can see it, then you can do something about it.

Jim McGee 31:13

So if you get if you get too focused on deliverables you lose sight of what sort of what comes after the deliverable, which is the decision or the action. So, but you start with deliverables and you start making you start tracking and you keep you pay attention.

Jim McGee 31:28

But the next piece is then you move back to a concept that I learned back in my days when I had to work in an auditing firm. I was a consultant, but it was it was Arthur Andersen and they wanted all of us to pretend that we knew something about auditing. I actually had to go into a vault once and literally count stock certificates and bond certificates as part of an audit.

Jim McGee 32:05

But one of the brilliant things that auditors did is they created this notion of working papers. They were all paper that but you know all of the documents and memos in the in the intermediate products that they worked with along the way to get to the... Cause the deliverable for an auditor was it was a two page letter. Right?

Jim McGee 32:27

And in fact, 90% of that two page letter was strict boilerplate. So what they needed to do in order to justify it to themselves and to their clients, but they needed to, they needed to be able to demonstrate what work had gone into creating a deliverable. We reviewed this many accounts, we sent these letters out to, you know, shareholders, we did X we did Y we ran this analysis, we found that and so this notion of working papers is a useful one to recover and to think in terms of as you do the work work you're doing is to think in terms of the intermediate products because the intermediate products are the ones where real reuse is going to be possible.

Jim McGee 33:42

Okay, now I got to source the data differently, but the analytic piece still holds. Now if it's buried in a deliverable I can't I can't find it. So you know, I can I you know, what, what you'll do if you're if your knowledge system is only working with deliverables is you go in, you open up a bunch of deliverables and you skim through it, you look for the graph, and then you try, then you hope you can find the particular analyst who did the work.

Jim McGee 34:10

Because, you know, damn well the partner doesn't understand what went into the analysis and track that individual down and say, you know, Mary, what, how was it that you did that? Right? And what was the creative? So, you know, I think the next piece of this, you know, to attack is going after work again, creating those intermediate objects and making those visible with tags, nothing, nothing exotic.

Jim McGee 36:08

I think the challenge is really about developing better mental models. It's it's not about the user interfaces. As much as it's about, if you look at the people who make progress with these tools, and you sort of unpack what they're doing, they're operating with a smarter mental model, and you're about what they're doing.

Jim McGee 36:29

And the the challenge of mental models is that it doesn't fit in a training regime. It doesn't fit in the normal kind of rollout schemes. We don't know how, I don't know how to equip people with better mental models in a systematic way, because it's an education problem, not a training problem. It's not about you know, where do you put the tags or, you know, how do you how do you put a, you know, creative view, it's about asking What, what kind of tags do I need? Why do I, you know, what am I gonna do with tags? Right? And so you look at some Traction. So, you know, they've got, you know, a little to do to, you know, to do as a tag, right, which is sort of, okay. One of the things that, you know, I need to think about tasks, and I don't actually need to create a whole systemic capability for doing tasks so much as I need to be able to tag something as a To Do

Jim McGee 37:26

I know you've got tasks coming. But if I bet right underneath it, and one of the things one of the things I find so fascinating about TeamPage and Traction which I've watched is fundamentally there's a richer model underneath the software than any of the other pieces of software I've looked at. Because of you know, Andy van Dam and Doug Engelbart, you know, in connection with Brown and and all they dug a level deeper to a model of what they were actually working with in terms of chunks of information. And then most of the other tools would sort of said, Oh, it looks, you know, I got a blog, I got a wiki I got, but there's not a model underneath. Or if there is a model underneath, they don't expose it to the, to the user community, the design community. So what do I do with the model?

Jim McGee 38:18

And we were talking about this last night about Lotus Notes and about SharePoint, both of which have this interesting problem that the demo systems out of the box, you know, the sort of default You know, my my, my, my, my wiki page or where my sites are Lotus Notes used to have a discussion, threaded discussion. They push most designers the average designer down a bad path and contribute to the disappointment that comes later in using the platform because they haven't exposed the real model of what you can do with the tool. So the to me the challenge is digging after these models. And I don't know how to do that. I just believe that that's where the that's where we're going to take observable work observable work, be able to see what's going on the next layer underneath is or what models does that let us support about how we are attacking work and developing work product.

Jim McGee 40:38

And what we're talking about here is knowledge work is always about performing the magic. So rather than sort of standardize everything around the magic, let's go focus in on how do we open up the magic box and understand kind of what are some of the intermediate steps one of the things we do to make the magic more likely to happen.

Transcribed by https://otter.ai