The Practice of Naming

Our cultural bent is toward action, toward fixing things, toward results. And doing it now! That pressure leads to a variety of unfortunate practices that dilute our effectiveness.

As difficult as the problems are that we might face, the more difficult task is choosing the right problem to focus on in the first place. The following questions are intended not only as a prompt for your own thinking, but as a template for making your case to your colleagues.

Without presuming a solution, what exactly is happening?

We often introduce a problem by hinting at the preferred solution, such as “We don’t have a long-range view” or "We don't communicate well enough". Even if such statements are true, they fail to define the specific events that deserve attention. For that reason, they pre-empt a discussion of alternate solutions for a better-named set of symptoms.

Be as specific as possible. Here’s a test: The stated symptoms should be recordable by a video camera. This leaves out attitudes, beliefs, or imagined shortcomings (none of which are directly observable). Translate everything into the observable events from which these less visible things might be inferred. For example, “low morale” might mean very different things to different observers, so be specific about the behaviors that give you that impression.

As you try to capture the symptoms, consider the following:

• When are the symptoms most likely to occur?
• When might they be absent? Delayed? Reduced?
• Is there a sequence of similar events over time, a trend?
• Is there a group for whom these symptoms are not a problem? What is different about their perspective?

Why is the problem important?

What would happen if we did nothing?

Remember that the impact of a problem can be in a variety of currencies. There may be. . .

• Failure to reach a strategic objective
• Loss of key capability
• Dollar loses
• Lost market share
• Damaged market reputation
• Legal liability
• Worsened customer relationships
• Damaged credibility with employees
• Loss of key talent
• Compromised supply chain or vendor relationships
• Some noxious consequence for the environment
• Soured relations with surrounding community

The impact may be further broken down into immediate consequences vs. medium- or long-term consequences. We are often blind to the long-term consequences of our immediate behavior.

And sometimes there is an immediate advantage offset by a larger, but delayed cost. For example, a company can make their “quarterly numbers” but compromise systemic capability in the process, or lose key employees because of undue stress.

What lessons should we learn from earlier efforts?

The initial efforts to solve a problem usually use the traditional and most obvious strategies. And there’s every reason to use such a strategy! They just might work!

But when they don’t, it often reveals a subtlety to the problem that we hadn’t considered. A training program might fail because there are no structural rewards for the new skill. A process improvement effort might fail because the culture is too hierarchical or too competitive to support cross functional collaboration. A clarification of “roles and responsibilities” might fail because the work is so variable that innovation and flexibility are the real requirements. An effort to shift the culture might fail because the CEO refuses to temper his own behavior.

Each example merely highlights a new dimension to the problem, one that should help shape the next round of interventions.

Who has to be included in the change?

Stakeholders can contain at least 5 distinct groups:

• Those affected by the problem (customers, employees, vendors, etc.)
• Those with the key information or experience for unraveling the problem
• Those with the organizational authority to command the needed changes
• Those who provide the financial resources
• Anyone who defines the conceptual climate by imposing preferred models to use or other conceptual parameters; typically players of either financial or positional authority

There may also be some who are likely to oppose changes in the problem area; it is best to bring them into the stakeholder group, where their opposition can be translated into a positive contribution (after all, there’s probably a substantive reason why they might resist change).

Not every stakeholder needs to be a working member of the problem solving group, but their perspective should be represented in a way that is satisfying to them. A focus group or survey might be sufficient.

What would a solution look like?

Without pointing to a particular solution, name the criteria that would have to be met by any proposed solution. The criteria might be in terms of . . .

• overall cost
• speed of implementation
• consistency with existing culture (or alignment with a more desired culture)
• acceptability to Legal (or Sales, or Engineering, or IT)
• acceptance by employees
• visibility to market
• high likelihood of success
• supportable with our current IT systems
• acceptability to some external regulatory agency (FDA, County Board of Sups, OSHA)
• or a variety of technical requirements.

It is easy for a results-oriented manager to slip into prescribing the solution, which absolves the staff of any responsibility for the outcome, and pre-empts any creative thought of their own. Staff may actually pull for your preferred solution, especially if they imagine you already have one in mind. In short, you start micro-managing.

The way out of this conundrum is to focus on the criteria for a solution rather than just describe the solution you want. Sometimes the easiest way to surface criteria is to acknowledge the solutions you are leaning toward, but then highlight the features of that solution that make it attractive. For example, you might be imagining an all-day training, but what’s really important to you about that option is that it would surface the wide disagreement you know exists among the staff involved. So, in fact, any solution that incorporated that feature would be fine with you. Or perhaps you’re favoring an off-the-shelf software solution. But what’s really attractive about that idea is the speed of installation. And any solution that could be implemented quickly would be satisfactory. Incidentally, once you state a criteria out loud, you may realize that there are faculty assumptions in your preferred model. An off-the-shelf software solution is often vulnerable to a long list of time-consuming complexities.

What is the essence of the problem?

Click here for quick summary of the problem types

Initially a problem may seem like any one (or two or three) of the following:

• A problem that is a Puzzle
• A problem that is Too Rich
• A problem with Uncertainties
• A problem that is a Dilemma
• A problem with a Life of its Own
• A problem of our Own Making
• A problem of Many Voices
• A problem that Bites

Even if you can only rule out a few types, or suggest 2 or 3 types, it still provides valuable guidance to sorting out the symptoms and chartering a staff effort.

and then . . .

Two of the most common stumblings in identifying a problem are (1) making a mountain out of a molehill, and (2) making a molehill out of a mountain. It's easy to see something too simplistically; it's equally easy to imagine it's part of something of epic proportions. So it’s best to explore both options explicitly. Is there a straightforward, simple way of casting the problem that should be explored before making it more complex? And, is there a broader perspective within which the problem makes more sense, and there are more powerful points of leverage?

One strategy for navigating this dilemma is asking what other symptoms might be clustered with the one on which you originally focused? We oftentimes relate one event to another without being completely conscious of the linkage. For example, we might relate conflict between departments to poor delivery on client contracts, which relates to slipping market share, which could be related to the aging infrastructure of your products.