Respect for people is a key concept mentioned in much of the Toyota Production System / Lean literature. Variations of it are mentioned in many related disciplines, like Theory of Constraints where I spend a lot of my time. What this phrase tries to describe is that the people who work in the system know a great deal about the system.
Just like "culture," this one is hard to describe by itself. Maybe the actions and behaviors help. (This may be a reason why people think it is "touchy feely.") Showing respect is asking people to participate in the creation of a solution. It's being honest enough to say that I don't know everything. Showing respect can also be challenging people to think differently, or to lead them on a path to learn something new. It's about giving them the space to actually learn. It's about drawing people in.
If we simply tell them what to do - or we ask for their opinion because we are supposed to and then disregard it - this is NOT showing respect.
I came across a video clip recently where someone claims that a bad demeanor or gruff interpersonal style is antithetical to the concept of "respect for people." I think there is a HUGE difference between a personal style and whether that style encourages people to learn and participate. Taiichi Ohno and Eli Goldratt amongst others have been known for their gruff and "difficult" interactions with people. My observations of Goldratt, after getting over the invective, has always been that he pushed people to think. Sure he would get frustrated when it appeared that they were being lazy, but I don't think this shows a lack of respect or a belief that people are stupid.
Come to think about it, what about Steve Jobs. He was classically monomaniacal. Was he showing disrespect for people? Or was he pushing them to their limits? I suppose it depends a bit on whether you were the subject of the diatribe.
Believing in the inherent value and quality of people comes out in how you challenge them and what you expect of them. It has much less to do with your direct personal style.
And p.s. You don't have to be gruff to be an effective leader, either. That's all in the style.
The Manager Tools podcast often has interesting food for thought for managers. It looks like they are going to do a series on "the collaborative manager," and they have started out with Chapter 1 on the topic on how to encourage more collaboration in meetings.
As with many people who observe the idea of "collaboration," they complain that the term is somewhat meaningless on its own. People have many ideas about what collaboration is - just like we have many ideas about what a good "culture" is. But without some expectations for results from collaboration, it doesn't help much.
As a result, their podcast talks about some direct actions people (managers in this case) need to take to get the desired effect of collaboration - this time in the context of meetings. Let people know you are going to be asking for more input - don't just spring it on them at your next meeting. Be specific in the type of input you will be seeking - just asking for "ideas" often gets unclear results. People develop their ideas in different ways - giving them advance warning allows those who prefer the slow boil to frame their ideas in a way that they are more comfortable sharing them with the group. They also suggest talking to some participants directly about the need for their input. This serves to both coaching people in how to perform (not everyone knows), as well as giving those who might be more reluctant specific direction.
In short, the podcast talks about helping your meetings be more collaborative by helping the people coming to the meeting be prepared. Novel, huh?
Oh, and how do they define collaboration? In this context of meetings, it is asking for, listening to, and incorporating other people's ideas. Fairly simple - now wonder they say, "We've just killed the buzzword of collaboration" in their closing.
Ihab Sarieddine has a nice overview of CCPM in his blog on project management, Improving Scheduling Using Critical Chain Project Management (CCPM).
He refers back to Goldratt's original book on the topic, Critical Chain, and gives slightly different definitions of some of the classic reasons projects run short even with plenty of buffer in task estimates: Parkinson's Law, Student's Syndrome, Dropped Baton, Self-protection, Excessive multitasking, and Resource Bottlenecks. (I assume these come from the book, but if not, I like them anyway.)
The article is entitled "improving scheduling" with CCPM. While this is true - scheduling often does improve when I do CCPM projects - CCPM is also a great execution management mechanism with the buffers and fever charts (buffer consumption vs chain completion) giving a means for prioritization and focus to everyone. This gives people early warnings if things are going pear-shaped - and a way to focus on what will bring it back into control.
I've had the Stop Starting, Start Finishing brochure / comic from Arne Rock and his team sitting in my briefcase ever since the Lean Kanban conference last spring. "I'll read this on a flight," I thought.
It's a fast read, so I don't know what I was waiting for. It's an entertaining introduction to a sequence of steps that Justin (as in Justin Time) takes to a team, as he introduces Kanban. The sequence is pretty familiar: make the work visible (because knowledge work doesn't show itself naturally); limit work in process; find what blocks flow; and continue looking for ways to finish more work. The brochure also suggests that Kanban principles apply at the portfolio level - something I have done successfully. Kanban is all about evolutionary change, after all.
Beyond the basics of Kanban, what I saw in this brochure was that, while the details are missing, it can be an effective way of articulating some of the why and what of an implementation like this.
Several articles came across my eyes around the topic of personal productivity, particularly in connection to practices around email. One comes from today's Boston Globe, another from early January in Slate, and the final one from David Allen. It's all around helping people pay attention to the important things. Focus.
Saturday's Boston Globe has a piece by Michael Morisy on the (slow) decline of email, E-mail gets the cold shoulder. While the tone is somewhat "everyone is using Twitter and Facebook," the content suggests a broader trend. Essentially, people are expanding their use of technology to connect with others beyond strictly email. There are people and some businesses who are shifting away from putting email in the driver's seat. Let's just hope they aren't simply replacing the distraction of email with these other tools. The tools are there to serve us, not the other way around. And, as any good piece on the topic has to do these days, Morisy mentions Luis Suarez efforts at a World Without Email.
My challenge with all the other platforms mentioned (Twitter, Facebook, LinkedIn, internal exchanges) is that they are semi-walled gardens and subject to the whims of the owners. If I don't have an account on the internal messaging system the best form of exchange is usually limited to email (I am a consultant, so I see). Facebook and LinkedIn require that we be explicitly connected before we can communicate (LinkedIn just sends emails anyway).
Moving to the more personal effectiveness side of this equation, someone mentioned Farhad Manjoo's Slate piece on My Technology New Year's Resolutions that starts with the surprise statement of "Stop chasing Inbox Zero". While I would probably be bothered by the look of his inbox, here is his key statement:
But here’s the key detail: I don’t let the tardiness bother me. So I’m not good with email; so what? As long as you’re attending to your work and your life, your email habits aren’t ruining you.
That is the point of Inbox Zero anyway. Don't let email run your life. Come up with a system that is going to work for you and doesn't cause excessive angst or grief. Manjoo's strategy is one way to go about it. Funny enough, when I check the Inbox Zero website (who knew?), the minimalist page says something very similar.
It’s about how to reclaim your email, your attention, and your life.
That “zero?” It’s not how many messages are in your inbox–it’s how much of your own brain is in that inbox. Especially when you don’t want it to be. That’s it.
It's about how much of an attention drag your inbox (email, Twitter, paper, …) is. If you open email and all those messages make you cringe? That it is a mental drag and something needs to change. If you open your inbox and know exactly what you need to do for the time you've allotted? Then you are doing just fine.
And this leads to one of the gurus of personal productivity, David Allen of Getting Things Done fame. His recent Productive Living message (sent via email!) talks about "curing interruptitis" and why we get so frustrated with interruptions. My read of his comments is that interruptions are so frustrating because we don't know when something is going to really be important and deserve to interrupt what we're doing now. We haven't taken the time to figure out what is important when, so anything that shows up could be important. And you need a process in place to easily pause and return to things when you are interrupted.
All this suggests to me the idea of intentionality: be thoughtful in what you are doing and why you are doing it. Email (and Twitter and Facebook and ...) can become time sinks because there is so much potential stuff there, but these can also be a useful tools to learn new things and execute your work.
[Photo: "Close focus Wage" by revlimit]
This poor blog has been neglected all month, and now I pick a day to write when very few people are going to be around to read it... Oh well, at least I have something to say.
I had been wanting to read Bob Sproull & Bruce Nelson's Epiphanized: Integrating Theory of Constraints, Lean and Six Sigma since it came out last winter. I finally got around to it. The story grabbed me, as many business novels do, and I finished it over the course of several evenings while I was on the road. (On the road with a TOC consulting client.)
The basic story is fairly familiar: struggling company, introduce TOC, company turns around. Oh, and of course there is a TOC guru who helps the protagonists think through the changes they need to make. The storyline expands in line with the title as successive people get "epiphanized" to the ideas of Theory of Constraints. The protagonists go from a small cabal of TOC enthusiasts to bringing in their corporate leadership, then to their suppliers, and even to their customers.
The style of writing was sometimes distracting. And some of the plot elements were painful to read. (The women are all "beautiful tonight," even if they are intelligent.) But the strange thing was that the overall line of the story was engaging. I realized at a key crisis point in the story that my heart was racing to discover what was going to happen to the main characters.
The subtitle talks about integrating TOC with Lean and Six Sigma, but there is very little about Lean and Six Sigma other than some buzzwords and familiar corporate positions. There are a lot of assumptions about what people know and do that aren't given enough meat for my tastes. The book is also a long advertising piece for Eli Goldratt's classic business novel, The Goal. So much so that I think I need to re-read it again.
All that said, the book gave me some interesting food for thought. In particular, since I am working on yet another TOC-related project, I gauged what the story proposed against what is happening in this new project. I liked how he used some of the TOC tools, such as the Intermediate Objective Map. And I am curious about the new-to-me idea of the Interference Diagram which is a way to outline what factors and policies are getting in the way of a stated goal.
One point that was repeated a couple times in the story was the importance of the involvement of the full workforce in these kinds of transformation - this is a point that often isn't fully appreciated in change projects which might engage a small "core team" to make everything happen. And even the membership of the core team is often the wrong people: rather than those who are going to be directly affected by the change, the core team is made of people who manage or coordinate, rather than the people doing the work.
Working with clients on project management, as I do, I see a familiar theme come up over and over again. People have a difficult time separating the creation of an idea from starting to work on that idea.
Why does this matter? It's the classic vicious cycle for projects: Get an idea. Start doing something about it. Realize you are missing some pieces. Go retrieve the missing elements. Start going again. Get stuck again. Start again. Stop. Start. Stop. Start.
And of course, while you are "stuck," you don't just sit there. You pick up one of those other great ideas and start marching along until it gets stuck. And again. And again.
Before too long, you have ten projects running and none of them are making progress. This applies whether we are talking about personal projects or projects that require coordination amongst many people and organizations.
Try things another way. Step back and put together a plan of attack. Do you know what success looks like for this project? What is the overall sequence of work? (I like to work backwards from the goal of the project.) What might cause the project to get stuck (and can you do anything to prevent that)? Do you have the people, money, resources available to do this?
Once you've thought through elements like this, pause. Decide when you want to activate this project. Maybe it doesn't make sense to start now because of the answers to those questions. Maybe there are just too many other things going on right now and this new project will throw current projects into chaos. If you must start now, consider what current activities should be shelved to create the space for this new one.
[Photo: "Pause - השהיה" by Eran Finkle]
Problem Solving Knowledge Transfer: An Expert's Perspective by DeAnna Myers is a Capstone research report from Northwestern's Master in Learning and Organizational Change (where I was on faculty for a few years). Abstract:
Engineering firms in the power generation industry, like many knowledge organizations, commonly attempt to sustain their intellectual capital by utilizing in-house experts to train novice staff, but an expert’s ability to predict what is necessary to transfer knowledge to novice learners can be compromised by biases associated with an expert’s superior level of expertise (Hinds, 1999). This study surveyed how one organization’s experts perceive the task of novice-level knowledge transfer, and compared these perceptions to feedback from novices who participated in their classes. Findings from the study suggest that experts misdiagnose novice learning needs and though they usually attempt to adjust content to accommodate the novice learner, those adjustments are less successful than the experts perceive.
There are some classic knowledge transfer / knowledge sharing aspects mentioned in this study. The report looks at the expert's approach to knowledge transfer within an organization. I see similar things happening when outside experts come in as well, but then there is another layer of cultural concerns, such as "not invented here."
I could imagine a parallel study that looks at the novice's ability to "know what she doesn't know" and know how to ask questions. There are, of course, many pieces to this puzzle, but it is always good to see people thinking about it.
I still exist. Just buried in a new project and a very interesting course...
I've been taking Howard Rheingold's course Toward a Literacy of Cooperation, and this past week's readings and conversation were on the topic of social dilemmas, best described by The Prisoners' Dilemma and similar multi-party games.
One exercise was for us to play some Prisoners' Dilemma games available on the net and describe what we thought. The games were
- Game Theory.net - Lets you play five different styles of computer player.
- Serendip from Bryn Mawr - Pits you against Serendip to see who can come out on top.
- The Iterated Prisoners Dilemma - a simulation that does all the work for you against many different strategies.
It was strange, going into the games with the knowledge of the basic strategies (tit-for-tat, etc) because I automatically went for the strategies that the research suggested were generally the better strategies. So, I started generous and usually stayed generous the entire time. Even when I intentionally started with "defect," I quickly switched to cooperate because I felt guilty - and it was only playing with/against a computer program who didn't care at all. However, when the computer started playing "dirty" and obviously not following my lead, I went to the other extreme and went for "defect" all the way. Unfortunately, when the computer didn't play nice, I generally lost much more than I won. The computer beat me in those situations.
I also want to mention that I started to watch the video The strangest split or steal ever. I am obviously not the target market for a show like that because once I understood the setup, I could not stand the rediculous tension-building blather from the host. I ended up turning it off halfway through and I am not terribly curious about the strangeness of it.
Matthew E May has How Intelligent Constraints Drive Creativity at HBR blogs. It's a topic I've come across before - particularly because of the constraint in the title.
An intelligent obstacle or constraint is one laden with creative tension, whether stated in the form of a well-defined problem ("How might we simultaneously decrease both inventory and backorders?") or a challenging goal (NASA's 1990s mission to land a rover on Mars in half the time and a tenth the budget of the previous mission). An intelligent constraint informs creative action by outlining the "sandbox" within which people can play and guides that action not just by pointing out what to pursue but perhaps more importantly what to ignore.
This time the article was forwarded by a friend with whom I'd just been discussing the ideas behind Theory of Constraints. The focus of TOC is productivity and getting results for the organization, not creativity directly. However, think there are parallels between the worlds. If you know and acknowledge where your constraints are you then get to expend your energy on doing as much as you can in light of the constraint. The TOC mindset is that as long as the constraint "makes sense" and cannot be removed easily that the rest of the work has to be focused on dealing with the fact of the constraint. The opposite is the situation where the constraint is hidden or unknown, so improvement efforts go about doing all sorts of things and do not necessarily provide the greatest benefit to improving flow - flow of results.
The Process Excellence Network has a post by Chris Gardner on best practices, When do you know a practice is truly "best"? The usual warriness of "best practice" discussion applies, but the author does a nice job of reminding people that there is really no superlative:
Finally, there is no practice that is best for all organizations or in every situation. In addition, no practice remains "best" forever, as business practitioners constantly find better ways of doing things. Benchmarking helps bring context to a set of conditions (e.g., demographic, environmental, cultural) that are best for a given practice.
Practices are what they are. If they produce the results that you want, they are good enough for now. The important thing to watch for is when your results start falling off (either because output drops or the market expects more or your competition does more). Having benchmarks, as discussed in the article isn't a bad thing. You just need to remember why they are there - they are proxy measures and indicators, rather than the core indicator of results.
Project management and knowledge management are about getting things done. I attended and spoke at the Center for Business Information (CBI) 6th Annual Forum on Knowledge Management this week in Philadelphia. Rather than talk about knowledge management directly, I opted to speak about managing projects - whether they are KM or other types. If you are curious, here is the mind map that I used to structure my talk (full map for the very curious).
I spent most of the time speaking about the challenges people have in project management and some of the underlying causes. I reflected back on the vicious cycle of how organizations operate (one version here) that almost guarantees projects will be late. And then, of course, talked about some options on changing the way we operate. Those are:
- Encourage focus (no multitasking)
- limit how much work is active
- full kit - don't start the work without having everything you need to do the work
- Discourage local rules
- keeping people busy makes for too much multitasking
- finishing tasks "on time" doesn't ensure project success
- Create a mechanism for priority
Of course, Critical Chain Project Management is a great solution, and I have had great successes with this approach. CCPM does this by ensuring the planned project doesn't reinforce the idea of multitasking (critical chain = the longest chain of resource dependent activities). And CCPM pulls safety out of individual tasks and puts it where it belongs: the project, where it can be monitored and used to help determine priority and attention required of the project.
But what if you don't have the authority to change project management in your company? There are some great ideas out there for personal effectiveness and "time management" that strive for the same goals about multitasking and getting stuff done. I mentioned the idea of Kanban boards and related mechanism. The key behind them is that they help small groups and individuals separate the "things I should do" from the "things I'm doing now." Separate the great ideas from what you have decided to do. And keep the number of active items to a minimum, so that they get to DONE quickly.
For reference, here are some starting points on what to read next. On the CCPM side of things:
- Billion Dollar Solution, Rob Newbold (my review)
- Simplifying Innovation, Michael Dalton (my review)
- Be Fast or Be Gone, Andreas Scherer (my review)
- Lean Project Leadership, Lawrence Leach (my review)
And on the Kanban / Personal Effectiveness side of things:
- Kanban, David Anderson (my review)
- Personal Kanban, Jim Benson & Tonianne DeMaria Barry
- Getting Things Done, David Allen
The conference was intimate. And the interactions superb, as usual. Thanks to CBI for inviting me. (And to Kate Pugh for the suggestion.)