Traction User Group (TUG) 2010 Meeting Newport RI TUG 2010 Keynote: 'Doing and Managing Knowledge Work' Jim McGee New Shoreham Consulting www.mcgeesmusings.net 13 Oct 2010 http://tractionsoftware.com/traction/permalink/Public1863 Greg Lloyd 0:00 With without further ado, I'd like to introduce our keynote speaker, Mr. Jim McGee, who will dazzle us -- as always. Jim McGee 0:10 I just been set up. Jim McGee 0:12 Good morning! Jim McGee 0:14 If I've done this, right, I've probably got somewhere between 35 and 45 minutes worth of material plus or minus. And so it's designed for interaction and discussion as we go. And I would, you know, we'll all benefit if we do that. I've been working in this area for one way shape or another for more years than I care to admit. Let's put it that way. Going back at least into the, you know, the early 90s when I was Ernst and Young, we ran a multi-client program, Tom Davenport, Larry Prusak, and I ran a multi client program called mastering the information environment, which we thought was complicated back in 1993. Little did we know. But what I've what I've been focusing on all this time, it's really the problem of what's different about doing and managing knowledge work from doing other kinds of work. And one of the notions that sort of cropped up between Jon Udell and Greg, myself and others is this notion of one of the problems with knowledge work is that it's essentially become invisible. And one of the first steps to solving all the other problems is how to make it something you observe. And see. That’s sort of the thread that I'm going to going to talk about this morning. Jim McGee 1:35 Then starting with for those of you who are old enough and recognize Pogo, you know, Jim McGee 1:40 “We've met the enemy and he is us” Jim McGee 1:43 One of the challenges from a systems development point of view. I started life as a real propellerhead database designer, systems designer and then ultimately went on and began got a PhD in organizational design. It's a weird combination, but there's a reason for it. That has to do with why technology failure is so common, which is that we ignore the human and organizational element on a routine basis. When we start developing for I would argue that for most of the time, we've been building information systems in organizations. We've been building systems for them. We've been building systems where the user group is somebody else. And it's somebody that we treat as a component in a mechanical system. And all the systems we're dealing with today are systems where the technology is for us, we are the the audience. And that difference is important. What's different about us as users in this in the system and as creators of these systems is important. Jim McGee 2:45 So that's kind of the thread I want to I want to follow through on. So Peter Drucker, we're all most of us are fans of Peter Drucker, I figured a lot of the over the years I concluded that If you wanted to make a career as a consultant, you would back up 10 years to whatever Peter Drucker was saying 10 years ago, and start selling that. And you would almost always be right. And shortly before so 10 to 15 years ago, Peter wrote several interesting articles about the problem of productivity of knowledge workers. Basic argument is, is it the 20th century was this that all the economic growth in the 20th century was about making production workers more effective. It was Frederick Taylor, it was, you know, scientific management, it was, you know, Gilbreth and others, you know, cheaper by the dozen going in and looking at production work, and making it better over time, and that we needed to do the same thing. For knowledge work. If we wanted the 21st century to have a similar kind of outcomes as we had in the 20th century. Jim McGee 3:58 Now, the problem with that Is that Peter didn't really buy the people who superficially read what Drucker was saying is that we treated the problem as if it were identical to the problem of improving production work. And we didn't understand what was different about knowledge work and knowledge works. Okay, in production work, the simplest, the reason you can systematically improve production work over time, is that at the end of the process, here's a very clear, well defined deliverable, you know, we need to make, you know, 100,000 of these, and they all need to be identical. They all need to meet a certain set of tolerances. And given that output was defined, you could then go back and look at all the steps in the process and look at ways to eliminate weights, redundancy and so forth. The problem with knowledge work, is the first problem is understanding 'what is the task?' Jim McGee 4:57 Right so you understand what the task is, you can't improve it. Jim McGee 5:01 The second problem is that knowledge workers have a great deal of autonomy. To do knowledge work successfully, we have to have the freedom and the range and space to work on the problem as we see fit. Until we understand those problems, we're going to be stuck in trying to apply Taylor's techniques to the wrong problem. Jim McGee 5:26 So this is happens to be Al Gore's office when he was working on an inconvenient truth, and the point is, excuse me. point is this. Jim McGee 5:47 When you see an office like this, we will laugh but you'll also understand that there's a great deal of creation going on. And that creation is necessarily messy. It was an interesting piece of research and I've forgotten a the woman's full last name. Now Allison was her first name, I'll dig up the reference was a psychologist who studied offices of creative workers interesting. And essentially came to the conclusion that in order for them to be to create and be creative, their offices essentially needed to look like this. [Applause and laughter, "Vindication!"] Jim McGee 6:27 Don't you feel so much better now? Jim McGee 6:31 Because in fact, for Al Gore, there is order and there is information in this environment, the piles matter, right? Where the books are matters. And that's the way that that that ability for Gore to see that is part of his ability to manage that environment and you can think of your professors you think of, you know, creative directors, you know, an ad agencies you you look at, look at the works spaces of systems software developers in the walls are littered with pictures, right? There are piles everywhere. And that was a good thing. Jim McGee 7:12 And then, somewhere 20, 30 years ago, we begin to apply automation to this problem. And we created a problem for ourselves because this is what most offices look like today [person at clean desk, typing while staring at screen] Jim McGee 7:24 Right? This is now the knowledge environment we work in Jim McGee 7:28 and everything has become invisible. Jim McGee 7:34 All of that is still there. [flips back to point to messy desk] Jim McGee 7:41 But now, it's somewhere in there. [flips forward to point to screen on clean desk] Jim McGee 7:44 And that invisibility creates a huge problem. Jim McGee 7:51 And, you know, until we solve the visibility problem, all the other kinds of problems aren't going to get solved. So if you talk about knowledge management, knowledge sharing, sharing what we know, be more effective knowledge, you can't do any of that until we solve the problem of this invisibility. Jim McGee 8:14 So I want to start by taking a look at just thinking about that office of Al Gore's or what you know what's on hidden on your hard drives or hidden on the servers in your organization and think about knowledge stuff. And I want to think about in terms of on one dimension, we've got this dimension of structure, in, you know, the stuff is more structured or less structured, or much of its individual work, but there's a huge component of knowledge work. It's also social that we can't do the work unless we participate and interact with others, okay? And just as some examples, so for example, you know, you know, a contract, highly structured document created socially, among a group of people. That's one extreme. Jim McGee 9:07 The other extreme is a sketch on a napkin in a bar, trying to figure out what your next product is going to look like what your next user interface is going to look like. I was a systems designer for years we no project was ever done until there was at least one napkin or placemat, you know, in the files. Because that always was the point at which you understood what the problem was you were really trying to solve it until you had some two or three people that sat down and created that you weren't done. And then we have a whole things that I think of as knowledge containers, the different than the stuff itself. Things like you know, databases, books, a wiki, blogs, internet novels, you know that those are the problems we deal with. And of course, it's all kind of makes sense. Sort of a real simple minded? Okay, now of course, that's what it really looks like. Jim McGee 10:05 Right? It's not that ordered. Jim McGee 10:09 And that's what begins to create and complicate this observability problem. All of this is there. And for most of us, we keep track of it in very crude and ineffective ways. Because we don't actually realize that that's what we're trying to do. So Yogi Berra is always one of the better systems designers around. And we come to this notion, this idea of, what do we do to make this work, these objects, this stuff visible, so we can then do something with it, and making it visible is only the first step. All right. This sort of notion of observable work is only sort of step zero. Moving forward is a foundational step. It's not the end, it's just the beginning we'll talk about where I think we were going to take us as we do that. Now, in most cases, for we've, we've dealt with it as a tool kind of idea. We think about, we think about what's there, through the lens of the individual tools we use, when you know whether it's a web browser, or it's a mind map, or it's PowerPoint presentation or blog or a spreadsheet. Jim McGee 11:31 And that, for me, I'm finding the tools perspective, inadequate. Jim McGee 11:39 Because each tool has a set of assumptions built into it, about what's underneath and most of us don't think about what those assumptions are and don't think about what what they mean. And that leads us into trouble. Jim McGee 11:58 I see some heads some people can have gradually daunting comprehension or complete lost in the weeds. Weeds or comprehension? audience 12:09 Comprehension! Jim McGee 12:10 Okay. Sweet. Jim McGee 12:16 So I think instead the question. So this is where the notion of making knowledge work observable is drilling down one layer beneath the tools and asking what are the things we knew we need to begin to do to bring order to this chaos to bring order to this virtual environment that at least in the Al Gore's case he could see. Jim McGee 12:43 And even if we couldn't see the order he saw the order. Jim McGee 12:46 I think it's important to think about seeing the order for yourself first, and we'll get to the social part later, but first, I've just seen the order for yourself. And I think that there are a couple of layers in the first layers what I think of as a hygiene layer. Little things that turn out to be important that we never think about either individually or organizationally, what we name our files. How many of you I used to teach at Kellogg in the MBA program and I get but I also ran consulting projects for a long time. How many of you on your laptop somewhere have a file in a directory somewhere whose file name is 'Final Presentation N' where N is some number between zero and nine? Jim McGee 13:35 Right? Because we have no better way. Jim McGee 13:37 Now - two years from now. How are you going to know what's inside final presentation seven and why is it different than final presentation eight? Simple minded and if you look at systems development shops, software development shops there, they're quite ruthless about how they name modules and files because it turns out, it matters. It turns out that putting a time stamp on it on a document or on something is important. Now the problem is that the timestamps at the operating system puts on a file are basically irrelevant to you is every time you modify the file that the operating system modifies its timestamp, because it's time stamp is important for its purposes. And you might want to know, at some point when it was you actually first created that file. Now, the arbitrary timestamp was the last time you edited it this week might be important to you now that you actually created that file five years ago. Jim McGee 14:41 Simple minded version control. I'm really annoyed with the software development community. Because the software development community figured out 25 years ago, that source code control and version control is important. Right, what version of the presentation you have? And they didn't give it to us. They kept it. And the best, the best thing they could come up with to give us was Track Changes in Microsoft Word. Jim McGee 15:14 Please. Jim McGee 15:17 And oh, by the way, they didn't bother to give us Track Changes in PowerPoint until PowerPoint whatever, you know, however many versions it was, you didn't even have it in PowerPoint, you could put notes on slides. Jim McGee 15:34 And that's because I think the original versions of most of the tools were just fundamentally focused on producing paper output. And what happened before that was irrelevant, because if you think about it, the word processors and the other tools originally got deployed in places like word processing departments. How many of you with an organization long enough to have had a word processing department don't have one. You still have one? Jim McGee 16:06 She's a lawyer. Jim McGee 16:12 And what would you do? Right? You would write stuff out longhand, and do all the thinking work, then and then you when you were very near the end, you would turn it over to the word processing department. And you will you basically did the last 5% of the creative process with the word processing department. Right? And they would, they would, so then Track Changes was a useful idea, because you get most of it right. And you go and you edit a little thing that you weren't doing major revisions. That's an assumption built into the tool that doesn't reflect the actual development and creation process that goes into writing a complex document. Jim McGee 16:51 Now, all of us who had to write for a living grab those tools because those tools were so so much better than writing something out longhand. We grabbed it, but we didn't deal with the fact that it didn't do half of what we wanted to do. And then we wonder why we're working till 10 o'clock at night. Right now it's not simply because, you know, the guy on the left you and the gal on the right of you have been, you know, reducing force in or off, you know, starting their consulting business because they're not employed anymore. And you're working till 10 o'clock at night in order to stay employed. But we've built inefficiencies in to the environment in a huge way. Second thing is then we start to get you know, as we start to move into a social environment, we start to move into a, you know, we start worrying about things like adding metadata, and tags tagging is a wonderful thing. Jim McGee 17:46 Taxonomy not so much. Tagging is a great thing. Jim McGee 17:50 I you know, I'm biased in the focus on clearly hard over on the side of things. Now, I was the Chief Knowledge Officer in a consulting firm at one point in so I went through the whole taxonomy game, and I regret it. Jim McGee 18:06 I apologize to all those people working for me at the time. Jim McGee 18:10 Because, you know, it's... 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:06 We're way ahead way premature to talk about how do we promote knowledge sharing among everybody else. Jim McGee 19:16 So the step is to start thinking about tags 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 20:02 Another example. Jim McGee 20:06 I have two people working with me, in this particular consulting firm one was an absolute world class call center expert. Dave could walk into the lobby of a call center, spend two minutes just looking around the lobby. And he could predict, you know, within plus or minus, you know, 2% exactly what the productivity of the center was, where all the problems were and how to fix them. He just knew. And he had, you know, series of checklists that he used to sort of document what he had figured out in the first two minutes. Jim McGee 20:42 For the purpose of billing the client for all that expertise. Jim McGee 20:46 Well, it's like the old it's the old auto mechanic story, right? You know, I need an item, you know, you hit it with a hammer, right? You know, I need an itemized bill right? 10 cents wear and tear on a hammer $100 knowing where to hit with it. Now. Nadia was a PhD mathematician from Princeton. She's now running a big chunk of operations at Amazon. And she grabbed one of those spreadsheets that was in stored in our knowledge management system and went off and created havoc in a call center. Super smart, had all the right materials, but had no context with which to interpret. It didn't have all of the kind of package knowledge or what we would call tacit knowledge that Dave had, and she could have gotten enough of it if she'd had the conversation with Dave before she went off and did the 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 22:12 And then lastly, Jim McGee 22:14 All of the work needs to be put in context. And this goes back to the notion, I think of it, Todd, I know you've talked about I think Dave Weiner is the first guy I know who talked about narrating work, but you know, that this notion that the best way to do knowledge work is to sort of as you create the work products is to keep a running kind of note log for yourself and what you're thinking about, it doesn't show up in the document. Okay, well, the classic is why did you make the particular design decision that you did? What were the alternatives that you considered and rejected? A lot of my examples tend to be systems development, because that's where I started. Yeah, audience 22:56 I was just on a three hour phone call with My colleagues yesterday talking about a three page document for exactly this reason, because you read it, you know, like, okay, I kind of get what we're talking about. But then you talk about it, like, Oh, this is what this is what you're thinking about this paragraph. And this, I mean, cuz it's marketing, it's gotta be perfect. But the context you get from having that conversation is completely different than, well, I know what we're doing in the business. And I kind of know what this is supposed to be the context you get from that conversation. And whether you're narrating it on the phone, or you're narrating it, kind of like what you're talking about. But having that context is so important. And I think it's very easy. Jim McGee 23:36 Right. And 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 24:13 You know, the idea of issue management is another, you know, kind of thing Jim McGee 24:16 I just had a conversation with a colleague the other day we were, we were actually thinking that you could manage almost all knowledge work through a bug tracking system. If you really thought about it, that, that the management layer was an issue management system, you had the creation of deliverables and everything else was an issue management system. Right, I have this problem with the document, I have this problem with the concept of weight on and your management is a question of basically tackling issues in the right order. And that the management task was to sort of figure out all the issues, group them and then knock them off. Again, another one of those lovely tools at the systems development community created and didn't share. It's not their fault actually said management didn't understand what was going on and understand what why those things were important to what work they were doing. We'll come back and pick on management some more later. Jim McGee 25:10 Okay. 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. So, any of you people, anybody here working on Help Desk environments, at some point or tech support? You recognize this acronym ? [PEBKAC] Yes. Who wants to try and translate that acronym for those who are bored? audience 26:04 “Problem Exists Between Keyboard And Chair.” Jim McGee 26:07 That's where that's where our problem is. That's where our problem lies here. Right? What are we going to do to help this individual operate in this environment? What are we going to do not? Well, not what are we going to do here so much as what are we going to do here? Jim McGee 26:26 Which is the point of this, you know, observable work. And I think the first step is to think in terms of breaking this environment up a little bit in terms of structure. And I want to start with sort of the structure down, which is what I think of as deliverables when we talk project management worlds talk about that a lot. And that's actually a useful first structuring point. You know, what is it out of knowledge, what are we going to create, we're going to deliver a software system, we're going to create a contract, we're going to deliver a document and deliver a presentation, right? What is it that we're gonna, you know, we're gonna, what is it that we're creating? Can we look at that, you know, can we make those more visible? Simpler? Jim McGee 27:06 And that's where a lot in a lot of knowledge management systems start with capturing and managing deliverables. You know, I know there are a couple of other consultants in the crowd here, right? It's yeah, we hear a lot of proposals here, the final client reports, right, here's the you know, the engagement paperwork, FDA, here's the, you know, the new drug application, like the deliverable, what's that? And some of those are very complex. But that's that's the deliverable side of things. And that's an okay place to start. Jim McGee 27:40 But when we start thinking about the question of improving knowledge work, and making it better, we can we can go farther than that because the problem with the deliverables, the mistake that gets made when we focus completely on deliverables is that we start to mimic this Tailoristic approach to productivity improvement that we use in the 20th century. And we start to focus on issues of making all the deliverables look the same. Right, we start to focus on, you know, uniformity. And the problem with knowledge work is, I've yet to see a consulting client who wants to report I gave to my last client. Right? And so the danger of focusing strictly on, if I take the last deliverable from a project, you know, what can I do with it? How does that help me to do the next project? Jim McGee 28:44 Just in and of itself, because what I what I need to do when I'm doing knowledge work, what I'm rewarded for, is what it is that's unique about the product I created. Not what it is about it that it reinforces the brand message and has all the corporate logos where they belong in the right color scheme and all those things that you know, the marketing police beat you up for when you're a consultant. You didn't use the right color scheme. The font was, you know, 18 point in the standard says is supposed to be 14 point. Jim McGee 29:24 We're not reinforcing a brand message. Jim McGee 29:27 Because what the client wants click what a lot of places what the client wants is the client wants, you know, a recommendation do X scribbled on a napkin. Jim McGee 29:41 And the rest of it is justification for what's on the napkin. Jim McGee 29:47 Best story I heard about this, I was talking to a partner at McKinsey the other day, who had very smartly invested a lot of his career development time in picking out the people at the clients that he was working with as a junior consultant who he could tell we're going to far. Cause you know, you're working side by side this, you know she's gonna. And so if 20 years later he had, you know, out of the hundreds of people who paid attention to five or 10 of them were CEOs of Fortune 500 organizations, they went to one of them, they said, you know, I'd like to do some work. Like I said, that's great. I love you know, I, I value, your insights, whatever it takes in the McKinsey part as well, as a McKinsey partner. I'm expected for this, you know, account to deliver $10 million dollars of Billings every year. CEO said fine. As long as I anytime I pick up the phone, I can get you. You can put teams doing whatever you want. I don't care what they're doing. Doesn't matter what they're doing. Your advice is worth $10 million. So now that place is littered with reports from McKinsey. And study teams wandering around, but the frankly the CDO sort of view is as long as they do no harm. [laughter] Gotta be there has to be managed. As long as they do no harm, it's worth it to have access to that guy since. Right? 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. And you know, you know, you the guard watches you through the door, you know, you basically you couldn't wear your jacket you couldn't you know they inspected you in a way. It wasn't quite a strip search, but it was close. 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:10 Right? You're going to do an analysis here, that's going to prove to be generate some insights for one client and it a similarly structured analysis. With the thinking behind why you did that analysis, you know, where did you source the data? Why did you do set up the spreadsheet and why you did? Why did these pivot tables reveal these insights? You know, why did you that piece, if you capture it, as a working paper piece is the piece that you can take out and move over to another project. 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:09 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 34:39 You just, you want to be able to find them when you need them. And give a little bit of thought to that. And eventually, you know, I think we're gonna get back to capturing scraps of ideas and notions and whatnot. I saw over there. I Oh, and I always have paper on, you know, little notebook in my pocket, just because you I'm old enough, if I don't capture it, if that idea comes, it's going in a hurry. If I don't get it as it goes by, it's never coming back. Jim McGee 35:15 And so you do those and then and then the other thing that I've learned with you that you then have to write it down a second time. If to take a little note and you have to read the note and reconstruct what you were thinking when you wrote the note. Right? And if you do that within 24 hours that usually works. If you wait 48 hours, it's -- I can't actually I can't read my handwriting after about 72 hours. Jim McGee 35:43 No, I go back and like it because I have these notebooks going back. Jim McGee 35:50 And ultimately, so that's a bunch of mechanical I think, for me, where this more comes down to that anywhere else is a challenge of this. This is sort of latest thinking. So it's not worked out yet, completely. But I'm going to, we're going to put it out here. And we'll start off is 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:28 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 39:19 That's where I think that's where I think it's going to go. Jim McGee 39:23 Some cautions about this. Jim McGee 39:29 One, so we talk old habits, we're going to fall the biggest risk is we're going to treat this like production work. We're going to try and do you know, we're gonna try and focus on on, you know, assume that the final product is a given. And we're going to try and standardize steps in the process and then to you know, nail down the process tightly so that we create exactly the same product right? Jim McGee 39:57 I used to examine software development methodologies, which is sort of bad example, if you were going to create a system in order to create a system in a controlled way, here are all the steps that have to take place. Right? If you actually examine those methodologies carefully, every one of those, you know, they have these wonderful charts and steps where there was always a box. In every methodology, the name vary, but what was inside the box was that was 'perform magic'. There was all this stuff, you could specify, document this talk to these people. There was always a box it was essentially perform magic. 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. Anytime you change the system, people are going to game it. If we start making observable work something we track, right, people are going to create lots of observable stuff. Jim McGee 41:13 Right? whether or not it makes any sense. So we got it, you know, we have to think about this issue here is to avoid the trap of immediately falling into metrics for the sake of metrics. We want to see stuff to draw inferences from, but we don't want to start counting things very much right away, because that we're gonna get Jim McGee 41:36 There are two ways in which management is a problem. There's the flip way, which is, you know, management's always the problem. And they're going to, you know, resist and they're going to, you know, not get it and they're going to be busy sort of worrying about the next quarter and all the things in management. But the more interesting question to me is, when you start thinking about observable work, Jim McGee 41:55 then the question becomes, what is it about what management does that you can observe? Jim McGee 42:01 And track. Jim McGee 42:04 Right? If what a manager does is sort of makes sure that everything happens and other people are the ones who are creating the deliverable out into the objects of interest. What is it that we're paying attention to about what the manager does in an observable work way? Now, it may be, it may be it's about how to manage, you know, managing the issue flow, you know, prioritizing issues and so forth. I don't you know, or it may be about the distribution of tasks to the right people. Right, say, you know, you're the, you know, and Andy you're the guy who should be working on user interface and right, Greg you're the one who should be working on database design, because if I did it the other way around, I wouldn't get a good a good answer. That's a little hard to know what it is that I observed there about management. So that's a problem to kind of conundrum that I identified but haven't solved. So any of you solve it here I will give full credit to. Jim McGee 42:56 And then the last is an issue that all of these systems have which the issue of organizational boundaries. Particularly when you get to knowledge systems, what we discover is that all of the work doesn't take place inside of the boundary of a single organization. In particularly today's world, right? We've got consultants, we got contractors, we got, you know, ex employees, we got new, you know, and one of the reasons that email continues to be the system of default choices, the only system that crosses firewalls, with any predictability. Right, you know, so if you've got if you're using SharePoint or using TeamPage, you're using Lotus Notes and you want to get your contractors involved. Right? You don't, because you don't want to go deal with the security folks in it, who are going to argue with you about why we're giving credentials out to someone who's done an employee, And oh, by the way, you know, we can't anyway because, you know, they don't have a security clearance and, here the question, it's not a question of, if you violate the NDA, we sue you, it's a question if you violate the NDA, we send you to Guantanamo. So it's complicated, but the work, work ignores organizational boundaries. And what most of us do to get work done is we ignore organizational boundaries with ourselves. Jim McGee 44:17 So the question is, how do we get how are we going to build, you know, kind of get our systems to catch up with that? Jim McGee 44:23 Just just, you know, so that's kind of the where I see the problem. My last bit of advice, and then we throw this open discussion. I think you start down here. I think you start at the individual and you start with structure and you work that way. Jim McGee 44:41 Right. And I think you and I think it pays to start at the individual knowledge worker level. Jim McGee 44:48 It's simpler. Jim McGee 44:50 Every you know, each of us has the ability to sit to, again, pursue a lot of this without permission. You don't need permission to be smarter about how you name your own files. You don't need permission about, you know, tagging your own materials. You don't need permission about migrating yourself away from email to something else. Luis Suarez at IBM has done fascinating you know, it's a social media guy at IBM and it's basically reduced his his, his email traffic, you know, by 99% by basically telling you why you want to meet with me, you got to get me on Twitter, you want to do this, you got to put it in the blog, you know, I'm not responding to emails, you know, you know, other than, you know, a handful of things. He's really pushed that traffic down. What I do for example, personal practice (Are we on time. Okay). We have time for discussion. You know, my personal practice, I generally write all of my emails in a private blog that I keep on my laptop. And then I cut and paste them into Outlook. I mean on the mechanics of setting up meetings and stuff. So anything that requires any thought I write first for myself, draft it and play with it, and I just cut and paste it to sort of, you know, it's like so proposals client, the deliverables I write, I write reports for clients in my in my blogging system and then I move them into Word at the last step and I if I can persuade the client not to do that I just point them to a blog entry if I can, but that's a little harder. I've set you know, a set of project blocks for clients who don't use it, you know, it's cheap, you set them up, you know, I Traction's a little more overhead that I can afford right now. Jim McGee 46:33 but I know Greg would be nice if I really talked to him. Jim McGee 46:40 There's a learning you know, I, you know, I but because most of the work is in images, so that's, you know, if I were to summarize this in, you know, besides start here, you know, it's, you know, step one is to just to think about how do you make what you're doing visible because until you can see it you can't do anything about improving it. Once you can see it, then you can point at other people and other people see it, you know, we start with yourself and the teams. Other things start to flow from then you start thinking about how do I begin to improve those practice, you know, the, the, you know, the work itself, not in terms of laying down rigid processes, but I think attacking bits and pieces of practice. I think the core pieces that kind of working papers notion regenerated in a digital form. How much of this? I saw most head going like that [nodding up and down]. I didn't see too many doing that [nodding side to side]. I think we're more or less on target. What are some of the key? Where do you, where would you take this next or what's what's missing? What do you like? What what's the answer to that question? Jim McGee 47:50 I don't know if I have it, but let's ask to see what he has. audience 47:51 This is more of a challenge to this proposition. And that is, I mean, I agree with everything you've said. And you'll get a lot of head nodding. The problem I think we find is that this takes time. Jim McGee 48:04 Excellent audience 47:51 This takes more time than just cranking out a Word document, saving it and moving on to the next thing. And I know in my organization, the time is absolutely critical. And you also use several times the term knowledge management system. I don't know if you really meant to use that, because I don't know what that is anymore. And hopefully, there isn't. Right. So one of the things that we try to do is, I mean, for example, I'm watching an email conversation going on here in my office, and I'm, it's annoying to me that they're doing that. Stop it. Stop it move the stuff to Traction, and they're going to think about are how do I want to tag it and it's going to take a little time, but ultimately, there's going to be much more observable people can find that stuff, right now getting organizations to say, yeah, this might take a little longer, but in the long run, it's going to save us so much time by getting people to think about the long term investment as they spend an extra minute per perhaps what would have been an email or saving a Word document to the C drive versus let's see, if I tag it and I put it out, you know, you're using... That's what that's what I swear we're struggling with now is that is getting people to understand the extra minute can save hours right long run for the organization. Jim McGee 49:19 Chris, you want to leap in on that? Chris Nuzum 49:21 I want to tie a question onto that. Why start here? You're starting on the formal end, and, and I think all sort of expressing my problems a little bit further to the left on the axis. The individual who isn't receiving the benefit of starting? You know, it's just defaulting to email, and not starting out defaulting to ... audience 49:44 Well, you have to you have to change that mental model, right? It's it all comes down to people's mental models it whether they're willing to make the commitment of the extra time or not. Jim McGee 49:53 Yeah, for me, Well, it's true, but I think the reason I picked there is it's the most natural place for people They're most comfortable starting there. And it's the only place I think to gradually move them back up the chain. Right? Ideally, you'd want to start at the other end. And that's where I, you know, I've ended up but I, you know, you start there. This problem of time, is is is, is absolutely of the essence that I think fundamentally, it's probably the biggest task in front of management to do this is to get is A. to get to believe for yourself that it makes a difference to have spent the time so I think, you know, rolling this out in organizations depends on finding the willing participants who will get it first and ignore routing around those who who resist because you don't have time to deal with resistance with everything else that's going on. Jim McGee 50:48 So you pick the pick those people who pick it up fastest and in support the hell out of them. Right. And, and then you have to begin to approach you can't it's hard to build metrics. You have to build stories. Around, you know, look how I was able to create the next deliverable by being able to search through the tags and find that right or how I avoided a dead end because I had the context for this, and I didn't go off and you bring in somebody new to a project, and they go, Well, why don't you wait, we should do. Right. And you know, if you don't catch them, they're like three weeks down that path when you would abandon that path two years ago, because you realize that week four of that path, you know, you crash and burn. And so they've just wasted three weeks. So it's, you're absolutely right. That's the heart of the challenge. Jim McGee 51:34 And it's, you know, the management task is to provide the sort of air cover and support and to use it, cut it out, I'm not going to, I'm not going to do that. It's to say, I'm not going to answer emails, right. I you know, I won't answer queries if they're not in the you know, in the space. Right, and people are going to be annoyed with you and then someone three levels up is going to get really annoyed. right because something that something that will step on some pet project, you know, and then you know, then you decide whether, you know, what's more, you know, how badly you want to push it right now, or whether you need to back off, and those are all kind of management judgment tasks that happened there. But I think, you know, that's, that's right at the heart of it, that by the way, those issues is what drove me back into organizational design in a way from technology because that those were the, you know, how do you manage change? Jim McGee 52:24 How do you and it's, it's not about it's not about training sessions. It's not it's about working, essentially one knowledge worker at a time and doing it but picking those knowledge workers who are going to kind of expand the network out from there, you know, the ones who are right correctly placed in the networks and they're, you know, it's going to spread. Jack Vinson is a blogger because he used to comment on my blog, and I got tired of, you know, him writing, you know, paragraph long comments to my two line blogs. I said, made me kind of look stupid. I said "Jack start your own blog!". Right. So, you know, you plant seeds, and that's, you know, but it's so but it's also the other time issues. It's it's a much longer process. The deployment isn't about getting the software up and running. Right now project management challenges, we all think of the software's running. We're done. Jim McGee 53:20 Right, no software's running we've just begun. Jim McGee 53:24 And we need to play ball audience 53:26 Well, but you describe the critical role that, you know, is like unrecognizable is sort of that mentoring, right. And, and the gardening and the whole, you know, the people talk about social, as if social is just something that happens, and then there's none of this sort of caring and mothering that goes on. Jim McGee 53:51 Yeah, I'm working with a colleague and doing some some things in this area. And one of the one of the pieces that we've been pushing heavily on that is the notion of pairing people up, that that all of these social environments are fundamentally built on pairs. That's the relationship between two individuals that you have to invent. You have to I have to invest in a relationship with you, and you have to invest in one with me. And that's where that's the fundamental building block. And so we, you know, we were in, for example, in the profiles, we're using this system, where we're asking different kinds of questions for people to put in their profile in terms of, you know, what kinds of things can you help people with? We're encouraging people to go seek out other people and find ways to help them. So I think we're -- Are we out of time? Greg Lloyd 54:35 No, no. Okay. audience 54:38 First, I want to say everything here is great, and I really get it. My problem is Jim McGee 54:44 I was hoping to piss a few people off. Jim McGee 54:47 Get some arguments. They're probably in the air here. audience 54:50 It'll happen when I go back. This is where the crux of my question is, is, you know, I work for a manufacturing company. So they totally see the benefits of the 20th century approach to standard work. And they want to push that through the knowledge work side of the house and and so that's gonna fight with any attempts I do to start here at some point. audience 55:17 So how do I get them to see this message? Jim McGee 55:21 Well, you know, for me what what one of the issues is, is the notion of the value in a piece of knowledge work is in its uniqueness. It's not right, you know, if, if, if, if I'm doing a software development project, right, the project plan for the last project is probably not terribly helpful for this project. In broad outline, and maybe but the real crux between success or failure in the project is identifying for this project, what are the particular critical issues, and I think you can have that kind of discussion, Do you want the same you know, you want the report, here's the report I gave you last time, here it is. You satisfied? audience 56:01 Our customers don't want that. Jim McGee 56:02 Well, okay? Your customers don't want it, so why should you? Why did you know? Why should we know your customers want handholding? Anyone, TLC. So it's a slow. The biggest challenge in all this is that none of this is quick. Right now, the flip side, it also does not require hundreds of people running around the organization to push it. It requires handfuls, you know, it's a highly leveraged, you know, kind of work. It's finding the individuals, it's, you know, it's a leadership challenge. And the question is, you know, do To what extent if at all, how do you supplement you know, with your, you know, your your teams, and, you know, kind of enlist the right participants to move it ahead. It's not about picking up the phone and bringing in 100 resources who can just push it over the the goal line. audience 56:33 That's great for those early adopters. How do you overcome the organization disincentives that exist, as well as the lack of incentives for the later adopters to actually pick up over. Jim McGee 57:09 Well, my I guess my my, my underlying assumption is that untested, but at least reasonable is that the early adopters will be ultimately be more productive and more effective. And people mimic those who are effective. And so the late the laggards will will learn by mimicking what's working and you know, at some point, it becomes the default way of work in the organization. And then the questions, really and then I guess the next question is, do you need 100% in engagement for you to declare victory? I don't know. It's an open question. Do you need everybody participating or not? Jim McGee 57:50 Or just or just the right ones? Jim McGee 57:54 You know, I I do make a point here. I talked about knowledge work, not knowledge workers, because I think we're that was one of the mistakes I think Drucker made was focusing on knowledge workers, not the work itself. Because if you start looking everybody in organizations from the janitor on has elements in their work, that's knowledge work, instead of trying differentiate some people as being better than others by the knowledge workers. One last question, right? Greg Lloyd 58:19 Maybe two, audience 58:20 Increasing adoption, or how do you convince people to do this? Well, everybody has to keep their stuff. So everybody has to, you know, I need to put my files somewhere. If you can make it happen and observable the way, my my theory that I'm sort of testing in the real world is, once enough people do that it kind of creates a center of gravity that pulls other stuff in and that just becomes the place that work is done. So that by default, they happen to be doing something that they think they own for themselves, and they can, they're the author and they own it. It also happens to be a place that other people can see and comment on. Jim McGee 59:01 Yeah, I think trying to create paths of least resistance is kind of the way I think about this as sort of making things, the default easy thing to do. Last question. audience 59:09 But continuing on what Brian just said, I think, is it a reasonable hypothesis that there's always going to be a bottom sort of approach versus a top down approach? And, and if there's a tipping point where it does become a top down, and if it's a bottoms up approach, in my mind, it's going to take years and years to get there. Jim McGee 59:27 I think it's, in a sense, it's not top or bottoms up. It's a network approach. So you can pick anybody in the network who wants to start behaving this way, whether they're at the top or the bottom, and they can begin to you get pockets of activity, you know, good. You can get project teams, I know you've done that we brought you on, and then that starts to, you know, propagate. So it, what I think will happen is too soon to know for sure what I think will happen is like a lot of network effects, it'll start slowing and it's like sort of the doubling sort of problem that you know, nothing looks like it's happening and then all of a sudden it's everywhere. I think it's going to be more that it changes in the management tasks. Jim McGee 1:00:04 Greg sort of calling time on this and I know we've got, Chris is gonna tell you about how TeamPage next release is going to make this all easy. Just magically happen and you won't need to do any effort to. Greg Lloyd 1:00:17 I would also remind people that we're going to have an entire observable workshop tomorrow morning, at nine o'clock until noon. We don't have fixed speakers. We don't have a fixed agenda. I ask you to basically look over what's being logged here. Look at some of the questions and comments, the things you want to follow up on. And that will be very helpful for tomorrow morning. Jim McGee 1:00:37 And, you know, I'm gonna be here through that as well for my own selfish reasons. Jim McGee 1:00:44 Thank you. Thank you. [applause] Transcribed by https://otter.ai