©2010 Steven M. Smith

Do you have a mole undermining the work of your team? Someone who constantly complains privately to any teammate who will listen but refuses to bring that same complaint publicly to the team? Someone whose actions are destroying teamwork?

A mole erodes productivity. Stop that mole now.

A team is like a garden. A good gardener manages pests –

Bambi, a deer, can kill a portion of your garden by eating your produce’s leaves. His attacks can be seen so they can be managed by the non-specialist, by using such means as scaring him; erecting a fence; planting produce that he doesn’t like; and using chemicals that make your plants smell or taste yucky.

Buck, a mole, undermines the roots of your garden killing your produce. But unlike Bambi, you can’t see Buck in action so his attacks are almost impossible to mange by the non-specialist. For instance, scaring him won’t work because you can’t see him; erecting a fence won’t stop him because he does his work under the surface; planting different produce won’t stop him because his food source is the worms, insects and grubs beneath your garden; and using chemicals to kill the insects and grubs won’t stop him because his primary food source is the worms.

Bambi’s behavior can be managed so that it is an annoyance. Buck’s behavior is much different — it’s destructive.

Real moles aren’t malicious. Their intention is to eat rather than destroy the garden. I admire them for their single mindedness and work ethic. I, however, disdain a mole on my team.

I believe the Bucks of the world think their actions are helpful. But unlike my ability to manage the Bambis, I don’t have the special skills necessary to consistently manage or turnaround the Bucks. And in my experience, I estimate that there are only 0.1% of all managers who have that special management (therapy) skill.

What’s to be done? Confirm you are dealing with a sibling of Buck’s by — bringing the tunneling behavior to the person’s attention, telling them it’s unacceptable, and determining whether the tunneling continues. If it does, work with HR to immediately rid yourself of them.

Once they’re gone, the team will feel like the weight of the world was lifted from their shoulders. Productivity will skyrocket. Stop that mole. Now.

convert this post to pdf.

(c)2007 Steven M. Smith

“What?” raced through Janet’s head as she read the email. “Now that’s a surprise.”

The message was from Jack Johnson, vice president of development. It said she would receive a meeting request from Rajan Alak, an outside consultant, to interview her about the problems with the new system. The message went on to say the company had made a significant capital investment in the development of Synergy and problems with the system were preventing the company from enjoying the expected ROI. Jack asked Janet to give Rajan her full cooperation.

“He wants me to give an outside consultant–a total stranger–my full cooperation?”

The problems with Synergy didn’t surprise Janet. She had invested almost all of her time during the past year in developing the system. She believed the business planners had been too aggressive with the system integration plans. She thought the company’s chance of achieving the projected ROI was zero. Her suspicion was that the projection was based on politics rather than reality.

A portion of Jack’s message was a surprise: In addition to fixing the problem with Synergy, he wanted to fix problems in the development process that had caused the issues with the system. Solving problems with the development process was an initiative Janet had wanted to see since she started her job seven years ago.

She waited to exhale and asked herself, “How much should I tell this outside consultant? Will my statements be used against me? Or my manager?” And as she exhaled, no answers came.

The next morning Janet received the meeting request from Rajan to interview her the following Wednesday. The request included a copy of Jack’s message and told her she would receive more information about the interview in a forthcoming email.

A part of her kept wondering, “How much can I say?”

Rajan’s email titled “The Interview Process” arrived two days later. Janet read the message carefully. It said she had complete control over the information she shared. She could choose to have information marked as originating from her, originating from an anonymous source, or recorded as off the record. Rajan said that after the interview she would receive a transcript of the “on the record” parts of the interview for her review and approval. Rajan emphasized he would not share any of her comments with anyone else until she approved them.

“Hmm . . . ” she thought. “Maybe it’s OK to share what I know.”

Fundamentals

The quality of an interview depends on how safe the interviewee feels. People guard their knowledge when their answers may endanger themselves or a valued colleague. The safer the interviewee feels about answering questions, the higher the quality of information available to the interviewer.

Creating a safe environment is only the start. In addition to safety, the quality of a set of interviews–whose purpose is to discover problems and solutions–depends on managing the sponsor, interviewing the right people, and interacting skillfully with the interviewees.

Let’s explore effective actions available to the interviewer before, during, and after the face-to-face interview.

Before the Interview

Sponsor Agreement

Gaining clarity about the objectives of the sponsor saves everyone time. Help your sponsor write down what is important to him and, just as importantly, what will gain the cooperation of the interviewees. Have the sponsor sign off on a written set of discovery objectives and a list of people to be interviewed.

For instance, if a vice president says her objective is to fix the problems with a system, her message will be compelling to some of her people. Adding that she also desires to solve the development problems that caused the system’s problems may energize additional people.

Rarely does anyone create objectives that are compelling to everyone. Objectives that are compelling to some people may de-energize others. So, focus on creating compelling objectives for the people whose opinions matter most to your sponsor.

Overcome Restrictions

You will want to talk to the organization’s customers. Some organizations carefully restrict who communicates with their customers. Despite these barriers, assume management wants you to speak with them. Work with your sponsor to identify which customers you will interview. If your sponsor objects to your talking directly to the customer, negotiate. Explain that without customer feedback, the most that can be discovered is less than half the available information.

I prefer to interview the customers first. I want to hear their unfiltered perspectives about outcomes that were expected but never satisfied. Next, I like to interview key middle managers to gain additional perspective. The customer and middle management interviews reveal a panorama of the most visible problems and provide an opportunity to find out more about whose opinion is the most influential.

Sponsor Communication

Regardless of whether you are an inside or outside interviewer, the person you are interviewing needs to hear from his management why he is being interviewed, who will perform the interview, and what actions management expects from him. In the introductory story, a vice president, Jack Johnson, provided that information to Janet.

Prepare an email for the sponsor to send to all the people being interviewed. Take control; if the context isn’t set properly, it will be a barrier to your success. If the sponsor is uncomfortable with your message, ask him to discuss it with you and work with him to revise it so it works for the sponsor and you.

Ask the sponsor to send the message to each interviewee individually. My experience is that messages addressed to a single recipient gain more attention than messages addressed to a group.

Also ask the sponsor to mention the interviews in staff meetings and to emphasize the importance to the interviewees. Scheduling interviews is difficult in busy organizations. When upper management deems the interviews to be of high priority, middle management will more readily support the scheduling of its people’s time. Otherwise, the interviews will be a low-priority event that may never happen.

Interviewer Communication

After the message is sent from the sponsor, it’s up to you to schedule the interview. I suggest you attach the sponsor’s original message to your scheduling request so recipients can review it. The inclusion of the original message prevents confusion by people who may not have read the message from their management.

Follow the meeting request with an email from you to each interviewee explaining how the process will work. This message lets the interviewee know he controls the use of the information he shares. This email will surprise the recipient. People in large organizations frequently receive messages about protecting the company’s rights but rarely receive messages giving them rights.

My preference for the first interview requires no preparation by the interviewee. If you are interviewing the right people, they already know everything they need to know. Inform the interviewee that he doesn’t need to do anything prior to the interview.

I strongly suggest you telephone the interviewee the day before the interview to confirm the time and location. Priorities change regularly in organizations and the interviewee may need to cancel the interview. Knowing about cancellations early will enable you to reschedule your day. If your call is transferred to voice mail, let the interviewee know the time and location of the interview, leave your cell phone number, and let him know that you’ll assume everything is as scheduled, unless you hear from him.

Question Sequencing

The sequence of your questions contributes significantly to a successful interview. A key aspect of most interviews is gathering information about problems. I like to look at questions as either branches or stems. Branch questions move to a new subject area. Stem questions (indented below) gather more detail about a branch. Let’s look at a high-level plan for sequencing questions during a sixty-minute interview:

Q: Who is your customer?

How does your customer relate to Synergy?
Who else is your customer?
Would you recommend that I interview any of the people you mentioned?

Q: What problems did Synergy solve?

Tell me more.
Anything else?
Someone in a previous interview mentioned that Synergy retired a number of older applications. What’s your take on that?

Q: What problems did Synergy create?

Tell me more–what evidence do you have?
Who else should I talk to about that problem?
Who might see this differently?
Anything else?
Francois suggested that I ask you about complaints about poor performance. What can you tell me about that?
Why did this problem occur?
Could something have been done to prevent it?
What suggestions do you have for fixing the problems?

Q: What problems happened during development?

Tell me more.
How did that affect you?
What else?
What recommendations do you have for fixing the problems?

Q: What other questions should I be asking you?

How would you answer your questions?
Anything else?

Q: Do you have any questions for me?

Q: May I contact you if I have additional questions?

These questions can be asked to anyone in the organization. As you gain information from each interview, adapt your questions to fit the person you are interviewing.

Metaquestions

In addition to questions on the topic of interest, effective interviewers equip themselves with metaquestions to gather feedback about the interview process itself. Metaquestions are questions about questions. For instance, if you see a puzzled look on the interviewee’s face, you might respond, “I see a look on your face that suggests to me that you might be puzzled by my question.”

I find answers to metaquestions open new possibilities about what to do next. For instance, you may discover that the person you are interviewing has a different role than you thought and the role isn’t relevant to the discovery. Rather than continue the interview and waste his time and yours,you now have the option of ending the interview. The following is a list of metaquestions I have found valuable in any interview situation:

Do you have any questions for me?
Do my questions seem relevant?
Do my questions puzzle you?
Are you the right person to answer these questions?
Is there anything else I should be asking you?

Don’t Worship the Plan

Plan the interview, but don’t worship your plan. Effective interviewers adapt to the desires of the interviewee. Don’t be the type of interviewer who never deviates from his list of questions. I have experienced that kind of interviewer, and I wondered if he even heard or cared about my responses.

If the interviewee makes it clear that he would enjoy answering more questions, you have connected. And connection is an objective of every interview.

During the Interview

Virginia Satir, a pioneering family therapist, created an interaction model that offers interviewers insight into how to conduct an interview. Satir insightfully broke down each interview interaction into a series of steps. She suggested that careful processing of each step offered new choices for strengthening the connection between the interviewer and the other person.

Satir’s interaction model can be summarized as follows: Perceive -> Interpret -> Evaluate -> Respond.

Let’s use the interaction model to examine a portion of the interview from the perspective of Rajan, the interviewer. For example, Rajan asks Janet, “What problems did Synergy solve?”

Perceive

The first step in the interaction model is to perceive the interviewee’s response. Rajan hears and sees Janet’s response. The words are a single component of Janet’s response; other components–such as tone, pace, breathing, and facial expression–are also part of her response.

For instance, before Janet uttered a single word in response to the question about the value of a solution, Rajan noticed her eyes narrow and her forehead crinkle. Rather than rush to interpret the words, the interaction model suggests there is an opportunity to gather more data before interpreting meaning.

Rajan has the opportunity to say something like this to Janet: “I noticed that your eyes narrowed and your forehead crinkled before you answered my question. I’m not sure how to interpret that reaction. What can you tell me about it?” Regardless of how Janet responds, Rajan has gained additional and perhaps more relevant data about Janet’s response.

Janet blinks, straightens herself, and answers, “It would mean a whole lot to the department. We could process work faster.” Let’s analyze this. Notice that Janet’s words are about the value of the solution to her department rather than to herself. Without further probing, valuable data could be missed.

An effective interviewer explores how something directly affects the interviewee. That’s the subject where the interviewee has total expertise. Rajan, an experienced interviewer, then asks Janet a clarifying question, “What would a highly effective solution to the problem do for you?” Rajan might ask several probing questions to gain more specific data about the value of the solution to Janet.

Interpret

The second step in the interaction model is to interpret the data. Rajan decodes Janet’s meaning from the data he gained through his senses. Successful completion of this step happens when the interviewee agrees that the interviewer’s interpretation is the same as his meaning.

Sometimes interpretation is simple. For instance, Rajan says, “Janet, I understand that solving the problem would save you four to six hours per week. Does that capture the value of the solution for you?” If Janet says yes, Rajan is done with that question. But watch for her wanting to say more. After a long pause from Rajan, she may say, “But the most important thing is that I then could rely on the accuracy of the results.” Now Janet has revealed the real value to her.

Sometimes interpretation is difficult. Transmission errors are normal. Your perception might be wrong. The interviewee might have said something wrong and not realized it. That’s why it’s crucial to gain the interviewee’s agreement about this meaning. After you publish the findings and recommendations, the last thing you want to hear is an interviewee saying, “That’s not right,” “That’s not what I said,” or “That’s not what I meant.”

Let me suggest a method for confirming that you have captured an interviewee’s meaning correctly. Ask the interviewee a series of “Do you mean X? Do you mean Y? Do you mean Z?” questions until you hear three “Yes” answers. For instance, Janet may have provided Rajan with a lot of data about the value of the solution that doesn’t have a single simple interpretation. Rajan asks Janet:

“Do you mean the solution will save you four to six hours per week?”
“Do you mean the solution will enable you to more effectively communicate the status of the client’s requests?”
“Do you mean the solution will enable you to help your colleagues with their work and for them to help you with yours?”

A “Yes” answer confirms your interpretation. “No” answers provide opportunities for finding out what was meant.

Evaluate

The third step in the interaction model is to determine the significance of the meaning. Explore how the meaning connects to value for the interviewee, organization, and customers.

For instance, consider the response “X will save me four to six hours per week.” On the surface that sounds terrific. But how significant is that savings? During the interview with the head of engineering for an airplane manufacturer, I informed him that someone in his organization said that a new system would save each of his engineers four hours per week. He squinted his eyes and said, “So what? That doesn’t guarantee me increased productivity. They may take that time savings and stare at the holes in the ceiling tiles.”

In other words, without connecting the time savings to something else, a benefit that seems obvious at one level may not be obvious at all to a different level or perspective. Dig deeper. Ask follow-up questions such as, how would you use the time savings? Keep probing until you uncover a benefit that is meaningful to the interviewee and, if possible, to his management.

Respond

The final step in the interaction model is for the interviewer to choose the next question. You can choose to continue asking stem questions, ask the first question in a new question branch, ask the first question in an unplanned branch, or ask a metaquestion to help you decide what to do next.

If you are like me, you may have times when you aren’t sure what to ask next. I have found a comment and a metaquestion that has worked well. I tell the interviewee, “I’m not sure what question to ask you next,” and then ask the metaquestion, “What question should I be asking you?”

After the Interview

Observe And Transcribe

I suggest an interviewer use a pocket recorder so you can keep your eyes on the interviewee rather than looking at your notes. Be sure to ask for permission to make a recording, and if you don’t get it, don’t record. Throughout the interview, watch for signs that the interviewee is uncomfortable with the recording. Be willing to switch it off if it’s obstructing the interview process.

Write the transcript of the interview as soon as you can. The transcript only includes the material you may want to use in your discovery report. Share only what is relevant and needs to be confirmed by the interviewee.

I like to tell the interviewee that anything in the transcript is something that I might quote directly. I believe it’s extremely powerful to include in the discovery report quotes from people in the organization as well as customers. If the interviewee grants you permission to quote him, give him the credit for discovering a problem and how to fix it.

Don’t Share Until Approved

Don’t share information from the interview with anyone until the interviewee has given you permission. And let me be clear: I mean no one else. That includes the sponsor and your manager. You have made a commitment to the interviewee with the hope he would feel safe to share things with you. Don’t break your promise.

Adapt Your Plan

From each transcript, follow the suggestions about questions to ask other people. The interviewee gave you a person’s name because he thought that person knew something important or his thoughts had significant influence within the organization. Use this information.

Revise your question plan based on what you have learned during the interview.

Thank the Participants

Thank the participants at the end of the interview. Thank them when you send the transcript. Thank them when all the interviews are done. Thank them all in the preface to your report.

The more appreciation you show the participants, the more they will appreciate you.

Summary

Interviewing is an art. Learning how to do it effectively takes practice.

I’ve made many suggestions. If you can only do three of them, I recommend:

1. Building a foundation of safety so interviewees will tell you what they know.
2. Conducting face-to-face interviews so you hear and see what is being communicated.
3. Planning your questions and using metaquestions to adapt to the needs of the interviewee.

By executing a set of effective interviews, you will gain knowledge about the organization and its problems that no single person in the organization can offer you.

Remember to conduct yourself with integrity every step of the way. It’s fundamental for gaining the trust of people you are interviewing.

<>

Steven M. Smith (www.stevenMsmith.com) is a management consultant who specializes in helping leaders of technical organizations delight customers, manage change, and strengthen teamwork. With more than three decades of experience as a thought leader in technical organizations, he shares his know-how through his writing, consulting, and leadership of experiential workshops. He is a founder and host of the annual Amplifying Your Effectiveness (AYE) Conference (www.ayeconference.com), at which he leads experiential workshops. You can contact Steven at steve@stevenMsmith.com.

convert this post to pdf.

Always have an exit strategy.

©2005 – 2009 Don Gray, Gerald M. Weinberg

“The thought that disaster is impossible often leads to an unthinkable disaster.” – The Titanic Effect, The Secrets of Consulting, pg 95

Engelbert, the Software Engineering VP, sat quietly in his office pondering the current state of UberDenke’s next UDCRM release. Slowly he had realized the release wasn’t going to ship on time. There were many more errors than he planned for, and over half of the code had not even reached the testing group.

The more he thought about it, the more he felt trapped. The more trapped he felt, the more he wanted out. The more he wanted out, the more he felt trapped. And around, and around his feelings traveled in a vicious circle of trapped and wanting out. But there wasn’t anyway out.

Or was there? Engelbert’s thinking and actions have trapped him in a reinforcing feedback loop. His feelings are creating an emotional downward spiral that will continue until some system limit is encountered. The system limit may be the when he finally admits to others the release won’t ship on time. Perhaps his health (mental or physical) may break first. Or maybe he’ll change jobs.

We can all sympathize with Engelbert?s plight, because at some time or another, we’ve all been caught like this–a trap artistically summarized by Jean Paul Sartre’s depressing play about three people trapped in Hell, No Exit.

Engelbert set up his own No Exit hell right from the beginning, because he, like Sartre’s victims, had no exit strategy. An exit strategy is a planned set of activities to initiate when one party suspects that a relationship isn’t working, activities that should prevent the situation from becoming a hellish trap.

Dynamic Basics – Getting Started

The no-exit dynamic generally begins when two (or more) parties agree to work jointly on some project. Sometimes the agreement is not explicit, as often happens when the work of one party depends on another party’s output. This joint work could stem from a voluntary relationship (such as co-authoring articles) or perhaps from a management mandated decision. In Engelbert’s case, his manager told him to use a new process to build the next generation of their software product.

The parties start merrily to work under the agreement, and all goes well for a while. Next, life happens.

Perhaps the person with whom you agreed to write an article falls ill, changes jobs, or takes time away from the joint project to deal with pressing family problems.

Perhaps the other team at work discovers the problem is more difficult to solve than anticipated. Possibly another higher priority project siphons manpower from their team.

Or perhaps the dynamic starts up when the levels of commitment and interest are unbalanced, or when there is a different understanding of the agreement.

Locking In

The first slip or two may not create a problem. We use explanations like these:

• It’s only happened one time. (Not noticing prior behavior on the part of either party).
• Things are bound to get better. (Seeing through rose colored glasses)
• I’ve made a commitment, so I’d better not say anything. (The team player problem)
• They’ve got a plausible story. (Just one more chance).
• I’ve already invested so much, a little more investment and I’ll have what I want. (Good money after bad)

Whatever the reason–and there are hundreds of variations–the slips soon become the norm, not the exception. Since the slips happen individually, separated by days or weeks, the cumulative effect isn’t noticed until it’s too late to do anything reasonable about the slips. The more we become accustomed to the slips, the more tolerant we become as new slips occur. It’s not that Engelbert is stupid. It’s just that he lacked foresight, or was too optimistic. If he had known when starting development that the project would slip several times, he could have planned differently.

Failing to take early action sets the precedent for continuing failure to act. Failing to act causes negative feelings to accumulate. The negative feelings are there from the first slip, but they are ignored or suppressed until the accumulated value becomes greater than we can tolerate. When we finally surface the negative feelings, we feel trapped by our previous actions. We’ve become locked in the reinforcing feedback loop of simultaneously wanting out and feeling trapped.

In this dynamic the system continues accumulating more negative feelings until the system experiences a catastrophic collapse. Engelbert may be fired, or quit, or get sick, or ship a system that drives his company out of business.

Setting up the Exit

So, what’s the solution? The first step to exiting the reinforcing feedback loop is to become congruent by balancing the factors of yourself, the other party or parties, and the context in which the dynamic is taking place. Most commonly, in this type of a feedback loop, the other becomes lost. As you try to cope with the situation, you start blaming the other person for the problem, and that only tightens the loop. Responding incongruently like this creates stress and does nothing to improve the situation or help find an exit from the loop.

Becoming congruent allows you to be centered in your actions. Being centered opens a range of responses you can use to change your view, each of which might break the trap. By changing your view of the situation, we can see possible interventions that will change the loop dynamics. Among such interventions are these:

• Changing how you see your contribution to the problem.
• Determining why you feel like you’re trapped.
• Obtaining a better understanding of what you heard during the “agreement” process.
• Bringing in a third party who adds a compensating loop. Sometimes you do this by just letting the loop escalate until someone else is affected, often by not trying so hard on your side. This is an example of:
• Doing the opposite of what you’ve been doing. This personally applies Marvin’s Fourth Great Secret, ?If what they?ve been doing hasn?t solved the problem, tell them to do something else.? The Secret of Consulting, pg 41

Exiting the Loop

No self-reinforcing loop can last forever. Sooner or later, one way or the other, the loop will exit. If no action is taken, the reinforcing loop will continue its downward spiral until some other part of the system collapses:

• Personal health (mental / physical) will deteriorate until the exit happens. (This is breakdown of the self.)
• The interpersonal relationship will decay and animosity replaces the original camaraderie. (This is breakdown of the relationship with other.)
• A third party starts to be affected and intervenes. Of course, this is the result some people are hoping for (if we make enough noise, Mommy will stop the fight). But, you can also encourage it. (This is where the context intervenes.)

Another exit option is to become centered, congruent and work on changing the loop dynamics. The key here is to recognize the No Exit dynamic early, and take corrective action quickly. Your plans and strategies must be flexible. While the goal can be constant (exiting the loop), life continually changes, so fixed plans inevitably become obsolete or, even worse, counter-productive.

When the loop finally exits, there are several possible outcomes:

• An intervention works and the joint effort continues
• The “healthy” participant becomes “sick” and the effort ends due to lack of effort
• One person takes over the entire effort

This applies to multiple party systems (two or more). In addition to software development this could include:

• marriage and other long term interpersonal relationships
• business ventures
• article or book writing
• sports or other activities you are doing “for fun.”

An Ounce of Prevention

Next time, Engelbert should consider prevention interventions. Prevention interventions can be used to prevent the No Exit dynamic from happening in the first place. Or if it starts anyway, they provide an agreement among the parties as to how to handle it–if you like, a meta-agreement, or agreement on the limits of our agreement and what we’ll do when we reach them.

In a crisis, it’s much easier to stop and think if you have provided time in your plan for stopping to think. If you haven’t, one party will say, “Here you tell me that we’re behind schedule, but you’re adding this thinking-bit to the schedule. That doesn’t make sense.” With that easy dismissal, everyone quickly hurries back to their unproductive panic.

Examples of advance preparation of exit strategies include:

• Periodic check-ins
• Gate points where either party can exit the activity, if they’re not perfunctory so you can really exit at these points
• Better understanding and more explicit statement of each party’s expectations, along with a process by which expectations can be modified along with the plans that were based on them.

A well-designed system will set some limits at the beginning, limits that are not vulnerable to a buildup of tolerance.

Third Party Interventions

Most parents have learned some dos and don’ts about what to do when they witness such a no-exit loop. If you find yourself on the outside looking in, you might apply one of these principles:

• Know when to enter (never do unless you’re asked for help, though you can encourage the parties to ask you).
• Prevent damage (whatever that is) to others.
• Decide it’s not your problem and walk away, letting the nature of the no-exit loop take its course.
• Avoid creating addiction (co-dependent) dynamics.
• Avoid using fixes that accentuate the dynamics, unless you want to make it worse so it will crash more quickly or lead to enough pain that the parties will work out their own solution.
• Be careful not to prevent natural learning.
• Look for interventions that remove barriers and/or increase resource states.

Exit Levels

In deciding about intervening, choose which of three Exit Levels you’re seeking:

• First exit is when participants realize how much pain the feedback loop is causing and figure out a way to break out for themselves.
• The second exit is out of the situation (as when the parties concur that the agreement has failed). This may lead to a new agreement, or an exit agreement where they continue the relationship with each other.
• The third exit is where one party opts out of the system by ending the relationship.

Of course, the best exit is the one you have planned for before you ever get started. Unfortunately, there’s a prevalent romantic notion that real relationships shouldn’t need a pre-nuptial agreement. As Engelbert’s boss argues when he tries to set up some exit strategies before his next project, “Thinking of possible failure is negative thinking. It’s just that kind of thinking that guarantees we’re going to fail. Just like you did that last time.”

Of course, the last time, they had no such exit strategy, so their failure was much more costly and painful than it need have been. That’s The Titanic Effect: The thought that disaster is impossible often leads to an unthinkable disaster–”Why would we need lifeboats on an unsinkable ship?”

convert this post to pdf.

© Gerald M. Weinberg, 2004 www.geraldmweinberg.com

“1,073,741,823 lines of correct code, but one unknown bug is going to send us into that Sun.”

“Do not panic.” Peri said, using Calming Voice. “We have adequate time to find it.”

“Peri is correct,” echoed Setho. “Remain logical. We must divide the code in half and allow the simulator to find which half contains the defect. Once we repeat this process 30 times, we are guaranteed to find the culprit.”

“I know I couldn’t have designed this ship,” I said, “and you’re absolutely right about the process. But you have no concept of time. Each test will cost us 10 minutes, and in 4 hours we’ll pass the point of no return. Yes, an hour after that, we’ll be able to unlock the controls, but it will be too late. Perhaps you Zaard will be satisfied to choose your personal sunspot for cremation, but it doesn’t do much for me.”

“We will remember our ancestors,” said Peri, twisting into the Zaard meditation posture.

“Yes,” Setho agreed, in posture as in words. “Termination of existence is the only logical conclusion, so remembrance of ancestors is the only logical action.”

“Don’t go to sleep on me. There is a way, if we’re lucky.”

“Luck is a human concept,” Peri said, his voice slowing and sinking. “Do you really think you can find one out of a billion lines of code by luck?”

“Peri,” said Setho’s Chastizing Voice. “Please be respectful. We must not interfere with his religious beliefs, no matter how preposterous they are to us. Proceed with your foolishness, John, if you wish. We shall watch, and pray for your soul.”

“I could use more help than that. I figure that if I can guess a division of the code that puts the bug in the smaller half, I can accelerate the process.”

“Your assumptions are incorrect. Though you name it ‘code,’ we know it is Leethaa, not some simple computer instruction.”

“Doesn’t matter what you call it. If we find the Leethaa, or code, that’s wrong, we can change it through the console.”

“True. We can change it, but if we merely know it is wrong Leethaa, that still does not mean we know what is right Leethaa.”

“Of course you’ll know. You built it.” Peri and Setho exchanged another look, and the odor in the compartment changed. “I’m just a passenger, remember, like any human, taking advantage of your intergalactic freight service. You’re the designers.”

Setho turned several of his eye to me, but spoke to Peri. “Since we are all to end our existence, in a few hours, can there be harm in telling him?”

No, the memories of our ancestors will not be harmed.”

“Tell him what? And don’t talk about me like I’m not here.”

“We Zaard are not the designers of these ships. We, too, are passengers, enjoying these gifts from our ancestors, countless time in the past. We do not know how the Leethaa operate, but only how to repair them when they fail.”

I was quickly rearranging all I thought I knew about the Zaard. Too bad I wasn’t going to be able to tell anyone. “Then how can you repair it?”

Setho was about to reply, but Peri raised an appendage and used the Interrupting Voice. “We use the binary search, using the simulation logic, as I explained. When we locate the offending Leethaa, we alter its state – le to eth; eth to aa; aa to esu; esu to culara; culara to le. Those are the five possible states, as I believe you well know from observing us through these months we have flown together.”

I didn’t know they had been watching me watching them, but what did it matter now. “Fine,” I said. “So once I locate the right Leetha through my guessing, you can make it right.”

“True, but guessing depends on luck, and we do not believe in luck. You will not find it.”

“Moreover,” said Setho, “even if we were to assume your false premise about the existence of luck, then we would logically have to accept the existence of bad luck as well.”

“And with bad luck, your guessing process would actually take longer.”

“Hey, we’re going to fry anyway, so what more do we lose if it takes longer? Besides, I need your help.”

“We cannot help with luck. We can only remember our ancestors.”

I swept my gaze over the full circle of consoles. “Then call it ‘intuition,’ if you don’t like luck. You two know a lot more about this vehicle than I do, and your guesses may actually be better than mine.”

“But we already told you, we don’t believe in guessing.”

“Well, one thing for sure you do believe in is arguing, and arguing for sure isn’t going to save our skins. While we’ve been having this lovely philosophical discussion, I’ve been running my first guess. It should be done in 30 seconds.”

“We noticed,” said Setho, who seemed the more alert of the two. “… And there it is. You see, it seems that the flaw is in the larger of your two parts – not the smaller one chosen by your guess – and now the process will take even longer.”

“Okay, so it was bad luck. But if my luck turns better, we can make up the lost time.”

The two Zaard merely exchanged more glances that I couldn’t interpret, so I made my second guess. “I think the transporter code is the most likely place, so I’ll make that one of the halves.” I entered the cutting point and restarted to testing process. “If it’s in there, we’ll be down to less than a million lines of code.”

But it wasn’t there, and by the time we found out, I had already lost 20 precious minutes without reducing the problem significantly. Setho and Peri didn’t seem to mind, lost as they were “remembering their ancestors.”

I started feeling warm, even though I knew that the sun’s heat would not be affecting our interior temperature for another couple of hours. Setho must have noticed.

“Do not be distressed, John. Having remembered our ancestors, we are now at peace. Do you not have ancestors to remember?”

“Most of my ancestors aren’t worth remembering.”

“How sad. No wonder you solve problems by guessing. But surely your ancestors must leave you some worthy memories.”

I paused to enter my third guess. It was even more risky, but I had to make up time. I felt it was more of a gesture than anything useful. Three hours and thirty minutes – 21 guesses – was all that was left.

“None of them ever knew the Zaard even existed, so none of them ever toured effortlessly around the galaxy. What memories could they leave that would do us any good?”

“True. Your history is so strange to us that I never thought that you might not have useful memories. How unfortunate that we know each other better only now.”

“But your ancestors’ memories don’t seem any more useful than no memories at all, if they can’t help fix a failure.”

“Oh, but they can. We have memories of all ship failures in the past, and how to repair them.”

“Then why aren’t you fixing this one?”

Setho gave me a look that even on his/her strange face seemed to say, “Don’t be a stupid Human.” What s/he actually said was, “Because our ancestors never encountered a bi-quinary star system such as this one, so there is no memory of this particular failure.”

“But there were failures before?”

“Of course, but not this failure.”

“And how often do you have these failures?”

“Among the entire fleet, perhaps once every thousand of your years. Would you like to know exactly?”

“You mean you have a record of them?”

Peri now joined the conversation. “Of course. We told you that we remember our ancestors.”

“All of them?”

“Yes, of course. What would be the logic of forgetting errors. We have a saying, ‘A Zaard who forgets his/her ancestors forgets how to stay alive.”

My mind was racing, but my mouth was having a hard time keeping up because I was trying to keep my chest from swelling with hope. “Okay, how many have there been, since the beginning? Or is that too hard?”

“Why should it be difficult? Approximating the time, in the past 180,000 years, there have been 674 distinct ship errors.”

I did the arithmetic in my head. “That’s a mean time between failures of about 250 years.”

“267,” Peri corrected.

“Not bad, but not perfect, either. Maybe your ancestors weren’t as perfect as you thought.”

“We do not think our ancestors are perfect. If they were perfect, we would not have to remember them. But, to their credit, these failures are in a fleet of more than a million ships, so the mean time between failures on any one ship is greater than 267 million years. They are not perfect, but they are very, very consistent.”

I was impressed, but I wasn’t going to show it. “Sure, that’s great. But we’re on one ship, and it’s failing right now.”

“Fortunately,” said Setho, “the signals have already been broadcast, so we will be remembered. You will have the honor of becoming the first Human Zaard ancestor.”

“Oh, thanks, I hadn’t thought about that. But I’d rather live and be forgotten, so what else can you tell me about these errors?”

“What else would you like to know?”

“I’d like to know the distribution of errors across the various Leethaa components – like, which component has had the most errors per element?”

Peri paused for a moment, then announced, “That would be the Nisoog-arthl component, with 402 of the 674 errors, if I have remembered our ancestors honorably.”

“You have,” said Setho, “Most honorably.”

Now my heart was beating audibly, and fast. “And how large is the Nisoog-arthl?” I’m not superstitious, but I crossed all my fingers as I waited for their reply.

They replied in unision, in the Data Voice, “The Nisoog-arthl comprises Eight-hundred seventy-seven thousand nine-hundred and twelve Leethaa.”
As they spoke, my pad displayed the number: 877,912. I could do the necessary calculation in my head. “That’s it, then. One more guess and we’re done!”

I stopped the current simulation, now useless, and entered the boundaries of the Nisoog-arthl as my fourth guess. Now all I had to generate the patience to wait ten minutes to know whether I would live or die. Since Peri and Setho showed utter disbelief, I explained.

“You told me that your ancestors were very, very consistent, but not perfect. When they built these ships they didn’t make many mistakes, but they did make some. And if they were as consistent as you say, then their mistakes would be consistent, too. They would consistently make most of their mistakes in the same parts of the Leethaa. And the one part they most consistently made mistakes in was the Nisoog-arthl – so I’m guessing that’s where this mistake will be found. We’ll know in seven more minutes.”

“Yes, that’s quite logical, in a strange sort of logic, but what good will it do?”

“Yes,” said Peri, also using the Query Voice. “That was a logical guess, but that only narrows the problem down to the Nisoog-arthl. We have no more refined data, so what logic can you use for your next guess?”

“But if the error is indeed in the Nisoog-arthl, I won’t need any more guesses. I can switch to a pure binary search and be sure of narrowing the search to a single Leethaa in the remaining divisions.”

“Aaah,” they said in the Simultaneous Voice, “so in the end you can be logical.”

“And in two more minutes,” Setha continued alone, “we will all know logically whether or not we will visit that sun.”

convert this post to pdf.

© 2003 Gerald M. Weinberg, www.geraldmweinberg.com

P.T. BARNUM said there’s a sucker born every minute, but Barnum was a conservative estimator — or else he didn’t know any IT managers. For more than 45 years now, I’ve watched an endless stream of technical “solutions” being promoted, sold, and quickly put on the shelf and forgotten.

Come to think of it, forgetting these “solutions” is not such a bad result. As someone once said: “A problem is the solution to the previous problem.” At least forgotten solutions don’t become bigger problem than they were supposed to solve.

Remember COBOL? What was it supposed to solve?

As Jean Sammet recalls in her History of Programming Languages, the users for whom COBOL was designed were two subclasses of those people concerned with business data processing problems.

One is the relatively inexperienced programmer for whom the naturalness of COBOL would be an asset, while the other type of user would be essentially anyone who had not written the program initially.

Little solutions

In other words, the readability of COBOL would provide documentation to all who might wish to examine the programs, including supervisory or management personnel. Little attempt was made to cater for the professional programmer.

I have clients today who are maintaining, with professional programmers, tens of millions of lines of COBOL code — and no supervisory or management personnel would dare to look at a single line, let alone change one.

COBOL solved some little problems, but left us with a much bigger one. Because these organizations are busy chipping away at the incredible mountain of maintenance, new development work of organizations falls behind.

Like addicts deprived of their drugs, the customers are eager for a “quick fix,” and ready to deal with any pusher. One quick fix is called “rapid prototyping.” Almost all of the “rapid prototyping” I’ve so far seen hasn’t been all that rapid, but that doesn’t matter, because it hasn’t been prototyping either.

I know that statement will bring letters from a hundred vendors agreeing with me – except as far as their product is concerned. But that’s not the battle I want to fight. Nor am I concerned that where prototyping works, it often works backwards. In building airplanes, for example, a prototype often leads to a higher rate of failure in the final version because the prototype makes the builders overly ambitious about the successor.

But let’s put these little quibbles aside and assume that everyone’s rapid prototyping system is both rapid and prototyping. Let’s grant that they work (after all, COBOL worked) and contemplate some of the consequences.

Santayana said that those who failed to study history were condemned to repeat it. I suggest we study the history of that earlier rapid prototyping language, COBOL, so perhaps we won’t all repeat it.

Although many today consider COBOL a failure, objective analysis says it was a great success. If it hadnít been a success, we wouldnít have billions of lines of COBOL code to maintain.

Here is a riddle: How do you accumulate a billion lines of COBOL code? Answer: one line at a time. In most cases, thatís literally true, because very few of those billions of lines consist of original code. Over the years, as requirements changed, the COBOL programs have changed. Studies indicate that in a mature COBOL program, there have been three lines written for every one that remains in the code.

It took many programmers many years to accumulate those billions of lines, one line at a time. But we’re lucky, because now that we can program so much more rapidly, we won’t have to wait as long to accumulate our mountain of rapid prototype code.

In fact, now that we’ll eliminate the professional programmer, we’re going to have 100 times as many people developing prototypes. It took us half a century to get into the COBOL mess, but with rapid prototyping we can surpass that in a few weeks.

It’s not just the volume of COBOL code that causes the huge maintenance effort. Volume must be multiplied by a quality factor, because low quality code takes more effort to maintain. Yes, I know rapid prototyping languages are supposed to produce more readable code — but have you looked at any? Have you seen what happens after the users have made a few changes?

Lessons of history

History teaches us that when the users do actually make those changes, their ambition quickly outstrips their skill and the capacity of their language. At this point, they turn to the more experienced — the professional programmers who already are buried in COBOL code.

Again from history, we know that the more different people using code or data, the more constraints there are when it comes time to change. The amount of constraint makes each change more difficult, so a constraint factor must be added to the maintenance effort equation.

There may be some hope of controlling all this, but history teaches that most IT managers are going to go into a dopey daze in the sand while this quick fix enters the bloodstream of their organization. They can look forward to more maintenance, more difficult maintenance, done under greater constraints, with greater shortages of professional staff. Because they’re in a dopey daze, however, they won’t be looking forward at all.

The only people who can resist a quick fix are those that are not addicts. The only organizations that can avoid turning the maintenance solution into a maintenance trap are those that already have their maintenance under control. But that takes good management, for which there is no quick fix.

The moral of this story for my readers: Don’t despair of these hard times! There will always be enough work for those who are willing to slowly fix those quick fixes.

convert this post to pdf.

©2003 Don Gray, www.donaldegray.com

I remember when I first started solving problems for a living. I would leap down the stairs three at a time, race to the computer room, and stare at the line printer (yes, it was that long ago) trying to determine what had happened, and what to do about it. I couldn’t possibly slow down. I had to “Just Do It!” They were depending on me. Of course, by the time I was notified, the problem had already happened, and there wasn’t anything I could do to turn back the hands of time. So eventually, I went down the stairs one at a time, walked to the computer, and was calm and composed when I started investigating the problem.

Now that I spend time working with people, the habit of “Don’t Just Do Something, Stand There” serves me well. But for me, “standing there” is an active event. I use this time to determine what is happening, how it is happening, and the best course of action before diving in. To help me with this effort, I use the following techniques:

Gather Some Information

The first activity is gathering information. Asking open-ended questions keeps me involved in what’s happening while I’m standing there. Three of my favorite questions are:

1. How did you (we) come to be here?
2. How do you feel about it?
3. What would you like to have happen?

These questions can be answered on many levels. You might hear the history of actions. Maybe you’ll hear about the decisions and personalities involved. Another possible response is a story of emotional highs and lows. The response you get will tell you about the corporate culture. Superficial responses indicate a closed culture that doesn’t tolerate free thinking very well. An open, honest, well-balanced response indicates a safe culture where individuals are encouraged to think and speak freely.

As I gather information, I try to use as many of my senses as possible. As I listen, I watch and see if the body language, facial expressions, and setting agree with the words. Is the information coherent? Do I have enough information, or do I need more? Common problems with information gathering involve getting too little information or getting too much.

Decide What the Information Means

The next activity as I stand there is to figure out what the information I’ve gathered means. It’s probable that the message I’ve received is not exactly the message that was sent. This is because, as Bandler and Grinder said in The Structure of Magic, “there is an irreducible difference between the world and our experience of it. We as human beings do not operate directly on the world. Each of us creates a representation of the world in which we live, that is, we create a map or model which we use to generate our behavior.” In other words, there is always some interpretation going on.

To help improve the odds of getting the right message, I like to use Jerry Weinberg’s Rule of Three. The Rule of Three states: “If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.” Then of the three, I can select the interpretation that seems to best fit the situation at hand.

For example, in reviewing project progress, I sometimes hear, “I thought you were going to do that.” Three possible interpretations (among many others) might be:

1. It wasn’t clear who was going to do this task.
2. You’re right, I’m wrong, and I’ll get right on it!
3. I am a bad person because I didn’t do what you thought I was going to do.

Evaluate the Significance of the Interpretation

This raises the significance question. How do I feel about the interpretation I select? Even though the interaction I’m working on is external, how I approach the matter is influenced by my feelings and world model. Additionally, the significance I associate with the selected interpretation may not have any relationship to the significance assigned by others.

When determining the significance of my interpretation, a wonderful check is “What have I seen or heard that makes me feel this is the best interpretation?” This data question serves as a check on my processing, and allows another view of what I feel is happening.

Now Do Something

After getting information, selecting a meaning for it, and determining its significance, I’m ready to make a response. I’ve found that following these steps keeps me from jumping the gun and doing things before I’ve fully processed the situation.

How long should this “standing there” take? The quick answer is “It all depends.” In actual practice, it doesn’t take long. And the time spent is redeemed by the increased effectiveness of my work. My mother was right. She always told me, “Before you do something in haste, you should count to ten.” Now you know what I do while I’m counting!

convert this post to pdf.

©2003 Gerald M. Weinberg, www.geraldmweinberg.com

The introduction of the new $20 bill has me thinking about the Bureau of Printing and Engraving today. They’re one client I ever had who couldn?t use the slow-payment excuse that they’re short of cash, since they print the stuff. One of the most irksome parts of being an independent contractor is the client who doesn’t pay, or at least seems like they won’t pay in time for you to pay your own bills.

First of all, this is not a new problem, so it’s important not to take it personally. Taking it personally only gets you annoyed and out of your best thinking mode. True, some clients believe that contractors don’t need to think creatively: “Just keep your ideas to yourself and get back to coding,” they say, but they’re wrong. Creative thinking is your best ally when it comes to getting your fair share of the cash.

There are, of course, traditional ways of enticing your clients to pay you on time. My father was in the auto painting business, and I recall how careful he was to pay his paint bills on time in order to earn his “2% discount for payment in less than 30 days.” Knowing that this discount strategy worked well to motivate my father, I once tried it on a slow-paying client.

This multi-billion-dollar company had typically taken 4-5 months to pay my tiny bills. I started adding that “2% discount” clause to my bills, and sure enough, it motivated them to change their behavior. They still paid in 4-5 months, but they now deducted 2% from every bill.

I learned several lessons from this experience. The first lesson is that large clients have payment patterns that no rinky-dink contractor is going to change. I call this Gilb’s Law, because I once asked Tom Gilb about a recruiting firm in Europe that wanted me to do some work with them. I’d had some trouble getting payments overseas, so I asked him about their payment practices. “Oh,” he said, “they always pay. Eventually.”

In short, their consistent pattern was reliable, but slow. The second thing I learned was that I can use the client’s consistency to my advantage. Knowing that they typically paid 6 months late, I inflated my normal billing rate by an amount equal to 6 months of interest on that rate. If they wanted to compete with my bank for my CDs, that was fine with me (but I did add a tiny bit more because they didn’t offer Federal Deposit Insurance).

This strategy has worked well for me ever since. The most important part is that I no longer get annoyed with my clients for playing financial games with my money. It’s never a good idea to get annoyed with your clients, so it’s never a good idea for someone like me to feel that I’m a victim of my client’s lack of adaptability. After all, if I’d wanted to be a helpless victim of a large corporation, I could have been their employee?and gotten health insurance to pay for my psychiatric bills.

A few clients actually understand their own slow-pay patterns and have worked out solutions that I have adopted as my own. (As Tom Lehrer says, “if you steal from one person, it’s plagiarism; if you steal from many, it’s research.”) I gave a short course once at a large government agency, and I was picked up at Washington National airport by Chuck, my contact at the agency. As we drove to the agency, Chuck asked if I was in a hurry to get paid. “How much of a hurry?” I asked. (That’s another good consulting technique?answer difficult questions with other questions.)

“Well,” he answered, “we seem to have a difficult time processing this kind of payment in less than eight months.”

“In that case,” I said, “I’m in a hurry.”

“I thought you might be,” said Chuck. “But don’t worry, we can pay you in cash.”

This wasn’t the Bureau of Printing and Engraving, so I was rather surprised that they could actually do cash business. I told Chuck of my doubts, but he reassured me. “In fact,” he said, “we’ll get you paid in advance, just in case there’s any hangup.”

And, sure enough, when we arrived at the agency, he took me directly to a barred window marked “Cashier.” The little guy behind the window lacked a green eyeshade, but otherwise looked just like the teller in a bank about to be robbed in a Clint Eastwood Western. He didn’t even blink when Chuck slipped him a hand-written voucher for $2,500. He asked me for some identification, then a signature, after which he counted 25 hundred-dollar bills into my hand. I was then led to the classroom where I gave a stunning class, never once being distracted by worries that I might not be paid.

I’ve now added “cash in advance” to my repertoire of payment possibilities. It’s especially useful in cases of doubt or complication, such as working overseas. There can be drawbacks?every solution creates new problems, as every consultant knows. Once, after an extended tour of Japan, my sponsor had me in for a tea ceremony, during which he handed me an envelope wrapped with a red ribbon and containing, I presumed, my fee for the visit?in cash, as our contract had stipulated. I thought it would be discourteous to count it in front of him, but as I was about to slip it into my inside pocket, my translator suggested it would be rude not to count it.

Knowing that cultures differ, I opened the envelope and counted over $10,000 in crisp new American money. The amount was correct, but counting it raised my anxiety about carrying so much cash. I wanted to take it to a bank and convert it to some sort of non-negotiable instrument, but I was told, regretfully, that it was “Honor Old People Day,” so the banks were closed. That night, I slept with the money under my pillow (and not too well).

The next morning I had to leave for the airport before the banks opened, so I had to carry the cash with me all the way home. I learned, also, that when you carry more than $10,000 cash into the USA, you have to have a friendly discussion with the customs agents?a discussion in which you must convince them that you’re neither a counterfeiter nor a drug dealer. I also discovered that it wasn’t even that easy to deposit that much cash in my own bank?once again, lots of rather personal questions.

In other words, cash has some disadvantages of its own, in addition to the disadvantages of money in general. Disadvantages of money? Yes, life is never as simple as we contractors think it should be. Indeed, the worst accounts receivable situation I have had to solve?the one that took all my creativity and more?was when, Lily Gilding Limited (LGL), one of my best clients paid the same bill twice .

The bill was $4,240. (It would have been $4,000, but I had added the interest for their 4-month pay cycle.) The first check arrived right on schedule?that is, four months late. Unfortunately, even before I had time to spend all of it, a second check arrived?same invoice number, same amount, same date.

LGL was a good client, so it wouldn’t have been good business to try to pretend that we didn’t get the second check. We called their Accounts Payable Department right away to tell them of their double payment, but they said, “No, you must have made a mistake. We couldn’t possibly have paid you twice. We have controls . You’d better have the manager of your Accounts Receivable Department check your records.”

I smiled, thinking of how Lois would feel being called the “manager of the Accounts Receivable Department,” but I kept my mouth shut. A/P departments can only talk to A/R departments, not to the do-everything-person-named-Lois in a small consulting firm. Lois checked everything again, and I double-checked Lois’s records. Same result. LGL had definitely paid twice.

After about twenty calls back and forth, I became convinced that LGL could never admit to such a mistake. I then brought the matter to the attention of my contact person, Nel, and she made a few phone calls on my behalf. Next time I was consulting at LGL, Nel told me, “I’ve tried everything I can think of. My advice to you is just to keep the money.”

“But I can’t do that,” I protested. Mostly I was thinking that LGL might someday discover their error and think I was dishonest. It’s always harder take being thought of as dishonest when you really are dishonest.

“No, really,” Nel said. “Even if you could finally get us to take it back, it would cost us more than $4,240 to get it cleared up. Believe me, this is the best solution for both of us.”

Well, she was right, of course, but Lois is one of those honest Nebraska farm women who simply couldn’t keep money that didn’t belong to her. She simply wouldn’t accept any solution that involved us keeping their money, so I turned the problem over to her?having exhausted my own creativity. And, as usually happens when I have the courage to admit I can’t solve a problem, Lois found a way.

Her solution may not always work for you, but since LGL was a good client, Lois simply deducted $4,240 from the next bill she sent them and called it a rebate. Apparently they were happy to receive a “rebate,” and we never heard another word from them. Another accounts receivable problem solved, and another happy client!

What?s the moral of all this? It reminds me that when you?re in business for yourself, your problems never end, and even that wonderful event – getting paid – can be one of your worst problems.

convert this post to pdf.

©2005 Gerald M. Weinberg

The other day, I was trying to help a client (let me call them “StartupCompany”) mired in conflicts, exceptions, errors, anomalies, lapses, modifications and other deviations from the norm. These annoying exceptions were playing tricks with my blood pressure, so I had to be wired to a wearable blood pressure computer for twenty-four hours. As if StartupCompany didn’t have enough interruptions, now my wearable computer was inflating a blood pressure cuff at random intervals throughout the day.

Every time the cuff inflated, I petulantly asked myself: Why can’t they run a project like real people living run-of-the-mill, low-blood-pressure lives?

That night, I was using the Yellow Pages, and in the A categories in the Yellow Pages index, I chanced to notice a curious pattern. Here are the first few items:

Abortion Services and Alternatives. These were the first two entries in the index. I decided to skip them both, so as not to take sides in the pro-choice/pro-life conflict. I had enough conflicts within StartupCompany.

Abuse – Men, Women, Children. I decided to continue my scan of the index, and this was the next entry. The normal process of family living involves people loving and respecting each other, communicating well, and behaving appropriately according to societal norms. But when people start behaving inappropriately, they need Abuse Services. In StartupCompany, people normally respected one another, communicated well, and behaved appropriately according to societal norms. But they sometimes didn’t, and they lacked “abuse services” for coping.

Academies (including private schools and special education). When the formal education system doesn’t provide special knowledge or handle special cases, private academies and special education are called for. People within StartupCompany often needed to know things they hadn’t learned in the public schools, but StartupCompany had no provision for special education.

Accident Prevention. Accidents aren’t “supposed” to happen, StartupCompany had accidents. In order to improve, they needed processes to prevent accidents and to mitigate their consequences.

Accordions. Despite what some people think, accordions are perfectly normal, though not everybody learns to play them or appreciate them. Still, StartupCompany could have used some entertainment to lighten the mood once in a while.

Accountants. Accounting is also normal, but, if everything always went according to plan, we wouldn’t need to account for things so carefully. We have to protect our financial well-being from mistakes and misbehavior, and that’s what accountants do – and also what they should have been doing in StartupCompany.

Acetylene Welding. Some welding is normal, and some is for repairing things that are not supposed to break – but do anyway. StartupCompany lacked a “welding team” to handle lots of stuff that broke.

Acrylic Nails. Most normal people have fingernails, so why is there a nail business? Oh, yes, it’s the human interface, and StartupCompany had to cope with conflicting ideas of what made a system beautiful – but they had no special beauty experts to resolve the conflicts.

Acting Instruction. We all need to “put on an act” now and then when we’re caught by surprise. StartupCompany’s people certainly needed training in how to behave in improvisational situations, but there was no acting instruction.

Acupressure/Acupuncture. If we were all healthy all the time, we wouldn’t need medical services, and if “normal” Western medical services worked all the time, we wouldn’t need acupressure and acupuncture. So, there are not only abnormal services, but meta-abnormal services – the services when the normal abnormal services fail – certainly true in StartupCompany.

Addressing Service. Have you ever tried to maintain a mailing list? Almost all the work is not the mailing itself, but maintaining the addresses. It’s even worse for email, because email services haven’t yet evolved “normal” ways of dealing with changes. Gee, neither had StartupCompany.

Adjusters. Adjusters, of course, are an abnormal service from the get-go. Without accidents, we wouldn’t need insurance, and if things stayed on course, StartupCompany wouldn’t have needed risk analysis. But they did.

Adobe Materials and Contractors. Adobe materials may not be “normal” where you live, but here in New Mexico, adobe is a normal building method. StartupCompany, too, has its idiosyncratic processes that are not normal in other projects – and newcomers have to learn about them or pay the price. But StartupCompany had no special services to bring newcomers up to speed.

Adoption Services. Yes, sometimes people are not wanted by their parents, and StartupCompany certainly had some unwanted people. But, they lacked “adoption” services for moving unwanted people around.

Adult Supervisory Care. “Normal” adults can take care of themselves without supervision, and normal workers wouldn’t need much managing at all. But StartupCompany had two adults who could not take proper care of themselves, and the managers spent an inordinate amount of time on these two out of a hundred.

I stopped there, sobered by my reading. It was now clear to me that StartupCompany, being a startup, had an overly simplistic picture of what it takes to run a company. I needed an adjustor to adjust my blood pressure – I needed to see that my job as their consultant was to teach them that deviations are normal, and that they (and I) could do what real people do:

• stop whining and deal with them
• create systems to deal with them
• create systems to prevent them

convert this post to pdf.

©2007, Gerald M. Weinberg

This morning’s news brings a story of a small manufacturer of add-on
hardware suing large computer manufacturers for alleged illegal price-cutting.
I was surprised. I thought the lawyers had finally learned the futility of suing
hardware makers over pricing.

Ordinarily, I have an aversion to lawsuits, and even to news about
lawsuits, but my surprise told me I might learn something if I looked further
into this one. It seems that the company’s sale of add-ons had fallen by some
thirty percent in one year. Stockholders usually want explanation when sales
drop even by a factor of one percent, so management looked around and
discovered that the big guys had dropped their prices on similar add-ons, just
around the time sales began to fall.

My older sister, Charlotte, is a lawyer. Charlotte’s always bragging that
law school is great training in logic.
She taught me the logical fallacy that goes by the Latin name,
post hoc ergo propter hoc, which in English means “after
this, therefore because of this”. The fallacy lies in thinking that because one
thing comes after another, the first thing is the cause of the second. Because
manufactuers dropped their add-on prices, the plaintiff’s lawyers reasoned, its
own sales fell.

The courts will decide whether the company’s post is truly the
manufacturers’ propter, but obviously there is another explanation. Anyone
who has studied the history of hardware prices knows that once a particular
line starts losing value, it drops incredibly fast-along with any add-ons.

So it could be that the company was the victim of its own belief that it
could continue making profits with an obsolete technology. If so, they
wouldn’t be the first to make that mistake in reasoning.

I never went to law school, but this fallacy is so common among high tech
managers that it deserves an impressive Latin sounding name. Forgive me, but
let’s call it bonus antequam, ergo bonum postquam”: it was good before, so it
must continue to be good.” Or, if you prefer Street English to Fractured Latin,
“Shut up and keep rowing!”

The high tech business has great appeal for people who would like to
make a lot of money. One good idea can make you as rich as Midas-but a
second good idea can transfer the golden touch to someone else and put you in
the poorhouse. It is no business for cowards. As soon as you lose your nerve,
you stop investing in new ideas. And as soon as you stop investing in new
ideas, your days are numbered.

Hardware or software, it makes no difference. Poor managers destroy the
environment that nurtures new ideas, the ideas run dry, someone with more
daring improves on your idea, and finally, sales plummet. Some managers
react by going outside to buy new technology. Better managers react by
changing the environment to get the ideas flowing again. The worst managers
call in the lawyers and sue the competition for stealing their ideas or competing
unfairly.

In a high tech market, the return on resources invested in new ideas is a
thousand times greater than a similar investment in lawsuits. Lawsuits are
tempting only when innovation is drying up-at least in the organizations that
were the early leaders.

That’s easy to see from the outside, but it doesn’t feel that way to the
insiders. When this happens to us, we feel genuinely robbed, cheated, and
betrayed. These angry feelings destroy our ability to keep innovating, so
lawsuits seem the only reasonable alternative.

I understand these angry reactions because I’ve felt that way myself when
someone had “plagiarized” my work. Sometimes entire paragraphs and even
articles have been copied word for word without a hint of credit.

When I cool down, I begin to see things differently. I’m in the ideas
business, not the lawsuit business. My big payoff comes from writing
something new, not hanging onto things that are done and gone. Sure, if the
culprits have actually copied word for word, I’ll have my secretary write a mild
letter suggesting that they must have made a clerical error in forgetting to
obtain permission and make a reference. People, who have to copy the work
of other verbatim are not much of a threat to my continued existence, so why
threaten them? (I have sued once, and won a bundle, when the plagiarizer
claimed I had plagiarized him. That behavior triggered a different kind of
anger.)

When the copy is not exact, I often write a personal letter to the copier,
noting the remarkable similarity and suggesting that our thoughts and interests
have a lot in common. This sometimes brings apologies, and sometimes starts
a long-lasting friendship with someone whose thoughts and interests do run
parallel to mine. One such friendship is worth the price of hundred old ideas-
even if they were actually stolen-and is often the source of a hundred new
ones.

But sometimes I have trouble cooling down and getting rid of my
irrational desire to sue. Lately, I’ve come to understand that this anger actually
is a symptom of something else-a strong feeling of inadequacy. Just like those
managers who fear that innovation is finished, I’m afraid that I no longer have
what it takes to turn out new ideas.

Instead of reacting by creating a batch of new ideas, I start grasping for
ways to protect the ones I’ve already produced. In short, I’ve lost my nerve.

I’m not ashamed to admit that I sometimes feel that way. When it takes
all the running you can do to stay in the same place, it’s no shame if you
sometimes feel weary of running. Every technical hotshot, at some time or
another, has to face the feeling of wanting to stop and live off past glories.

Each time that happens to me, I get frightened, and angry, and unable to
produce new ideas. Then I rest for a while, do some new things (like writing
novels) and eventually get back into the racket again.

convert this post to pdf.

©2003 Gerald M. Weinberg, www.geraldmweinberg.com

I’m not the kind of person who hangs out in nightclubs. In fact, the last nightclub I can remember visiting was in Miami Beach in 1957. What I remember about it is what the stand-up comic said.

After warming up the audience with some rather gross remarks, he commented that early in his life he had learned the motto he had lived by every since:

Sound mind; sound body …
… Take your choice!

How funny to hear it articulated so clearly, but many of us did make this choice early in life. Somehow we got the impression that athletes are stupid and software developers are flabby – and that we must make choose one or the other. Actually, though, a reasonable level of physical health increases the effectiveness of my intellectual work. Increased effectiveness then produces more slack time in which I can pursue healthy practices. So, good health tends to produce better health, at the same time that it produces better mental health.

But this syndrome works both ways. Poor health tends to produce poorer health by diminishing work effectiveness, which in turn causes work to pile up. Piled work causes me to overwork, consume junk food in haste, and generally ignore my physical well being. Eventually, my health becomes even poorer, and the cycle continues unless I can manage to break it in some way. I become, literally, stupid – “in a stupor; deficient in alertness; lacking in the power to absorb ideas.”

But this kind of brain dysfunction is merely the grossest kind – akin to the effects of being struck on the braincase by a piano leg. The brain is a complex problem-solving device whose functioning we still only vaguely understand. We know that the piano leg will put the brain out of commission, as will sickness. But we also know that a computer can be put out of commission with a sledgehammer, or by pulling the plug. What interests me now is some more subtle elements of my brain. Those subtle elements make people want to hire me as a consultant, treat me like royalty, and pay me large sums of money.

My interest in subtle brain factors drew me to reading an article about “personal chemistry.” The author’s list suggested some of these success factors:

Articulate: writing and speaking fluently in at least your native tongue.

Thoughtful: weighing a question for a few seconds before responding.

Bright, informed, sparkling: difficult to define, but obvious if a person doesn’t have it.

Breadth of interest: able to carry on an intelligent conversation without permitting embarrassing gaps because of lack of interest or education.

Unfortunately, the author seemed to suggest that you can somehow wipe a veneer of “chemistry” over your otherwise dull, boring self. For instance, he says, “brief reflections give the impression that you have good judgment” – not good judgment, but the impression of good judgment.

At this level of analysis, brain chemistry consists of a set of rules. For example, “count to three before you answer a question, so people will think you are thoughtful.” In the typical steamy working environment I usually encounter, however, this kind of veneer peels quickly, revealing all my ugly lumps and hollows underneath. No, if I truly want to be more articulate, thoughtful, bright, informed, and sparkling, rules won’t suffice. I have to devote some time and effort to the job.

My acquaintances who don’t work with computers tell me that software people are the dullest people they know. I have a hard time believing this assertion. We all know that computers aren’t dull – they are an endlessly fascinating subject. But let’s face it. There is more to life than computing, and more parts to our brains than those we use in our professional work.

At AYE Conferences, I’ve repeatedly seen that problem-solving behavior becomes stereotyped when people work in a closed situation. Once they find one or two tricks that work well, they tend to adopt those to the exclusion of all others. I wish we presenters could take more credit, but most of the effectiveness amplifying that takes place at AYE seems to come from exposing the participants to the problem-solving styles of other participants.

My consulting problems are growing more difficult. Systems are growing more complex; needs are growing more demanding; because of past successes, my expections run high. If I remained at the same level of problem-solving effectiveness, I’d soon accumulate a deadening backlog of unsolved problems. With a little slack time, I have some possibility of “outside” activities that stimulate those parts of my brain I don’t ordinarily exercise at work. Without such activities, my problem-solving effectiveness would grow ever more narrow and specialized. New problems would then become unsolvable problems.

My brain is a muscle. Like any muscle, it requires stimulation to remain healthy. If I’m locked into a pattern of work, work, and more work, my brain soon stagnates. Paradoxically, if I want to be more effective at work, I must be less single-minded in my devotion to work. Anything I do that stimulates new segments of my brain will make me a better programmer, or tester, or analyst, or manager, or writer, or consultant.

Many technical folks, seeking this kind of stimulation, enroll in university courses. Some are successful, but some are not. Perhaps the course is dull – not stimulating at all – yet they persist because their employer is paying the tuition and they are embarrassed to quit.

Or, the course may be too “relevant” to their work – more of the same bland diet they consume every day on the job.

If you want to keep your brain healthy, you might do better seeking your stimulation outside the formal education system. For instance, change your TV-watching habits, not necessarily to something more “intellectual.” Or, if you never watch TV, a little tube time might prove a stimulating change. If you don’t read anything but manuals, pick some paperback at random on the way home and read it – but stop if it’s dull.

If you read frequently, read something different. Or, stop reading for a few days and just open your eyes and ears and nose to the world around you. I find that natural settings always make my brain sparkle.

If you must attend courses or conferences, participate in something your employer would never pay for. That way, you can quit if it’s dull and move onto something healthier for your brain. Sound mind; sound body – it’s not a choice, it’s a mandate.

convert this post to pdf.

©2002 Gerald M. Weinberg, www.geraldmweinberg.com

On a typical day, I get 100-200 email messages, and some of my clients in large projects receive even more. Though emails improve my ability to communicate clearly and quickly, they may also prove a hindrance to certain kinds of communication. In particular, email does not adequately serve as a medium for recording an important agreement. An important email may be too transitory, too easily lost among volumes of less important communications, too easy to misunderstand, and too easily lead to unnecessary conflicts.

Although email can reduce the need for personal contact, it cannot entirely eliminate contact between teams building components that must work together to form a system. Separation of teams tends to create language differences that lead to misunderstood emails. Teams develop local goals that may diverge from project goals and actually conflict with other teams’ goals. With different language and divergent goals, interfaces stop being stable, clear, stakes in the ground. Instead, they can easily become the disputed border between two warring states or two different cultures. To prevent border wars, I prefer the ancient solution – writing and signing treaties.

A software treaty is more or less identical to a treaty between political units. I like my treaties to be written on a single piece of paper with a fancy border, like a gilt-edged stock certificate. A typical treaty might contain.

1. A reference to the technical terms being agreed to – such as a reference to a specific version of a document in the project’s repository.

2. A statement that all signatories agree to the technical terms in (1).

3. A statement that the treaty will remain in effect unless and until renegotiated among all the signatories.

4. Dated signatures of each team’s official representative – most often the team leader. The treaty implicitly recognizes the independence of the signatory teams and their ability to enter freely into agreements on technical matters.

5. (Possible) Management signatures witnessing the treaty.

Although a manager quite likely acts as facilitator to the negotiations, treaties will not work if parties are coerced into signing something they don’t understand, or don’t agree with. Nor will they work if some affected party fails to participate in the negotiations and sign the treaty, so management must ensure that all affected parties are represented.

After signing, however, good management becomes mandatory to enforce the pact the parties agreed upon. In other words, once each party freely gives its signature, the matter is no longer a purely technical one, but becomes political.

Why political? Because after the agreement, one party could disrupt the project and/or make the other party look very bad by covertly changing the agreement. A written treaty seals off this avenue for expressing any animosity or mistrust that exists between the parties. When people understand that management will rigorously enforce each treaty, they can quit bickering and get down to the business of building. Moreover, teams can work with the assurance that anything not in a treaty is not a commitment – and will not become a commitment without going through the treaty process.

With signed treaties covering all interfaces, no single team can disrupt the project by covertly changing the rules in the middle of the game. Woe to any team that fails to meet the interface specifications agreed upon in their treaties.

What happens if one party to the treaty decides they made a mistake, or got a poor deal? For instance, during the negotiations, I might have agreed to pass error-free data in return for two milliseconds more of execution time, but now I find that I cannot scrub the data that fast. I can then call for a renegotiation, but I may have to trade something else for the relief I seek – even something that will simplify my enemy’s job.

Such a concession may prove a bitter pill for me to swallow, especially as the renegotiation is done in front of management, but I have to understood that unilateral changes to my treaties will damage the project and make my life much less pleasant.

The startup of a treaty system will sometimes seem awkward, unfamiliar, and overly formal. I know from history, however, that this degree of formality is needed if former antagonists are to work together cooperatively. White ties are optional, however, and quite soon the awkwardness dissipates.

We frequently see one party resist actually signing a treaty, but such resistance always indicates that the resisting party is uncertain. Because the whole treaty process is designed to eliminate uncertainties, resistance tells me what I want to know that there is still more definitional work to be done.

Treaties are especially helpful for contractor professionals, who may rush into a poorly understood commitment in their eagerness to improve their cash flow. But no matter how much I hope that the definitional job is finished, the strong commitment implied by a signature prevents me from mistaking hope for reality.

By keeping communications on the level of reality, rather than hope, I may create a few problems today, but I avoid bigger problems tomorrow.

By making agreements between cooperating parties a strategy for peace, I avoid the hardest problems of all, the misunderstandings that lead to interpersonal conflicts.

convert this post to pdf.

©2005 Steven M Smith

Jake tossed and turned. He looked at the bedside clock. 3 AM. “I need sleep,” he thought to himself. But sleep would not come. Only worry about tomorrow’s meeting.

Edmund, Jake’s manager’s manager, enjoyed probing managers in his organization to discover how well they were doing. He expected his managers to lead people so they wanted to follow. And he expected them to have complete command of their business. “There are no bad soldiers,” the retired Army Captain loved to say, “only bad officers.”

“Am I a bad officer?” Jake wondered. “How would Edmund even know? He doesn’t understand Storage Resource Management (SRM), and that’s my organization’s total responsibility — everything from provisioning to backup to disaster recovery.”

His eyes were wide open as he stared at the ceiling thinking about what questions Edmund would ask him. His mind raced through the standard list, contemplating his responses.

“Where do you stand versus budget?” (I’m square on that, with the paperwork to back me up.)

“What are our biggest risks?” (My risk spreadsheets should toss out this one.)

“What are we doing to mitigate those risks?” (Yep, the spreadsheet will handle this, too.)

“What’s the morale of your staff?” (Hmm, that’s harder, but I’ll ask my most vocal people this morning.)

“So why am I tossing and turning?” Suddenly he sat up in bed, wide awake. “It’s storage utilization. He’s going to ask me why utilization is only 50%.”

“He’s going to ask about that, first thing, because it looks like a glaring management problem. Especially since just last week I made a procurement request for more storage — which he hasn’t signed yet. Sure as heck, he’s going to ask me why.”

The alarm sounded. 3 hours had passed. Jake hadn’t slept a wink. 4 hours until the meeting with Edmund.

Jake slid out of bed and stumbled into the bathroom. He looked in the mirror and saw the big bags under his eyes. He fired up the shower, tested the water, which was just right, and jumped in. He did his best thinking in the shower. He needed a revelation.

“I must be managing better than the data shows,” he muttered to himself as we washed his hair, “The utilization number doesn’t tell the whole story: I need all the storage I have and more.”

The shower water began to cool, and he hadn’t finished rinsing. “Darn,” he thought. “I should have installed a bigger hot water heater.” Shivering as he rinsed away the suds, the idea snapped into his head. “Of course. Data storage is just like the hot water.” He scrambled out of the shower and grabbed a towel.

He wrapped the towel tightly around his freezing body, but his mind was running a mile a minute. “Data storage is like the hot water — it requires a safety margin to prevent the business from being impacted by a shortage.”

Clarify the Story

In my experience, Jake isn’t alone. Managers of storage organizations everywhere face the difficult task of providing a simple explanation to upper management about resource utilization.

I have faced this problem many times throughout my career. I have never forgotten the words of the CIO of Consolidated Freightways, “Steve, we never send our trucks out half full. I expect us to fully utilize all of our IT resources in the same way we fully utilize our trucks.”

His comparison is the first clue to explaining resource utilization to upper management. The utilization that you report is compared with other resources that may have much different utilization characteristics. 100% utilization may appear possible in the packing of a truck but it isn’t possible with storage. Show me a fully utilized disk array with dynamic data and I’ll show you a broken system.

Compounding the explanation problem, upper management wants to understand resource utilization and its relationship to cost with minimal understanding of the underlying technology. They pay you to understand, manage and measure.

Storage managers typically answer the following questions:

• How much storage do we have?
• What percentage is allocated?
• What percentage is unallocated?
• What percentage is allocated but not being used (free space)?

Note, it’s easier for everyone if the percentages all refer to the same quantity, namely the total amount of storage.

A manager who answers as follows will trap themselves:

1,000 Terabytes
95% Allocated
5% Unallocated
50% Free

Why a trap? Because upper management will sum Unallocated and Free and ask the inevitable question, “Are you telling me that 55% of our storage isn’t being used (my costs are more than twice the amount truly required)?”

Caught flat footed, the typical storage manager answers, “No, uh-uh…. I mean yes,” followed by a long, complicated explanation that doesn’t satisfactorily answer upper management’s question and, most importantly, wasn’t desired.

Upper management will certainly doubt whether the manager of a storage management group is effectively managing his or her costs if they hear unused space is greater than 40%. Don’t trap yourself.

Save yourself a lot of grief by adding answers to the following questions:

• What percentage is a safety margin?
• What percentage is now free after factoring in the safety margin?

What does Safety Margin mean? It’s space reserved for growth. A dynamic file system or database must have free space for growth. Let’s use a conservative 20% rule of thumb for the Safety Margin for each file system, for instance a 100 GB file system would thus have a 20 GB reserve as a safety margin for growth.

Upper management needs to know that without an adequate safety margin they risk an unplanned system outage. A series of requests for more storage than is available will cause an outage, which may impact a critical business function.

And, finally, upper management always likes numbers to add up so transform the percentages so their sum is 100%. That means rather than reporting Allocated, you report all its elements — Utilized, Safety Margin and Free.

With answers to the fifth and sixth questions and transformation of the percentages, the storage manager can say:

1,000 Terabytes
50% Utilized
19% Safety Margin
26% Free
5% Unallocated

Calculate Utilized as 100% minus what we previously called Free (50%), which equals 50%. Calculate Safety Margin as 20% of Allocated (100% minus Unallocated), which equals 19%. Calculate Free as Allocated (100% minus Unallocated) minus Utilized minus Safety Margin, which equals 26%.

When upper management now sums Free and Unallocated, they arrive at 31% rather than 55%. They will ask for better results, but they won’t think you are an ineffective manager.

And everything you are sharing with them is a fact. You have simplified the story so they don’t become frustrated by unneeded and undesired explanation.

Tell the Story

Jake arrived at the office at 7:30 AM. The meeting with Edmund loomed over him, but he was determined to put to use what he discovered in the shower.

Without the revelation, Jake would have shared with Edmund the following state information:

2,500 Terabytes
95% Allocated
5% Unallocated
50% Free

Jake used the safety margin concept to transform the state information as follows:

2,500 Terabytes
50% Utilized
19% Safety Margin
26% Free
5% Unallocated

He discussed morale with two of his most vocal people. They reported that they felt good about things and they thought others did too. He walked into Edmund’s office at 10:00 AM feeling fully prepared.

Edmund asked him the usual questions. And Jake felt good about his answers. Edmund was pleased to hear that the morale of Jake’s people was high.

Edmund asked Jake, “What is the utilization of the storage?” Jake shared with him the five numbers and explained to Edmund the safety margin concept. He nodded and said, “You are telling me that we need a certain percentage in every file system as a reserve to prevent application outages.”

Jake smiled and replied, “Exactly. It’s just like with the disk on your PC. If you want to put more files on it, you must have available space.”

Edmund smiled back and asked, “Why 20%? Why not 10%.”

“20% is a starting point. I will monitor and calibrate it as we get more experience. And I’ll report what my team thinks is an appropriate safety margin each time we talk.”

Edmund wasn’t finished, “Okay,” then he frowned and asked, “Tell me why you have asked for more storage when I see that 31% of the storage isn’t used?”

Jake thought to himself, “That’s the question I was worried about but not anymore.” He paused and then replied, “We have a new application that will consume all of unallocated space and more.”

“We are monitoring storage closer than last year and now know the clients who are wildly exceeding the expected safety margin for their file systems. But going back now and releasing that free space requires downtime to reallocate and move the data, which puts the business at a bigger risk than if we wait until the next technology refresh on the storage array that contains the file systems. With the storage technology we use, freeing storage during the technology refresh is the safest time to reduce allocation sizes and thus return the free space to the pool of unallocated storage.”

Edmund smiled and said, “Jake I have enjoyed talking with you. You have a strong command of your business. I was thinking of raising your salary…”

“Oh, boy,” Jake thought.

” …but I’m not sure I have enough safety margin in my payroll budget.”

convert this post to pdf.

©2005 Steven M Smith

He is wearing his traditional garb — dark suit, white button down shirt, red tie, and black tasseled shoes. The glare off his wire rimmed glasses makes it difficult to see those steely blue eyes. Harry Fox has all the right moves and his quick climb up the management ladder proves it. He is arrogant and ruthless. People who oppose his ideas pay a price. And the payment is extracted when they can least afford it.

We are both participating in a problem solving meeting. Well that’s not quite true, I’m observing and Harry is talking. He just stole the floor from Jim King a few minutes ago by talking louder than Jim. I hate this bully. Harry is dictating his ideas about how the team should solve the problem. But he is wrong. He has missed some crucial facts.

Should I share the facts? Wait a minute. Harry doesn’t care about facts; he cares about looking and sounding good. Harry is connected all the way to the top of the company. I’m connected to the people on my team. I hesitate. Wow, that’s totally uncharacteristic of me: I am known as someone who speaks his mind. I look over at Harry. He has taken his glasses off and is moving them rhythmically up and down as he talks. Although what he is saying doesn’t make sense, it sounds authoritative. Damn, I feel my gut twisting. Is it anger? No… It’s fear.

Harry wraps up his talk. There is a pause. If I want to speak, it’s time. I say nothing.

Safety

The omission of crucial facts and opinions happens in thousands of business meetings every day. If people don’t feel safe, they aren’t going to say anything. And you will have no idea about what you missed.

Too often the participants whose opinions count the most assume that the other members of the meeting feel as safe as they do. This assumption is wrong more often than not. But it is rarely ever tested.

You can help increase the safety of your meeting. Collect data. Share it. Interpret it. And decide how to respond to it. These actions will open the opportunity to transform your meetings. For instance, the opportunity to discuss and take action on previously undiscussable items, such as who was or wasn’t invited; what is and isn’t on the agenda; and how the discussions will or won’t be processed. I’ve experienced the power of this kind of transformation many times. You can too.

Collect the Data

Inform everyone that you will use a secret ballot to poll the participants about safety. Poll people with the following question, “How safe is it for you to fully share your ideas during this meeting?”

Write this question on the board or a flip chart. Clarify that the ballots are not identified, just a number on a slip of paper. Expand on what “fully share” means by listing some controversial ideas that weren’t shared at other meetings that would have made a difference.

An unsafe environment causes participants to share fewer ideas and to carefully filter the ideas that they do share to be sure they’re safe. Poll for the information in Figure 1.

Figure 1. A gradient of safety

Pass out a ballot — a small piece of paper, post-it note or note card — to each participant. Ask everyone to write either the number 0, 1, 2, 3, or 4 that corresponds to their level of safety onto the ballot. My experience is that some people will, regardless of the instructions, write a decimal number. Simplify things for yourself by informing everyone that all the ballots will be rounded so that the results fit the range of the gradient.

Ask them to cup the ballot in their hand so that no other participant can see their rating. Stress to everyone that you don’t want anyone to share their rating with anyone else, regardless of how safe they personally feel. Again, emphasize that only you will see their ratings. Have the participants fold the ballot in half and place it in a container, such as a hat.

Share the Data

Ask a participant to help you build a histogram of the poll. I suggest that you use a flipchart so that have a hard copy of the histogram to use when your write up the minutes of the meeting. Pull each ballot out of the container one-by-one and read the score to the person building the histogram. Stuff the recorded ballot into one of your pockets or put them in your briefcase so no one else can or will ever see it. Note, you are not only revealing how safe people feel — you are also building safety by checking in a way that reinforces safety.

Figure 2 shows an actual histogram built during a requirements gathering meeting that I facilitated at a large manufacturing company.

Figure 2. The histogram of an actual safety check that was built during a requirements gathering meeting. How do the participants who feel completely safe help the participants who feel threatened?

Interpret the Data

Ask the participants, “What is your interpretation of the histogram?” A manager in the requirements gather meeting told all the other participants that they needed to start trusting each other. His management colleagues vigorously echoed his belief. And his colleagues had a lot more to say about the importance of trusting each other. I let this discussion continue for 10 minutes and asked, “What cluster of people on the histogram do you think is offering the most advice?” The room fell silent. The people who felt the safest realized that they were doing the most talking. And they realized that the people who felt threatened weren’t talking.

Telling people how they should feel doesn’t work. And, in my experience, people know that as a fact but forget to put that knowledge to work. It helps to give them a gentle reminder. Ask everyone, “How do the participants who feel completely safe help the participants who feel threatened?” The answers I have heard in meeting after meeting can be summarized in two words: 1) Care and 2) Listen.

During the manufacturing meeting, people did start to care and listen. The participants slowed down and asked each other questions. And, most importantly, they were okay with moments when no one spoke. I believe that silence is a gift. It shows people that you are ready and want to listen. And, in the case of a meeting, silence demonstrates that the group is ready and wants to listen.

These changes made a big difference in the requirements meeting. The discussions were deeper. And the enriched conversation enabled them to discover requirements that would have been invisible to them. They were more effective together than they had ever been.

Other Methods

Another method that can help create safety, especially in large groups, is to let the participants build the safety guidelines for their meeting.

Split the participants into small groups. The ideal size is a triad — 3 participants. Ask the groups to 1) introduce themselves to each other, and 2) create a set of guidelines for conducting a safe meeting. Give them a few test cases to ponder. For instance, someone starts blaming someone else, someone tells an inappropriate joke, someone dominates the meeting, and so on. Let everyone know that they shouldn’t limit themselves to the test cases. You want them to share any guideline that will make the meeting safer.

The hope is that the discussion will help remind people of what they already ready know about safety and remind them to practice what they know. And, just as importantly, the hope is that a connection with a small, manageable number of people will increase safety.

Have each small group introduce their members and share the safety guidelines they created to everyone. You will be amazed at the wisdom that people have about safety. Gain agreement from everyone on which guidelines to accept. Remind them that the guidelines are theirs rather than yours. If someone violates a guideline, you will call them on it.

Ask the group to monitor your facilitation and to inform you if you allowing any deviation from the agreed upon guidelines. When someone mentions a deviation, treat it with the utmost care and respect. It’s the ultimate demonstration of the value you put on safety.

Final Thoughts

Regardless of the method used, you can never be absolutely certain that all the participants feel safe. If someone would have asked me how safe I felt during the meeting with Harry Fox, I would have voted neutral or safe so that Harry wouldn’t find out.

The best that you can do is to solicit and respect everyone’s ideas. The leader that models appropriate behavior in meeting after meeting is constantly renewing and enriching safety and productivity.

Be a leader. Care. Listen. Model the behavior you want.

Acknowledgements

A special thank you to Jean McLendon for making me aware of the importance of safety and how to measure it; Jerry Weinberg for suggesting that the number one isn’t nearly as evocative as the number zero for connoting the absence of safety; and Esther Derby, Don Gray, and Jerry Weinberg for sharing their feedback about this article.

convert this post to pdf.

©2005 Don Gray

It was Saturday afternoon when the house phone rang. “Don, this is John. I know we haven’t talked in 10 years, but I have a client who has a problem.” In 20 years I’ve never had a client call and say “Don, things are going great! Why don’t we pay you to do nothing? Just send us an invoice.” So I’m not surprised when the first words I hear are “Something’s wrong, can you come and take a look?” What did surprise me was Saturday and at home.

George, the client, works for a major defense contractor. Recently George inherited a system he didn’t know much about. The system had suddenly started producing about 25% defects. At $300 to $25,000 per part, upper management was screaming to find the problem and solve it.

Prelude to a Problem

We can use a general systems thinking drawing called a “Causal Loop Diagram” (aka “Diagram of Effects”) to see the situation’s dynamics.

Figure 1 – George’s Problem Solving Ability

You can start reading this diagram at any node. Cloud-shaped objects represent subjective quantities, values that defy quantifying, or are too expensive to quantify. “George’s Ability” doesn’t quantify easily, but you can experience it anyway. Ellipse-shaped objects represent objective quantities. Counting the number of problems and problems solved is easy to do. The arrows connect the variables and show the direction of influence. As George’s ability to solve problems goes up, the number of problems solved goes up. Black dots indicate an inverse action, so as the number of problems solved goes up, the number of remaining problems go down. As the number of remaining problems goes down, the time available per problem goes up. As the time available per problem goes up, George’s ability to solve the problems goes up. And around and around it goes.

Figure 1 contains “fuzziness.” George’s ability to solve any given problem will vary. Has he seen a similar problem before? What is his energy level? Will solving a given problem fit in the time available or will George have to “come back to it?” Even so, if we know George, we have an idea what kind of problem solving ability he has, and it’s a useful approximation.

Another important fact about Figure 1 is that the loop reinforces itself. This means if things are going well, they tend to get even better. Conversely, when things are going poorly, they’ll tend to get worse. We indicate this reinforcing loop with an “R1″ in the loop’s middle. When we add another reinforcing loop, we’ll label it “R2,” and so on. If things keep going well, eventually George will solve all the problems. I don’t think that will happen in George’s world, but theoretically it could. More likely, the QA department will want new information collected during production, clients will want different reports, the product engineers will decide to run the process differently. Or, George’s problem-solving ability will be recognized by management, and he’ll be “awarded” the department’s “problem project.”

Houston, We Have A Problem

When George inherits the problem project, suddenly, the number of problems he needs to solve skyrockets. Since this loop reinforces itself, as the number of problems shoots up, fewer problems get solved (or at least the problem-solving rate goes down). Customers become unhappy. QA rejects more parts. When management finally gets involved, the “BIG MANAGER” flies down to take hands on control until “the problem gets solved.” Dynamically, this looks like Figure 2.

Figure 2 – From Bad to Worse

Note that adding management pressure creates a boomerang affect. The management’s goal is to help solve the problem quicker, but now George has less time to solve problems since he’s required to attend the daily meeting from 8 – 9 AM explaining what’s wrong, and what’s being done to fix it. The BIG MANAGER also moved into George’s office space. Now George gets to overhear the phone conversations about the project. This creates an additional distraction that reduces George’s effectiveness. Management pressure actually creates two new reinforcing loops that amplify the effects in the original reinforcing loop.

Reinforcing loops are ‘engines’ in systems thinking. They cause either growth or decay until something happens that stops the cycle. In the positive cycle, George would eventually solve all the problems. In the negative cycle the problems get worse until something collapses. George could quit or get sick. Clients could take their business elsewhere. To prevent collapse, management needs to intervene to balance the system’s dynamics. This led to the Saturday phone call.

When I became involved, the system structure changed again. The result looks like:

Figure 3- Starting to Balance

As George’s ability goes down, the need for George to obtain help goes up. As George gets more help (becomes more efficient), the number of problems solved goes up. As the number of problems solved goes up, the number of remaining problems goes down. As the number of remaining problems goes down, the time available per problem goes up. As the time available per problem goes up, George’s ability to solve the problems goes up. Eventually, the need for my involvement should be come less, as the system recovers its balance. My involvement creates a “balancing loop” (B1). Balancing loops add stability to systems and organizations.

Creating Causal Loop Diagrams

Causal Loop Diagrams help reveal system dynamics. Creating the diagrams involves more work than reading them, but can be done by anyone willing to take time to think things through and look for relationships. For example, what problems might arise by involving help? Is it possible that things will get worse before they get better? And why would that be?

The Buddy System

The first step in creating CLDs: find a buddy, friend or coworker with whom to share the process. When I started working with CLDs, I didn’t pay attention to this. I’ve since noticed that I add something to every diagram that comes my way, and every diagram I send out comes back with meaningful corrections or contributions. This happens because everyone’s world-view is slightly different. Most world views overlap enough that we can understand each other, but are different enough that other people will think of things you don’t. If you’d like, you can send me your drawings for review and comment.

If another view-point is necessary, two may be better. But be aware that at some point adding people will create more “drag” on progress than contributing “thrust” towards completeness. In a work environment, completeness counts more than speed, so make sure you consider all viewpoints when developing CLDs. For independent work, I prefer “mostly complete” and quickness.

When sharing with your buddy, consider how you’re going to present the CLD. I worked with a friend on the phone one time and tried to draw the CLD as he described his drawing. Unless you enjoy lessons in miscommunication, skip this and at least send some sort of a drawing (JPEG, GIF, PNG) they can view, print and mark up. I’ve found sending the actual drawing works best. For Windows users, I typically use Visio. I have a template for CLDs (using Jerry Weinberg’s notation) that my friend Brian Pioreck created. When I’m working with Mac users, I use Canvas to create the CLDs. In both cases, we can change the CLD and share the results via email.

Creating a CLD usually follows these steps:

1. Bump headfirst, sometimes painfully, into a puzzling question.
2. Think about the question.
3. List some variables related to the question.
4. Connect the variables showing how one influences others.
5. Check the CLD by reading the story.
6. Repeat steps 2 – 5 as necessary and appropriate.

What was that?

Here are some questions that usually start my systems thinking mode. “What is really going on here?” “Why is this happening again?” “You mean adding help might make things worse?” “What possible negative impacts could there be?” “How could that happen?”

Thinking

Sometimes when I think about a problem, I can see the answer immediately. Other times I have to commit the problem to my subconscious and do something else until good ideas surface. I have favorite activities that involve my body, but leave my mind free (like bush hogging). Other activities (like Aikido, hitting golf balls) occupy all of me. Typically the more perplexing the problem, the more I need to focus on something else for a while.

Thinking about the question hopefully leads to a deeper understanding of the situation. If it doesn’t perhaps the question is too small or too big. Perhaps the question isn’t clearly stated. Try changing the question and see how it changes your thinking.

As I thought about the question, I remembered how sometimes the changes we make to help actually result in decreased results before things get better. This leads to the “worse before better dynamic”.

Variables

Now it’s time to list the variables you’ve discovered in your thinking. Choose things that can change. “Number of Problems Solved” changes and influences other variables. I like to use variable names that work with “As [insert name] goes up (or down), then [downstream name] goes down (or up).” This helps me prevent putting constants in the model. Let’s consider the following variables:

• Number of New People
• George’s Training Load
• Number of Problems Solved
• Relative Progress

In my experience, getting all the variables in the first pass doesn’t happen often. The point here is to look for hidden structures that create the observed dynamics. As the drawing takes shape, new variables appear, and old variables may not be needed. It depends on your point of view.

Which Comes First?

Since all the variables are related, and you can start reading a CLD at any point, it doesn’t matter which variable gets put in the drawing first. Pick one and get started telling the story. Once in a great while I do a hand sketch. Generally I head straight to the drawing package where I can cut, paste, drag and drop. So far, the results of getting someone to help George looks like:

Figure 4 – Adding Help

This means as more people are added, George will actually solve fewer problems in the immediate future so the relative progress goes down.

The Rest of the Story

As I draw the CLD, I find myself rethinking assumptions and conclusions. This restarts me iterating through the steps. Don’t be surprised if it takes several iterations to become comfortable with the CLD. For example, Figure 4 doesn’t include the results of George’s training load. Adding Figure 1 and Figure 4 together we get:

Figure 5 – The Solution

This happened in this situation. The additional skilled effort increased the number of problems solved to the point where the defect rate fell below 1%. This put George back in the original position of being able to solve the problems as they occurred.

The Never Ending Cycle

If two people take the same variables and each create a CLD they may not produce exactly the same drawing as I do. That’s OK. That’s also why it’s good to have other people review your drawings.

Causal Loop Diagrams give us a method for revealing hidden system structure. Being able to read and create CLDs provides a way to clarify our thinking and for sharing our current understanding.

Appreciations:

I appreciate Johanna Rothman and Stuart Scott for their contributions to this article.

convert this post to pdf.

©2005 Don Gray

“Repeatedly curing a system that can cure itself will eventually create a system that can’t.” - Marvin’s Second Great Secret, Jerry Weinberg

“Don, the software’s locked up again! Can you come up here tomorrow and fix it?” George was on the other end of the conversation. George and I had started working together when his employer moved a production line from Florida to Virginia. This move created all sorts of problems¹.

The daily struggles getting the hardware, software and process playing nicely together had become a weekly check-in with an occasional on-site visit. This made the request seem a little odd.

Taking a deep breath allowed me to work through some quick thoughts². The software was running on 15 different computers. There wasn’t any way they could all lock up at the same time. And what does “lock up” mean anyway? What’s going to happen different between now and tomorrow, or now and next Monday? And if I drop what I’m currently working on to rush up there tomorrow, am I really helping George? What long-term consequences result from this?

Solution #1 – The Quick Fix

Accepting that a problem is an undesirable difference what we want and what we have, George had a problem. Since I helped George with several other problems, it seemed natural that I should help with problem also. Using a causal loop diagram, the situation looks like this:

The more the computer locks up, the more Don gets called. The more Don gets called, the more problems he solves. The more problems Don solves, the less the computer locks up. This is a balancing loop that brings stability to George’s process. It’s also a symptomatic solution, a quick fix to make the pain go away. But following the steps in B1 only solves the immediate problem; it does not solve the underlying fundamental problem. Think of it as treating the symptom, not the disease.

Solution #2 – George Learns to Solve the Problem

There’s another possible answer. What does it look like if George solves the problem without calling Don? First George needs to learn “C” much better than he currently knows it. That takes time. This time delay gets represented by the “||” mark on the line. Then he needs to figure out where in the 5000+ lines of code the problem resides. That also takes time. Finally George can solve the problem, but by now something else is broken worse somewhere else, everything gets put on hold, and when George finally gets back, he’s lost his train of thought, and has to start solving the problem again. Diagrammatically we represent it this way:

This is also a balancing loop bringing stability to the system. B2’s advantage over B1 is B2 represents a systemic solution. The more the loop executes, the better the system gets at solving the problems. This reduces the system’s dependence on outside interventions. The disadvantage of B2 is the time delays involved in learning “C” and understanding the application code. The time delays do get less the more the loop executes,

Solution #3 – Combining the Symptomatic and Systemic Solutions

Since B1 and B2 both contain “Computer Locks Up” we can combine the two causal loop diagrams into a more complete problem-solving picture.

This shows the how the event “Computer Locks Up” can trigger one of two responses: a symptomatic response to make the problem go away quickly (B1), or a systemic response (B2) where the system becomes more capable of solving problems without external influence. This pattern occurs often enough that systems people have given it a name, “Shifting the Burden.” I’d been aware of this archetype, but preparing for my “Deja vu” session³ with Diane Gibson sharpened my awareness of what could go wrong.

An Unintended Consequence – Too Much Help

There happens to be a long term reinforcing loop that can show up with this archetype. This occurs when the symptomatic solution (B1) gets all the action. Don becomes better at both “C” and knowing the code base. This makes it easier and quicker for Don to solve the problems, and Don becomes indispensable.

This means the system’s ability to “cure itself” becomes atrophied. George loses his ability to persuade management to give him training. Production becomes accustomed to “great customer service” from Don. The ability to tolerate “pain” goes away, and the quick fix becomes the only fix.

Invoking the symptomatic solution not only starts B1, it initiates R3. Calling Don reduces the need to learn “C”, thereby weakening the system’s problem solving ability. Carried to the extreme, this becomes an addictive response, and cripples the system.

And The Final Answer Is

Either balancing loop can be chosen to a given problem occurrence. Handled properly B1 can be used to alleviate acute problems, while invoking B2 to solve chronic problems. This pattern of selectively, consciously choosing how to deal with each problem has resulted in George’s ability to solve more code problems and start making enhancements to the code base.

I appreciate Stuart Scott and Jerry Weinberg for their suggestions about this article

¹http://www.ayeconference.com/Articles/Howdidthishappen.html

²http://www.ayeconference.com/Articles/Dontdosomething.html

³http://www.ayeconference.com/wiki/scribble.cgi?read=SessionFour022 and http://www.ayeconference.com/wiki/scribble.cgi?read=SessionFive005

convert this post to pdf.