Multi-tasking, Learning and Phone Conferences

My company is getting more distributed. Workers on a project (problem) located at opposite ends of the country and even overseas. For that reason, we are having increasingly frequent phone conferences. They're great for touching base frequently without having to hop on a plane but I have some doubts about how effective these meetings really are.

My earlier post about multi-tasking cites evidence that multi-tasking is a misnomer and yet these phone conferences are a invitation to do so. One ear on the phone, sending an e-mail and perhaps even in IM or working on a document is probably pretty standard behavior for participants in a phone conference. Frequently someone is asked a question and their response is "Pardon, please repeat the question." Their attention was elsewhere.

In the chapter 9 of his book Brain Rules, John Medina reviews studies which show that optimal learning is when multiple senses are involved . In phone conferences, we only have one of our senses involved. When you're in a meeting, you're learning, unless of course you are doing all the talking. You're learning what others know, what you have to work on, what they're working on.

The phone conference is a less than ideal learning situation. I wonder if there are any studies on the efficiency of face-to-face meetings versus phone only and phone and visuals. I wonder where the break-even point is for the travel costs versus the wasted time in the meetings.

Some suggestions for your next phone conference.

• Send an agenda out beforehand so everyone is prepared to learn about the topics.
• Use some sort of desktop sharing program so everyone is seeing the same information.
• Send out minutes along with any visuals after the meeting is over so everyone can review the outcomes. (Another chance to learn what was discussed).
  
• If you're a participant. Pay attention. It may seem like you're more productive when sending IMs, EMs, but every time you ask for something to be repeated you're wasting x number of other people's time.

Modern technology has made many things more efficient, but our brains are still "primitive". We learn best by incorporating multiple senses and reviewing the information multiple times.

Being Good Enough

This month, Wired magazine has an article about products that are good enough to do the job but not great. The point of the article is that this is how these products can creep up on the leaders in the field until eventually the are capable of surpassing them.

The same applies to problem solutions. Often we are perfectionists, trying to anticipate every possible angle before implementing the solution. Sometimes this can delay implementation of a solution and result in lost opportunities. Often (except when safety is involved) getting a partial solution in place quickly is more important than addressing all the issues beforehand. You can then evaluate what the weaknesses are under operation and utilize an iterative process to optimize the system. Your supporting structures (management of change, document creation, document control, etc.) need to be efficient enough so that they aren't a drag on the process.

If your support functions are more taxing to complete than the solution itself then something is wrong. Often Quality organizations become enamored with lots of checks and balances and the whole process gets bogged down. Often these people aren't users of the process but only enforcers. If you start thinking to yourself that you know how to do something but don't want to cut through all the red tape to get it implemented, then something is seriously wrong. Both because good ideas may not get implemented and because people are tempted to take shortcuts without submitting the ideas to the proper review process. This can lead to unintended consequences.

Even our best laid plans can go awry. One needs to balance the desire for a "right the first time" solution with the inevitable refining process that occurs anytime you try something new. Continuous improvement works best when it is continuous. If it proceeds in fits and starts, then often it won't re-start.

Distractions

Over time, the communications and information streams that we are exposed to have gotten more and more complex. This interferes with problem solving. Here is some recent research by a group at Stanford which demonstrates that multi-taskers are actually less capable multi-taskers than those who don't multi-task.

I've read about people who have figured out through data visualization techniques when most of their e-mails arrive. They then set aside a few times each day when the address e-mails. I only get 10s of e-mails a day. I can't imagine someone who may receive hundreds. They must develop an efficient system to wade through this smog.

If you cannot focus on the problem seriously, you will have trouble finding effective solutions. While there may be a time to get exposed to new ideas, and stimulate your creative problem solving, it is not in the midst of a problem.

Thinking Strategies

Garr Reynolds posted a presentation on Thinking like a Designer. His rules apply to problem solvers also. We must always work within constraints but need to balance this with the beginner's mind. Our solutions should be as simple as possible while still being innovative. We need to be able to communicate our ideas effectively, etc.

Check out his blog for many ideas about effective communication.

Measuring Perceptions of Uncertainty

I found the reference I mentioned in my previous post. It is Figure 18 in Chapter 12 of Psychology of Intelligence Analysis

The table shows the probability assigned by various reader to statements containing verbal expressions of uncertainty. For some terms, such as 'highly likely' or 'probably' the probability assigned by various users spanned a range as high as 50%. Clearly using verbal descriptions of probability is probably :-) a bad a idea!

Nicolas Bissantz beat me to this topic by at least 1 week in his posting. Speechless not numberless He gives examples from the financial and medical area.

Quantifying Uncertainty

Scientists and engineers are familiar with quantifying uncertainty in situations where we have data and measurements available. If we know the measurement standard deviation and the number of measurements we made, we can calculate a confidence interval in which the true answer lies.

Things are more complicated when we are asked to make a judgment call. For example, what if you are asked when you will get a report finished. You might answer, "probably tomorrow". The problem with this is that "probably" can mean something quite different to different people. "Probably" to you might mean "maybe" to another. Some will use the word "unlikely" instead of "might" or "might not".

Although it will seem uncomfortable, try to put some sort of odds on your judgment calls. If you answer, "there's a 90% chance I'll be finished tomorrow" it's a lot less ambiguous than "I'll probably be finished tomorrow". Even though the odds might only be 70% or 80%, they're certainly not 20% or even 50%. Attempting to apply some sort of numerical as opposed to verbal uncertainty will make your communication clearer.

Somewhere I've come across a study of what various verbal uncertainty terms meant to different people. I'll try to find it again and post it here.