Is it too much to ask that people show up to meetings on time? Is it too much to ask that software developers care about craft? Is it too much to ask for an honest politician? Is it too much to ask that drivers drive as if they were sharing the road? Is it too much to ask that immigrants learn how to speak English?

Here’s how to tell whether you’re asking too much: How do you feel when you don’t get it?

Every so often someone rants about the term “human resources.” A person is not a resource, they say. A person is a person. True enough.

I suppose some managers see people as resources, replaceable, fungible, interchangeable cogs in the corporate machine. My sense is that few managers who use the term “human resources” use it in that way. And still the term rankles.

I don’t often use the term myself. And when I hear it, I interpret it to mean resources that originate in people, in much the same way that natural resources refers not to nature per se as a resource, but to resources that originate in nature. The human resource is not the person, but something that the person offers to the organization.

Several years ago, Jerry Weinberg offered a nice idea for what that resource is. I don’t remember Jerry’s exact words, so I’ll paraphrase from my perhaps faulty memory: The resource is the person’s agreement with the organization. The resource is the person’s agreement to contribute to organizational ends.

I liked that idea, and I’ve kept it in mind ever since, whenever the “human resource” complaints crop up.

Today I found another idea. On Twitter, Brian Marick quoted a New York Times article by Jon Mooallem: “[Sandpoint, Idaho council member John] Reuter seemed to argue that enthusiasm is an actual asset, a resource our society is already suffering a scarcity of.”

And my synapses made a connection: Enthusiasm is the human resource. Especially in knowledge work, the primary human resource is people’s enthusiasm for the the organization’s purposes and for the work that serves those purposes.

What I like about this notion is that it is more dynamic than “human resource” or even “the person’s agreement.” A person’s enthusiasm can wax and wane. We can nurture it, squander it, squash it. We as leaders have a great deal of influence over how much enthusiasm exists in our organizations, and how much is available for the organization. And it’s not only renewable, but potentially non-diminishable: We can use people’s enthusiasm in ways that leave them even more enthusiastic than they were before. And enthusiasm is catching.

By the way, though I’m convinced that distinguishing between management and leadership is an utter waste of time, I’m gonna do it anyway: A manager deploys people’s enthusiasm toward organizational purposes. A leader (in an organization) nurtures, cultivates, grows, invites, coaxes, inspires people’s enthusiasm for organizational purposes.

(Yes, I know that enthusiasm is only one thing people offer their organizations, so *the* human resource doesn’t tell the whole story. Of course skills and knowledge matter, too, and a host of other things. But today I’m enthusiastic about enthusiasm, so I’m taking a little blogistic license.)

Beware accounting errors.

A highly visible part of TDD is that developers write more tests than they used to. It is tempting to conclude from this that programming takes longer with TDD than without. After all, we are writing tests that we didn’t write before, and this is additional work on top of all the work we used to do. Right?

That’s a perfectly reasonable conclusion. But it is based on a flawed assumption, an accounting error that leads us to overlook some important costs. The assumption is that in addition to the new work of writing tests, developers will continue to do all of the same work they were doing before.

This assumption turns out to be unwarranted in practice. For example, before TDD, developers typically spend a great deal of time debugging. Why are they debugging? Because they have identified a failure, but they don’t know what specific piece of code is broken that produces the failure. They step through the code in the debugger in order to trace the failure to the fault. Only when they identify the broken code can they fix it.

TDD reduces the amount of debugging in two ways. First, developers write fewer defects. Second, when a developer introduces a defect, the code immediately fails one or more tests. These tests point directly toward the broken code. If the tests tell me what specific code is broken, I don’t need to run the debugger to find the fault.

Also, if developers write fewer defects, they now spend less time fixing defects.

If we add up all of the effects of TDD, including the cost of writing tests and the cost savings we gain by writing tests, we find that the first few features cost slightly more than without TDD, but that the quality is noticeably higher. And we find that later features take less time than without TDD, because TDD keeps code changeable.

An additional wrinkle leads to another accounting error: not everyone sees debugging as a cost. In my pre-TDD days, I usually enjoyed debugging. I loved having a meaty puzzle to solve. It was often the most fun and interesting and engaging part of programming. And in one job, my managers (falling prey to yet another accounting error) rewarded fixing bugs far more visibly and vocally than preventing them.

If you’re a manager, learn to attend not just to the obvious costs and benefits of a given set of programming practices, but also the costs and benefits that require a little effort and insight to detect.

If you’re a developer, I can tell you that I don’t miss debugging. The puzzle of how to choose the next test that will drive my code toward completion is as fun and interesting and challenging as debugging ever was. I hope it’s the same for you.

Loopy conversations.  Over the years I’ve seen people and teams go round and round in loopy conversations trying to determine whether some goal is a what or a how, a how or a why, a means or an end.  The reason such conversations spin is that end and means (etc.) are not attributes inherent in any particular goal.  Instead, they express relationships among goals.  In order to sort out means and ends, you have to consider the relationships among goals.

Example.  Suppose I want to buy a plane ticket to Toronto.  Is this goal a means or an end?  There’s nothing about buying a ticket per se that makes it one or the other.  But suppose I want to buy a ticket so that I can attend the Agile 2008 conference in Toronto.  Buying the ticket is a means to the end of attending the conference.

So attending the conference is itself an end, right?  Well, not quite.  At least, not in and of itself.  I want to attend the conference in order to confer with Agile colleagues.  Attending the conference is itself a means to the further end of conferring with Agile colleagues.

Now, hold on.  Just two paragraphs ago I said that attending the conference was “the end.”  Now I’m saying that it’s a means.  What’s going on?

Chain of goals.  One thing that’s going on is that, like any goal, my goal of attending the conference exists in a chain of goals, each instrumental to achieving some deeper goal.  I want each thing in order to achieve some more important thing, some deeper goal.  I want to buy a plane ticket in order to attend the conference.  I want to attend the conference in order to confer with colleagues.  The chain (or this part of the chain, at least) looks like this:

buy plane ticket -> attend conference -> confer with colleagues

So… is conferring with colleagues the end?  Again: not in and of itself.  I want to confer with colleagues in order to (among other things) build relationships with them.  That is, conferring with colleagues is a means to the end of building relationships.  Now the chain is:

buy plane ticket -> attend conference -> confer with colleagues -> build relationships

We could keep going.  I want to build relationships in order to …  And so on.  I leave it as an exercise to the reader to discover whether the chain ends and (if so) where.

We can also extend the chain in the other direction.  In order to buy a plane ticket, I will have to (say) call United on the phone.  And in order to call them, I’ll have to look up their phone number.  And in order to look up their phone number, I’ll have to …  (Another exercise for the reader.)

Relationships among goals.  Okay, so our goals form a chain.  Each goal in the chain is a means with respect to the goals later in the chain and an end with respect to the goals earlier in the chain.  Similar for how versus what, or how versus why.  With respect to conferring with colleagues, attending the conference is a means, a how.  With respect to buying the plane ticket, attending the conference is a what, a why, an end.  Means and end thus express relationships among goals.

Distinguishing means and ends.  Okay, so how does this help untangle a tangled conversation?  In any moment, in any conversation (loopy or otherwise), what makes a given goal a means or an end?

The answer:  Your attention.  No kidding.  The only thing that makes a goal an end is that you’ve decided, however momentarily, to focus on that goal in particular, to hold that goal in your mind as the goal.  That’s it.  If you choose to focus on the goal of attending the conference, your focus (temporarily) makes attending the conference the end, and each goals earlier in the chain a means to that end.  Whichever goal you hold in your mind as the one to focus on, that goal becomes (temporarily) the end, and all the earlier goals become means to that end.

Unwinding the conversation.  If you find yourself stuck in a conversation about means and ends, pause the conversation long enough to draw the chain of goals on a flip chart or whiteboard.  Or scratch it into the wall with a nail.  Show that the chain can extend in either direction.  Then with that picture visible to everyone, get back to whatever you were doing before you got wrapped around that axle.

A further complication: Design versus requirements.  A further complication comes into play when people argue about whether a given choice is a design choice or a requirement.  The distinction is not in the choice itself, but in your choice of which system you are discussing at the moment.  Every requirement for a given system is itself a design choice for some larger system.  Every design choice for a given system creates requirements for one or more subsystems.

Whether a give choice is a design choice or a requirement is not an inherent quality of the choice itself.  The distinction between design and requirement depends entirely on your point of view, in particular on your choice of which system you are talking about.

So if you’re in a loopy conversation about whether some choice is a requirement or a design choice, stop the looping and take some time to identify as well as you can which specific system you are talking about.  That sometimes helps.

Update: Note the new date for the workshop.

Join Elisabeth Hendrickson and me for our Developing Agile Teams workshop in Mountain View, California on March 1 and 2, 2007:

(more…)

I’ve been invited to be a guest presenter at this year’s Amplifying Your Effectiveness Conference (AYE). I’m honored to join the AYE hosts and the other guest presenters, all of whom I’ve known and admired for years.

(more…)

role

1. n. A cohesive set of contributions made by a single, identifiable agent to a shared outcome.

(more…)

information

1. n. Data that reduces uncertainty.

I once defined information as “that which informs.” I was unsatisfied with this definition, because I didn’t have a good definition for “inform”. The dictionary definitions didn’t help (e.g. “to impart information” or “to impart facts”), so I turned to the web to seek other people’s ideas.

The definition I found most useful is Claude Shannon’s: Information is that which reduces uncertainty. I’ve refined Shannon’s definition by replacing the fuzzy word “that” with the sharper word “data,” which I define as descriptions of events or conditions.

For a while I was worried that this definition, focused so specifically on reducing uncertainty, was too limiting. Why uncertainty? And why reducing uncertainty? What about data that increases uncertainty? Suppose I discover a datum that invalidates a key “fact” that I thought I knew, and therefore leaves me uncertain about many other “facts.” It seems to me that that would be information, too.

I was tempted to substitute the more general word “alters,” and to find some variable more general than “uncertainty” as the central variable that is altered by information. But I’ve found that the limitation—the intense focus on reducing uncertainty—turns out to be helpful when I’m seeking information. In most cases where I’m gathering information my goal is to reduce my uncertainty. Of course, I may end up being informed by data I wasn’t seeking, and I may be informed in ways that increase my uncertainty. But when I’m seeking information, I’m almost always trying to reduce my uncertainty about something. This definition reminds me to ask myself which uncertainties are most important to me, and which I’m most uncertain about. Then I can focus more productively on gathering the data that may reduce my uncertainty.

I’ve made good use of this definition in a number of contexts. I’ve found it especially helpful in talking about testing, because a central purpose of testing is to deliver information, specifically information that reduces stakeholders’ uncertainty about quality.

The definition also helps me when I’m estimating. It invites me to assess my uncertainty about the variables that affect the thing I’m estimating. That assessment helps me to focus my search for data.

Another definition I like is Peter Drucker’s: Information is data endowed with relevance or purpose. Drucker’s definition emphasizes purpose and the relevance of data to our purposes. I’ve seen numerous metrics programs flounder because they started by collecting data rather than by clarifying their purpose for measuring. The end up collecting lots of data, and then not knowing how to make sense of it.

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.

Once upon a time I was the C++ programming language guru in an organization of 200 software developers. People would come to me with all sorts of esoteric C++ problems, and I’d give them the answer. It often seemed—more often than mere coincidence can account for—that whatever problem someone was having, I’d had the same problem myself, and solved it, only the day before. So I was often able to give the answer off the top of my head, which gave me an aura of being smarter than I really was.

This encouraged people to come to me with even more problems. Eventually they posed problems—not only about programming but also about other sticky issues—that I couldn’t solve off the top of my head. In order to understand the problem better so that I could solve it, I’d ask questions to get more information. Simple questions such as What have you tried so far? and What happened? and What else did you try? I noticed that often as people were answering my questions they would suddenly say, “Ah, I’ve got it!” It turned out that I didn’t need even to understand the problem, much less to solve it.

I began to enjoy helping people with those problems most of all, the problems that I had no idea how to solve. I learned to notice what puzzled me and to ask questions about my puzzles. Not leading questions with embedded advice (“Have you tried regrafting the Johnson rods?”), but questions simply to help me understand more clearly what was happening. And in answering the questions, people became more clear themselves about what was happening. I was surprised and delighted to learn that as people understood their problems better, they were usually able to come up with great advice of their own, advice that was far more useful than anything I might have offered.

Over time I’ve added other questions to my repertoire, questions not only about understanding the problem per se, but about understanding how the person is going about trying to solve the problem. Those “meta-problem” questions, such as the ones I asked Paul, the dream-home builder, seem to have great power to help people create their own advice. And they help people learn to examine their own problem-solving process, to jiggle themselves loose when they’re stuck so they can better solve their own problems.

One day Sriram poked his head into my cube, raised a finger, and said, “Dale, I— No, I got it.” And off he went.

Later I asked him what that was all about. He said, “On my way to your office, I was asking myself, ‘What questions would Dale ask me?’ I answered those questions, and I came up with the answer myself!”

I’d helped Sriram without even being there! That’s the moment I knew I could be a great coach. If only I could find a way to get paid for stuff like that.