The Theory of Naming

Naming is actually making meaning. The world does not come to us neatly divided into 'problem' vs. 'normal', or even 'symptom' vs. 'cause'. There is no boundary and little focus. The world is "in your face", immediate, and compelling. There may be a clear sense that "there's a problem somewhere", but nothing quite so clear as to exactly what it is. In short, it's a mess.

A particular event starts to stand out from the background not because of any inherent properties, but because we associate it with other events. It is the context that creates the meaning of the event. So it is in organizations. As an event is put in the appropriate context, it emerges as a 'problem' rather than fading into the blur of daily events, many of which are annoying, frustrating, or stresful, but not considered "problems to solve".

This section explores a model of Naming, which I strongly urge you to download. The discussion below amplifies each segment of the conceptual map. It is admittedly prescriptive rather than descriptive. That is, this is a model of how we should do problem naming, not a description of common practice.

Like any theoretical discussion, it is laboriously detailed. Entire segments of the process described below may occur in the space of a single conversation, or even a moment's reflection. Real life practice is never as cumbersome or as explicit as it is in theory. But knowing the theory should enable you to navigate the toughest Naming situations with greater effectiveness and grace.

Naming seems to start with a vague awareness that "something's wrong". It is often no more than indicating a domain, a place where it hurts.

Eventually the problem (still undefined) is seen as intolerable. The cost of NOT solving it becomes too high. And so the search for understanding begins.

Trying to pin down the symptoms is a critical step. It shown here as if it was the next step. In reality there are a number of less conscious but essential intervening steps.

This is the point where common practice most often leads us astry. The discussion shifts to solutions rather than understanding the problem. Someone calls for "best practice" or industry standard, and the exploration of the problem is cut off.

But ideally the discussion about when, where, what, who, etc is allowed to expand. And the importance of the problem (in terms of cost of NOT solving it) is considered fully.

The key step in this section of the process is challenging the role of the problem solvers. We usually assume we are "outside" or even "above" the problem. We treat our perceptions and thoughts as objective or expert.

In reality, we are most often "in" the problem. Our beliefs and assumptions may be the heart of the problem. And usually those unconscious beliefs are protective of our authority, our ideology, or our advantage. That's why it is so hard to push them to the surface. Most complex problems call for change, not stability or preservation of the status quo.

Challenging the role of the problem solvers will influence how the symptoms are clustered with other symptoms. It will also effect who is identified as a relevant stakeholder. Both will modify how the symptoms are understood.

Perhaps the most subtle aspect of Naming is select the Unit of Analysis. Is the problem a question of individual skills? Group dynamics? Corporate culture? Company visioning? Leadership styles? Ethnic frictions? Market forces? National culture? Historical trends?

One of the most frustrating aspects of this early stage is how easily the problem can expand, morph, shift, and change. Often it is only the frustration of an authority that corrals the discussion and brings some focus, even if its premature or presumptuous.

Explicitly considering alternate units of analyses (UofA) will change who's a stakeholder and what other symptoms should be brought into the discussion. For example, if an initial concern for project delilvery is re-cast as an example of a competitive company culture, we would need to bring department heads and other executives into the discussion. Departments raiding each other for talent would become part of the cluster, since it reflects the same competitive culture.

The UofA provides the framework for thinking about the symptoms, and its eventual solution. Every company I've worked with has complained at some point about the inefficiency of their meetings. And most have brought in a training program to teach the disciplines of using an agenda, managing the process, and other techniques of "good meetings".

The "skills" last as long it takes to put the notebook on the shelf. With a little reflection, it is obvious the poor behavior in meetings is only one manifestation of a lack of a clear company vision that results in few priorities for resolving disputes. Or perhaps, it comes from a culture that honors the "cowboy" who refuses to be constrained by the opinions of others. Or, maybe poor meetings reflect the weak definition of key work processes, so there is a constant need for poeple to meet and try to iron out the kinks.

Selecting a UoA will impact the definition of stakeholders, what causal dynamics will need to be considered, what range of interventions will be considered, and a raft of other key features.

All of this exploration of stakeholders, symptoms, and units of analyses will eventually re-cast the original symptoms into a set that is strongly supported by key stakeholders, who believe a solution is required, and worth the cost.

If it doesn't, then you should return to whatever segment of the discussion is still unsettled.

Assuming there is a strong consensus, it is possible to identify ideal reference points that support the assumption that a solution is possible, as well as offer critical clues about what that solution might look like.

It will also be possible to ask what has maintained the problem. There is often considerable historical momentum and personal interest behind the existing situation.

The final outcome is the ability to define the constraints on the problem in terms of scope, time frame, and expected benefits. Now you're ready to Frame the problem.