What Do You Do
When You're Stuck?

Sometimes doing nothing actually works. It may be that if you just focus attention elsewhere for a while, the problem will be resolved. This can happen in a number of ways.

• The problem might not be the real problem. It could be that what you think of as an undesirable behavior or property is actually a state that arises only as a result of another problem, which, if repaired, renders the first one irrelevant. Turning your attention elsewhere might give the team time to find and resolve this underlying difficulty.
• A fresh viewpoint might be all that's needed. Giving the team time to just do something else for a while could provide that freshness.
• The problem might appear to be too complex to solve, but with additional information, it might be seen to be a conspiracy of two or more simpler problems, which are more easily resolvable. Getting this additional information might take just a little time, as might happen if the problem is observable only in a rare coincidence of events. Giving it time might unravel it.
• Sometimes (too often!) sponsors or customers change their minds about what they want. Usually, this means more work. But it just might happen that a change of mind might render resolution of the problem irrelevant. Giving time to let this happen could be all you need to do.

Doing nothing might be difficult, unless you replan part of the project. Even though this can be an expensive thing to do, replanning might be well worth the price if it creates as an option the strategy of doing nothing.

Sometimes it might be difficult to pause to do nothing, because the problem you're having could be blocking something in the critical path. Can you replan to take it out of the critical path? If you can, you'll find a number of advantages:

• You make it possible to do nothing for a while, which could be just what it takes to break up the logjam.
  
• Speaking of logjams, one of the things that keeps logjams jammed is the pressure of the flowing water. If you lower the flow (hence the pressure) the jams can sometimes begin to break up on their own. Replanning to take the problem out of the critical path reduces the pressure and helps people think more clearly.
• If you apply effort to another part of the project for a while, you might learn something that could help you with the problem you've replanned around.

Perhaps one or two people on the team know exactly what is needed to resolve the difficulty. And it could be that they simply don't know that they alone have this knowledge. They might be assuming that everyone knows it, and that for some reason, it isn't the key to the puzzle. Or it might not be the key to the puzzle by itself, but when combined with one or two other pieces, the problem resolves or a solution comes into view.

One thing that helps in these situations is a simple game that I call "What Haven't I Told You?" You play the game in rounds, with a small group of about ten or fifteen people. It helps if one person acts as a facilitator and scribe.

• Everyone thinks of something that they know and that they haven't heard anyone else talk about. For each round, everyone takes a turn telling their item to the group. The scribe records each item.
• After the ideas stop flowing, the group can process them in a number of ways — rank them according to relevance, cluster them according to relationship criteria, or apply morphological analysis.

This game helps reduce the volume of knowledge that's held by each individual but hidden from the rest of the team, and it increases the volume of shared knowledge. In this way, it puts more light, more brainpower on the problem. It does this by intentionally inverting the hierarchy of technical competence and specialization. More about "What Haven't I Told You?"

This sometimes works, but looking to past experience can be dangerous if you're trying to think differently. It's like steering a car by looking in the rear-view mirror. If you can avoid that trap, you can mine the solution of one problem for the solution of the current problem, in two important ways.

• Look at the solution to the prior problem, and try a similar technique.
• Look at what you did to find that solution. What technique was it that provided the key? Did you use brainstorming? Morphological Analysis? Play "What Haven't I Told You?" Did you take a break? Did you replan part of the project to remove pressure? Perhaps some combination?

Morphological Analysis, invented by Fritz Zwicky, is a technique for systematically determining the effects of combinations of factors. It's described in Conceptual Blockbusting, [Adams 86].

The basis for the success of this technique is that sometimes the problem you're dealing with has multiple contributing causes, and then understanding the problem requires that you have in mind several of these causes at the same time. Here's how to use it.

Make a list of all the relevant factors you want to consider, and write them in a single column along the left edge of a page or white board. Then make a copy of the same list across the top of the page or white board. Each factor in the left column defines a row, and each factor at the top defines a column. The intersection of each row and each column thus defines a pair of relevant factors. You really only have to consider the triangle of pairs above the main diagonal, because the cells along the main diagonal are just pairs of identical factors, and the triangle below the main diagonal duplicates the triangle above it.

The procedure, then, is to consider each cell — to meditate on it, and see what comes bubbling to the surface. The utility of this technique is that it provides a way to make certain that you consider all pairs.

You can extend it to triples, by thinking of a cube instead of an array. I've never gone to 4-tuples with this technique, but perhaps you could if you needed to.

Places to apply this technique might be to the list of items generated in a game of "What Haven't I Told You?", or to a list of options generated by brainstorming.

Increasing the pressure to solve the problem may help some people, but it causes many others to shut down. People are motivated in different ways — some avoid negative outcomes (the "away from" type), while others work toward positive outcomes (the "towards" type). The idea that increasing pressure will increase output comes from a belief that people are motivated to avoid negative consequences — that all of us are "away froms."

While this is true for some people, it isn't true for everyone. When you increase the pressure, you lose many of the Towards types. Now, if you've used this strategy over a long period in your organization, you may already have driven off most of the Towards, or you may have trained those that remain to behave in what is for them a less natural mode — that of the Away From. If that's the case, you may have lost some of your best people already, and depressed the productivity of many who remain.

But if there are any Towards types in your organization, remember that they respond better to a vision of a positive outcome than to a fear of a negative one. Driving up the pressure, if it's an example of keeping on doing what you've been doing, probably won't help. And it could contribute to tension and possibly low morale. If enough people are affected, the tension could also impact the Away Froms. Then you'd be in a pickle.

Interestingly, the effects aren't symmetric. Using a vision of a positive outcome as a motivation doesn't depress the Away Froms — it motivates them too.

Doing what you've been doing is how you got into this fix in the first place. To get out of it, you just might have to do something different. That's why I suggest that you might have to temporarily suspend standard solution patterns, or deviate from your usual hierarchy when you ask people to look at the problem.

You might have to adopt some unusual measures to do things differently. For example, if you want to increase the effectiveness of a brainstorming session or a game of "What Haven't I Told You?", conduct it in an unusual place. Or invite an outside facilitator. Or have a local stand-up comic or humorist do the facilitating. Pass out balloons or bubble mix. Declare a casual day (if you need to). If your organization already is casual, declare a Suit Day! Or hold the session outside. Jiggle the status quo. Sounds strange, but it often works.

New ideas are always fragile. They're easily crushed, because they're new.

• New ideas have few advocates
  If they're truly new, they have a very small constituency of supporters — often, a single person. Crushing a new idea is always easier than crushing an established idea, because fewer people rise to its defense.
• New ideas often are poorly understood
  Although a new idea may fit well into the way your organization thinks, it may happen that the ways that it fits are subtle or difficult to grasp. Often, new ideas seem to be inconsistent with other cherished beliefs, or accepted understandings of your prevailing technologies.
• New ideas can be incomplete or somewhat incorrect
  The idea itself may be a bit incomplete or poorly conceived, even though it's basically correct and useful.
• Since the idea is new, it's more likely to have an unfavorable ancestry.
  New ideas are more likely to have come from outsiders, those who are low in the hierarchy. This often biases us in favor of rejecting them.

Criticizing new ideas prematurely is a good way to kill them. Since new ideas are especially vulnerable to criticism, try to find ways to suspend criticism of new ideas. In a forum in which the team is discussing new ideas, try establishing a rule that suspends criticism. Instead, try a rule that if someone wants to comment on an idea, the comment must be confined to strengthening the idea.

Focusing on what will happen if you fail is an often-used tactic for applying increasing pressure to the project team. It can take many forms:

• If we don't ship during this quarter, the share price will nosedive (and your stock options will be worth a lot less).
• They'll take our organization apart if we don't straighten this out.
• Heads will roll — so get it done.
• We all want to do that other new product — if we don't get this finished, they'll assign another team.

And so on. All of these threats assume that all people are of the Away From orientation. While some of us are, the people who are Towards types can be demoralized by threats. If they are, the general tone of the team can be depressed even if there are only a few of the Towards orientation.

Sometimes managers withhold information that they think will retard progress, especially if the information is bad news regarding availability of resources, budget, or some critical component. Sometimes members of the project team withhold information that they think might be dangerous to reveal, especially if they fear that they might be tagged with blame. Information is sometimes withheld on both sides of the supervisory divide — and it's almost always a bad idea, for two reasons.

• Even if you withhold the information, you know about it.
  Do you really think you're so good at concealment that the people you work with have no clue that you know the bad news? Are you that good a poker player? Probably not. The more threatening the information is, the more tempting it is to withhold it, and the more difficult it is to conceal your own anxiety about it. If you really were that good at concealment, you should probably consider a career in magic, acting, or espionage, and get out of project work — your talents are wasted.
  
  Moreover, the future may someday arrive (it usually does). And in the future, it may be somehow revealed that although nobody else knew the bad news, you did. And you withheld it. What will happen to the atmosphere of trust when this fact becomes known? Hint: nothing good.
• You might be able to influence what people think (for a little while, anyway), but you surely can't influence whether they think.
  
  By this I mean only that people have brains, they speculate, they gossip, they guess, and, sometimes, they guess right. Even if you don't tell them about whatever it is you're withholding, they still have brains of their own, and sources of their own, and they might find out anyway. And you can't control that.
  
  And let's suppose they guess wrong. There's a good chance that their guess could have even more negative impact than the truth. By depriving them of the truth, you've actually made the situation worse.

It's nearly always better to tell the truth, to not withhold the bad news. Nearly always. The sole exception is the blaming organization. And in that situation, you have far more serious problems.

Punishment and blame are very effective at stifling creativity — and creativity is just what you need to get out of stuck places. Here's how they work.

• When you create a blaming atmosphere, you effectively tell everyone that if any problem is traceable to any of their personal actions or decisions, then it's likely that they'll be tagged with the problem. This encourages people to adopt the defensive strategy of not taking any action or decision, for fear that it might someday be used to blame them for a problem. And since action is just what we need to get out of a stuck place, blame is a major cause of stuckness.
• In a blaming atmosphere, it becomes difficult to find out the truth about technical issues.
  People who offer information about technical artifacts risk becoming the owners of those artifacts. If those artifacts are ever implicated as a source of a problem, the blame could come their way. The defensive strategy here is to avoid offering one's technical expertise. If a piece of work is lagging behind schedule, this fact may be concealed for as long as possible to avoid blaming.

For a complete discussion of the effects of blaming, see [McLendon 96].

You might find that there are some people working on the project that you believe may have considerable responsibility for the project's problems. Whatever you believe, relieving them of any significant portion of normal duties is a risky proposition. Complete reassignment is a better option. Best of all, do nothing, if you're confident that no further harm is likely.

The reason for this is that it's important to avoid creating an atmosphere of blame. If it seems to the project team that the individual is being punished for making a mistake, some of them could become so afraid of making a mistake that they'll be unwilling to take the ordinary kind of risks that a project team needs to take, such as speaking out about a good (or bad) idea.

We all want to learn from our mistakes, so it makes sense to try to find out why the problem arose in the first place. But save it for the Project Retrospective. If you try to investigate while the problem is still open, you're taking some big risks.

Some may feel that a case is being built against them.

Investigations are always difficult to do, but in a pressure environment, there's a higher than normal risk that investigations will be seen as exercises for documenting a dismissal or transfer or discipline. If the atmosphere is such that people feel they're being examined, they may not be as creative or productive as you need them to be.

If you really want to find the truth, wait for success.

When success is still in doubt, fear and uncertainty can cause people to behave in strange ways, and to perceive things differently. An investigation of a "live problem" is likely to produce half-truths and CYA behavior and — shudder — email and memoranda.

If you have some information to share, a meeting is a good way to do it. People can deliver the information they have to everyone at once, and there can be room for interaction, questions, and new insights. But sometimes, especially when the project is stuck on something, we tend to use the regular informational meeting as a way of exerting pressure on the teams that are stuck.

Of one thing you can be sure: the moment a long-standing problem is resolved, everyone will find out about it. There's no need to hold a meeting to share that kind of information. And as discussed above, increasing pressure isn't likely to help. Meetings to announce success in breaking a logjam or to increase pressure aren't likely to help much. They might even do harm.

Celebrations are another matter — they almost always help. If you want to hold a celebration of a success, go ahead and do that — but don't celbrate at a meeting.

Let's suppose that your part of a project is stuck. And let's suppose you've been told to attend a meeting at which not much is likely to happen that will help you unstick your part of the project. How attentive and helpful are you likely to be at that meeting? Such a situation is more likely to raise tension and frustration than to help in any way to move your part of the project forward. Best to have meetings when you need interactive discussion of new information or matters unresolved.     Top

Adams 86

Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas. San Francisco: Perseus Publishing; 4th edition. 2001. W.H. Freeman, 1986.

McLendon 96

McLendon, Jean and Gerald M. Weinberg, "Beyond Blaming: Congruence in Large Systems Development Projects," IEEE Software, July 1996, pp.33-42.

Contact me to discuss your specific situation, by email at rbrenner@ChacoCanyon.com or by telephone at (617) 491-6289, or Toll-free at (866) 378-5470 in the continental US.

Are you a writer, editor or publisher on deadline?