Video: Twitter in Plain English

Once again Lee and Sachi LeFever have produced one of their excellent video introductions to new web technology. This time their topic is twitter. By the way, if you want to follow my updates on twitter, I’m @jmcgee.


This 2.5 minute video is a result of feedback from our fans. We’ve received a number of requests from people who want their
friends to use the micro-blogging service Twitter, but can’t seem to explain it well. We hope this video helps.

If you’d like to follow us on Twitter, we’re @leelefever and
@sachilefever.

Dealing with social in the enterprise

The theme at this year’s FASTForward conference is the “user revolution.” Don Tapscott gave a nod to Time Magazine’s selection of “You” as the person of the year in 2006 as part of his keynote Monday evening. References to Facebook, Flickr, and Wikipedia have been rampant throughout the general sessions and in hallway conversations. The question that remains unasked and, thus, unanswered is “how are things different inside the enterprise.”

One obvious difference is scale. Applications and services on the net have the entire population of net users to draw from. The 1/9/90 heuristic works nicely on the scale of the net as a whole. Inside the enterprise, the rule suggests that implementation efforts need to consciously manage participation and activity to compensate for the smaller population.

The second important difference arises from the need to manage participation within the enterprise rather than capitalize solely on “natural” participants. This collides with the aspects of the enterprise that substitute artificial order for natural order. Large-scale enterprises explicitly design roles and responsibilities to address task requirements in a controlled fashion.

While organizational researchers and designers have been pointing out the limitations of control thinking for much of the last 20-30 years (if not more), the reality in enterprises is that control remains central to enterprise DNA. While insightful folks like Andrew McAfee identify the importance of emergence in the successful uptake of Enterprise 2.0 technologies, I think they tend to downplay the barriers created by the reliance on control. When McAfee talks about the importance of culture in successful Enterprise 2.0 efforts, he is fundamentally talking about enterprises that have managed to move past classical models of control. What makes this such a challenge is the extent to which these models are unarticulated or regarded as axiomatic.

Thinkers you should know – danah boyd

Here’s a 14 minute video interview with danah boyd, who’s been working on a Ph.D. for the past several years at the Berkeley School of Information. She’s focused on understanding social networks and their interplay with youth culture. The video is an excellent introduction to her work. I’ve found her blog, Apophenia, a source of regular insight into the interplay between people and technology. I characterize her as an enthnographer of digital culture.

Discover Magazine video of moi

Last fall, I did an interview for Discover Magazine about my research. I still think that I look strange in video, but I figured others might appreciate it.

Allan Cox on finding your singularity

  Your Inner CEO: Unleash the Executive Within, Cox, Allan

This book is a bit of an unusual hybrid, lying somewhere between a management text and a self-help book. While it’s being marketed as a business book, it’s applicable in a much wider range of settings.

Your Inner CEO is another entry in the long argument that self-knowledge is the core of effective performance. What makes this entry more intriguing, and more valuable than most, is the unique perspective that its author, Allan Cox, brings to the exercise. Allan works as an executive coach and consultant to CEOs, boards, and senior executives of large and small organizations around the world. His advice is rooted in the pragmatic experiences of years of working with demanding and skeptical audiences. 

He describes beginning new assignments with the following statement to his clients:

I’ve found, almost without exception, that by the time executives get married, take on a mortgage, raise kids, cope with the crabgrass, climb the corporate ladder, do their best to manage career pressures, and build their net worth and get into their forties, they’ve lost touch with what they believe in and care about most deeply. (p.20)

He goes on to quote Eric Hoffer:

That which is unique and worthwhile in us makes itself felt only in flashes. If we do not know how to capture and savor those flashes, we are without growth and without exhilaration. (p.20)

Your Inner CEO is Allan’s map for how to find and tap “that which is unique and worthwhile is us.” It’s organized into nine chapters:

  1. Goals
  2. Changes
  3. Facades
  4. Boundaries
  5. Boards
  6. Visions
  7. Futures
  8. Models
  9. Mentors

Each chapter offers a series of stories and recipes for exercises that can help you and your organization do the necessary work of discovery. Allan takes his theoretical lead from the psychology of Alfred Adler, a contemporary of Freud and Jung, who emphasized a more social conception of psychological well being. I don’t know enough to say what the mix is between Adler’s theories and Allan’s distillation of them from his work in business settings. The result, however, is a collection of deceptively simple questions and exercises that can lead to deep reflection.

The core exercise is a quest to articulate what Adler termed “style of life,” an integration of self-image, world view, and central goal. These are drawn out by completing the following three sentences with two to three word answers:

  • I am ____________________________________
  • Life is ___________________________________
  • My central goal is __________________________

While easy to state, digging for honest answers takes work. I’m several weeks into the effort and just now beginning to reach answers that feel meaningful.

In the chapter on Visions, Allan turns this same grounded approach to strategic planning in organizations. Consider the chapter opening quote from Yogi Berra, , “we may be lost, but we’re making good time,” a clue to Allan’s perspective. Allan challenges you to answer “who are we?” and “where are we headed right now?” as a necessary first step in formulating strategies with any hope of success. Dreaming about who we might like to be needs to be grounded in who and what we already are, either as individuals or organizations.

Allan’s approaches square with my own biases. I’d place Your Inner CEO in with Ellen Langer’s Mindfulness and Donald Schon’s The Reflective Practitioner as examples of the power of good conceptual frameworks grounded in rich data from the real world. You need to do the work, but the payoffs will follow.

 

 

ooVoo review courtesy of Scott Hanselman

The wonders of Internet serendipity. Scott Hanselman provides an excellent review of ooVoo, the video chat software that Allan Cox will be using next week. (See my earlier post on that tonight.) My ooVoo name is “jimmcgee”

ooVoo – Multi-person Video Chat comes to Windows

I’m not sure of the relationship between ooVoo and the others, but I can tell you that ooVoo is like Skype PLUS multi-person chat. Wow. It’s fantastic. It’ll do 6 people. I tested it with four as you can see above. The video is better than the audio, but we had folks in 4 states (1 in Hawaii) so I’m not sure everyone had the best connection.

A new thinker to become acquainted with and an invitation for next week

If you’ve got 30 minutes next week and are interested in ways you might become more effective, consider this invitation. It’s a chance to participate in an intimate video conference/chat with Allan Cox. Allan is the author of eight books on management and leadership including his most recent effort, Your Inner CEO: Unleash the Executive Within. I’ll have a review of it here shortly, once I finish my second pass through it.

I’ve had a chance to get to know Allan over the last several months, all courtesy of the interactions enabled by social media. Although Allan and I both live in the Chicago area, we were first introduced by Ross Mayfield of SocialText. (I’m still waiting to meet Ross face-to-face, even though we’ve been interacting virtually for several years.)

Allan is an executive coach who works with senior level executives and boards to make organizations more human places. It’s been a real treat getting to know someone with such grounded insight into people and organizations. This is a chance for you to gain the benefit of his perspective for a little bit of your time. I’m signed up.

So, Let’s Get Together . . .

I d love an opportunity to chat with you. Yes, YOU. Face to face.

I m participating in an event called “My ooVoo Day With…” in which you can sign up to video chat with me. During this time, we can talk about questions you might have about my book, about your career and leadership challenges, or anything you d like. If you don t have a webcam, don t worry you can be audio-only and still take part.

There are only a limited number of seats I m doing 30-minute sessions on Feb. 11, 12, 13 and 14 so sign up now. Head over to www.myoovooday.com to download the software and sign up. I look forward to seeing you online.

All the best,

Allan

So, Let’s Get Together . . .
Allan Cox
Fri, 08 Feb 2008 18:18:00 GMT

Quick mindmapping survey from Chuck Frey

Chuck Frey is running another of his periodic survey of mindmapping tools and features. If you’re a mindmapping fan, let Chuck know what you think.

Mind mapping software: What’s hot, what’s not

Honlogo It’s time to have a little fun. A popular website is HotorNot.com, where visitors get to rate pictures of men and women on a scale of 1-10, corresponding to how “hot” or “not hot” they are. I’ve decided to adapt this idea to mind mapping software, to get a feel for what features and capabilities you think are “hot” and which ones are “not.”

Please click here to participate in this fun survey.

The results will be shared in this blog in a week or two. Have fun!

Tags:

Prusak on Knowledge, Community, and Dunbar’s Number

These are my notes from a talk that Larry Prusak gave at my invitation at the Kellogg School back when I was on the faculty there. (For posterity’s sake, here is a link to the original blog post, although that version is suffering from bitrot. The Magic Number 300: Knowledge and Community)

His reference to the “magic number 300” is what I now recognize as Dunbar’s Number, which most people seem to estimate at closer to 150. The point remains largely the same.

I persuaded Larry Prusak to swing through Evanston last week (February 2002) and talk about knowledge management to students here at Kellogg. Over the course of 90 minutes he shared his perspective on knowledge as part of organizational life.

On a side note, Larry has abandoned Powerpoint. He’s always favored storytelling anyway. It does make the audience have to work harder, but that’s a good thing.

Unit of Analysis

Larry started with an old research design question – what the right unit of analysis. His answer? The group. Not the individual, not the enterprise. While he argued that there are important ideas tied up in the terms “network” and “community of practice,” he’s also concerned that the terms are well down the devolutionary path toward buzzword. “Group” is a nice simple word and you then have to listen to the actual points he makes instead of tuning out.

His research reinforces others in setting 300 people as a “magic number” — about the limit on the number of people you can know by name. He added one tidbit I hadn’t thought of before; that the typical military working unit has also averaged about 300 through history (worth tracking down the evidence for that later).

Social Capital

Given In Good Company, it wasn’t surprising that Larry tied the issue of group size and knowledge to social capital. He sees knowledge largely in terms of trust and of the conditions where reciprocity works. His evidence says that incentives are useless in knowledge management settings. You have to look to the level where people share without explicit incentives.

As Larry put it, “people want to find each other and want to talk.” You can force this into an economic framework, but that 300 number hints that we’re dealing with something pre-economic. “Gift culture” is the technical term for what Larry has tagged as one of the driving forces of knowledge creation and uses in organizations. What’s interesting about that is that it creates a point of tangency with open source software development as a social phenomenon. Eric Raymond’s writings on The Hacker Milieu as Gift Culture is a good entry point. I’ve got an old essay on linking KM and Open Source ideas that I’ll dust off and post as a story.

Defining Knowledge

Here’s Larry’s densely packed definition of knowledge: “embodied, tacit, pattern recognition.” Whew!

Here we tie in directly to the community of practice literature and to the learning processes that take someone from novice to expert. The late Herb Simon estimated that it takes 10-12 years to become an expert in a field. Experts reveal themselves in their ability to see the patterns in a situation that are invisible to a novice. I had a partner who was an expert on call centers. Dave could walk into a call center and tell you in a matter of minutes where the problems were. If you grilled him for a day or so, you might be able to figure out about half of what went into his judgments. This was why expert systems never succeeded.

Promoting Community

If you believe that capturing knowledge is a vain quest, then you need to direct resources toward community. That’s certainly where Larry comes down. While I believe that community is the more important and more malleable element, I’m not quite so quick to dismiss investments in capturing and organizing knowledge.

The keys to encouraging community relate more to providing time an space than providing money. That’s actually trickier, because it’s easier to throw money at problems. Chapter 4 of In Good Company is the place to go for more details.

Knowledge and Learning

Community is a means to the end of learning how to put knowledge into practice. To IBM’s great disappointment, Larry isn’t keen on document management as a path to better knowledge and he’s pretty skeptical about the value of technology tools to nurture communities. I think he finds much of the money poured into formal knowledge management systems wasted. As he put it “asking about the ROI on knowledge management is like asking about the ROI on babies.”

While Larry is no Luddite, some of his technological skepticism is generational. He’s squarely in the middle of Negroponte’s digital homeless. His skepticism is a useful counterbalance to the usual utopian promises of technology advocates. But I take his input more as design constraints than a meaningful argument to avoid technology.

Larry closed with a really great question to use when poking around in an organization trying to get a sense of its attitudes toward knowledge and learning — “can you make a mistake around here?”

Tags: ,

Zen and the scientific method

Espen reminded me of the following passage from Zen and the Art of Motorcycle Maintenance. It is a wonderfully succinct description of the scientific method and its power to protect us from the risks of wishful thinking when problems call for discipline. We used to use this passage as a piece of our basic training for all incoming consultants at Diamond.

 

…this morning I talked about hierarchies of thought–the system. Now I want to talk about methods of finding one’s way through these hierarchies–logic.

Two kinds of logic are used, inductive and deductive. Inductive inferences start with observations of the machine and arrive at general conclusions. For example, if the cycle goes over a bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over a long smooth stretch of road and there is no misfiring, then it goes over a fourth bump and the engine misfires again, you can logically conclude that the misfiring is caused by the bumps. That is induction: reasoning from particular experiences to general truths.

Deductive inferences do the reverse. They start with general knowledge and predict a specific observation. For example, if from reading the hierarchy of facts about the machine, the mechanic knows the horn of the cycle is powered exclusively from the battery, then he can logically infer that if the battery is dead, the horn will not work. That is deduction. Solution of problems too complicated for common sense to solve is achieved by long strings of mixed inductive and deductive inferences that weave back and forth between the observed machine and the mental hierarchy of the machine found in the manuals. The correct program for this interweaving is formalized as scientific method.

Actually I have never seen a cycle-type maintenance problem complex enough to really require full-scale formal scientific method. Repair problems are not that hard. When I think of formal scientific method, an image sometimes comes to mind of an enormous juggernaut. A huge bulldozer–slow, tedious, lumbering, laborious, but invincible. It takes twice as long, five times as long, maybe a dozen times as long as informal mechanic’s techniques, but you know in the end you are going to get it. There is no fault isolation problem in motorcycle maintenance that can stand up to it. When you’ve hit a really tough one, tried everything, racked your brains and nothing works, and you know that Nature this time has really decided to be difficult, you say, “Okay, Nature, that’s the end of the nice guy,” and you crank up the formal scientific method.

For this you keep a lab notebook. Everything gets written down, formally, so you know at all times where you are, where you’ve been, where you’re going and where you want to get. In scientific work and electronics technology this is necessary because otherwise the problems get so complicated you get lost in them and confused and forget what you know and what you don’t know and have to give up. In cycle maintenance, things are not that involved, but when confusion starts, it’s a good idea to hold it down by making everything formal and exact. Sometimes just the act of writing down the problem straightens out your head as to what they really are.

The logical statements written down into the notebook are broken down into six categories: (1) statement of the problem, (2) hypothesis as to the cause of the problem, (3) experiments designed to test each hypothesis, (4) predicted results of the experiments, (5) observed results of the experiments and (6) conclusions from the results of the experiments. This is no different from the formal arrangement of many college and high school lab notebooks. But the purpose here is no longer just busywork. The purpose is precise guidance of thought that will fail if they are not accurate.

The real purpose of the scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There is not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard. That’s the main reason why so much scientific and mechanical information sounds so dull and so cautious. If you get careless or go romanticizing scientific information, giving it a flourish here and there, Nature will soon make a complete fool out of you. It does it often enough anyway even when you don’t give it opportunities. One must be extremely careful and rigidly logical when dealing with Nature: one logical slip and an entire scientific edifice comes tumbling down. One false deduction about the machine and you can get hung up indefinitely.

In Part One of formal scientific method , which is the statement of the problem, the main skill is in stating no more than you positively know. It is much better to enter a statement “Solve Problem: Why doesn’t cycle work?” which sounds dumb, but is correct, than it is to enter a statement “Solve Problem: what is wrong with the electric system?” when you don’t absolutely know the trouble is in the electric system. What you should state is “Solve Problem: What is wrong with the cycle?” and then state as the first entry in Part Two: “Hypothesis Number One: The trouble is in the electrical system.” You think of as many hypothesis as you can, then you design experiments to test them to see which are true and which are false.

This careful approach to the beginning questions keeps you from taking a wrong turn which might cause you weeks of extra work or can even hang you up completely. Scientific questions often have a surface appearance of dumbness for this reason. They are asked in order to prevent dumb mistakes later on.

Part Three, that part of formal scientific method called experimentation, is sometimes thought of by romantics as all of science itself because that’s the only part with much visual surface. They see lots of tubes and bizarre equipment and people running around making discoveries. They do not see the experiment as part of a larger intellectual process and so they often confuse experiments with demonstrations, which look the same. A man conducting a gee-whiz science show with fifty thousand dollars’ worth of Frankenstein equipment is not doing anything scientific if he knows beforehand what the results of his effort are going to be. A motorcycle mechanic, on the other hand, who honks the horn to see if the battery works is informally conducting a true scientific experiment. He is testing a hypothesis by putting the question to Nature. The T.V. scientist who mutters sadly “the experiment is a failure; we have failed to achieve what we had hoped for,” is suffering mainly from a bad script writer. An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question, when the data it produces don’t prove anything one way or another.

Skill at this point consists of using experiments that test only the hypothesis in question, nothing less, nothing more. If the horn honks, and the mechanic concludes the whole electrical system is working, he is in deep trouble. He has reached an illogical conclusion. The honking horn only tells him that the battery and horn are working. To design an experiment properly he has to think very rigidly in terms of what directly causes what. This you know from the hierarchy. The horn doesn’t make the cycle go. Neither does the battery, except in a very indirect way. The point at which the electrical system directly causes the engine to fire is at the spark plugs, and if you don’t test here, at the output of the electrical system, you will never really know whether the failure is electrical or not.

To test properly the mechanic removes the plug and lays it against the engine so the base around the plug is electrically grounded, kicks the starter lever and watches the spark-plug gap for a blue spark. If there isn’t any he can conclude one of two things: (A) there is an electrical failure or, (B) his experiment is sloppy. If he is experienced, he will try it a few more times, checking connections, trying every way he can think of to get that plug to fire. Then, if he can’t get it to fire, he finally concludes that A is correct, there is an electrical failure, and the experiment is over. He has proved that his hypothesis is correct.

In the final category, Conclusions, skill comes in stating no more than the experiment has proved. It hasn’t proved that when he fixes the electrical system the motorcycle will start. there may be other things wrong. But he does know that the motorcycle isn’t going to run until the electrical system is working and he sets up the next formal question: “Solve Problem: what is wrong with the electrical system?”

He then sets up hypotheses for these and tests them. By asking the right questions and choosing the right tests and drawing the right conclusions the mechanic works his way down the echelons of the motorcycle hierarchy until he has found the exact specific cause or causes of the engine failure, and then he changes them so that they no longer cause the failure.

An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the mechanic does. Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the greatest part of his work is careful observation and precise thinking. That is why mechanics sometimes seem taciturn and withdrawn when performing tests. They don’t like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all. They are using the experiment as part of a program to expand their hierarchy of knowledge of the faulty motorcycle and compare it to the correct hierarchy in their mind. They are looking at underlying form.

(Chapter 9. pages 107-111 from Pirsig, R. M. (1999). Zen and the art of motorcycle maintenance. 25th Anniversary Edition. Morrow.)

Tags: