Every few months one or more of my blogger friends writes about some new research about the effects of multitasking. Multitasking, the research invariably says, doesn’t finish the work any faster. In fact, multitasking usually makes work take longer.

I don’t think we need more research about the ill effects of multitasking. It doesn’t surprise anyone to learn that multitasking is at best ineffective and at worst dysfunctional. Everybody knows it already. I think everybody has known it all along.

If everybody already knows that multitasking slows the work, and if study after study merely confirms what everybody already knows, why do people keep multitasking?

Suppose I’m working on six different tasks that I’ve committed to six different people. If I want to complete all of the tasks as soon as possible, I will prioritize them and do them one at a time in priority order. Then I can tell Andy, whose task I’m working on first, that I’ll finish his task today. And I’ll finish it today. Andy will be very happy.

But what will I tell Bonnie, whose task I have given second priority? I’ll have to tell her that I haven’t made progress on her task yet. I’ll have to tell her that I won’t even start her task until tomorrow. Bonnie won’t like that. And I won’t like that Bonnie won’t like that.

And what about Francis, whose task I have prioritized sixth and won’t start until some time next week? Francis will be very unhappy. Francis will be furious. And Francis knows ways to make me very unhappy. This will not do.

So what’s a harried worker to do? Multitask! If I split my time among all six tasks, I get to tell all six people every day that I’m making progress on their important tasks. And I get to be sincere about that. And I get to avoid Bonnie’s unhappiness and Francis’s fury. Never mind that nobody will be satisfied until late next week. I’ll deal with that next week. For now, multitasking gives me a way to placate all of the people who are making demands of me. Multitasking delays the day of reckoning.

This explains how multitasking can remain so popular even though everybody knows it slows the work. The real purpose of multitasking is not to finish work faster. The real purpose of multitasking is to avoid conflict.

And that’s a tragedy, because multitasking does a lousy job of avoiding conflict. For one thing, our expectation of conflict is probably overblown. People are often more reasonable than we fear, as long as we keep them apprised of our priorities and plans. We reach for multitasking to solve a problem that often doesn’t need solving. For another thing, multitasking doesn’t avoid conflict but at best merely delays it. And by delaying everyone’s satisfaction, multitasking often exacerbates conflict rather than reducing it.

If conflict is the problem, multitasking is a poor solution. A better solution would be twofold. First, improve your skill in negotiating expectations and commitments. This reduces the likelihood of conflict. Second, improve your skill in resolving conflicts. This reduces the cost of the conflicts you can’t avoid. These are both enormous topics. But even a little improvement in these skills pays off far more than the ineffective and dysfunctional practice of multitasking.

The Pecker Principle: The people who care most about the pecking order are usually the biggest peckers.

When I was first learning to delegate, my biggest challenge was letting go of control. After months of struggling, I created a model that helped me to ease my fear of losing control.

The model is based on three key ideas. First, all tasks have common parts. The most obvious part is doing the work to create the intended results. Other parts may be less obvious to new managers, but are inherent in any task. Here are the parts that I see in every task:

• Define the desired result.
• Define how we will know we’re done.
• Define how we will achieve the result.
• Define how we will assess progress.
• Do the work.
• Assess progress.
• Determine whether we’re done.

The second key idea is that I don’t have to delegate a whole task. If tasks have parts I can delegate some parts and retain other parts for myself. I can delegate the parts that I feel safe delegating, and retain the parts that trigger my fear of losing control.

And this leads to the third idea. I can improve my delegating bit-by-bit by letting go of just one more part of each task, then one more part, then one more. If I can choose wisely which parts to let go of next, I can steadily, safely, and effectively improve my delegating.

So which parts should I let go of next? To answer that question, I created a model that I call The Ladder of Delegation. I draw a ladder, and on the rungs I list the parts of a task, arranged according to my willingness to delegate them—the parts that I’m most willing to delegate at the bottom, and the parts that I’m most reluctant to delegate at the top. My Ladder of Delegation looks like this:

Here’s how I use The Ladder. When I’m preparing to delegate a task to someone, I notice how far up The Ladder I’m willing to climb. Which rungs am I willing to delegate? At which rung do I hesitate? Then I ask myself, “What would have to change in order for me to be willing to take one more step up The Ladder?” Usually my hesitation is a matter of trust. In order to take another step, in order to delegate the next part of the task, I would need to trust the person to do that part well. There are various ways to build that trust. Once I’ve clarified my hesitation by noticing which step I’m reluctant to take, I can usually see a path toward building trust.

I may be at different rungs of The Ladder with different people. With Dana, I may feel confident delegating up through the fifth rung, determining whether we’ve achieved the result. With Pat, I may be willing to delegate only doing the work itself. And even with a single person, I may be at different rungs for different kinds of tasks.

Build your own Ladder of Delegation and try it. Your ladder may not look like mine. Maybe you would slice tasks into parts differently than I have. Or maybe you would order them differently than I have. Adjust as you see fit. Then use your Ladder to improve your delegating. The key is to notice where on your Ladder you hesitate, to identify what would have to change so that you can take that next step, and to work toward that change.

A few weeks ago, Esther Derby, inspired by a Fast Company article about Whole Foods Market CEO John Mackey, wrote a short article about appreciation.

Esther says, “Some people are uncomfortable expressing appreciation.” I know something about that. When I first learned about Temperature Reading, at Weinberg & Weinberg’s week-long Problem Solving Leadership workshop in 1992, I felt very uncomfortable expressing appreciation. We held several Temperature Readings during the week, and at each I expressed my appreciation to several people for things they had done. Each time, as I opened my mouth to speak, my throat tightened and my eyes teared up. I was puzzled about that, and I made a mental note to think about what was going on for me in those moments. Why would it be so difficult to express something as wonderful as appreciation?

Over the next several months I experimented with expressing appreciation to people at work. Slowly I noticed what made it hard for me. Whenever I expressed my appreciation, I was reminding myself (unconsciously) that I, too, yearn for appreciation, and that I wasn’t experiencing the appreciation I wanted from others. And I was reminding myself (again unconsciously) that I often left my own appreciation unexpressed.

Once I was aware of my yearning, I found ways to satisfy it. The most important way was to remember to express appreciation for myself. When I began to do that, I found that I was more able to appreciate others, and that I didn’t feel such a strong need for other people to appreciate me. I’m sure that affected the way I related to people, because they began to express their appreciation for me.

In a comment on Esther’s article, Robert Watkins suggests that “This is one of those new age ideas which can be nice in theory, but in practice often just results in fake sincerity.” When I’m facilitating a session of appreciations, I do a few things that encourage sincerity. First, I invite appreciations. I don’t require them. It’s possible that people may feel some internal pressure (”I should …”) to say nice things when others around them are saying nice things to each other. I haven’t noticed a problem with that. Sometimes I see a chain reaction, in which the people who receive appreciation immediately want to offer appreciations of their own. However it happens, the appreciations that people express seem sincere to me.

Second, I encourage the person giving the appreciation to describe specifically what the receiver did, and what need that fulfilled for the giver. The main reason I encourage this is that the specifics make appreciation more meaningful, both to the giver and to the receiver. Sincerity is just a bonus, a nice side effect. It’s hard to be both insincere and specific about what someone has done and what need that has served for you.

In another comment, Jason Yip says, “I’m wondering if it’s useful, if doing it in public is a bit too ‘New Age’, whether it would be appropriate to start out with individuals doing it privately by themselves.”

I think it is wonderful for individuals to start by offering appreciations in private. It’s also wonderful to start in public. Here’s an example.

My friend Joe managed a team of a dozen software developers. He wanted his team, one of the more effective teams in the organization, to become even more cohesive than they already were, and asked me to help with that. One of Joe’s concerns was that the people on the team may not be reviewing each other’s code as often or as eagerly as he would like. We talked more about the situation, and decided that I would facilitate a Temperature Reading for the team.

A Temperature Reading is an activity that gives a team important information about itself and its members. The first phase of a Temperature Reading is appreciations. I offered people an opportunity to express appreciation to their colleagues for things they had done.

The people in the room—hardcore geeks all—had no trouble offering appreciations to each other. They offered dozens. And my impression was that about half of the appreciations were about code reviews. “John, I appreciate that you found that null pointer bug in my code.”

Joe noticed, over the next few weeks, that people were more eager to review each other’s code, and more eager to express appreciation to each other in the moment.

Starting privately is good. Starting publicly is good. When it comes to expressing appreciation, whatever will get you started is the right way to start.

Speaking of getting started, I started to write this article two weeks ago, inspired by Esther’s earlier article. Then I set it aside. Today Esther offers another look at appreciation, this time as a form of recognition. And I was inspired again.

Esther, I appreciate your two articles about appreciation. The first inspired me to remember some of the wonderful things I’ve learned about appreciation, and to start writing this article. The second inspired me to finish what I’d started.

Robert and Jason, I appreciate your expressing your concerns. Your comments to Esther inspired me to write about my experience doing Temperature Readings with technical people, many of whom may share your concerns.

I’m developing two workshops, one about leadership and another about power. These workshops are for software people—developers, managers, executives, and others—and I’d like your input.

First imagine a leadership workshop. In order for the workshop to be exceptionally valuable for you:

• What objectives or needs would the workshop address?
• What kinds of situations would the workshop address?
• What concepts would the workshop cover?

Now imagine a workshop about increasing your power and using it wisely. In order for the workshop to be exceptionally valuable for you:

• What objectives or needs would the workshop address?
• What kinds of situations would the workshop address?
• What concepts would the workshop cover?

Finally, I have two more general questions:

• What other questions should I be asking?
• What else do you want me to know as I develop these workshops?
• Is there anything you want to ask me?

Please let me know what you think, either through comments here or through email. I will be grateful.

As an exercise in clarifying my thoughts, I created definitions for the words lead and leadership:

lead

1. v. To influence people to freely serve a shared purpose.

leadership

1. n. The process of influencing people to freely serve a shared purpose. (The process of leading.)

How well does this definition fit your idea of leadership? What’s your definition?

[Update July 15: Shortened “ongoing process” to “process.” I think the word process implies ongoing.]

From time to time, The Standish Group publishes reports about their CHAOS research, which analyzes the factors that drive success and failure in large IT projects. The first CHAOS Report, published in 1994 and now freely available on the Standish Group’s web site, has become famous in the software industry. The report identifies these failure factors:

1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
4. Lack of Executive Support
5. Technology Incompetence
6. Lack of Resources
7. Unrealistic Expectations
8. Unclear Objectives
9. Unrealistic Time Frames
10. New Technology

I’m astounded that this list omits the single most important failure factor. I call this missing, crucial factor The Prime Project Failure Factor.
So important is The Prime Project Failure Factor that if it isn’t present in your project, you can prevent the project from failing even in the presence of all of the other failure factors.

Imagine this scenario. You have been asked to commit to a proposed project. You notice that you have been given unclear objectives, no user input, requirements that are incomplete and unstable, and unrealistic expectations and timeframes. You have no executive support and few resources. You do have some new technology to use, but the few people assigned to the team are technically incompetent to use even the old technology.

This horrifying proposal exhibits all of the Chaos report’s top ten failure factors. The project is clearly doomed to failure, right? Well, no, not quite. No matter how many failure factors a potential project exhibits, you can still prevent failure by choosing not to do the project.

Seems simple enough, and yet I wonder. Think of a failed project in which you took part. Did you really not know at the outset that the project’s objectives were unclear, or that you didn’t have executive support, or that expectations were unrealistic? Did nobody know these things? And did nobody feel in their bones, right from the word go, that these factors doomed the project to failure?

Many “failed” projects fail from the start by ignoring The Prime Project Failure Factor: Choosing to proceed with a doomed project.

However it turns out, the project to build the Olympic stadium for the 2004 Summer Olympics in Athens will make a great case study for students of project management.

Here are three news stories that give a hint about the status of the project:

• “Greece Starts 100-Day Sprint as Games Loom Large” (Reuters)
• “All Work, No Play 100 Days Before Olympics” (Associated Press via Yahoo)
• “Greece Behind In Summer Games” (60 Minutes, CBS News)

As I scan these stories, I notice these quotes:

“In Greece, we are like ‘Sirtaki’ dance. We start very slowly, and then we speed up. And then at the end, you cannot even follow how quickly it goes. So I believe that’s exactly what happened with us,” says [Athens Mayor Dora] Bakoyanni. “We might be afraid until the last minute, but I believe that we will be ready in time.” (60 Minutes)

“So, granted, there have been delays. And there’s been inefficiency. Call it what you will,” says [former foreign ministry official Alex] Rondos. “The fact is that, as we approach the Olympics, not unlike the condemned man approaching the guillotine, it concentrates the mind wonderfully. And we are there right now.” (60 Minutes)

[Deputy culture minister in charge of the Games, Fani Palli-Petralia:] “We are working triple shifts everywhere and we will be ready.” (Reuters)

Petralia said: “We are turning nightime into day and I am convinced the project will be ready and will be magnificent.” (Reuters)

Those quotes don’t inspire confidence in me. But what does the project’s key customer, the International Olympic Committee (IOC), have to say?

“Our experts who have reviewed these plans say, ‘Yes, it’s feasible. It can be done,’” [IOC overseer Denis] Oswald said. (Associated Press)

“All the reports I receive indicate how fast and how hard Greece is working to complete preparations,” IOC president Jacques Rogge said. (Reuters)

“Feasible” and “working fast and hard” don’t have the ring of high confidence.

All of these quotes, from the IOC and from the project team, seem vague and non-committal. I don’t know whether that’s because the people are saying only vague and non-committal things, or because the reporters are selecting only vague and non-committal quotes, or what. Whatever the reason, these quotes smell funny.

The planned roof on the swimming stadium was scrapped weeks ago. Anyone taking bets on the (as yet uninstalled) glass roof over the main stadium?

(As I write this, news comes from Reuters of a series of three bombs exploding in Athens, near the hotel where Olympic officials will stay during the Games.)

Employment relationships are based on an exchange of value. Jane provides products and services to her employer, Phil, in exchange for money. Phil provides money to Jane in exchange for her products and services. (There may be other values involved, such as an opportunity for Jane to do interesting work, but let’s keep this simple.) The exchange works as long each party values what they receive at least slightly more than what they give.

If one party or the other is not gaining in the exchange, either can choose (among other options) to end the employment. If Jane isn’t satisfied that the money is worth her time and energy, she can leave the company. If Phil isn’t satisfied that Jane’s products and services are worth the money, he can fire Jane. These choices give each party power with the other. Each has control of something the other wants, and the choice of whether to provide or withhold it. As long as the value they provide each other is reasonably similar, each party has similar power in the relationship.

Though Phil and Jane each have equal choice about continuing the employment relationship, there is a factor that swings power in the direction of the employer: aggregation.

Aggregation is one of the fundamental survival strategies of living systems (and non-living systems, too). An aggregate is a system that is made up of a critical number of more or less uniform pieces. A colony of ants is an aggregate made up of more or less uniform ants.

The power of aggregation as a survival strategy comes largely from what Jerry and Dani Weinberg, in their brilliant book
General Principles of Systems Design
, call
The First Law of Aggregates: When it comes to survival, aggregates outlive their worst members. If the weakest ant dies, the colony survives.

Aggregates abound in living systems. A sea turtle lays hundreds (or is it thousands?) of eggs. If only one of her eggs survives to produce offspring of its own, her lineage survives the death of thousands. If none of her eggs survives, thousands of other sea turtles are laying eggs. If enough of their offspring survive, the species continues despite the deaths of millions.

That is the power of aggregation. That power is based in massive redundancy.

Human engineers use the power of aggregation when they build technical systems. The lighting for a football or baseball stadium, for example, consists of a dozen banks of lights, each bank including dozens of bulbs. If one bulb burns out, the light from the bank diminishes slightly. Suppose that instead of banks, a stadium were lit by twelve enormous, high-intensity bulb. The failure of a single bulb would reduce the quality of lighting significantly, perhaps putting the safety of the players at risk. In addition to survival, aggregation helps systems to degrade gracefully rather than catastrophically.

Organizations tap the power of aggregation. Phil has lots of employees in addition to Jane. If Jane decides to leave the company, the performance of Phil’s group will decrease, but not collapse.

Jane, on the other hand, is less likely to have aggregation on her side. Where Phil has lots of employees providing products and services, Jane has a single source of income. If Phil decides to fire Jane, she will lose that single source. Where Phil may suffer a bearable loss of production, Jane suffers a possibly catastrophic loss of income.

Now, Jane may have a few aggregates of her own. She may have three other companies bidding to hire her. She may have a home business on the side. She may have a husband with income. She may have a small fortune in the bank. She may have a large pile of stock options, giving her what Silicon Valley engineers in the dot com boom called “fuck you money.” If she has these things, her income (or wealth) may degrade merely significantly instead of catastrophically.

It is rare for employees to have aggregates that match those of their employers. Aggregation tips the balance of power in favor of employers. Aggregation is the mechanism that creates the imbalance of power between employers and employees.

Here’s a topic that comes up now and again among technical people and their managers: Do managers of technical people need to understand how to do the technical work they are managing?

Until recently, my answer has been: Not necessarily. If the manager can trust the technical people on the team to be able to translate technical information (about plans, progress, problems, and so on) into business information, and vice-versa, the manager can manage well even without personal technical knowledge.

A few weeks ago, management consultant John Levy gave an answer that I like even better. He had finished speaking to the local Software Process Improvement Network about managing technical work. Someone in the audience asked the magic question. “Must technical managers understand the technical work well enough that they can do the work themselves?” John’s answer:

Not necessarily. Managers must understand the technical work well enough that they can appreciate it.

Very nice!

And I’d say that John’s advice applies equally well to non-technical work.