Loopy Conversations: What Versus How, Means Versus Ends, Requirements Versus Design Choices

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.