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.

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.

I’ve been thinking about a number of “flows” within organizations — the flow of authority, the flow of value, and the flow of communication — and how they interact. I have a few ideas and a lot of questions today. No answers.

The flow of authority is defined by the organization’s formal hierarchy. Authority is the organization’s permission to allocate its resources. People higher in the hierarchy have greater authority. That is, they have permission to allocate more resources.

The flow of value is the circulatory system of the organization. The organization functions by arranging the flow of value within and across its boundaries. Across the organization’s boundaries, products and services flow out to customers; and money flows in. Profits flow out to investors; investment capital flows in. Money flows out to suppliers; materials and tools and services flow in. As long as each flow creates value for each person who participates in the flow, the organization sustains itself.

Within the organization, value flows from group to group. Each group acts as internal investors, customers, and suppliers for others. As long as each flow creates value for each group, the organization thrives.

Here are some questions I’m pondering: How do these flows relate to each other? How do they interact? What are the effects of different ways of relating and interacting? What kinds of interactions lead to a healthy organization? What kinds lead to organizational illness and death?

Communication flows along both kinds of channels. It flows up and down the hierarchy, and it flows through the networks of internal and external investors and customers and suppliers. It flows from one channel to the other, allowing the flow of value and the flow of authority to inform each other.

What happens when communication flows less readily along each path? One kind of blockage is when communication flows more readily within a group, but not across the group’s boundaries to related groups. This is the familiar stovepipe or silo problem.

What other kinds of communication blockage are there? Are there organizations, for example, in which the people in each group communicate readily with their internal customers and suppliers, but not up and down the authority hierarchy? What do those organizations look like?

What other kinds of flow are there? How do they relate to the flows of value, authority, and communication, and to each other? What are the characteristic symptoms of blockage in each flow?

I suspect that thinking about flows can help us identify ways to increase an organization’s health.

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.

I often see project teams, as they define the requirements for the project, use the words “want” and “need” to sort essential requirements from nonessential. The needs are the essential requirements, critical to project success, and the wants are non-essential. If we find out that we can’t satisfy all of the requirements, we’ll jettison some of the wants and focus on the needs.

This simple distinction between wants and needs has the advantage of allowing speedy triage. We gain that speed by trusting the unexamined and risky assumption that needs are more important than wants.

But hold on… The risky assumption that needs are more important than wants? Needs are more important than wants. Aren’t they?

Sort of. Most of the time. Often enough to lull us into believing that “needs versus wants” is a good way to sort requirements.

Labeling requirements simply as wants or needs hides at least as much information as it expresses. Each requirement, whether we call it a need or a want, is a value. Like any value, a requirement gains its importance through a rich web of beliefs and values called a Value Hierarchy. When we quickly label requirements as wants or needs, and quickly sort the requirements under the assumption that needs are obviously more important than wants, we leave unexplored the rich web of beliefs and values that motivates the requirements in the first place. If we act on requirements without testing the underlying beliefs and values, we increase our danger of solving the wrong problem, and of wasting precious time, money, and attention.

What leads us to think of needs as more important than wants? To explain that, I’ll need to describe how I think about wants and needs.

In their noun forms, the words want and value mean the same thing: a condition that we desire. Wants, then, are organized into Value Hierarchies — each want becomes a want precisely because we believe it leads to some other condition that we desire even more. Each want is a means to an end.

I see needs as special kinds of desired conditions — that is, as special kinds of wants. Like other wants, each need is a means to some more important end. What distinguishes needs from other wants is that a need implies necessity, our belief that the means is necessary if we are to achieve the end. If I want to attend a conference in Boston, I need to go to Boston. Given my desire to attend the conference, going to Boston becomes a need.

Not all wants are needs. If I want to go to Boston, I might choose buy an airplane ticket. But I don’t need to buy a plane ticket. I could instead travel to Boston by car or by train. Buying a ticket is a possible means to the end, but not a necessary means. So buying a plane ticket is a want, but not a need.

A need, then, is made up of three elements:

• A deeper value.
• Our belief that satisfying the need will satisfy the deeper value, or contribute to satisfying it.
• Our belief that we can satisfy the deeper value only by satisfying the need.

It’s the third element, the element of necessity, that distinguishes needs from other wants. And it’s that additional element that leads us to consider needs more important than other wants.

So now I’ve shown that needs are more important than wants, right? Well, yes, with important conditions: A need is more important than a want if the value underlying the need is more important than the value underlying the want, and if the beliefs underlying the need are reliable. Those conditions are important. If we lull ourselves into believing that all needs are (obviously) more important than wants, we forget to test the underlying values and beliefs. And sometimes those values and beliefs don’t hold up under scrutiny.

If we’re going to claim that this requirement is more important than that one, we owe it to ourselves to explicitly test the values and beliefs by which we assign the requirements their importance.

What can happen if we choose to leave those beliefs and values tacit? Here’s an example of a time when I focused so much on something I thought I needed that I didn’t bother to ask myself what problem I was solving.

I was writing a conference paper about resistance, and I kept referring to “the person you are asking to change.” I got tired of writing that, and it seemed like an awkward phrase to repeat so often. I tried the word “client,” but that didn’t seem quite right. So I wrote to a group of writer friends, and said, “I need a better word.” They offered lots of ideas, but I wasn’t entirely happy with any of them. (I was happy that nobody suggested the word “target,” a metaphor that I do not want to promote.)

Finally, Jerry Weinberg said, “What’s wrong with ‘person’?”

I tried “person,” and it fit nicely in some places, and awkwardly in others. I was stumped. So I asked myself, “What is wrong with ‘person’? What am I trying to do here? What problem am I trying to solve with a better word?”

As I looked closer at what I was writing, I noticed that the reason I was repeating “the person you are asking to change” so often was that I was trying to avoid the awkward “him or her.” Aha! My real goal was to find words that were both gender-inclusive and graceful. By focusing so intently on my “need” for a better word, I had distracted myself from discovering my real goal, the deeper value. Once I realized that my real goal was to find graceful gender-inclusive terms, I solve the problem easily.

I think you’ll agree that this example is relatively harmless. I wasted a few hours of my time, and perhaps a few hours of my friends’ time. Not a major disaster.

But what if something similar happens on your projects, on your requirements? What if the deeper need behind some “critical” requirement turns out not to be very important after all? What if the requirement will not really satisfy the underlying need? What if there are better ways to satisfy the underlying need? What if you discover these problems only after you spend precious time, money, and attention to implement the requirement?

Don’t let your need to quickly sort requirements distract you from understanding the requirements more fully. Take the time — especially for the requirements that you are sure are “needs” — to test your underlying beliefs and values. What underlying value motivates this requirement? Will implementing this requirement really satisfy the underlying value? What makes us think so? Is this requirement necessary, or might there be simpler, less costly ways to satisfy the underlying need?

Where do values come from? Every value comes from a deeper value. Each value — that is, each condition that we desire — is motivated by our valuing some other condition even more. For example, I want to pick up my telephone because I want to buy a plane ticket to Boston. I want to buy an airplane ticket to Boston because I want to go to Boston. I want to go to Boston because I want to attend First Annual International Symposium on Where Values Come From. I want to attend the symposium because I want to present my ideas about where values come from. I want to present my ideas because… And so on.

Each value links to others, and the links form a Value Chain.
Each link connects a less important value to a more important one. Buying the ticket is more important than picking up the phone. Going to Boston is more important than buying the ticket.

Each value is linked to the next through a cause-and-effect belief, a belief that satisfying this value will partially or wholly satisfy that more important value. I believe that if I pick up the phone, I can buy a ticket, and that if I buy a ticket, I can go to Boston.

Each of our values, then, becomes a value through our belief that it contributes to an even more important value. My desire to buy a ticket comes from my desire to go to Boston combined with my belief that if I buy a ticket I can go. If I didn’t want to go to Boston, or if I didn’t believe that buying a ticket would help me to go to Boston, I wouldn’t want the ticket.

One way to explore a Value Chain is to use the experiments I described in my article about “The Value Question.” Another way is to start with any desire you want to explore, and state it in the form, “I want (this desire) in order to __________.” Then fill in the blank. That tells you the deeper desire that is motivating the first one. Now state that deeper desire in the same form, and fill in the blank. Repeat until…

Hey, wait a minute! If every desire comes from a deeper desire, then a Value Chain goes on forever. Are Value Chains endless? Not quite. As we trace any value through a Value Chain we eventually arrive at a value that we desire in and of itself, and not because it supports a deeper value. Connirae and Tamara Andreas, in their marvelous book
Core Transformation
call these values Core States. Though people use various names for their deepest values, the Andreases have identified five common Core States: Being, Inner Peace, Love, OKness, and Oneness. Every Value Chain leads to a value like one of these Core States. In other words, every value is a value because we believe (in most cases tacitly) that it leads ultimately to a Core State.

I believe each Value Chain continues at least one step beyond a Core State, but in a way that we cannot access consciously. I suspect that there is a single deeper value that motivates all of the Core States: express and sustain the force of life.
And I suspect that the reason that this value is inaccessible to us is that it ultimately serves not us as individuals, but the force of life itself.

We have lots of these Value Chains, because we have many relatively independent values and desires. Right now, I want to post this article on my web site. I also want to read a chapter or two of a book I’ve been reading. I also want to get to sleep within the next few hours. Each of these desires has a Value Chain.

Our many Value Chains interconnect into a web that I call a Value Hierarchy.
Some values lead to more than one deeper value. For example, going to Boston supports my attending the conference, and it also allows me to visit my family and friends in New England. And some values motivate more than one lower-level value. Wanting the attend the conference motivates me to travel to Boston and also to book a hotel room.

Value Chains — values linked through cause-and-effect beliefs to deeper values — are central to my approach to resistance and power. If you want to increase your influence, learn whatever you can about your Value Chains and those of the people around you.

Reference: For more information about Core States, I highly encourage you to read Connirae and Tamara Andreas’s
Core Transformation: Reaching the Wellspring Within
. You may notice that I recommend lots of books. If you read only one of the books I recommend, Core Transformation is the one. This book helped me more profoundly than any other to understand people, especially myself.

Laurent Bossavit’s recent blog entry about stability got me thinking, as his incipient thoughts always do.

What makes stability an issue? Under what conditions would we pay any attention at all to stability? When we care about something that may be threatened by a force acting on it. If we care about a thing, and there are no forces acting to change it, we don’t need to worry about stability. And there’s little point maintaining the stability of something we don’t care about. Stability is an issue only when we care about something that is threatened.

How can we maintain stability? I can think of three general strategies: adapt, isolate, and absorb.

The first strategy is to
adapt the thing you want to stabilize, to modify it so that it now benefits from the forces that previously threatened it. For example, when the United States experienced oil crises in 1973 and 1979, U. S. automobile manufacturers began making smaller, lighter cars with more fuel efficient engines. And when Japanese companies began to export inexpensive, high quality cars to the United States, U. S. manufacturers began to sell foreign-made automobiles under American companies’ brand names.

The second strategy is to
isolate the thing, to separate it from the forces that threaten it. For example, the paint on your car separates the metal from the wind, rain, and salt that can corrode it.

The third strategy is to
absorb the threatening forces, to convert them into a form that is either less harmful or more useful. Then either incorporate the new form or dissipate it. Absorbing is a combination of adapting and isolating. You adapt to the environment so as to better convert or direct the threatening force. And you direct or convert the force so as to separate it from the thing you are trying to stabilize. For example, the shock absorbers and the tires on your car absorb mechanical motion. They convert mechanical motion into heat, a more readily disposable form, then dissipate the heat. For another example, your automobile insurance converts sudden, large expenses that could threaten your financial stability into smaller, more predictable expenses.

Note that each strategy for maintaining stability requires change. In order to keep the important thing stable, we must be willing to change something else, something that is less important. When you buy automobile insurance, you give up something less important, your available funds, in order to maintain something more important, your overall financial stability.

Here’s a question that now intrigues me: How do we decide which strategy or combination of strategies to employ to keep some precious thing stable? Do we adapt to changes when we can, and isolate ourselves only from forces to which we cannot adapt? Or are there some forces that we will try first to isolate ourselves from, and adapt only if isolation fails? What about the nature or value of the thing we’re trying to keep stable? How does that influence our choice of strategy?

One more question: Are there other common strategies for maintaining stability that are not accounted for by adapting, isolating. or absorbing?

If you look at my list of favorite books of 2003, you’ll notice that over the past year I’ve been a student of conversation and relationships. I’ve been especially interested in how we can make our conversations more rewarding for ourselves, for others, and for our relationships.

Crucial Conversations: Tools for Talking When the Stakes are High

by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler helped me to make a big leap in that direction, and that’s why it is my favorite book of 2003.

A few years ago my friend Kay Pentecost, knowing of my deep interest in communication and relationships, recommended Crucial Conversations very highly. I bought the book a few months later, and finally read it in September, 2003. Of the ton of helpful ideas in Crucial Conversations, I found four most helpful: starting with heart, filling the pool of shared meaning, safety, and stories.

Starting with heart means clarifying your purpose in the conversation. Before starting the conversation, ask yourself, What do I really want for myself? What do I really want for others? What do I really want for the relationship? If a conversation becomes difficult, return to your purpose by asking the questions again, and by asking, How would I behave if I really wanted these results?

Filling the pool of shared meaning. The authors define dialogue as the free flow of meaning between two or more people. We each enter a conversation with a personal “pool of meaning”, the combination of our opinions, feelings, theories, and experiences about the topic. “People who are skilled at dialogue,” the authors say, “do their best to make it safe for everyone to add their meaning to the shared pool.”

Safety. What makes safety important? “At the core of every successful conversation lies the free flow of relevant information.” When people feel unsafe in conversation, that flow is blocked. “As people begin to feel unsafe, they start to move down one of two unhealthy paths. They move either to silence (withholding meaning from the pool) or to violence (trying to force meaning in the pool).”

Crucial Conversations offers many ways to test and maintain safety. One key idea is that if we want to maintain safety, we must attend to two “safety conditions.” The first is mutual purpose. We can maintain mutual purpose partly by “starting with heart.” The second safety condition is mutual respect. “In essence, feelings of disrespect often come when we dwell on how others are different from ourselves. We can counteract these feelings by looking for ways we are similar.” The authors say that in many cases, “If you simply realize that your challenge is to make it safer, nine out of ten times you’ll intuitively do something that helps.”

Stories. Like several other books I read in 2003, Crucial Conversations emphasizes the importance of stories in our communications and relationships. “Just after we observe what others do and just before we feel some emotion about it, we tell ourselves a story. That is, we add meaning to the action we observed. To the simple behavior we add motive. Why were they doing that? We also add judgment—is that good or bad?”

This sequence is very similar to Virginia Satir’s Ingredients of an Interaction, the model of communication that I describe in my article “Untangling Communication.” I like the author’s use of the word story here, because it gives me a richer, more dynamic way to talk about how we make meaning.

My review has only scratched the surface. I highly recommend Crucial Conversations.
And Kay, thank you so much for recommending this book so strongly.

Over the past few years, I’ve been learning to express my judgments in a way that I like better than my old way.

By judgment, I mean a statement that some person, event, or condition is good or bad, or morally right or wrong. For example, “John is lazy” is a judgment, a statement that John is bad in a particular way.

I’ve found that beneath every judgment lies a feeling, and beneath every feeling lies a need. Every judgment I make comes not from the person, event, or condition I’m judging, but ultimately from my needs, and from how I feel about my needs being either met or unmet. A “positive” judgment means that my needs are satisfied. A “negative” judgment means that my needs are unmet.

“John is lazy.” What needs and feelings lie behind that statement? The need could be nearly any need. Maybe I’m needing some companionship, and I’ve asked John to go to a football game with me. When John says that he doesn’t feel like going out today, my need for companionship isn’t met. I feel lonely, and attribute my loneliness to John. I see John as the reason that I don’t have the companionship I’m needing. I judge him to be lazy.

Judgments leave the most important information unsaid. “John is lazy” says nothing about my need for companionship or the loneliness I feel when my need isn’t met. My loneliness comes not from John’s actions, but from my need for companionship. If I had other people to be with, I wouldn’t feel lonely in response to John not wanting to go to the game. And my need for companionship is about me. It has nothing to do with John.

Judgments deflect attention away from my responsibility. “John is lazy” seems to be a statement about John. Though I’m the one making the statement, the content of the statement says nothing about me. It says nothing about my needs or about my feeling about my needs being unsatisfied. My needs and feelings are my creations, and therefore entirely my responsibility. By talking only about John, I distract your attention, and more importantly my attention, away from my responsibility.

Judgments are ineffective ways to satisfy needs. I believe that every judgment is an attempt to satisfy the need that gave rise to the judgment. But judging makes it less likely that I will satisfy my need. By judging John as lazy deflects responsibility for my feelings from me to John, and gives away my power. It makes John responsible for meeting my need. And given that John is not meeting my need, I’m stuck with my loneliness.

I’ve learned a more effective way to meet my needs: Express my needs and feelings directly. I might tell John, “I’m feeling lonely because I’m needing some companionship.” (I first learned of this phrasing from Marshall Rosenberg’s book
Nonviolent Communication
. The earlier first edition of Nonviolent Communication was my favorite book of 2001. Thanks to my friend Bill Pardee for recommending it!)

I see two main advantages in expressing myself this way. First, by expressing my need clearly and directly, this gives me a chance to find other ways to meet my need. And it gives John a chance to offer ideas if he chooses. Maybe he will invite me to his house to play chess.

Second, directly expressing my needs and feelings draws my attention (and John’s) to my responsibility. My need is my need. My feeling is my response to my need. If John chooses not to satisfy my need for companionship, I can seek other companions, or simply accept that I don’t have the companionship I need. In any case, I am now owning my need, and owning my feelings.

I’m still working on this. I’m often tempted to say “That was a great movie” instead of “I loved that movie.” Exploring the needs and feelings that give rise to my judgments is sometimes a lot of work. But I’m much happier with the results.

Laurent Bossavit asks a great question, “What is the purpose of planning?”. He then gives examples of two of the most common purposes: to facilitate completing the project by some significant date or event, or to facilitate predicting the budget. I like Laurent’s question, and encourage you to ask it before (or during, or after) you engage in any significant planning.

“What is the purpose of planning?” is a form of The Value Question. However you answer the question, whatever your purpose for planning, your answer expresses a belief that planning will achieve that purpose. I want to explore that belief by asking another question: How will planning achieve that purpose? How, for example, will planning help you to complete the project by a significant date? How will planning help you to predict the budget?

Planning helps you do those things by making explicit your thoughts about what resources you will apply and what will happen as a result. Planning exposes your commitments, expectations, and assumptions, and allows you and other people to explore them, to test them, to assess your confidence in them.

Whether your expressed purpose for planning is to help you meet a committed date, or to predict your budget, or some other purpose, planning always has this intermediate purpose: to communicate our present commitments, expectations, and assumptions about the project.

One implication of this purpose is that though planning seems to be about the future, it is, ultimately, entirely about the present, about what we are expecting, assuming, and committing to right now.

Experiment: The next time you plan, make this intermediate purpose explicit: to communicate and examine our present commitments, expectations, and assumptions about the project.

Experiment: If planning is entirely about the present, about the commitments, expectations, and assumptions you hold right now, what information becomes more important to your planning? What information becomes less important?

Experiment: If planning is entirely about the present, how does that affect the way you treat the plan as the project progresses?