Wednesday, July 8, 2009

Make Your Mission Possible

Copyright 2008 Johanna Rothman, originally published in Better Software

Janice strode down the hall and made a sharp right at a cubicle decorated with dragons. “Hey, Steve, got a minute? I need your help with a problem.”

“Janice, the last time you asked me for my help, I got stuck in that installation mess. I appreciate being one of your team leads, but I get worried when you ask for help with problems. What’s going on now?”

“We have a problem with customizations for Big Customer2. The good news is that we do these customizations, right?” Steve nodded. “But the bad news is that we have to port them from release to release.”

“We did that last month.”

“Well, you did. Then tech support decided to add the extra piece of the reports we discussed last month.”

“What? Why did they do that? Not to this product-they can’t.”

“Well, Big Customer2 paid us a pile of money for not too much work. And that’s where you come in. I need you to add that new report to the point release you’re working on now.”

“How much money? I bet tech support has no idea how much this piece of the report will cost us to support or how much time it will take away from our next release. We can’t just think of this report as a pile of money; it’s a headache. We were never going to put that functionality into the product. We were going to put it in the new reporting system, remember? Now we’re going to have to support that report forever. Big Customer2 is never going to want to change.”

Steve put his head in his hands. Finally, he looked up and said, “OK. I’ll do it. But on one condition: We decide what we’re doing as a development group once and for all. You asked me to be a team lead, right?” Janice nodded. “Well, I don’t know what I’m leading. Let’s decide what our mission is-whether it’s to support any crazy thing our customers want, or make products, or support installations, or what. Let’s define our mission and write our mission statement. Then we’ll have a basis on which to say no to new work if it doesn’t support our mission. From now on, we will have a reason for the work.”

A week later, Steve and Janice met to develop their mission. “Steve, I invited Chris so we have all you technical leads in one room. Since you prompted me to think about the mission for our group, I decided to ask my boss for his mission, as well. He doesn’t have one yet, so we may have to revise ours later. But at least we’ll know where we’re going.”

Janice placed two lists on the table. “Here’s all the work we’re doing in development. One list is a month-by-month portfolio of all of our projects and all the extra things I’m supposed to do as a manager. This other list is the work other people would like us to do that we’re not doing. Now, do you two have work you’d like to be doing that’s not on this list?”

Chris and Steve nodded.

Janice handed them a stack of index cards and said, “OK, let’s write all the work we’re doing and the work we’d like to be doing, one project to a card. We’ll organize them on the table into these buckets: work that seems to make sense for our group; work that needs to get done, but maybe not by us; and work that we are doing but we don’t understand why.”

After a few minutes, Janice, Chris, and Steve had their cards sorted. Chris said, “Wait a minute. Why are we looking at the work? Why don’t we decide on our mission first and then manage the work?”

“Good question,” Janice said. “Since my manager doesn’t know his mission, yet, I’m not sure we can finalize ours beyond the work we do. Clearly someone in the company values our work, so we have to make sure we continue to do work the company values but that also makes sense for us to do. By starting with an analysis of our work, we’ll have a basis for our decisions-especially when we start looking at the work we’d like to be doing that we never have time to start.”

Janice, Chris, and Steve discussed their work, bucket by bucket, starting with work it made sense for them to do.

Next, they discussed the work that they thought the company needed to have done-but not necessarily by them-and put a sticky on the card with the name of the group that they thought should do the work.

Finally, the trio discussed the work they didn’t understand why they were doing. Janice wrote a sticky with the name of the person she was going to talk to about those projects.

“Now that we understand our work and the reasons why we have it, let’s discuss our mission. A good mission explains what we do and don’t do. It establishes the boundaries of our work and explains how our development group fits into the organization. A great mission will provide reasonable and measurable objectives for our work so other groups can see what we are responsible for-and not responsible for,” Janice explained.

“Oh, so I don’t have to add something impossible such as, ‘Respond to all requests in twenty-four-hours’?” Chris asked.

“No, that’s how we got into trouble with Big Customer1 last quarter, remember?” Steve said.

“You know, if we were a custom development group, responding to all requests in twenty-four hours might make sense. But we’re not!” Janice said. “Let’s develop a mission that makes sense for us, and I’ll talk it over with my boss. I’ll convince him our mission is on target.” Janice grinned. “But if he doesn’t agree, at least I’ll understand what he wants us to do differently.”

The three of them worked for a while, until they were satisfied. Janice said, “Read the mission out loud, Steve so we can hear it.”

“We will enable our customers to organize and see their data by creating products that our company can sell. We will continue to extend each product and family of products so the products provide a cost-effective solution to our customers’ needs.”

“OK, with this emphasis on products and product families, as well as cost-effectiveness, I now have ammunition to say no to more of these customizations,” Janice said. “Maybe my boss will think about his mission instead of just saying yes to everything that he sees. But if not, we can use our mission to set some boundaries for what we do and what the company does. Thanks, guys.”

Story Lines

  1. Without a mission, you can’t define the work that belongs in your group and the work that doesn’t belong.
  2. A mission should say what you will do and help you explain what you won’t do.
  3. Beware of missions that promise immediate response or continuous response to the organization unless you do have a 24/7/365 organization and the staff to support that service level.
  4. It’s easier if your manager has a mission, but if your manager doesn’t, start with the work you do (and want to do) to generate your mission. Be ready to revise your mission when your manager develops his.


I thank Dwayne Phillips and Esther Derby for their review.

Wednesday, June 10, 2009

The Blame Game

©2007, 2009 Don Gray and Jerry Weinberg

Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

“Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

The Tangled Web

It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

We can see in the following diagram that Engelbert had at least three options available to him. He could:

  • Respond negatively, looking for reasons, usually blaming someone else) for the results.
  • Decide no difference exists by ignoring the results and do nothing.
  • Respond constructively, learning from what happened and improving at getting the results we desire.

Choices for a poorly ending project.

Choices for a poorly ending project.

Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a ?success?) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

Let the Game Begin

Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

Blame affects organizations on multiple levels creating different problems.

  • Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
  • If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
  • Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
  • Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.
Results of blaming

Results of blaming

So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

An Ounce of Prevention

The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

  • Observe what’s actually happening. Are people doing what they say they’re doing?
  • Listen to the language people use. Do you hear blaming?
  • Does it feel like there’s an elephant in the room that no one acknowledges?

No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like ?It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

Multi-level Blame

Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

What’s A Girl To Do?

At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

Friday, May 29, 2009

Drawing Out the Facts: The Art of the Discovery Interview

(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.”


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.


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?”


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.


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.


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.


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.


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 ( 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 (, at which he leads experiential workshops. You can contact Steven at

Friday, April 24, 2009

Is Collaboration the Right Way to Work?

©2008-2009, Esther Derby

As a manager, your job is to organize people and work for success. That includes work design–figuring out whether you have a group or a team, and creating an environment where people can do their best work. I don’t know about you, but work design wasn’t part of my training as a technical person. And it’s not explicitly included in many business and management programs either.

The default belief seems to be “teams and collaboration are good,”  and in a previous column, I wrote about the benefits of collaboration.  But is collaboration always possible?  Is it even the right thing to do in every situation?

In this article, I’ll show different levels of collaboration, and lay out the questions that managers need to answer to decide whether they have a group or a team.


Josh and Julie work in a tech support area. The primary responsibility of the unit is to configure, tune, and support servers.  The workflow is controlled by a ticket system where the requestor submits an order with basic requirements and most of the work is handled first-in, first out. Of course, there are exceptions, when there’s extra lead time to order a special server or establish the configuration for a new product. But those orders are the not the rule.

And though different people excel in different areas and each brings unique talents, the most server installs in their company require a core set of skills.

Josh, Julie and their co-workers have a connection: they share professional skills, hold each other in high regard, and let each other know what they are working on. Julie, Josh, and their co-workers help each other when asked, but they don’t really collaborate. The workflow in their department isn’t conducive to collaboration, nor does the work require it. They may call themselves a team, but they aren’t engaged in teamwork. And that’s just fine. There’s nothing wrong with being a workgroup if that’s what the work needs.


Deb and Doug run test labs for two different products within the same company. Because their respective products are on different release schedules, there are times when the equipment in each lab isn’t fully booked.  They cooperate with each other by loaning resources when its possible and makes sense to do so. Deb and Doug are working together to meet organizational goals. But they aren’t a team.


Frank and Frannie work in a product development group. Each has responsibility for a distinct product aimed at different consumer groups. They meet on a regular basis to keep each other abreast of release schedules. They consult with each other about market trends as they prioritize features. It is necessary to coordinate, but given the product mix in their company, it’s not necessary for Frank, Frannie and the rest of the group to collaborate with each other to achieve their goals. No team here.


Ellen and Eddy work on a large project-over 100 people. Their manager calls it a project team, but there are people on the “team” they wouldn’t recognize if they passed them in the hall. Their project is too big to truly be a team, though there are sub-groups within the larger project who function as collaborative teams. Groups larger than 12 or so almost always break down in to sub-groups-which may or may not be teams.


Abby, Alec and their four team mates work on a software development team. They have overlapping skills all of which are necessary to build the product.  They jointly commit to a goal and work very closely to deliver working software in two week iterations.  They share a goal, they are mutually accountable, and if they don’t work together, they won’t succeed-they are a team.

So, as a manager, how do you determine how to organize people to accomplish goals?

  1. Consider the work goals. Are people committing to a leader to achieve individual goals, or are group members mutually committing to each other and sharing accountability?
  1. Examine the skills needed to do the work. Does all of the work require the same (or similar) set of skills or does the work require broad range of skills?
  1. Analyze the work. Is the work mainly projects that one person can complete from start to end-individual products? Or does the work of several people need to integrate to create a coherent whole-collective products?

If you answered ‘yes’ to the second question in each pair, the work is probably best suited for a team.

On the other hand, there’s nothing wrong with work groups that aren’t teams. If you answered ‘yes’ to the first question in each pair, the work  probably best suited for a work group.  It is important to determine which will best meet the needs of the work.

Building a team doesn’t happen by accident…. and your job as a manager will be different from the manager of a workgroup. I’ll talk more about that in a future column.

Sunday, March 5, 2006

Climbing Out of Technical Debt

© 2002 Johanna Rothman,

Have you ever had a conversation like this one?

Vice President: In the last release, you were able to bring the release date by over a month by cutting the testing. Do that again, ok?

Project Manager: Sorry, boss, we can?t do that. For the past three releases we?ve shortchanged the design work and the testing. We can?t cut any time from this project. In fact, it?s time to re-architect the system, redesign it, and do the testing we?ve put off.

Vice President: NO WAY!

Project Manager: Hey, that?s just the way it is. We haven?t taken the time to finish this product yet, and our shortcuts have come home to roost. Our technical debt is too high to work this release the way we?ve worked the others.

Technical debt, as defined by my colleague Dave Smith, is the debt a company ?owes? to a product they persisted in shipping in an incomplete or unstable condition. This is a situation referred to in Hunt and Thomas?s book The Pragmatic Programmer as ?software rot? or by Gerald M. Weinberg in Quality Software Management, Volume 4 as ?design maintenance debt.? The software isn?t necessarily rotten?the product is incomplete.

As the technical debt increases, the load on the customer support staff becomes overwhelming, and the developers have trouble adding or changing system features. When developers are stuck on new development and support is overloaded, you face difficult choices about what to do now: have developers support the current product; ignore the current product and continue with development; some combination of support and development; or stop developing and fix what you?ve already got.

Project managers, development managers and test managers often can see this coming. They know there is a window of opportunity to fix the product before the technical debt overwhelms the company?s ability to do new product development.

Look for these signs of technical debt:

  • You ship a product and then have to put out a point release before it?s even left the CD duplication house.
  • Testing time increases disproportionately to the development time.
  • The developers tell you that part of the product needs to be re-architected, because the current architecture doesn?t support the current requirements, never mind the additional requirements.
  • Developers refuse to touch a part of the product saying, ?No one but Fred can touch that. I know Fred left three years ago, but no one else can work on it, because we don?t understand it.?
  • Developers spend more time supporting current customers by solving customer problems, fixing defects, and answering customer questions, than they spend developing new product.
  • You hire more testers than you have developers, and you?re still not sure you?ve tested the product.
  • Your developers threaten to leave because all they do is ?maintenance?.
  • You ship the product not because it?s ready, but because the developers? families have abducted them to go on vacation, or the developers are too exhausted to continue the crunch mode you?ve been in.
  • You stop testing because you don’t want to find more defects.
  • Your cost to fix a defect continues to increase, from release to release. (If you?d like to see a picture of this dynamic, check out Weinberg?s Quality Software Management, Volume 4, reference below.

Recognize your technical debt, and start planning what to do. Before you can plan, you need to know a little about how you came to have this technical debt problem. These questions may help you understand how your product acquired its technical debt:

How do you staff projects? Do you assign enough people at the time they are needed, or are some positions never assigned or assigned late to a project? If you never assign enough testers, or you don?t have an architect, you will incur technical debt. Don?t blindly accept people starting on your projects late, because you can?t make up time in a project. Have people start when they?re supposed to start, or recalculate the project schedule.

How do you design your projects? Do you first architect the entire product for its entire lifetime? Do you iterate on the design for several projects? If you don?t architect the product, and update the architecture as necessary, or if you don?t do a high level design before starting to code, you will not have a congruous product. One way to recognize an incongruous product is when you have multiple ways of doing the same thing. At one organization, the developers couldn?t agree on how to open and save data files. Since they couldn?t agree, every time a developer wanted to open or save their data file, they had their own open and save functions. When they moved from a command line interface (CLI) to a GUI interface, they had no easy way to integrate the open and save functionality.

How do you test the product? Do you have a way to start testing the product at the beginning of the project? Do you only have manual tests through the graphical user interface? If you start limited testing late, you?re guaranteeing yourself technical debt. You have many opportunities to test early and often: requirements inspections, design reviews, code inspection or peer review, unit tests, daily builds and smoke tests (tests to verify the daily build works at least a little bit), peer review of fixes in addition to system test. Decide what makes sense for your environment, and add test capability as early in the project as possible.

How do you organize your projects? Do you have functional managers who hand off the product from the analysts to the developers to the testers to the manufacturing folks? If so, no one has the same view of what the product should be. At a minimum, assign an overall project manager or program manager, so someone is pulling the entire project together. Projects without project managers are highly risky, and in my experience, always fail. In addition, projects without a sponsor or champion have a difficult time finishing.

How do you know what done means? Do you have some objective criteria to know when the project is complete? If not, you?re more likely to release an incomplete product. Develop release criteria for every project, so that everyone on the project, and the project sponsor understands what your company will receive for its project money.

How do you run your projects? Do you stick to only one type of lifecycle and one process? You may need to choose other lifecycles and/or processes to avoid future technical debt. Many project managers are comfortable with a particular lifecycle and/or process, and it can be difficult for those project managers to switch to a different lifecycle for a project. If you?re used to a waterfall lifecycle, you?ll have to learn to plan for an iterative or incremental lifecycle differently. And, you?ll have to monitor your projects differently.

If you?ve changed your lifecycle, you may need to change your process. What you do and when you do it will make the lifecycle successful and keep down technical debt. If you?ve never planned when to do inspections and reviews, start with something small, such as peer review of defect fixes during system test. I?ve found that a nightly build and smoke test helps find defects faster, and helps everyone realize when the product is not ready to ship.

Although it feels as if you?re moving faster when you take shortcuts on a project, in reality, your technical debt prevents you from making project progress. You might be able to shortchange your product on one or two releases, but at some point your product technical debt is like credit card debt ? if you don?t pay it off in a planned way, the debt buries you.

Observe and measure your products, to know when you should act to reduce or avoid technical debt.

For more information, see

Hunt, Andrew and David Thomas, The Pragmatic Programmer. Addison-Wesley, Boston, MA 1999.

Weinberg, Gerald M., Quality Software Management, Volume 4. Dorset House, New York, 1998.

Choosing Facilitation

© 2003 Johanna Rothman,

Meetings are a fact of our lives. Most of the time we don’t need a facilitator to help move our meeting along; we can manage to accomplish the goals of the meeting without a formal facilitator. However, there are times when a facilitator makes sense.

Darcy is a middle manager in a startup. They have enough money for the next eight months. For the last three months, the senior managers have closeted themselves in meetings day in, day out. Darcy knows they’re trying to define the current strategy and tactics to accomplish the goal: drive enough revenue to break even. If they can break even in eight months, their investors will consider investing just a bit more to overcome the slow economy and the company will succeed. If they can’t break even, they’ll be shut down.

Darcy’s no dummy. Neither are the other people in the company. They all know what these closed-door meetings mean. Darcy is concerned that if the senior management team can’t figure out what they’re going to do soon, the meetings will turn into layoff-decision meetings.

Darcy’s management team needs a little facilitation to help them overcome their inability to come to a decision and move forward to specific tactics and action items.

Senior management teams aren’t the only groups who become stuck and need help making decisions. Sometimes, a technical group has the same problem. Desmond, a database developer has on ongoing discussion with George, the GUI developer, and Tina, the tester about how to appropriately design the database upgrade for their product. Desmond, George, and Tina all agree they need an upgrade. They can’t decide how the upgrade should work. Depending on how they choose to implement the upgrade, their work will change, as well as the work the users will have to accomplish. Each of them has different ideas, and each idea is valid. They can’t come to a decision, and they have only a week left to decide.

In both of these cases, well-meaning, intelligent people are stuck. Their normal ways of managing their disagreements are not working.

Consider choosing a facilitator under these conditions:

  • When a group has trouble coming to agreement on a strategy or set of actions.
  • When you want to be part of the discussion and decision-making. It’s not possible to treat the group fairly if you want to participate and facilitate.
  • When you want to explore a previous project (retrospective facilitator) or explore alternatives (meeting facilitator)

You may be able to use people inside your organization as facilitators. Sometimes HR people or others are trained as facilitators. If you’re not part of the problem context or solution, you can facilitate the decision-making.

Whatever you do, choose when you require a facilitator. Don’t let the problems or conflicts escalate into no decisions, especially when you require a timely decision.

Beyond Blaming

© 1996 Jean McLendon and Gerald M. Weinberg, and

“England, though at present enjoying a very high state of prosperity, still shows some symptoms of a decaying nation. Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to finding a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible; if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple. Import the same principle or show the same machine to an American, or to one of our colonists, and you will observe that the whole effort of his mind is to find some new application of the principle, some new use for the instrument.” — Charles Babbage, 1852

As early as 1852, Charles Babbage could see symptoms of decay and infer from them a vision of future performance. In so doing he provides a perfect description of the blaming style of communication, which emerges in ‘decaying’ organizations–be they nations or software engineering organizations. What is a “blaming style of communication,” and why is it important in systems development?

What Is Congruence?

Congruence is a concept that describes the human experience of alignment between the internal and external–what is thought and felt (the internal), and what is said and how it is said (the external).

In order to operate congruently in the world, you need to take into account three general factors: self (the internal world), other (the immediate external world of people), and context (the larger external world of things, structures, processes, laws, and cultures).

  • Self: You must consider your own needs and capabilities. Suppose you are a manager who doesn’t trust anyone else’s judgment, so you try to attend every technical meeting. Doing this, you’re likely to overload all your available time, and then be unable to do the managerial job, nor to make real technical contributions in any case.
  • Other: You must consider the needs and capabilities of other people. For instance, if you are a programmer who refuses to be bothered to write readable code, then testing and maintenance of your code will be a great burden, if not an impossibility.
  • Context: You must consider the reality of the context in which you are operating. For instance, if you are a manager who insists on sticking with an old design that no longer has the capacity to handle the task, your project may be doomed no matter how hard everyone works. Or, if you are a manager in a start-up company and spend money as if the company had a billion-dollar cash balance, your organization may be out of business before its software product is ready for market.

Congruence is integrity at the most basic level and thus has immense value to a project and each individual in it. Without integrity, we cannot build trust; without trust, we don’t feel safe; without safety we have a hard time being congruent. Thus, congruence reinforces congruence in a powerful loop which improves the chances of producing a quality product, on time, and within budget.

On the other hand, the same loop causes incongruence to reinforce incongruence. If a project is allowed to ride such a downward spiral, the integrity of information is destroyed. Soon it becomes impossible for anyone to know what is really happening. Such projects invariably fail, and when they fail, they are invariably found to have been keeping two sets of “books.” Their external picture is not congruent with their internal picture, and they die. Or worse yet, live forever–the living dead.

If congruence is so important for project success, why aren’t all projects congruent? One reason is that congruence is not without a price. Another is that congruence usually involves risk. The level of risk is somewhat contingent on the kind of congruence being demonstrated–mental or emotional.

Mental congruence

In the United States, it’s relatively easy to express our thoughts with out too much incrimination–freedom of speech was a foundation upon which the country was built. Even so, there may be a price to pay for “speaking up.” For example, differing with a colleague or someone in authority at the wrong time can put us on a fast track to isolation, reprimands, reduced opportunities, and subtle door closings. Thus, we’ve all learned the importance of being careful about what we say where and to whom. Saying the wrong thing can lead to heated debates, followed by proclamations of who is right or wrong and who is good or bad. At that point, we’ve lost most possibilities for enhanced understanding and effective communication.

Emotional congruence

In our culture, feelings are reserved for athletic events, celebrations, funerals, near death experiences, deeply felt spiritual experiences, fights, and exchanges between intimate others, the very young and the very old. We even have many feelings about our feelings and some of the strongest have to do with shame and embarrassment over having them. Feelings are personal and lie close to our heart, where we are tender and vulnerable. No wonder we have all become so skilled at denying our feelings–which necessarily makes us incongruent.

Suppose you are a developer who is scared that you won’t be able to deliver a product when you promised. You try to tell your manager about your fear, but he tells you in no uncertain terms what will happen to you if you don’t express more confidence. “Why are you so negative? Aren’t you a team player?” One way to protect yourself from such negative responses is to live in your head. Perhaps you say, –”It’s just an estimate; I’m not attached to it,” meaning you won’t be hurt because you’ve distanced yourself sufficiently to ward off anything that might hint at rejection. But, though you deny your scared feeling to your manager, you still feel it, squashed down inside. You can stand back away from your ideas, but you always remain standing in your feelings. And, of course, you have been incongruent, and deprived your manager of your best information.

When you share your feelings, your heart-self is being presented to the outer world–exposed to the elements. When you’re scared and express your fear while maintaining consideration for the other person (your manager) and the context (the project), you are being congruent. Your critical issue here is, “Can I share my feelings and still be in control?” If the environment of your project is blaming, it threatens to remove your control if you tell the truth–so the temptation to lie about your feelings and your ideas increases. That’s why blaming cultures lead to “double books,” and that’s how they lead to failure.

What is Blaming?

In a congruent organization, your manager asks, “Where does your project stand?” and you answer, “I’m rather scared that I’m not going to make my schedule.” This starts a problem-solving discussion, out of which the two of you make new plans to get the project back on track. In a blaming organization, however, your manager may well tell you that only inferior people lack confidence. In that case, problem-solving will be replaced by blame-avoidance.

From a writer’s point of view, congruent interactions aren’t very dramatic; people just act sensibly, are considerate of one another, get their work done, and enjoy what they’re doing. That kind of behavior might not make as good a soap opera scene as your manager throwing a tantrum and you cringing in the corner, but it definitely makes a better project.

Not that a blaming culture conducts every interaction in a dramatic, blaming way. Under ordinary circumstances, congruent coping is the rule, but if circumstances were always ordinary, we wouldn’t need managers. When feelings of self-esteem are low, they are manifest much more dramatically in characteristic incongruent coping styles: blaming, placating, being superreasonable, loving or hating, and acting irrelevant. We can’t deal with all of these in a short article1 , so let’s discuss blaming, perhaps the most common and most directly destructive of the coping styles.

Under stress, people tend to lose their balance, and one or more of these three essential components may be ignored, leading to a characteristic incongruent coping style. For example, when people fail to take other people into account, they fall into a blaming posture. Here is a typical blaming action you may see in software organizations (italicized words are stressed in this style of speaking–because multiple stressed words in a sentence are a linguistic sign of blaming2):

Manager, as programmer arrives late for a meeting: “You’re always late. You never show any consideration for other people.”

Why is this incongruent? If the manager really is feeling and thinking that the programmer is always late and inconsiderate, isn’t she being congruent by saying so? Yes, but that isn’t what this manager said. She didn’t say, “It’s my impression that you’re always late to my meetings.” Instead, she pronounced her impression of lateness as if it were a scientific fact, never offering the possibility that the programmer might have a different impression. She generalized experience in her meetings as if they necessarily applied to all meetings, never allowing for the possibility that her experience might not be the only one that counts.

If the manager really is feeling and thinking that the programmer is always late and inconsiderate, she might say, “I think that you’re always late, and I feel that you’re not being considerate of me and the others. Is this your perception, too?” (And leave out the stressed words.) Even better management style would be to give the programmer a chance to provide a different perception before launching into interpretation. At the very least, that prevents embarrassment in situations such as the following:

Manager, as programmer arrives late for a meeting: “It seems to me that you’re always late. Is this your perception, too?”
Programmer: “Yes, and I feel bad about it. The reason I’m always late is that I have to donate blood for my 9-year-old son, who’s dying of leukemia, and the only time they take donations is just before this meeting.”
Manager: “I’m sorry about your son. I didn’t know about it. Let’s figure out a new meeting schedule so you don’t have to be late.”

More generally, it allows for the possibility that there may be other considerations that count besides those of this one manager. For example, perhaps the programmer is coming from a meeting with customers–a regularly scheduled meeting which overlaps the manager’s meeting.

But what if the programmer really is always late, with no reasonable explanation? Isn’t the manager then entitled to blame the programmer? Not really, because this situation is not about entitlement, but about getting the project done. For that purpose, the problem is most effectively resolved using a non-blaming confrontation with the facts about the unacceptable behavior. By foregoing blaming, the manager keeps the communication clear and open, maximizing the chance that the programmer will receive the intended message. And, of course, receiving the intended message maximizes the chance (though it doesn’t guarantee) that the problem will be solved.

When blaming, problem-solving is less likely because the facts of the case become a minor issue–the major issue in blaming is “who is important and who is insignificant.” When blaming, a person is saying, in effect, “I am everything, you are nothing.” Of course, this stance comes not from really thinking “I am everything,” but just the opposite. Directing the attention at another person–and blaming is often accompanied by a pointed finger–is a self-protective device to distract others from the inadequacy the blamer feels.

Like all incongruent coping, blaming is reinforced by feelings of low self-esteem. When you blame, you attempt to build yourself up by tearing down others because you don’t have the confidence that you can amount to much–or even survive–any other way.

Blaming usually fools people who are unsophisticated, or whose own self-esteem is at a low ebb. The knowledgeable observer, however, sees the amount of blaming as a sure measure of how inadequate the blamer feels. Moreover, if blaming is the preferred project communication style, then it becomes a measure of how far an environment has degenerated–how little communication is being directed at the project’s issues, compared to the amount that is being directed to puffing up the communicator’s weak self-esteem.

In a blaming organization, it’s not merely the managers who blame, as illustrated by these examples:

Programmer, when asked by a manager to volunteer to talk to a job applicant: ‘Why don’t you do it yourself? I’m not going to do your job for you. If you were better organized, you wouldn’t need to ask me such things.”
Customer, when project manager asks about the possibility of revising the requirements: “You never get the requirements right the first time. If I told you once, I told you a thousand times: Do the job right the first time, then you won’t bother me with revisions.”

(To test your understanding of the blaming style of communication, you might try to improve the congruence of these examples.)

How Blaming Hurts A Project

Of course, people are not perfect, so it’s impossible to conduct a large project without occasions on which people cope incongruently. Normal project management can deal with these situations–when they are exceptional. But when the whole environment encourages blame, each new situation further elaborates the incongruence. Fred Brooks3 once asked, “How does a one-year project get to be two years late?” His answer was “one day at a time.” Our answer is “one incongruent communication at a time,” as the following example illustrates:

One of the developers was developing a module that produced a printed report when it was tested. The manager put a lot of pressure on the developer to be ready on time, with no excuses allowed. The programmer produced the report, and the manager was pleased (though he didn’t show it, of course–it was “just an expected part of the job” in this blaming culture).
A month later, other people tried to use this module and discovered that it was not finished after all. The developer had used a word-processor to produce a fake report that looked just like a correct test report should look. He thought this would buy him time (it was a month, after all,until anybody found out) to finish the module. Unfortunately, since he was in over his head, a month wasn’t enough time.

The manager blamed the programmer. The programmer said nothing, because in this culture of blame, saying something only brought further streams of blame down on your head. The person who reported this incident said that in this organization, failure is not allowed under any circumstances. People who have problems in a project and can foresee slippage are unable to cry HELP! and receive appropriate assistance. According to the managers, each programmer is responsible for meeting the deadlines that the programmer agreed to. Inaccurate estimation is “not allowed” and perfection is to be achieved from day one–otherwise you are put in the pillory of blame. In this situation, fake test reports are the rule, not the exception.

Blaming is the dark secret underlying the failure of many projects. A blaming culture hurts a project in at least six major ways:

  1. People commit to plans they know they cannot achieve, at least to delay blame.
  2. People hide facts that managers need to control the project, as in the above example.
  3. When problems are finally revealed, people avoid coming forth with creative solution ideas, for fear they will be blamed if the ideas don’t work, or simply appear dumb at first glance.
  4. In day-to-day operations, a major portion of everyone’s effort is devoted to positioning themselves so they will not be accused when the time of reckoning arrives.
  5. Those people who somehow feel safe enough to focus on the job at hand find themselves spending large amounts of time checking up on the reliability of others’ communications.
  6. People feel bad most of the time, and spend a lot of time fiddling with unproductive tasks or simply staring at the walls.

What Incongruence Looks and Feels Like

Organizations can be changed from a culture of blame to a culture of congruence. To make this change, the first step is measurement, or at least detection–but how to measure blaming? Actually, an experienced consultant can detect a blaming organization within a few minutes of contact, because symptoms are everywhere. Indeed, people within the organization already know it’s a blaming culture-but of course within a blaming culture, blame is undiscussable, and moreover, the undiscussability is also undiscussable.4 Paradoxically, the existence of undiscussability makes blaming easy to detect. The manager of one project issued a memo saying that there would be no more discussion of project morale, and that he would entertain no questions on the subject because everyone should be grateful to be working on such a terrific project. This could happen only in a blaming organization.


A culture of blame usually starts at the top. Members of the top level of management are inclined to see the other people in the organizatation as the source of all problems. The employees are seen as “ungrateful” for the jobs, pay, benefits, and opportunities management has bestowed on them. They are seen to “lack an appropriate work ethic,” “not know the value of a dollar,” “have authority problems,” and “resist change.” These perceptions leave upper management in a predicament: “Do I fire them, or do I fire the people who hired them?”

Such managers feel that they are trying to realize a vision without getting the necessary support, which leaves them out on a limb. The internal kinesthetic experience of these executives is normally a dull and chronic headache-unless the profit margin is really down. In that case, they have more acute feelings, like pain in the chest and burning in the gut. Their low self esteem reflects outwardly in the form of frequent downsizing, re-engineering, avoiding serious problems, futile memos, and, of course, humiliating of subordinates. Towards themselves, they often practice addictive and self-destructive behaviors (which cannot be discussed, but are alway the subject of gossip).

Middle Management

When the top leadership is incongruent, middle managers constantly receive mixed messages. Project managers are told of their importance, then find that their seniors have bypassed them to intervene directly in projects or change the rules without consulting them. They feel as if they are living on a roller coaster–unable to predict whether a particular day or week will be an upper or downer. After being publicly humiliated a few times, they decide their best strategy is to try to stay out of trouble by not ever rocking the boat. Even though they cannot perform at their best, they try to appear important and extremely useful.

In the blaming organization, top managers try (perhaps unconsciously) to teach their middle managers their own blaming attitudes. When one project manager complained of her inability to get the developers to work faster, the Vice-President of Development said, “If your dog won’t jump high enough, get a bigger stick to beat it with.” Living in hail of such incongruence from above, middle managers’ survival issues stay close to the surface. As they did when they were children, they figure out how to either appease, please, or avoid the power owners. By so doing they insure their survival–and pass the blame on to lower levels.


At the bottom rung of a blaming organization, employees are usually looking for someplace else to work unless the company is in a stable condition with little competition-or if their retirement is within view. The way to survive is to hide out and appear only to pick up a regular pay check.

Employees are discouraged from thinking creatively–new ideas are interpreted as blaming the management or attempting to usurp their power and prerogatives. Employees are not rewarded for industriousness–but they are frequently punished for perceived “laziness.” Employees cannot seem to find their managers–except when there are problems. Then, the major efforts are directed as attaching blame rather than solving the problem at hand.

The style of blaming varies from organization to organization. It can be harsh, vindictive, direct or indirect–but it is always contagious. Some organizations have polished their blaming style to a high degree of subtlety–without raised voices, merely by a look, or a memo, or an e-mail message, or a phone call, or a visit if things are really bad. In other organizations, the blame is loud, angry, and frequently done in front of an audience of peers–ensuring that all get the message of who is right, who is good, who is in charge, and who should become invisible.

In such an environment, defensiveness becomes pervasive. To those without formal power and authority, it seems that those with power really don’t care about them–and would banish them with no feeling at all. Thus they feel justified in retaliating (in advance, and in secret), and in avoiding their managers and their problems.

Regardless of the style, blaming from the top always generates fear, malaise, errors, accidents, and passive-aggressive responses from the bottom. Those on the bottom feel small and act from a place of powerlessness. The lack of emotional safety effectively erodes the trust level and makes any attempt at congruence extremely risky. This envirorunent sounds awful and it is–both for the person who has regressed into emotional immaturity and, sadly, for the person at the top who is doing the blaming.

Those on the bottom of any large organization can easily come to feel a sense of dependency on those above them in the hierarchy. When blaming is the primary mode of dealing with people, this dependency is exacerbated. Then, out of a feeling of dependency, people easily generate a feeling of hostility. As this hostility grows so does the debilitating experience of shame–that overly critical judge that lies latent in all humans.

What Congruence Would Look/Feel Like

Most people who have experienced a congruent organization won’t tolerate the misery of working in a blaming organization. But many people haven’t ever had that experience, and have a hard time believing what a congruent organization is really like. Let’s look at what would happen if a healthy dose of congruence could be magically applied on a large scale to an incongruent project organization.


If we could magically install congruence in the internal programs of those blaming executives, their style would shift dramatically. For example, if they would truly consider the others involved in their communication, they would be more likely to believe in the intent of people to contribute, to be productive, to belong, and to learn–and would take deviations from this ideal as evidence of ineffective management. Their belief in the inherent value of all people along with a healthy respect for the constraints of the work context would engender energy, hope, appreciation, understanding, and gratitude among their employees.

An executive who truly does not believe in the good intentions of the employees will be likely to say, ‘No excuses! You will get this done on October First.” But, with employees whose intentions are bad, this style (or any other style) isn’t really going to work.

A congruent executive who truly does believe in the good intentions of the employees will be likely to say, “We need this badly by October First. What do you need from us to help get it?” This kind of mutuality and support enlivens a genuine “can do” feeling that increases the chance that a project meets its goals–and that nobody has to make false promises to escape abusive blaming.

When the top level managers sustain their commitment to congruence, they see that most workers appreciate the opportunity the business provides them in developing skills, meaning, relationships, and monetary rewards. They also know how to cope when the occasional worker doesn’t seem appreciative or even productive. Managers who know how to use their power congruently generally get the results they seek–not perfection, which they know not to expect.

These leaders know they have a special kind of power–power they use with awareness and sensitivity. They do not resist accountability to those they lead, but demonstrate the same level of integrity they seek from others. And if they cannot match the levels of commitment they request from others, they are open about that. They know they are sometimes going to be weak and vulnerable and need support–perhaps even to see the value of their own visions. They use their awareness of this human reality to nurture their capacity to empathize and to have compassion for themselves and others.

Congruent executives know that their principal job is developing their organization’s capability, not just pushing the same old shoddy products and services out the door. They involve themselves seriously in organizational improvement efforts while simultaneously involving others in the organization to ground these efforts in real-life, practical operational input and decision making. They know that synergy is needed for organizational development, and they know that synergy comes from high quality connections among people–regardless of level.

Middle Management

When the top folks begin to operate from congruence, the middle managers receive direct, clear messages–not mixed messages with double meanings. Communications are more open, making it is easier to know more about what’s really going on. Given higher quality information, they know more about how to be useful, so they can more easily join their leaders in their visions. Knowing more clearly the strategic directions desired and feeling that they count in this process frees them to contribute more generously and thoughtfully–rather than merely playing safe. Success becomes a goal that all can share.

Given their unique vantage points, middle people have useful input to assist in predicting problems, projecting realistic time lines, and forecasting trends. What they see, hear, think and feel is valued, and they are in a position to initiate behaviors that prevent project weaknesses from growing into project failure. They know the necessity of interdependence, so if major problems do develop, they can be counted on to provide–and seek-truthful information. They are not ashamed or afraid to work for those who employ them. Indeed, they have pride about their commitment to the organization–and know it is a commitment not so much as to schedules and budgets, but to the truth about schedules and budgets.

Because congruence at the top trickles down, middle managers take notice of the difference in their leaders. They respond to the modeling by passing it on to their constituencies. Everyone in the organization knows what is at stake in doing each job well, so everyone feels safe to tell what is wrong, what is getting in the way, and what is needed to fix it. Honest reporting of facts and feelings is genuinely appreciated, and do not put people at risk of being humiliated or losing their jobs. That’s why congruent organizations deliver their projects as promised.

Congruent middle managers encourage high quality communication. Their belief in people’s ability to learn and change towards more congruence make those around them responsive. With congruence radiating from the center of the organization, everyone can have a place, position, and function of importance and value–so things get done, and done right.


Working at the front line of a business where the top leadership is congruent, is entirely a different experience from working in a blaming organization. Commitment and energy are the norm, not the exception practiced by new employees until they “learn the way things are around here.”

Congruent organizations hold to an ideology that doing well in the marketplace is connected to doing well with employees as well as with customers. The perspective of the leadership includes a global consciousness about the existence of multiple non-linear factors, the importance of connections among all the various parts of the whole, and the necessity of all parts knowing their value. Workers feel that this is a company going somewhere, where growth is a natural state and everyones’ efforts count.

Workers in a congruent organization tend to have a long range view and can usually maneuver as needed to meet the changing needs of clients and customers. Employees trust that what they see and hear is real. They share in the enthusiasm of creating a future. They may not like everything that happens–for instance, they don’t always feel that they are rewarded adequately for what they give–but they don’t feel that there is a chronic pattern of undercutting, diminishing, discrediting, and devaluing them and what they do. They can risk congruence knowing that it will act as a catalyst for optimizing successful outcomes that benefit everyone.

Congruence is the bright secret underlying the success of many projects. A congruent culture helps a project in at least six major ways:

  1. People commit to plans they know only after open negotiation, so plans are more likely to be realistic in the first place.
  2. People come forth readily with facts that managers need to control the project, as soon as they are known, so managers can act early and act small to correct the problems.
  3. When problems are revealed, people readily come forth with creative solution ideas, increasing the chances for quick and effective solutions.
  4. A major portion of everyone’s effort is devoted to getting their jobs done, and helping other get their jobs done.
  5. Because human fallibility is considered normal, an appropriate–but small–amount of time is spent assuring the reliability of communications.
  6. People feel good most of the time, and thus are productive most of the time.

Congruence in Large Systems Development Efforts

In the course of developing systems, people engage in numerous acts of communication–about requirements, schedules, interpersonal problems, designs, progress, and just about anything else. That’s why effective individual communication is important in all projects, large and small. That being said, effective communication becomes even more important as the size of the development effort grows. The number of necessary communications goes up non-linearly with the size of the project, so the effect of imperfect communication style is magnified. Thus, if the quality of individual communications remains fixed while the project grows, the overall quality of communication will go down.

For instance, a certain level of congruent communication might be adequate for a producing a product with 25,000 lines of code, yet be totally unacceptable for a product with 2,500,000 lines of code. In order to develop larger and/or more complex systems, then, it’s not sufficient to pay attention to technical issues–accepting that the existing communication style will be adequate. Managers must also improve the project’s communication culture, and thus they must pay more attention to congruence.

To make matters worse, unless we manage well, tougher projects tend to dimish congruence–because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a viscious cycle.5

Congruence, of course, is but one of the factors in effective communication–other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.

Achieving Congruence

When Deming said, “Drive fear out of the workplace,” we think he was talking about changing the blaming organization to the congruent organization. This kind of change is made by one person at a time–hopefully starting at the top–and one step at a time. The steps can be broken down into six ‘A’s’, as follows: Awareness, Acceptance, Authorship, Articulation, Application, Activism. Let’s look at how each of these steps takes place in the context of an individual trying to change a blaming organization.


Awareness says, “This is happening. This is real.” Awareness comes from experience, when I allow myself to experience the world around me as it is–not as it is supposed to be, or I wish it to be, or someone else tells me they want it to be.

Awareness is always the first step, and probably the hardest, because generally we’re not aware that we’re not aware. Here’s a personal example of how lack of awareness stops the change process before it can even start:

Jerry was attending a project meeting in a software company–a meeting called by the company President to find out what was going on in a late project, After some coaxing, one of the developers said that she was afraid to go to Nat, the Development Manager, with problems, because of the reception she got. Nat got red in the face, stood up, and shouted angrily, “How can you say that? My door is always open to hear your problems! The only thing I won’t tolerate is if you’re all emotional when you come, or if you don’t have a proposed solution!”
In the calmest voice he could manage (it’s hard to stay calm when someone is being so angry, even if it’s not directed at you), Jerry turned to the President and asked if Nat ever came to him with problems. When the President said yes, Jerry asked if the Nat was always calm and carrying a proposed solution. Before the President could answer, Nat interrupted: ‘Why would I come with a problem if it wasn’t important enough to get excited about? And, if I had a solution, why would I come to him?”
Although it was now clear to everyone else in the room that Nat was demanding that others “do as I say, not as I do,’ he was unable to see the incongruence. Lacking awareness, there was no way Nat was going to change–and indeed he never did change, up to the time the President released him to seek greener pastures.

Nat’s case is quite typical. Since incongruence is a defense, incongruent people erect all kinds of shields that close off information about congruence. Their own incongruence, and that of others, is invisible–it is accepted, especially if it is the norm in the organization. This invisibility makes it very hard to reach them with any kind of information on the subject.

In other words, when you’re being incongruent, you’re losing your ability to take in what’s going on in the world (inner or outer). So, you don’t know that you need changing. And, even if you did, you haven’t a clue what to change to. No wonder it is so difficult to transform an incongruent culture, when the very first step–awareness–is so hard to come by.

Awareness comes from experience, when you allow yourself to experience the world around you as it is–not as it is supposed to be, or you wish it to be, or someone else tells you they want it to be. But in the blaming organization, where people shield themselves from experience, becoming aware usually requires help. Helping others become aware takes the skill to develop safe environments and to build relationships. It takes the patience and caring to watch for signs of awareness and help build on them. It also takes a belief and a commitment that “part of my job is to help the people on my team to develop– the most important part.” If you don’t believe this, then certainly don’t try to help people become aware. Otherwise, you’ll find yourself saying, “You aren’t aware of what a lousy employee you are, but I’m going to make you be aware!”

But awareness of the overall situation is not sufficient–you also need self-awareness. Self-awareness says, “This is me. This is mine.” You may be fully aware of the blaming, but as long as you merely say, “This is a blaming organization,” you’re not doing anything to change it. When you say, “I am a part of this blaming organization,’ you move forward. You own the blaming as a part of yourself and your behavior–not just something that “they” do (to you).

Self-awareness is often followed by depression or shame or guilt. Some people react with anger, at themselves or at any convenient target. Yet Self-awareness is empowering–the thought that since I own it, it’s mine to do something with.


Acceptance moves the change process beyond self-blaming and says, “I’m not a bad person because I do this. My intentions are good, though my actions may not be effective.” Acceptance means that you understand that taking responsibility is not the same as blaming yourself. Thus, you have mercy on yourself and your all-too-human imperfection. You stop being angry. You forgive yourself for not doing better in the past, based on your present understanding and standards. And, as you forgive and accept yourself, you gain compassion for the others involved–thereby increasing the chance that you can communicate with them and effect change.

At the point when you’re trying to reach acceptance, it’s critical that you not be punished or humiliated by someone else. You need a little help in getting off your own back, or else you think so little of yourself that you couldn’t possibly do anything about the situation. Of course, in a blaming organization, you may have a hard time avoiding this kind of punishment, which is why authorship and acceptance are usually done internally, and kept internal for some time.


Authorship is the first decision point, when you say, “I have choices. I can do something about this.” With some encouragement, you accept that you are responsible for choice in your life. You understand that you don’t have to react, but that you can chose your response–that you create, in large part, your own interpersonal context. You know there are some parts of the context that you can control and some that you can’t; and you know accurately which is which.


Articulation is the public commitment to change, and says, “I’m going public with this (for accountability and support).” Articulation is ineffective if attempted before the prerequisites are in place. If you can’t accept yourself or how you have reflected yourself out to the world, or if you don’t know that you have choices or feel you can gain support for those choices, then speaking out is merely ineffective bravado.

But, when the prerequisites are in place, you cannot be effective by keeping silent–you must decide to speak out. In the process of speaking you transform your inner awareness to another kind of experience. You hear yourself and you notice the response you get from others. You make public, if you will, your self–your mental and emotional position.

Initially, of course, you must seek out safe places to disclose your truer and more honest expressions of your thoughts and feelings. When you become more grounded in the power of your true self then you can seek the kind of support that challenges and confronts you, as opposed to the kind of support that coddles and consoles.

Initial steps of articulating congruence are often awkward. That’s why a responsive and receptive listener satisfies one of the requirements for promoting the development of congruence.


Application says, ‘These are my choices (my new ways of coping).” You learn to be congruent yourself, first in your most immediate, safe, and encouraging context. Then you expand the contexts in which you can respond congruently. Don’t try to “not be incongruent.” This paradoxical command only invokes the incongruence of perfectionism. (”If I can’t be perfectly congruent all the time, I’m worthless.”) Focus on congruence, practice congruence, and the incongruence “muscles” will simply atrophy.

With support and practice you can begin to use and test out congruence in your immediate relationships. We suggest that you continue to design for success, so that initially these tests of your new skill are done within environments where you will more likely be given the benefit of the doubt. As you experience success, then you can be centered even in more turbulent and conflicted arenas. In other words, once you “get the call,” don’t march into the president’s office and announce that henceforth, all the guilty parties must stop blaming, or else.


Activism says, “Now that I can make a difference in myself and my most familiar world, I’m going to help spread this throughout the organization.” Activism is applied leadership, starting at the point at which you have enough competence at being congruent to reach out and be proactive–anticipating, initiating, instigating–but not inflicting. You cannot operate from an incongruent position and force other people to be congruent. (”I have to blame them, because they’re so blaming. Once they change, then I’ll be able to change.”)

In any case, you don’t have to inflict congruence on anyone. Congruence is contagious–when directed consciously to creating a safe, nurturing, productive environment. It may spread more slowly than you’d like, but once it starts moving, it’s hard to stop.


  1. For more on how blaming and other incongruent styles impact software work, see Weinberg, G. M. (1994). Quality Software Management: Congruent Action. New York: Dorset House.
  2. For more on incongruence and verbal patterns, see Hardin, S. E. (1989). Success with the Gentle Art of Verbal Self-Defense. Englewood Cliffs, NJ: Prentice-Hall.
  3. Brooks, F.P. (1982). The Mythical Man-Month. Reading, MA:Addison-Wesley.
  4. For more on undiscussability, see Argyris, C. (1993). Knowledge for action: a guide to overcoming barriers to organizational change. San Francisco: Jossey-Bass.
  5. for more on such system dynamics of projects, see, for example:
    Senge, P. M. (1990). The Fifth Discipline: The Art & Practice of the Learning Organization. New Turk: Doubleday.
    Weinberg, G. M. (1975). An Introduction to General Systems Thinking. New York: Wiley-Interscience.
    Weinberg, C. M. (1991). Quality Software Management: Systems Thinking. New York: Dorset House.

How Much Work Can You Do?

Developing and Managing Your Project Portfolio

©2005 Johanna Rothman

This article appeared previously on

I meet many managers in the course of my work, and they all share a common complaint: They have too much work to do.

I ask how they know there’s too much work to do, and they look at me as if I’ve sprouted another head or two. “My staff and I are spread too thin?that’s how I know,” they answer.

I ask if more people would help. “Of course,” they answer. While they look at me as if I’m an idiot, I ask the question that too few managers can answer right then and there, “How many more people would you need,
and for how long?”

I have sympathy for those of you trying to work in organizations with too few people and too many projects. So, I recommend you develop an answer to the “how many people” question. Once you have the answer to that question, you can then deal with the trade-off question with your managers, “If I take on this new project, which work would you like me to stop?”

Define the Universe of Work

I develop and manage a project portfolio by first defining all the work (the “universe of work”), organizing the work by seeing when each person starts and stops each project or piece of the project, and by listing the unstaffed work.

It’s not easy to define all the work, so I make sure I include these activities when defining the work:

  • Project work (work toward a specific project with an end date)
  • Periodic work (such as monthly reports or yearly budgets)
  • In-process ad hoc work (work you are doing as the result of crises or other surprises)
  • Ongoing work (support for the operation of an
    organization or department)
  • Management work

Organizing the work this way ensures all your project work is included in the Universe of Work&msash;plus all the work you or your staff performs to maintain the lab, support a product, negotiate with another department, or to budget. When I discuss this with managers who are in charge of five to six people, it’s not uncommon for them to
list more than thirty activities. If you’re in a larger group, you may have more than thirty separate activities.

Take time to define your Universe of Work. I normally set aside one half-hour to write everything down. Once I have a first draft, I put my list away for a day. Afterward, I revisit it to see if I want to add anything. But don’t feel as if you need to complete your Universe of Work list with just one review; it’s easy to forget the periodic work or intermittent ad hoc work.

If you’re so busy you don’t have time to think, you may want to take a little time every day to review your list and add to it.

Organize the Work

Once you know what all the work is, you can make a plan of how you and your team will complete the work. I like to use a whiteboard or flipcharts for this, especially if I have more than a few people in my group. The top row of the paper lists your timetable, which begins with next week followed by consecutive weeks (January 1, January 8, January 15, and so on). Write the names of the people down the left most column. For each week, write down what each person is working on.

If you have many long projects, write the names of the months across the top of the page. Block out the projects, with their start and end dates down the page. Then take a one-month snapshot and fill in the blanks by person.

Now you have a list of what everyone is working on?and when?for the next month. And I’ll bet there’s more work from your Universe of Work list. List that work on the “unstaffed” list.

List the Unstaffed Work

Underneath the last person’s name, write “Unstaffed work.” Now, week by week, add in the unstaffed work row everything that’s in the Universe of Work that is not assigned to anyone. You should have a picture that looks something like this:

Week 1 Week 2 Week 3 Week 4
Amy Feature A UI Feature B UI Feature C UI Feature D UI
Bill Feature A database Feature B database Feature C database Feature D database
Claire Feature A middleware Feature B middleware Feature C middleware Feature B middleware
Don Feature A test Feature B test Feature C test Feature B test
Management Management Management Management
Project 1
Report B
(all of it)
Project 1
Report B
(all of it)
Project 1
Report B
(all of it)
Project 1
Report B
(all of it)

This is a portfolio for a cross-functional team. If you manage or are part of a single-function team, the tasks in the boxes would reflect that.

Estimate the People Required to Complete the Unstaffed Work

With this picture, you can see who’s working on what?and whether those people are multi-tasking?and how much work is not staffed. Now you can estimate how many people you would require to staff the unstaffed work.

Manage the Portfolio

I find that the hardest part of this is starting. Once I have a rolling wave, four-week portfolio, I find it relatively easy to maintain.

As you complete one week, add the data for the next week at the end of the plan. If you’re not sure how long a duration portfolio you need, start with a four-week plan. If you don’t have enough insight into the future, consider adding another week or two onto the end. But I find that few people or organizations are able to maintain detailed tactical plans longer than a few weeks, so more detailed planning isn’t useful.

Once you have a detailed rolling-wave plan, you’ll be able to answer the question of how many more people you need and how you could restaff the projects to take advantage of more people.

But I find the project portfolio chart much more useful than just showing my management where we are understaffed. I use the chart when my manager assigns my group more work. I show my manager the chart and ask, “My staff are working as hard as they can. They can’t do more. What work would you like me to move to the unassigned work?” Now we can have a conversation about how much work needs to be done, the criteria for completing the work, and the relative priority of the work.


Knowing how much work you group can accomplish?and when they can finish that work?is critical to your success as a manager. With a project portfolio, you can manage the work. You can make tradeoff decisions about which projects to staff and which ones to leave unstaffed. And you’ll know how many more people you need for how long. Make sure you’re managing the project portfolio, not allowing it to manage you.

The Identified Patient Pattern

©2006 Don Gray and Jerry Weinberg

Engelbert frowned, trying to understand why Pamela had been acting strangely. Her programming skills were among the best in the company. She had a way of getting things completed. That’s why he made her project lead for Uberdenke’s next UDCRM product release.

With only two weeks left until the ship date, Pamela’s personality had shifted. Normally calm and composed, she had been seen crying after meetings. Occasionally he could hear her screaming at the programmers working for her. Something had to be done. He was going to have to figure out what was wrong with Pamela. And fix it.

Engelbert’s decision casts Pamela as an “Identified Patient.” The Identified Patient becomes the focal point for the Engelbert’s intervention work to “solve the problem”. When Pamela is “cured”, Engelbert thinks, he can return to his normal schedule. Until then, he has more important work to do.

What happens when Engelbert becomes involved with the Identified Patient Pattern? And is Pamela’s behavior change really the problem? Could there be a fundamental problem that Engelbert is overlooking? What effect does Pamela’s behavior have on the project?

Identified Patient Dynamics

Trying to answer these questions requires considering several
points. As Pamela’s behavior becomes more pronounced:

  • People become distracted.
  • Extra work gets created (trying to “cure” Pamela) and time gets spent doing non-productive tasks (appeasing Pamela, hiding, gossiping).
  • The less useful work gets done.

This seems straight forward enough. But how do these relate to each other? Using a diagram of effects we can visually represent the process as

Identified Patient Activity

Figure 1 – Identified Patient Activity

This diagram shows the downstream effects these actions cause. Eventually these actions adversely impact Remaining Work, which increases Deadline Pressure, which increases Identified Patient Activity Level. And the dynamic starts over again with amplification due to the prior looping. The loops are all negative feedback loops. This means once Pamela (or anyone) becomes the Identified Patient, the system starts down hill, and continues until it hits a natural limit and stabilizes or collapses.

Without knowing it, Engelbert and the UDCRM team become embroiled in activities that add more pressure to system, thereby creating more Identified Patient Activity Level on Pamela’s part. By trying to “cure” Pamela, Engelbert engages in treating the symptom, not fixing the problem. In this case, Deadline Pressure continues to build, creating more stress and exacerbating the Identified Patient Activity Level.

All Stressed Up and No Where to Go

What does Pamela’s worldview look like? She’s the project lead for the next release of UDCRM. The project started with a bad release date (see “The Liar’s Contest”). Engelbert knows this (”No Exit). The project team can look at the remaining work and see they won’t make the ship date.

Uberdenke has to two intertwined systems: the formal hierarchical system with nice boxes and lines, and the informal “shadow” system formed by acquaintances, friends, antagonists, history, and working relationships. The intertwined systems can be congruent or incongruent. When the systems are incongruent, the informal system struggles to compensate–not always effectively–as long as possible. When the informal system can no longer compensate, it doesn’t degrade slowly, it collapses.

In this case the formal system won’t acknowledge the inevitable until it’s too late. The project team (informal system) knows they can’t meet the date, but for a variety of reasons don’t feel able to update the formal system with their reality. The incongruence between the formal and informal system takes a mental and physical toll on the employees by creating stress. To protect the others from blame, one of the people may actively (but perhaps not consciously) adopt the role of Identified Patient by “acting out” in bizarre ways. This behavior serves to distract management’s attention from the other people, but at the same time distracts them from the true, underlying problems. In the short run, then, Pamela is rewarded for her bizarre behavior, and reinforced to continue “protecting others.”

As project lead Pamela embodies the stress and manifests it via her behavior. As her stress level goes up, her behavior becomes more erratic. As her behavior becomes more erratic, the less remaining work gets finished (see above figure), which increases the project tension and so on.

When Engelbert starts trying to “cure” Pamela, two problems occur. First, the Identified Patient dynamic starts, engaging the negative feedback loops. Second, Engelbert’s attention becomes focused on Pamela, and misses the opportunity to look for a fundamental problem. Trying to “cure” Pamela may momentarily reduce pain, but–because the real problems are not being addressed–this ultimately leads to system collapse and much more pain.

Combining Pamela’s stress and Engelbert’s actions results in the following diagram.


Figure 2 -Triangulation

Once again we see two negative self-reinforcing loops:

  • Pamela’s Tension/Stress/Patient Loop
  • Engelbert’s Tension/Stress/Patient/Responsiveness Loop

Both loops keep on keeping on, resulting in more of what we already have. This results from the Identified Patient’s second order nature. Second order nature doesn’t mean the tension and stress aren’t real. It means some other problem causes this problem. Trying to cure an Identified Patient is like scratching athlete’s foot. You’re doing something that feels good, but when you quit scratching you still have athlete’s foot, and wounds from the scratching, which has also spread the fungus more widely.

To improve the situation, Engelbert needs to move from the negative reinforcing loop to the Tension/Stress/Awareness/Responsiveness balancing loop.

What You See isn’t What You Get

To “cure” Pamela, Engelbert needs to determine what’s making Pamela act out. Difficulties with this include:

  • Something in the formal system doesn’t want to know what the informal system knows.
  • Pamela’s behavior masks the real problem.
  • Engelbert may not have the interpersonal skills needed for this.

Management acknowledging the delivery slip would relieve the deadline pressure and stress wouldn’t build. Unfortunately managers promote what they want to hear with such comments as:

  • I don’t want to hear problems, I want hear solutions.
  • Our competitor can do this, why can’t we?
  • You’ll just have to work smarter.
  • If you can’t do this, I’ll find someone who can.

Comments like these ensure that managers only hear good news, until there’s no possible way to hide the bad news. Then they ask, “Why didn’t they tell me sooner?”

Pamela’s behavior indicates a problem exists, but doesn’t give a clue what it might be. Pamela could be acting out because of:

  • Work stress (our example).
  • Triangulation (compensating and covering for a fellow employee).
  • Problems at home.
  • Substance abuse.
  • Sexual harassment at work.
  • Some other unresolved problem.

Most software development managers made it there by having great technical skills, not great people skills. If Engelbert discovers the problem isn’t work related, he’ll need help. Dealing with personal problems in a work environment can be a legal minefield, and is best left to people trained to do it.

In the extreme case, Engelbert may choose to blame Pamela for the project’s problems. While incongruent and counterproductive in the long term, this tack appears to have short-term benefits. Pamela becomes the scapegoat, and hopefully the problems will leave when she does. In the mean time, a new delivery date will be set (while in panic mode). This temporarily relieves the Deadline Pressure. This dynamic may execute several times, until eventually some new delivery date finally provides the time necessary to complete the project. Or, the project collapses under all this extra effort and emotion.

Dealing with an Identified Patient

Identified Patients exist everywhere. The tip-off comes when you hear or think, “Things would be better if this person would just leave.” In reality, that person leaving won’t change the underlying system, and someone else will take on the role. The key to success starts with understanding the Identified Patient functions like a canary in a mine. They provide an early indication something is wrong and needs to be dealt with, but replacing the dead canary will not clean the toxins out of the air. Unfortunately, unlike the canary whose death tells the miners that the air is probably poisonous, the Identified Patient doesn’t indicate what problem exists. One thing for Engelbert to consider: the closer he gets to finding the real problem, the more Pamela may act out. One of Engelbert’s options involves getting the UDCRM team to focus on the remaining work, thereby reducing the attention given to the Identified Patient Activity Level. This becomes an exercise in active support and barrier removal, not platitudes and posters about success through working harder. If the Identified Patient Activity Level gets even larger, this indicates that something else is going on.

If Engelbert can remove Pamela from the system, it might allow the problem to show. Of course removing Pamela might cause other problems which would again mask the original problem provoking Pamela’s behavior. Another person becoming the Identified Patient would indicate underlying system problems. If the Identified Patient Activity Level prevents any useful work from being accomplished, this may be the first action to take. Hopefully, Engelbert will be able to find and fix the problem that created the IP. Engelbert needs to be aware some fixes actually exacerbate the symptomatic problem. Common fixes that fit this dynamic include:

  • Adding tools leads to the “worse before better” dynamic as productivity drops while people get used to the new tools.
  • Splitting tasks leads to the communications/interface dynamic where information needs to flow through more paths and permutes while doing so.
  • Splitting people between tasks leads to context swapping overhead, that period of time it takes to remember where you were and get back into the flow.
  • Adding new people to the project basically incorporates all the above dynamics.

Stress Reduction

Engelbert has several options available to relieve the Deadline Pressure causing Pamela’s behavior. He can use any one of three project leverage points to change the amount of Deadline Pressure:

  • Features – If the number of features decreases, the Remaining Work decreases, which decreases Deadline Pressure.
  • Quality Goal – If the acceptable quality is reduced, the Remaining Work reduces, which reduces Deadline Pressure.
  • Desired Ship Date – As the Desired Ship Date gets bigger (more days to ship), Deadline Pressure goes down.

This looks like:

Intervention Points

Figure 3 – Intervention Points

At this level we now have balancing feedback loops that help stabilize the system. Selecting the best leverage point or combination involves determining how the Uberdenke clients can best be served.

What to do if you’re the IP

Identified Patient behavior has several possible causes. These include:

  • Boredom – which results in irrelevant behavior
  • Triangulation – based on placating behavior. Could be caused by
    • Incongruent formal/informal systems
    • Compensating for other people in the system.
  • Really bad managers using blame to cope with bad results from poor decisions.

Identified Patient behavior is a symptom, not a cause. If management does recognize the behavior, they’ll most likely try to fix you, not the cause. Unless you want to be “fixed”, it’s important to recognize the source of your incongruent behavior. This enables you to work on becoming more congruent and changing the source of the Identified Patient behavior.

“If what you’re doing isn’t working, try something else.” Marvin’s First Law1

If you’re bored, change yourself. Try and find a more challenging position in the company. Take up a hobby that will provide the challenge you’re looking for. If necessary, consider changing companies. Get interested in solving some real problem that’s hindering others.

Triangulating due to incongruent systems doesn’t accomplish anything. The systems eventually align when the informal system collapses and the formal system has no choice. This usually happens too late to do meaningful risk management and damage control. Much pain accompanies the collapse. Trying to alert the formal system to impending doom may get you labeled as “Nay-sayer”, “Not a team player” and such. If this happens, consider changing companies.

While a nice concept for those taught to “play nice with the other kids”, triangulating by covering for other people boomerangs at two levels. You’re not going to be able to do the work for two people, the amount of remaining work will go up, leading to deadline stress, and the incongruent systems dynamic comes into play. Along the way, you’ll become exhausted and your health, both mentally and physically will deteriorate. This reduces your ability to produce and the cycle starts over again. It’s OK to occasionally help other people. But if helping other people gets in the way of getting your job done, learn to say no, or find another company to work for. Whatever you do, do it directly. There’s enough confusion without adding triangles to the mix.

Lastly, if you can’t change the system, and changing companies isn’t an option (and sometimes it isn’t), recognizing the dynamics that create the Identified Patient behavior can help you cope as congruently as possible.

And in conclusion

Identified Patients indicate something is wrong. Trying to “cure” Identified Patients seems important, but lowers the amount of useful work accomplished. Locating and correcting the fundamental problem is the best way to “cure” the Identified Patient. Engelbert needs to remember that correcting the fundamental problem may temporarily cause other problems.

1 Weinberg, G.M., The Secrets of Consulting. 1986, New York: Dorset House Publishing

What’s Wrong With Wednesday?

©2005 Johanna Rothman

Many of the project schedules I review contain milestone completions on Fridays and new task or phase beginnings on Mondays. With a Friday or Monday milestone, what you’re really saying is that people can work overtime all week and all weekend to make the Friday milestone, so they won’t be late for the Monday start.

Why? Why do we do this to ourselves and to our project teams?

It’s convenient to think about project milestones ending on Fridays and new things starting on Mondays. But just because it’s more convenient from a calendar perspective, should we use Fridays and Mondays to end and begin project segments?

I say no. Down with Fridays and Mondays. Let’s end and begin project segments on Wednesdays. Wednesday is a perfectly good day, and one that is possibly underutilized in project planning. Tuesdays and Thursdays are also good, and in my experience, underutilized. Here are the effects we might see if we choose a Wednesday to end a project phase or start a new phase.

  1. Improve schedule precision. We would know that our schedule estimations are wrong, and we might know more about how we estimate incorrectly. When we hide the actual milestone complete dates behind massive overtime, we encourage our project staff to inaccurately predict the next schedule, leading to even more overtime. Here’s why: When we schedule project phases to complete on Fridays, we allow ourselves to take the weekend to complete the pieces not quite done on Friday. Completing a phase on Friday really means the phase is complete by the time people get to work on Monday morning. If we don’t complete the work by Monday morning, then we’re honest-to-goodness late. But, if we completed the work on Sunday morning, are we truly late? In reality, yes! We have underestimated the work, and we need to know about that underestimation to improve our estimation the next time. Otherwise, we can continue to underestimate projects by however much we are underestimating them now.
  2. Adjust for schedule risk sooner. We would know earlier in the project that the project has a higher risk than we earlier believed of not meeting its release date. The earlier in the project you know that the project is in trouble, the more options you have. At the beginning of the project, you can still add more staff, change tools, drop features, modify your life cycle, change how you work to reduce defects, or choose to allow more defects. In the middle of the project, you may be able to add more staff, drop features, change how you work to reduce defects or choose to allow more defects. At the end of the project, you can drop features or choose to allow more defects. As a project manager, I want to have more options rather than fewer when I’m faced with schedule-related bad news.
  3. Avoid hidden overtime. We would have less self-induced project overtime. When we’re in the last couple of weeks of the project, it may make sense to ask people to work overtime. Many people can manage a week or two of overtime and still think carefully and make good decisions. However, allowing overtime for more than a couple of consecutive weeks is a poor management decision. People who work overtime for more than a couple of weeks stop thinking clearly because they’re too tired. Or they don’t have any new ideas because their brains are stuck on the same old ideas. Or they stop paying attention to themselves and their self-care, so they get sick and then pass the disease to everyone else, causing the entire project team to work at less than full strength. When we schedule for midweek milestones, the amount of overtime needed is much more obvious, and we can make conscious choices about how much overtime to use on the project. If you have numerous two-to-three-week minor milestones, and people are constantly working overtime to meet the milestones, you have an entire project of overtime. Constant overtime generally leads to staff burnout and software technical debt.

So if you’d like to see just how close your schedule estimates are, create schedules with milestones ending in the middle of the week. Track how closely you meet each milestone. At the end of the project, look at how much extra time you needed and see if you could have planned your project or estimated the tasks differently to have developed a more accurate schedule at the beginning. Make your project schedules honest and help yourself see the reality of the schedule sooner, say, on a Wednesday.

Watch for Falling Rocks: Unpredictable Risks

©2000 Johanna Rothman,

I was recently driving on some back roads in New Mexico, and saw the sign “Watch for Falling Rocks.” I turned to my husband, Mark, and said “Now, why do they tell us to watch for Falling Rocks? Why don’t they tell us to watch for Fallen Rocks? What in heaven’s name can we do about them, even if we see them?” Mark shrugged and grinned at me. I sighed and said, “It’s a Mystery of Life.”

A few minutes later, I realized that successful project managers watch for falling (and fallen) rocks all the time. They constantly assess risk from all directions, and manage the project’s progress to avoid the falling rocks, as well as other impediments to the project’s success. Some risks you can predict. Other risks you just have to watch for.

I’ve run into falling rocks on projects when:

  • A team member discovered her tumor was a pregnancy, and then gave birth within 48 hours of that discovery.
  • Two team members broke off their up-till-then secret romance.

My falling rocks have all been unpredictable people issues. I’ve been able to manage explicit technical risks, such as new versions of compilers, databases, or other supporting products. The project teams I’ve consulted with have anticipated those kinds of risks. However, we’ve never fully anticipated the people risks.

Unpredictable risks can turn into disaster, as falling rocks can do when you’re driving on back roads. So, what can you do about unpredictable risks?

Observe the project

As Yogi Berra said, “You can observe a lot just by watching.” Risks, especially implicit risks, don’t have to be a Mystery of Life. If you pay attention to the people on your project, if you observe what’s going on, and how people are working, you have a better chance of seeing the rocks before they land on your windshield. There are a number of ways to observe your project:

Watch how people on the team interact. Are they collaborating in small groups, or are some people working alone? Should they be working together in larger groups? Are the people working in a way that fits the project’s needs?

How do people feel about the project? Are people excited about their work, or are they just putting in time? Sometimes people just come to work to do their jobs although they’re convinced the effort is futile, but since you’re paying them, they’ll keep working.

Are people not talking about the fallen rocks? I’ve sometimes been hired to consult on projects in which rocks have fallen and no one is talking about them. It’s as if there’s a “Cone of Silence” over the project — other people can see the rocks and talk about them, but the project participants can’t. When that happens, people say things like, “Everything’s fine,” but they say it with a sigh or a frown. Talk to the people on your project in a variety of ways: one-on-ones, over lunch, in the project meeting. Listen to what people say and don’t say, and how they say it.

Is someone unable to do his or her project work? Are other people covering for that person? Do some people regularly come into work late and leave early? Is someone taking a lot of sick time, or seeing the doctor a lot? Look for patterns of behavior that suggests rocks have already fallen. There are numerous reasons for people not to do their project work. Discover the reason, or at least keep an open dialogue with the person having trouble.

Assess the damage

What are the effects of what you’ve observed? How bad is it? When two team members broke off a secret romance, they were no longer secret about their hurt feelings. If I’d ignored them, they would have polarized the group, by making their colleagues choose sides. Since the project team was only eight people, the effects of choosing sides would have paralyzed us. I spoke to both of them separately, and explained that I needed them to exhibit certain behaviors at work. We all agreed they couldn’t and wouldn’t ignore their feelings, but they would attempt to work in a professional, if not collegial manner. If I’d worked in a larger company, I might have asked one or both of them to transfer to other projects. However, in a company of 20 people, there was no other project.

Replan your route

When the team member discovered she was pregnant, instead of sick, we were relieved — surprised, but quite relieved. When she started feeling awful and going to the doctor for tests, we talked about her “illness.” She was concerned that she couldn’t do the work we needed her to accomplish, and that I would fire her. Firing her was the absolute last thing I would do, not the first thing. We jointly put together a work plan that allowed her to do the work we needed done at the times she could do it. She took naps, saw doctors, and was still able to do the required testing. Once she had the baby, our current plans went out the window. However, because she’d kept me aware of her condition, I was able to make other contingency plans quickly.

Unpredictable risks, like falling rocks, are a Fact of Life, not a Mystery of Life. If you observe, assess, and replan, you can avoid much of the consequential damage. In addition, as Mark told me in New Mexico, “Honey, maybe I’ll just drive a little slower, just in case there are some fallen rocks or rocks about to fall.”

How to Improve Meetings When You’re Not in Charge

©2004, Esther Derby

This column originally appeared on

Are you tired of attending endless meetings where the conversation goes in circles and nothing gets done? Even if you can’t stand up and take control, you can nudge the meeting in the right direction from where you sit. Here are some strategies for improving the quality of meetings when you’re not in charge.

Ask for an agenda ahead of time. When you receive a meeting notice, ask for an agenda. Make your request in the spirit of the best use of everyone’s time: “Knowing the agenda will help me come prepared to participate.” You can also say, “Knowing the purpose of the meeting will help me determine whether I can contribute.”

Sometimes a request for an agenda is unsettling to the meeting convener? probably because he hasn’t though through the purpose of the meeting. Your request may prompt him clarify in his own mind why he called the meeting. If you’re really lucky, he’ll realize he didn’t really need a meeting at all (it happens!).

Sometimes though, a meeting convener will insist that you must be there, even though he can’t provide an agenda. I’m a little skeptical when the meeting convener assures me that I need to be there but can’t articulate the purpose of the meeting. If you feel like its not political suicide, tell the meeting convener that you can’t assess the priority of his request against all your other work without an agenda.

Send only one person. Sometimes the person calling the meeting goes overboard to be inclusive. If two or more people from your group are asked to attend a meeting, check to make sure that all perspectives are really required. In many cases, one person can speak to the interests of the group and you can send a representative. One person can go spend an hour at the meeting and then report to the rest of the group. Fewer people will make the meeting easier to manage and the people from your group who don’t go will have a bit more desk time.

Politely decline the invitation. When you don’t have relevant knowledge and expertise to contribute or won’t be affected by the outcome of the meeting, bow out. Ask to be on the distribution list for meeting notes or other communication.

Offer to take notes. Some times when I talk to people after a meeting, its hard to believe we were in the same room. Taking notes can help. As a participant you can offer to help by taking notes. Bring your flip chart paper and a marker and take notes so that all can see. Taking notes in public ensures that every one agrees that what is written is what was said.

Facilitate from where you sit. A well-timed question or comment has saved many a meeting. Here’s a sampling of tactics that I use to facilitate from the back of the room. One word of caution about facilitating from the back of the room: Do this only if you genuinely want to be helpful. If you’re feeling snide, it will come across in your voice.

Request a review of the agenda. When you arrive at a meeting with an overstuffed agenda, make a request to review and prioritize the agenda: “I’m wondering if we have time to cover everything we need to in the time we have. Can we please review and prioritize the agenda before we start?”

Ask for a progress check. When you see that time is getting short, ask for a process check: “I’d like to check on our progress. Its 1:50 and we still have three topics on the agenda. Can we prioritize them since we can probably only do one in 10 minutes?”

Help others participate. You can help the meeting when you help others participate. If you see a quiet person trying unsuccessfully to break into the conversation, say “I think Jennifer has something to say.” Don’t force her to speak, but make an opening if she wants to take it. You can also help when a speaker is interrupted: “I think we may have cut Josh off before he had a chance to finish. Josh?” Then Josh can finish his though if he wants to, and the interrupters will be a bit more aware of their behavior.

Rephrase. Sometimes rephrasing can help when someone is stuck on one point: “What I hear you saying is XYZ. Is that right?” Rephrasing helps people feel heard and can break the logjam.

Comment on what you observe. Sometimes it helps to comment on what you observe: “I think we’ve covered that already,” can help get people moving again.

Summarize. Summarizing important points and decisions can help the group move forward. “Here’s what I heard us agree to. Is that right?” Don’t be upset if people disagree with what you’ve said ? you’ve just turned up the fact that people really don’t have a common understanding. Once you’ve surfaced the misunderstanding, it’s more likely to be resolved before everyone leaves the room.

You may not be able to solve every meeting problem when you’re not in charge. But you can help many meetings to run more smoothly. After a while, people may start following your cues: they’ll write an agenda, pay attention to whom they invite and start attending to the interaction. And you’ll look good, too.

The ROTI Method of Gauging Meeting Effectiveness

©2003 Esther Derby.

This column originally appeared on

If you lead meetings, you can make improvements starting tomorrow. For a small investment of your time, you can return time to your staff by eliminating unnecessary meetings and improving the ones that remain on the calendar. And when staff has more time, it means your group is more likely to meet its goals.

Start with the basics: Purpose, Plan, and People

Be clear on the purpose of the meeting. If there isn’t a goal, a meeting doesn’t usually help. Bring people together when you have a specific goal or purpose for the meeting. My rule of thumb is to have one and only one purpose for a meeting.

If you feel you have to have two purposes in the meeting, separate them within the meeting. Perhaps you want to know what obstacles people are running into and work on solving those problems. Time box each portion of the work: list all the issues and declare that part of the meeting over. Then move onto problem solving. Prioritize the problems and excuse the people not directly involved in the problems you intend to cover.

If you start problem solving on the first issue, you may not surface the most important issues. Most likely, the people not directly involved in solving the specific problem will not feel their time is well spent.

Have a plan. The agenda is the project plan for a meeting. It lays out the steps or topics you’ll go through to accomplish the purpose of the meeting. If the purpose of the meeting is to review and rank vendor proposals for a new CM tool, the agenda might look like this.

  1. Review decision criteria from June meeting (5 minutes)
  2. Site visit summary and assessment from Vendor 1, Vendor A, Vendor Q (20 minutes each)
  3. <break> (10 minutes)
  4. Review raking process (5 minutes)
  5. Rank vendors against criteria (60 minutes)
  6. Next steps — actions and assignments (15 minutes)
  7. Meeting wrap up (10 minutes)

In the best of all possible worlds, every meeting would have an agenda and that agenda would be distributed well in advance of the meeting. Distributing an agenda before hand allows people time to prepare or to assess whether their attendance at the meeting will add value for themselves and other meeting participants.

Last time I checked, we weren’t in the best of all possible worlds. If you don’t distribute an agenda before hand, make sure the purpose and goal of the meeting are clear to participants and then build an agenda at the beginning of the meeting. Then you can prioritize and assess how much you can reasonably accomplish in the time you have.

An over-stuffed agenda is a common problem. I saw meeting agenda that listed 20 topics for a one-hour meeting. Three minutes per discussion topic might be reasonable? or it might not. Thinking through the agenda will help avoid the horrible rolling agenda problem: when we don’t finish the agenda, we roll those items into the next week (so we have an overstuffed agenda again!).

Invite the right people.

Invite the people needed to accomplish the purpose of the meeting. If the goal of the meeting is to make a decision, are the people who have the responsibility and authority to make the decision in the room? Don’t complicate matters and muddy the meeting by including innocent bystanders. But what if people need to know the results of the decision? Ahhh. That’s a different purpose from making the decision, and requires a different sort of meeting (or not).

Once you have these basics down, troubleshoot your existing meetings.

Is a meeting the best vehicle to accomplish the goal?

It really helps to have a group together to understand all sides of a complex problem, reach a group decision, generate ideas or alternatives, and solve problems. Notice that these are all synergistic activities… not one-way communications. If the purpose of the meeting is to disseminate information, an email might suffice, unless the information is emotionally charged.

Trust me, very few people will be upset if you reduce the number of meetings on their calendar.

Some status meetings are essentially serial two-way communication. Each person reports his status in turn, and the manager asks questions of that person. Consider replacing a serial status report meeting with one-on-one meetings. By eliminating the serial status meeting, you’ll free up staff time. It’s true it will take more of your time to meet individually with the people on your staff. However, I can almost guarantee that you’ll hear about problems and obstacles in a one-on-one meeting that won’t come up in a group setting unless there is very high trust in your group.

Is the meeting structured to make the best use of participant’s time?

Brandon, a manager in an internal IT department noticed that people were looking bored in his weekly 2-hour staff meeting. Brandon spent 10 minutes on corporate and department information and then each team had roughly 35 minutes to update him on status. Brandon tried to spice up the meeting with jokes, fun activities, and treats. It didn’t help.

Brandon’s group worked as three separate products with little cross over. Except for the first 10 minutes, the discussion was irrelevant to 2/3rds of the group. Cookies weren’t a big enough pay off to make up for being bored for 70 minutes out of every meeting.

Brandon dropped his weekly staff meeting in favor of an email that outlined important information that all three groups needed to know. And he set up separate 40-minute meetings for each team. This arrangement didn’t take up more of his time and gave back over an hour each week to team members.

Work on improving meeting effectiveness.

If you host an on-going periodic meeting, you have a great opportunity to make incremental improvements. Start asking for feedback on your meetings, and be willing to make changes based on the information you receive.

At the end of the meeting, ask participants to rate their Return on Time Invested (ROTI) using this scale:

0 1 2 3 4
Lost Principle: No Benefit Received for Time Invested Break-Even: Received Benefit Equal to Time Invested High Return on Investment Received Benefit Greater than Time Invested

The benefit you receive for your time can come in several forms, depending on the purpose of the meeting:

Information Sharing: Did you receive answers to questions or hear information that allows you to overcome an obstacle, move forward on your tasks, or avoid rework?

Decision Making: Did the meeting result in a decision that allows you to move forward?

Problem Solving: Were the people in the meeting able to succinctly state a problem, generate candidate solutions, or decide on a course of action?

Work Planning: Did you leave the meeting with a clear idea of what you and your colleagues will be working on this week? Do you understand the goal your striving for and understand what the priorities are?

As each participant states his/her rating, build a histogram that shows the results. It might look like this.

Meeting ROTI
4 |
3 ||
2 ||||
1 |
0 |

I’m happy if most people feel the meeting was a break-even investment. Still, there’s almost always room for improvement. Even if everyone rated the meeting at 4, it’s worth doing the next step to find out why the meeting worked well so you can repeat your success.

  • Ask the people who rated the meeting 2 or above what specifically they received for their time investment.
  • Ask the people who rated the meeting at 0 or 1 what they wanted but didn’t get.
  • Then ask what specifically worked, what didn’t work, and for possible changes.

Don’t assume that a rating of 0 means you did a poor job. A zero rating may simply mean that the person didn’t care about the topic. That’s easily fixed by publishing an agenda ahead of time.

I’ve found that these steps make a big improvement in the quality of meetings and reduce the number of meetings. It takes some effort, but the pay off is usually significant.

What do you find makes a meeting effective? What have you done to improve meetings in your group?

Should a ScrumMaster Give Performance Appraisals?

©2006 Esther Derby

A ScrumMaster recently asked me if he should take over
responsibility for year-end performance evaluations since he was closer to the
work than the functional manager for the team. It’s not the first time I’ve
heard this question, and as more companies begin to use Scrum, I’m sure I’ll
hear it again.

It does make sense for a ScrumMaster to give feedback. But
when it comes to taking over (or participating in) the annual appraisal,
ratings, or rakings, my answer is “No. No. No!”

Here’s why.

There’s a fundamental conflict between coaching to improve
effectiveness and evaluating for ratings, rankings, raises, or promotion.

Yearly appraisals, performance reviews, and evaluations
emphasize hierarchy and differences in status. ScrumMasters are in service to
the team; they don’t manage the team. Creating a higher status position
(evaluator) is an impediment to the team self-organizing?and to team learning
how to give each other feedback and manage their own performance.

People who receive high ratings may bask in the glow of
affirmation. However, psychologists know that 80% of people believe their
performance is above average. Statistically that can

The Secret Ingredients of High Morale

©2004 Esther Derby

This column originally appeared on

Jessica and Sean scowled as they headed back to their cubicles after the company spirit meeting.

“I can’t believe they wasted two hours of our time with that award ceremony and stupid pep talk,” Jessica said. “Talk about de-motivating. Morale is bad around here with out wasting our time.”

“Yeah,” said Sean, “It was like the Oscars for the never-done-nothing crowd. I can’t believe they gave out those hokey certificates.”

“If they really want to build morale, they’d stop changing priorities every two days and let us get some work done,” Sean responded.

“When pigs fly,” answered Jessica. “I’ve got to get back to work… I’ll be here ’til midnight getting everything ready for the build.”

As Jessica and Sean turned down the hallway, Ted, their manager, peered around the corner to make sure the coast was clear. He hadn’t intended to eavesdrop, but he’d just heard an earful. “Do they really think managers are that clueless?” Ted wondered. “I always thought recognition and team spirit helped morale… that and a big pay raise. But maybe I’ve got it wrong.”

Ted may have been hearing something new, but we can’t be too hard on Ted. Recognition and rah-rah have been the conventional wisdom for building morale for a long time. Unfortunately, there is no quick fix. Cheerleading is no substitute for the hard work of creating solid morale.

If you’re a manager or a team lead and you really want to improve the morale on your team, take heed of this list — inspired by some real experts on what it takes to build morale in software teams — a software team.

Keep workload reasonable. If your team is being asked to “do more with less” (and who isn’t these days), it’s time to set priorities and decide what not to do. You can only do it all if you don’t care what “done” means.

Set a sustainable pace. A 40-hour week will do wonders for morale. Enforced overtime will not. The more overtime people work, the less productive they are.

Avoid multi-tasking. Assigning people to work on several projects at once creates the illusion of progress. In fact, multitasking slows down progress. Most people are motivated by a sense of accomplishment — actually finishing something. Multi-tasking works against a sense of accomplishment because it takes longer to finish everything.

Articulate a clear mission for your group. People want to know that they are working on something worthwhile. Even if you’re not in control of the company mission or product mission, you can articulate a mission for your group. Perhaps your group’s mission is to “Provide accurate and timely information to management about the quality of the product” or “Create inviting and easy-to-navigate documentation that enables our customers to access all the features of Widget Master.” Say it. Document it. Then stick to it. When you’re deciding on goals and how to achieve them, ask yourself and your team “How will this action help us meet the mission of our group?”

Set clear goals. A mission tells the big story ? why your group exists. Every group needs goals, too — specific, time-bound achievable goals. Your group’s goals may relate to a release, a project, or a service level. People will pull in the same direction when they know what that direction is. Muddy goals make it hard for people to focus their efforts and contribute to poor morale.

Set clear priorities. Shifting priorities undercut morale. People don’t like to throw away the results of their hard work. And switching priorities can have the same effect as multi-tasking — nothing reaches completion. Change priorities often enough, and people will view the newest priority as “flavor of the day.” The reality of business is that external events may dictate changes. Iterative development, with its 3 ? 6 week sprints, is one of the ways to manage for accomplishment in a shifting environment. If your organization can’t hold to one set of priorities for 3 weeks, it’s going to be hard to make forward progress in any direction.

Remove obstacles. This is one of the most powerful morale building tools in a manager’s toolkit. Find out what’s getting in the way and work to remove the impediment. When people see their managers are making it easier for them to work, morale goes up. Managers can’t always remove every obstacle. Let people know what you’re trying, and be honest if you can’t fix it.

Don’t over specify. Give people the goal, set them in the right direction and let them decide how to get there. People will come up with a surprising number of creative ways to achieve the goal. Telling people both what to do and how to do it stifles morale. There’s only one thing more de-motivating than over specifying the goal and the method: over specify the method, and not articulating the goal.

Deal with the un-jellers. It’s hard enough to build software without someone actively working against the goal. Its a manager’s job to field the best team possible. If there is a person whose interpersonal skills are making life hell for the rest of the team, deal with it. Sometimes that means moving someone off the team. Never underestimate the impact an un-jeller will have on the team.

Negotiate reasonable deadlines. We all know that we don’t always get to choose the release date. If you’re stuck with a hard date, prioritize the requirements and negotiate scope. Knowing from the get-go that the schedule is impossible to meet is not very motivating.

If you’re stuck with a hard date and a hard scope, talk to your team. Tell them you want everyone to work as hard as possible (but not overtime) and that you have serious concerns about meeting the goals even if every one does his best. Ask the team if they have any ideas on how to make the project work. Knowing that you recognize the situation the project is in will help the team remain focused and energized. Working reasonable hours is a better strategy for reaching goals than going on the fabled death march. Pep talks, contests, and certificates won’t build morale. They can be fun when things are going well, but when your team is in the pits, they contribute to cynicism. There’s no short-term fix or magic formula for boosting morale, but old-fashioned effective management may just do the trick.

Focus Your Project

©2003 Johanna Rothman

Do you ever wonder what you’re really supposed to focus on for your project?

Companies create a variety of products, and different releases of those products, for many reasons. Some product releases can tolerate glaring defects; others have to be extremely reliable. Some releases are bound by time to market. For other products, the customers will wait. Some releases are loaded with features; other releases have a minimal feature set.

The goals for quality, schedule, and features for a project are intimately related to the reasons for creating the release in the first place. Since the definition of quality is determined by the goals you?re trying to achieve, you need to define quality for your project, and figure out what you need to focus on.

Each project has one, and only one, of these goals as its top priority, and then addresses the other two goals within that context. This prioritization determines the tradeoffs the project manager and staff will make during the project, and should help define the product development process to use in developing the product.

An honestly designed project has two priority thresholds: the absolute bottom line and everything else. The bottom line is generally implicit?unless the top management is clueless, if a product destroys the hard drive of even 5% of the testers, the product will not ship even if time-to-market is the dominant priority. Why? Because the organization knows that shipping a destructive product will decrease its market share. In the same way, there is an absolute limit to features. A release has to have something new, even if there is just a requirement not to wipe disk drives. It might be a very minimal requirement, but it exists.

Project focus is about making “everything else” explicit. One way to focus priorities for a project is to use Geoffrey Moore?s high-tech marketing model to understand the market imperatives. Table 1 provides a view, based on his model, of the interaction between the definition of quality and the product lifetime. The users (and potential users) have different perceptions of product quality over the lifetime of a product. The chart shows how the three possible priorities are sorted for different classes of users. As a product evolves, it moves from one target user group to another, and (in the model) the priorities shift accordingly.

Table 1: Quality Perceptions over Product Lifetime
Life/ Market Pressure
Early Adopters
Late Majority
Time to Market High High Medium Low Low
Features Low Medium Low Medium* Medium
Low Defects Medium Low High High High

* Medium pressure for features does not mean pressure for new features. It means that the promised features must be in the product and must be working.

If you’re working on a product for Visionaries, you want to focus on time-to-market, not terribly low defects. If you’re working on a product for Pragmatists, you want to focus on low defects, not time to market.

I worked once on a project where the developers thought they were working on a project for Pragmatists. Management thought they were working on a product for Visionaries. Management panicked when developers missed a milestone about 6 weeks before expected ship. The developers’ priorities were low defects; time-to-market, then the feature set. Management’s priorities were time to market; feature set; and then low defects.

Since management realized they were not going to meet the original schedule with the original features, they then asked for anything the developers could get done in the next six weeks, to meet the original dates. Since the project focus was not explicitly stated, the developers did not change how they were working. The developer’s priorities remained the same.

This change of focus happened twice more, where management reduced the feature set, accepted higher defects, to get the product to ship as early as possible. SmartStore’s product development process was not flexible enough to accommodate the shifting goals, and the project manager was not capable of explaining to the organization how the shifting goals would prevent the project’s success.

After three sets of shifting goals, the Test Manager realized they might never ship a product. The Test Manager then chose specific product goals (a certain smaller set of features, moderate defect levels including performance no worse than the previous release, and an aggressive time to market) and formulated measurable release criteria. The project was complete when the release criteria were satisfied.

Even with all these goal changes, the product development activities did not change until the final product goals were defined. The development staff never understood the goals and what they needed to do to make those goals. Throughout the entire process, the product developers spent most of their time fixing defects to make a (lower priority) market ship target.

At the end of any project, defect-fixing is the main activity, it?s the choice of which defects to fix that is the most interesting. At the end of this project, the developers were able to consider which defects to fix, based on the release criteria.

If you’ve ever found yourself in the dilemma of shifting project goals, then consider how you focus your project goals on low defects, time to market, or features.

Hiring Testers

©2002 Johanna Rothman,

This article originally appeared on

Summary: What?s the best way to wade through those thousands of resumes you?ve received for the new testing position? To start, you could ruthlessly weed out those who don?t show experience with your organization?s particular toolset. But in this week?s column, Johanna Rothman warns against this type of approach to hiring. By not looking at the person beyond the tools, you might be letting a star slip through your fingers.

Pamela, an out-of-work tester, has a master?s degree in computer science and is most of the way to a doctorate in quality. She has eight years of experience in testing. Pamela has been unemployed for the past six months, and no one will even interview her.

Pamela doesn?t have any perceptible flaws on her resume, except for the time she took off from work to go to school. She has great references. Okay, she?s a geek, but a socially acceptable and technically astute geek.

No one will phone screen or interview Pamela because she doesn?t have all the toolset vendor acronyms on her resume. She has experience with parts of numerous testing tools, but not more than a couple of months? experience with any piece of one. Pamela?s not comfortable putting the tool names on her resume because she doesn?t have even one year of experience with any of them. Hiring managers and internal recruiters seem to be looking for tool experience rather than a person who can learn about a tool.

What a shortsighted mistake.

Why does this happen? One of the reasons many hiring managers and HR staff rely on tool experience is that they don?t know how to define the requirements for the kind of employee they want to hire.

I recommend against filtering resumes for specific toolset experience. It eliminates some of the most talented people, people who can easily learn a tool?who are already great testers, but not familiar with your toolset.

This mistake is not restricted to test managers or other technical managers. However, as technical people, we are more likely to depend on HR for initial resume screening. And, because most HR staff don?t understand what testers do, or understand the desired experience, they screen resumes based on things they can easily check off as a “yes” or a “no” (e.g., toolset, operating system, compiler experience, etc.).

Instead of letting your HR staff filter out promising resumes, try some or all of these alternatives:

Talk to Your HR Staff

When I have taught HR staff how to read technical resumes, I would write down a grid of the kinds of technical experience I expected to encounter on resumes. I listed the potential operating systems, compilers, and tools experience I wanted. Then, I talked to the HR staff. I explained why I was looking for this experience. I explained the relative importance of each kind of experience. In addition, I explained which personal qualities (such as perseverance, initiative, focus, curiosity, skepticism, problem identification, problem solving, goal orientation, adaptability, etc.) were important, and how those qualities ranked with the technical skills. I discussed what I was willing to trade off, in terms of tool experience vs. other experience. For example, I?m much more interested in knowing that a tester knows how to describe a defect so that a developer will fix it, rather than in which tool she has written scripts. In my experience as a hiring manager, once someone has learned a tool or two, learning another tool is trivial. I?m more interested in a candidate?s personal qualities, so I have a group that works well together.

Screen Resumes Yourself

Even when I?ve had the discussion with HR, sometimes they can?t help us. Some resume-screening tools categorize resumes by acronym, not by what the candidate has done. Or sometimes my HR person is a junior employee, someone who hasn?t worked long enough to understand what I?m saying. Or sometimes the HR staff is too busy to screen resumes in a timely fashion.

If that happens to you, then you can screen resumes yourself. Whenever I hire for an open position, I always screen the resumes myself. I create three piles: Yes, No, Maybe. I screen relatively loosely based on skill, and much more tightly based on how the person has worked, keeping in mind those personal qualities I want. I don?t mind phone-screening lots of people, because I can learn more from a brief phone conversation than I can from a resume. I phone screen the “Yes” resumes, respond via HR for the “No” resumes, and after I?m done with the “Yes” resumes, I decide whether to pursue the “Maybes.”

Clarify Required Experience

One of the reasons many hiring managers and HR staff rely on tool experience is that they don?t know how to define the requirements for the kind of employee they want to hire. If you?re in this boat, don?t feel bad; you have plenty of company! After all, there?s a huge difference between someone who?s a whiz at testing GUIs and someone who tests embedded systems.

Many hiring managers have never analyzed their open positions, to define the requirements. However, you can define the skills and personal qualities you want in a candidate relatively easily. Here?s a quick technique for analyzing the job:

1.Define the roles this person plays, and at what level you think the interactions lie.

2.Define the activities and deliverables of the job.

3.Take a look at your current staff, and identify the personal qualities that make a person successful in your group. If you?d like some ideas for this, review the list of talents in First, Break All the Rules, by Buckingham and Coffman.

4.Define anything that would prevent you from hiring a candidate. I?m not talking about your preferences, I mean anything that would make the candidate not fit into your organization at all. Examples are people who can?t work overtime at release time; people who aren?t available to travel and the job requires travel; classes of people your company doesn?t hire, such as felons; or whatever is specific to your job.

You?ll notice that education and toolsets are only a small part of this analysis. If you absolutely require some specific minimum of education (because your clients demand it) or tool experience, then add that. However, I?ve never found specific tool experience worth hiring for.

So, here?s my plea: Make sure you?re looking at the whole person, not just a tool. Pamela, and all the other Pamelas out there are ready, willing, and able to work. Let?s give them a chance to prove themselves in an interview.

Show this column to your company?s hiring manager(s), people in HR who scan the resumes, and everyone else involved in hiring. Help your hiring managers and recruiters look past the tools to the person.

Acknowledgement: I thank the following people for their helpful reviews of this article: Esther Derby, Elisabeth Hendrickson, and Dwayne Phillips

How 2 Buddy

©2004 Johanna Rothman

If you’ve hired new people or transferred people into your group, you know that they’re not immediately productive when they start. If you’re lucky, they start to be useful in a month, but you most likely spend closer to six months or even a year before they raise the entire group’s productivity. One technique for bringing a new employee up to speed quickly is to assign that person to a buddy, someone who will mentor the new employee through the first few days and weeks on the job.

If you’d like to bring new hires up to speed quickly, or if you’d like to cross-train your group, try a buddy system.

Buddies aren?t just for the pool

A buddy system at work is nothing like the buddy system you might have experienced in a pool when you were a kid. You didn’t get into the pool without your buddy, and when the whistle blew, you and your buddy found each other. You and your swim buddy were there to watch over each other, to make sure you both knew where the one was. This is not your child’s swim-buddy system.

A buddy system at work is a technique to help already capable staff learn how to apply their skills more quickly, to reduce the floundering that occurs at work when a new hire starts.

Here’s how to think about the knowledge necessary for work:

Functional skills: what the person knows about their job (development, testing, project management, writing, etc.) People learn these skills at school and on the job.

Product Domain Expertise: how people understand the product and the product domain, and how they apply those skills to the product. People learn about the product and its internals by working with products.

Tools and Technology: how well the person knows the tools of the trade: compilers, testing tools, defect tracking tools, databases, and so on. People may learn some basic skills, but most skills are learned on the job.

Industry Knowledge: what the person knows about the kinds of people likely to buy your system, and the general expectations of the your users. People learn about the industry by working in it, on the job learning.

Your new hire already has the functional skills?that’s why you hired that person. But the new employee may need product domain expertise, both in the problems the customer has and in how your product solves those problems. Your new hire needs to know how you’ve customized the tools and technology you use. The more you can help new staff understand your local environment, the faster they will adapt to your environment, and the more quickly they will contribute to the overall efforts.

Requirements for a buddy system

Creating a buddy system requires that you have people who are willing and able to mentor others. In addition to the mentors, you’ll need to document a few key pieces of information: the physical layout of the building and the security, where the tools are located and how to use them, where the project information lives, and some information about the product internals. The more documentation you have, the less the new staff will interrupt the experienced staff.

The documentation doesn’t have to be a huge honking binder. In fact, if you can keep the information to one web page or one to two printed pages, the information will look accessible and not threatening to the new hire.

Evolution of the buddy from guide into mentor

When someone new starts at work, that person needs to know everything, from how to use the phone and voicemail systems, where the bathrooms are, where the lab equipment is, to how to use the tools of the trade, such as the defect tracking system or the configuration management system, or even the compilers.

When you first assign a buddy to a new person, the buddy acts as a guide, to explain where everything is. If you’ve never had a buddy system in place, this is a good time to document the locations of everything, including the physical facilities and tools. Once the locations are documented, the buddy can explain once where to discover more information, and you’ve already farther ahead for the next new person.

On the first day, it’s helpful if the buddy can take the new employee to lunch, preferably with a group of people in your cafeteria. If you have no cafeteria, choose a lunch location that most people use. Sometime during the first day, the buddy can demo your products or applications to the new hire.

After the first few days, the new person knows where the cafeteria and the bathrooms are, and has probably started reading product and tool documentation. The buddy is available to answer questions about which platforms to make sure to compile on before checking in code, or how you use certain databases, where specific tools are, and so on.

During the first few weeks, discussing architectural or design tradeoffs with new developers, test strategies and choices with new testers, or project monitoring specifics with new project managers will help the new employee understand the context of how you work, which choices you’ve already made, and how to make sure the new employee’s work fits into your environment. As the discussion moves past the basics, the buddy has moved from guide to mentor.

You may choose to have a formal ending to the buddy relationship after one month. If so, one way I’ve found useful is to mark the new hire’s 1-month anniversary in a group meeting and say, “John is now experienced enough to not need the formal services of a buddy. Thank you Steve, for taking on the role of the buddy. John, you can ask questions of any of us at any time, and hopefully you can take on the role of a buddy to a future new hire.”

Pitfalls or common traps

Even when you’ve planned for a buddy system, things can go wrong. Here are some common problems:

The buddy assigned doesn’t want to be a buddy. Some people don’t want the responsibility of helping someone new acclimate into a new job. Sometimes, they’re not temperamentally suited for the role (such as people who are so shy or introverted they have a difficult time speaking in public), or they are on the critical path for some deliverable, or they don’t feel as if they know everything the new person needs to know. If your employee doesn’t want to be a buddy, don’t demand that that the employee be a buddy. Instead, understand why your employee is reluctant, and work on that problem. One caveat: if the employee is too shy or introverted to easily speak with a new hire, find other ways that employee can help new hires. Don’t demand someone perform the buddy role when they are nervous around new people.

The buddy inflicts help on the new hire. Some people are so inspired by their buddy role they give unsolicited advice about the new hire’s work. The buddy needs to provide advice about how the work is performed at your organization, not how to design or how to test or anything else, unless the new employee has requested peer review.

The buddy performs the new hire’s work. Another form of inspiration is to take over the new hire’s work. One of the common reasons I hear for this is, “It would take me less time to do it myself.” Well of course it would. That doesn?t mean one employee can or should take over the work of another employee. The first few months are when you can expect the new hire to be less productive. Don’t allow a buddy to short-circuit the new hire’s learning experience.

The buddy stops being a buddy before the new hire is ready. If the buddy takes a vacation or has a trip during the first crucial weeks, the new hire is left stranded. The new hire and the buddy have already created a relationship. If the new hire has to create another relationship with a substitute buddy, the new hire is less likely to ask the necessary questions.

Use a buddy system for cross training

If you’re concerned about single points of knowledge in your environment, you can also use a buddy system for cross training. In this case, the buddy assumes the new person only needs product domain expertise, or alternative techniques to applying functional skills to the new product domain. When you use a buddy system for cross training, make sure the two people develop a list of milestones where the already-knowledgeable person performs less and less work over time. That way you and the person learning this area both have feedback about how well the new person is learning the product.

When I use a buddy system for cross training, I assume it will take the people about three months to transition the product knowledge, unless you have very short releases.


Creating a buddy system for a new hire isn’t difficult, but does need to be handled with care. Make sure you’ve chosen a buddy who is willing. Create the minimum set of documentation, and revise it as you hire new people. Set an end date for the formal buddy relationship. Watch for pitfalls so you can guide both the experienced and new employees.

A buddy system can dramatically reduce the time a new hire requires to be productive. A new hire will need to ask questions anyway, so make sure you have an effective system in place to deal with those questions.

Planning for Technical Management Time

©2005 Johanna Rothman

I recently spoke with a manager who’d just incorporated another group of four people to his original three. “I was doing fine with my three people before I took over this group. I had time to manage, and I was able to contribute to the application. Now, with seven people, I seem to be floundering.” After asking the manager what else he was doing, he explained he was also recruiting for two open positions in addition to his normal management work and technical contributor work for one of the projects.

This manager has passed his limit of managing people and performing technical work. It’s not possible to be a good manager to more than three people and perform technical work. Depending on the circumstances, it may not be possible to manage even three people and perform technical work.

Here’s a sample breakdown of the kinds of tasks a manager of three people performs over the course of a week:

  • Meeting with with each of the three people one-on-one, and a group meeting. Including the preparation and follow-up time, this takes about four hours per week. (Each additional person adds another hour to this total.)
  • Managing the project portfolio (dealing with requests to start/end projects, assigning people to projects, making the tradeoff decisions, and keeping track of what the group is doing takes another hour.
  • Spending time with the manager’s manager to identify issues, solve problems, preparing budgets, reports, or other paperwork is about an hour per week.
  • Talking to peers across the organization can take about an hour.
  • Problem solving with the people in your group, with other people across the organization on behalf of people in your group takes about four hours per week/person, so here about 12 hours. I include recruiting for open positions in this chunk of work. (For each additional person, add another four hours)
  • Many managers have an unpredictable amount of organizational issues to resolve also

So if a manager is managing only three people, that manager may have about 20 hours available to spend on technical work. But once a manager adds another person, that manager has only about 16 hours left to spend on technical work.

Much of the management work listed above is interrupt driven, intertwined, and ad hoc. That means that a manager can’t schedule his or her work in discrete chunks. The most effective managers context-switch the entire day. In contrast, the most effective technical people spend large chunks of time on one task until they are stuck or have completed the task. Managers, by the very nature of their problem-solving work, cannot stick with one task until it’s completed.

When your group expands to four or more people, don’t plan on completing much technical work. You may still be able to do little bits and pieces, but managers of four people can only devote small pieces of time to
technical tasks. Managers of seven people have no time to perform strictly technical work–they must devote all their time to management to be effective managers.

If you’re managing more people than yourself, plan for your management time. Then you’ll see if you can fit more technical tasks in.

Multiprojecting: The Illusion of Progress

©2005 Johanna Rothman

This article was originally published on

Your CIO has two projects he wants finished in the next month. “We can share this project manager and that test team on both of these high-priority projects,” he declares confidently. “The projects are small enough that the teams should be able to make progress.” Two weeks later, the CIO realizes neither project is progressing the way he’d envisioned. What?s going on?

Pay No Attention To That Team Behind The Curtain

The short answer is that putting the same people on two high-priority projects only creates the illusion of progress. Here’s what really happened.

The project manager worked mornings on Project 1 and afternoons on Project 2. Part of the test group also chose to work mornings and afternoons. But the other part of the test group used Monday and Tuesday for Project 1 and the rest of the week for Project 2 because of the way they needed to work with the developers. The first problem was that the project team, including the project manager and the testers, didn’t work on the same project at the same time.

The project manager and the testers only maintained their time organization for the first week. After the first week, the project manager was an obstacle to both projects, because when he was working on one project he was needed on the other project. Work from Project 1 piled up when he was on Project 2 and vice versa. By the start of the third week, the project manager had not cleared any obstacles for either of the project teams.

The testers couldn’t help the projects make progress either. One of the testers who split his project work into mornings and afternoons discovered a problem that required test data from one of the Monday/Tuesday testers. It was bad enough that the testers had to wait on each other for information, but the developers had to wait for the testers, too. The developers would start to fix problems then have to wait more than a week for the testers to verify them.

In this case, the multi-projecting caused people to be far less productive than if they’d been assigned to only one project at a time.

Watch Your Time Disappear!

People pay a context-switching cost when they switch from one project to another. Even if they try to assign half of their time to one project and half to the other, they can’t. People need time to stop thinking about one project and start thinking about the other —particularly the details of where they left off. Multi-projecting doesn’t create more time in the day; it wastes time.

When people divide their time during the day, they switch context more often (at least once per day), paying the context-switching price more often. In the above example, the people who divided their time into mornings and afternoons paid a higher cost than the people who assigned different days for different projects did. The people who switched context only once a week paid the cost less often.

If you’re not sure how much time is wasted by multi-projecting, consider this: The relationship between number of tasks and wasted time is directly related. As the number of tasks increase so do the number of wasted hours. For example, as Gerald Weinberg indicated in his book Quality Software Management, Vol. 1: Systems Thinking, a person who works on two tasks only spends about 40% of her time on each task, wasting 20% of her time. With more concurrent tasks, it’s even worse: a person involved with four tasks spend only 10% of her time on each task, wasting 60% of this person’s time! Clearly, multi-projecting is not a technique for finishing projects quickly.

Nothing Up My Sleeve

So what could this CIO do to complete both high-priority projects in the desired timeframe?

In this case, the problem of two small, short-duration projects using the same staff with unplanned and unplannable interactions, the CIO could first decide which project is higher priority. The CIO could then assign the entire team to that project, and, using release criteria to make sure the minimum work is done on the first project, as people come off of that project, start them on the next one.

People do not multitask easily because of the context-switching cost. It is easier and more productive for people to continue working on the same project, at the same level, for as long as possible. It costs time and brainpower to switch to another project or to another activity. Rank your projects, and make sure people know what done means, so they only do the minimum necessary. Don’t fool yourself with an illusion of progress; make the progress real.


I thank Elisabeth Hendrickson and Frank Patrick for their reviews of this column.

What’s On Your Not-to-do List

©2005 Johanna Rothman.

This article originally appeared on

I’ll bet you’re one of those people who have too much to do. (I haven’t met anyone in the past few years who didn’t have too much to do, so it’s not much of a bet.) And, I suspect that you’re so busy with what you’re doing, that you haven’t yet thought of what you should not be doing.

A not-to-do list is as important–if not more so–than a to-do list. When you make a to-do list, you’re listing, categorizing, and prioritizing all the work you need to accomplish. But with a not-to-do list, you’re first thinking about why you are working, and ensuring that you’re accomplishing the strategically important work.

I recently worked with a Chief Technology Officer (CTO) who, aside from his CTO role was also acting as the development and testing managers, until he could hire people for those positions. As a short-term tactic, that may have been OK. But while he was acting as the manager of both groups, he was unable to perform his job as CTO. After three months of attempting to act as all three managers, he realized that he was not working well enough in any of the three roles. Because he was trying to perform all the work himself, he’d made it impossible to take the time to hire the people he needed to help the organization run smoothly.

Taking on too much work isn’t limited to senior managers; it’s just as much a problem for other managers. One test manager prided himself in his ability to be a team player–by taking on each project, regardless of whether he had the testers or time to do the testing. He assigned testers to every project, even if he wasn’t able to plan for staffing the project in advance-and whether or not his staff had enough time to devote to each project. He soon found himself in the position of assigning each tester to at least three or four projects. Because each tester was always context switching, the testers were unable to make progress on their projects. Soon, testing was a bottleneck, and the testers were assigned to each project later and later.

Technical contributors are just as susceptible to the problems of too much work to do and not enough time to do it. One developer I know somehow hadn’t managed to take long weekends or a week of vacation in three years. He was always too busy, adding a feature here, fixing something there, developing a tool for someone. Sure, all of his work was valuable, but it wasn’t necessary at the time he performed the work. A month ago, his wife discovered he was about to lose all his vacation time. So she packed a suitcase, dropped the kids off at the grandparents, and “kidnapped” him from work. On the way to the airport, she locked the cell phone and pager in the glove compartment and told him he’d better relax and enjoy the vacation!

There is always more work you could do. And there will never be enough time to do it all. The key to successful work is to pick and choose which work to do and when.

When you’re planning your work, ask yourself these questions:

  1. What does the organization pay me to do?
  2. What work helps me fulfill that mission?
  3. What work is important to the organization, but should not be done by me?
  4. What work is not needed by the organization?

Your first responsibility is to perform the work the company pays you to do–your mission. In the case of the CTO, filling in as the acting manager for a week or two, or maybe even a month, while recruiting for the open positions may have been a great idea. But as the CTO, his mission was to make sure the management work was accomplished, not do it himself. He would have been better off determining another way to manage the work without attempting to act as the development and test managers for three months. The previously mentioned, beleaguered test manager was initially confused with his mission. He originally thought his mission was to “fully test all the software.” But that’s an impossible mission. He revised his mission to “test the riskiest products in restricted time.” That mission allowed him to assign staff to the products with the highest risk, and to time-box their testing work, so people were available when they were needed for the next project.

Once you know your mission, you can look at all the work on your to-do list and determine if the work on your list helps you fulfill that mission. It’s all too easy to keep parts of older roles (before a promotion or a move in the organization), or to help a colleague around the company. But your first job, especially if you have too much work to do, is to ask yourself if each and every item on your to-do list helps you add value to the organization in your current role.

The CTO adds more value by acting as the CTO rather than as the development and testing managers. The test manager adds value by determining which projects to staff and which projects not to staff.

If you’re like many people, you have work on your to-do list that needs to be done. But if it’s tangential to your mission, someone else should do it. You may have started performing this work because someone needed it and you were the “go-to” person. Early in my career, before the days of reliable FTP, I babysat large file transfers to remote sites at particular times of the week. After a few months of doing this, I told my boss I couldn’t attend a meeting he wanted me to attend because of the file transfer. He explained to me that although this work was necessary, I was not the person to do it. That work didn’t require my skills and attention. The work was necessary, but I wasn’t the one to do it. If you still own work that doesn’t fit anymore, work with your manager to transition that work to someone else.

When I perform assessments, I inevitably find someone accomplishing work that is no longer needed. Sometimes the work is generating reports. Other times the work is a standing meeting. But whatever the work may be, the organization no longer requires that work. Once you recognize no-longer-valuable work, you can cross it off your list without worrying about who will pick it up.

Planning, organizing, prioritizing, and performing your work is not trivial. Take a few moments to think about the value you provide to the organization, and how to reflect that value in your to-do and not-to-do lists.

Designing Useful Metrics: Using Observation, Modeling, and Measurement to Make Decisions

©2000 Esther Derby

Originally published in STQE magazine, May/June 2000

As a manager, you want to increase effectiveness and improve the quality of software. Using measurement as a tool for accomplishing this, however, may be something you’re skeptical about. I’d like to encourage you to take another look at metrics, and show you how you can use observation, modeling and measurement to manage more effectively within your team.

If you’d like to see the figures associated with this article, read it on Esther’s site:

As a manager, you want to increase effectiveness and improve the quality of software. Using measurement as a tool for accomplishing this, however, may be something you’re skeptical about. Why? Perhaps you don’t have an established measurement culture, and implementing a measurement seems awfully daunting. Or maybe you’ve been around a measurement program that didn’t quite work as planned. I’d like to encourage you to take another look at metrics, and show you how you can use observation, modeling and measurement to manage more effectively within your team.

What makes a measurement useful? Here’s my definition: a useful measurement is one that helps you understand and make decisions. The cost of gathering the information can’t exceed the benefit it provides, and the measurement shouldn’t have lots of unintended side effects.

Let’s work from the basic premise that there’s a continuum of measurement. On one end is measurement to learn about what’s going on (to get information), and on the other is measurement to modify behavior. And there are lots of points in between that have some characteristics of both. (For more discussion on this read Tom DeMarco’s essay, “Mad About Measurement,” in his book Why Does Software Cost So Much?)

I might as well confess my bias up front: I’m not a fan of software measurement programs that aim to motivate certain behavior by tying metric results to performance evaluations or compensation. There’s a bunch of problems with this type of program, starting with the fact that the people being measured often figure out how to nudge the numbers to make themselves look better, or they neglect some important aspect of what they’re doing because it’s not being measured. This is not merely human nature — it’s a flawed measurement design.

I want to look instead at the other end of the scale: measurement to gather information so that you understand the current situation, and can make good decisions.

This isn’t part of a formal “official” measurement program. It’s the kind of observation, modeling, and simple data gathering that an experimenter does to learn something about the world around her. Measuring to obtain information assumes that you do not have a preconceived outcome in mind — you’re open to whatever the data tells you. The key is that you are looking to learn more about the environment so that you can manage more effectively.

Jerry Weinberg, in his series of books Quality Software Management calls this kind of metric first-order measurement: the sort of informal, “just enough” measurement that’s used to get a system working (versus second-order measurements, which are used to fine-tune a system). To illustrate the difference, consider two projects. Project A produced 200 lines of code (LOC) per programmer day. Project B cranked out 300 LOC. If you focus on LOC, Project B did better. But LOC is a second-order measure: it’s about tuning performance. First-order measurement is noticing that even though Project B produced more clean code, the project was cancelled after dragging on for six months after its original delivery date. Now you and I wouldn’t pronounce Project B more successful based solely on LOC, but it does make the point: Start with first-order measurements and the basics of getting the system working, and then worry about tuning it.

Measuring within a system

When you set out to gather information it helps to have some notion of how the system you are setting out to measure works. All measurement exists within a system, and can only be understood within that system. Designing, building, testing, and supporting software involves complex technical and human systems — and, like any complex systems, they are made up of multiple factors, any one of which might influence any other. Rarely are the relationships linear, or straightforward cause and effect.

You may not be an expert on modeling systems, but you probably are an expert on the system you work withyou just need a clear picture of it and some evidence of how it’s working.

Let’s examine an example of such a system, and how some simple guidelines can help you use measurement to your organization’s advantage.

Suppose for a moment that you work for Software Planet, a company that sells software, and that you manage the customer support function. You have a team of technical support representatives who take calls from customers who have questions or problems with the software. The agents may resolve the customer’s needs with a short answer, or they may work through a complicated problem with the customer on the phone.

One day your manager comes in and tells you that customers have been complaining about the length of time they spend on calls with your technical support representatives. Some customers have even cancelled contracts and gone to the competition.

Straight cause and effect would indicate that long calls cause decreased customer satisfaction. Simple, right? Reduce the length of the call, and satisfaction will go up. Figure 1 illustrates that model: When the length of call goes down, customer satisfaction with support services goes up. It’s an inverse relationship; when one value goes up, the other goes downor vice versa.

Figure 1. As the length of the call goes up, customer satisfaction goes down. (The dot with bi-directional arrows indicates an inverse relationship: as one factor increases, the other decreases.)

The phone system automatically tracks the length of calls, which you could use as a measure — but is it a useful measure? Will measuring the duration of calls help you understand what is really happening or help you decide how to go about increasing customer satisfaction?

First-order measurement can help you understand what’s going on and make a good decision, using the following steps.

First, model the system

You know that Software Planet’s system is more complex than what’s shown in Figure 1. Before you set out to drive down call duration, consider what other factors could be influencing the length of the calls, and what else might be causing customer dissatisfaction.

You can start by building a more robust model of your system to get some ideas about where to collect data. What factors could be affecting the duration of calls? What other factors might affect customer satisfaction? What other things can you observe about the system?

Maybe the reason customers don’t like being on the phone so long is that they spend half the time on hold while your team tries to get additional resources on the line. Perhaps they spend twenty minutes on the phone and don’t get a solution — but wouldn’t mind being on the phone for twenty minutes if they were getting results. Figure 2 shows how the system looks when you add in other factors that could influence call duration and customer satisfaction.

Figure 2. Call support system model with the addition of other factors that could be influencing call length and custoer satisfaction. (The dot with bi-directional arrows indicate an inverse relationship: as one factore increases, the other decreases.) Involve the team

Involving your team in a discussion about the problem and its possible causes will help build a more accurate model of the system. If you ask the people doing the work they may point you to other factors that are affecting their ability to solve customer problems quickly. Perhaps they can’t find the information they need in product manuals, or the network drops and they have to re-boot during calls. Add these to your model (as in Figure 3). Even though our Software Planet model is now more complex than what we started with (call duration goes down -> customer satisfaction goes up) the systems you work with are probably even more complex.

Figure 3. System model with additional effects suggested by the team

Now that you have a better notion of what the system looks like, you can think about gathering data. But before you start

Create safety

Before you begin collecting data, talk with your team. They need to understand why you are collecting data, and how that data will be used. It’s critical that your team understands that they will not be blamed, ranked, or rated based on the data. Blaming the people for the data will produce measurement distortion — not because of a flaw in human nature, but because of the flawed measurement design. You are depending on the team to collect the data, and you want accurate data. Once you assure your team that you won’t be using the data to evaluate them, be sure you don’t. The first time you do, or your team thinks you do, you will lose a valuable source of information. If your team starts reporting the data in a way designed to make their performance look better, you will be relying on distorted data — and that can be worse than having no data at all.

Convincing people that data is being collected only for information can be a tough sell if employees have been evaluated or penalized by measurement programs in the past. One way to increase employee safety is to arrange the collection so that you (and other managers) only see aggregate data, not the results associated with any one employee.

Gather data

Based on our Software Planet model (Figure 3), here are some things you might want to find out about:

  • How many separate problems are addressed in the average call?
  • How often does a solution require more than one call?
  • How often do representatives have to put off answering a question because they can’t find the information in the documentation or product manual?
  • How many problems are handed off to some other area within the company?
  • How long does it take to find the correct person to solve a problem that the agent can’t answer?
  • How long does the representative who first gets the call spend talking to the customer before she hands it off?
  • How often does the infrastructure fail during a customer call?

You don’t have to have fancy automated data collection or an elaborate measurement program to do this. Since you’ll only be collecting data for a short period of time — a few days — a paper form and a pencil will do. It will be a little extra effort for the people taking the calls, and will require some effort to tabulate and analyze — but you will collect some useful, accurate (and therefore interesting) data. The benefits of having a better understanding of the problem before you attempt a solution should outweigh these costs.

Act on the data

Once the data is collected, your new information will help you steer the system in a way that will increase customer satisfaction with the service your team provides. The data we have collected for Software Planet, for example, might show that technical service representatives don’t have a good understanding of the system they support, and that they need more training. Or it could show that when reps try to bring additional technical resources into the call it takes twenty minutes to locate and get that person in on the call. Each situation calls for a different remedy. When you consider what action to take, use your system model to anticipate what effects your change will have. You probably won’t identify every unintended consequence — but you will increase your chance of success by thinking things through with the model and giving some thought to what could go wrong.

Check on progress

Now that you’ve done your research and implemented a plan to improve customer satisfaction, you’ll want to collect some data to know whether or not your intervention is working. But you probably won’t want to collect all the data you did in the information — gathering stage. Metrics should have a sunset clause: If there isn’t a good reason to keep collecting the data, stop.

What measurements should you continue? Customer satisfaction is worth measuring, but it’s a lagging measure — you may know there are problems only when customer satisfaction goes down. As a manager you want to know sooner than that, so that you can correct problems before they impact the customer. When you designed your intervention, you targeted some key elements in the system for change, with the goal of improved customer satisfaction. Gather data on how that change affects both the changed elements and customer satisfaction.

Suppose the intervention involved decreasing the wait between (a) when a technical rep identifies that the call demands additional expertise and (b) getting that expert person on the phone. Watch to see if that measure decreases. Once you are convinced that your intervention is working, continue to check on this measure. You may not track it all the time; you may just sample the data intermittently, as scientists do. If the number moves it’s time to observe, model the system, and gather data. Find out if there is some new factor in the environment that could be causing the number to move. Figure out if the metric is telling you about a trend, or if there was an isolated event or situation that caused the movement. If the indicator still holds, make a correction — before customer satisfaction takes a dive.

Keep your eye on the goal

It’s fairly common in organizations for the metric to become the goal, rather than a useful piece of information. The key to keeping measurements useful is to pay attention to the meaning, not just the number — if a number starts going up (or down), it’s time to gather data and tune the system, not just announce that the number needs to move in a particular direction.

This is especially important if the measure you’re using is of some aspect that contributes to the desired result but does not measure the desired result itself. In our Software Planet example, increased customer satisfaction with technical support services is the desired result; shorter calls are one factor that contributes to the result. Lengthy calls were an indicator of a problem — but focusing only on shortening the duration of the calls would not have increased customer satisfaction (and might have actually decreased satisfaction, had technical reps become adept at getting the customer off the phone but not solving the problem).

First-order measurement can help you understand what’s going on, make decisions, and improve results. Observation, modeling, and simple data gathering are things that you can implement in your work group without a big measurement program or big funding. Our Software Planet example looked at software support, but you can apply the same techniques and analysis to software development, software maintenance, testing, or project management. As practice, start by modeling your system and working out on paper how different measures will affect your system. Then involve your team, expand your model, and try some simple data gathering. This approach to measurement is one more tool in your toolkit, and it will move your organization toward better quality.