Thursday, August 6, 2009

Coaching Whiners

(c) 2009 Steven M. Smith

Ban whining. It’s destructive communication inside organizations.

Why is whining destructive? How can a whiny complaint be transformed into a constructive, actionable proposal?

You ask Anthony, who reports to you, “How are things going?”

Anthony unloads on you like a dump truck unloading fertilizer, “I’m sick and tired of the mandatory meetings that your management is forcing me to attend. Management schedules these meetings at the last minute, which forces me to reschedule conflicting appointments and meetings. I’m losing credibility. And I’m pissed off about the poor organization of the mandatory meetings. I sit and listen to things that don’t matter to me. Attending these meetings wastes my time. Will this stupidity ever stop?”

Please, whatever you do, don’t say, “I’ll see what I can do about the problem.”

Utter those words and you take ownership of the problem. Anthony will rightly expect that you will do something about his problem. You are setting both Anthony and yourself up for disappointment.

When you accept responsibility for the complaint embedded in the whining, you add to your own burden; you make communication indirect; and you fail to train your people effectively.

Step back. Do you know what will satisfy Anthony? You can’t. I haven’t given you enough information to know. If you think you already know the problem and its solution, then you are assuming too much.

By unloading on you, Anthony may already be satisfied. Ask him, “What would you like me to do?”

You may be surprised to hear Anthony say, “Nothing. I know your management. That’s the way they do business. You can’t do anything.”

But if Anthony says, “I want you to talk with your management about the problem.”

Start training Anthony by replying, “Tell me the problem.”

“I thought I already told you the problem.” says Anthony.

“No. I heard a lot of things, but I didn’t hear a clear problem statement.”

Antony looks down at your desk as he ponders your statement.

“Uh…” sputters out of his mouth. “Uh… Scheduling mandatory meetings at the last minute isn’t fair?”

You ask, “What’s the impact on you of scheduling meetings at the last minute.”

“I have to reschedule other meetings and appointments at the last minute.” answers Anthony.

You ask, “What’s the impact of these scheduling changes to the business?”

“Some of the meetings I have to reschedule are with clients and some of them don’t like last minute changes.” replies Anthony.

You verify the problem by saying, “So I gather the problem is that last minute mandatory meetings are hurting relationships with our clients.” And you ask, “Is that close?”

Anthony looks you in the eye and says, “I know where you are going… That definition is close enough.”

Continue coaching by asking, “What do you recommend that my management do?”

Anthony continues looking you in the eyes as he replies, “I realize your management will need a few emergency meetings so I recommend that 90% of all mandatory meetings be scheduled at least one week in advance.”

“Sounds good. Email me the complaint and recommendation so I can forward it to my management?”

“My name will be on the message?” asks Anthony.

“Yes, of course, it’s your problem. Right?”

“Let me think about it. I’ll get back to you.”

Wednesday, July 8, 2009

Is Your Mission Helping You Decide What Work to Do?

Some groups have well-defined missions. Some don’t. The problem when you don’t have a mission is you can’t always know what work to do. In Make Your Mission Possible, I suggest ways to define a mission.

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

Fundamentals

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

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

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

Before the Interview

Sponsor Agreement

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

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

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

Overcome Restrictions

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

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

Sponsor Communication

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

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

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

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

Interviewer Communication

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

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

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

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

Question Sequencing

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

Q: Who is your customer?

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

Q: What problems did Synergy solve?

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

Q: What problems did Synergy create?

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

Q: What problems happened during development?

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

Q: What other questions should I be asking you?

    How would you answer your questions?
    Anything else?

Q: Do you have any questions for me?

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

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

Metaquestions

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

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

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

Don’t Worship the Plan

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

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

During the Interview

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

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

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

Perceive

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

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

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

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

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

Interpret

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

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

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

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

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

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

Evaluate

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

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

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

Respond

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

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

After the Interview

Observe And Transcribe

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

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

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

Don’t Share Until Approved

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

Adapt Your Plan

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

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

Thank the Participants

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

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

Summary

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

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

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

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

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

<>

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

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.

Connection

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.

Cooperation

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.

Coordination

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.

Conglomeration

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.

Collaboration

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.

Monday, April 6, 2009

Catch Them Doing It Right

(c)2008 Steven M. Smith

A smile formed on Eleanor’s face as she saw me approach her doorway.

She and I were meeting to discuss her views on recognizing and rewarding employees. She had been my manager for three years when I worked as a developer. A skillful manager, her recognition and rewards had brought out the best in me and my teammates.

I am now a manager in the testing organization. Although I recognize and reward the members of my team as best I can, I know that Eleanor’s recognition and rewards are more effective than mine. I knew what she did, but I knew little about the thought process behind her actions.

I wanted to learn about the thoughts that shaped her actions, because I suspected they could help me.

As I entered, Eleanor moved around her desk, extended her hand, and said, “Trevor, it’s great to see you. How is Ginny’s first semester at the U going?”

Typical Eleanor. Although we hadn’t talked in months, she remembered that my daughter Ginny had started at the university two months ago. How did she remember details like that?

“She’s doing well,” I answered, reaching out to shake her hand. “Although I think she may be a little homesick. Thank you for asking.”

“Sit down,” Eleanor said, motioning to a chair that I had sat in many times. She moved to the other side of the small, circular conference table and sat down.

“How can I help?” she asked.

“I want to learn the secrets you use to recognize and reward employees,” I replied.

“Secrets?” Eleanor’s forehead crinkled as she started to laugh. “I don’t have any secrets.”

“Your methods may not seem like a secret to you,” I said, returning her laughter, “but I don’t see any other managers rewarding the members of their teams as effectively as you. For instance, I recall your giving Fredericko soccer tickets as a reward for the work he did on the Tahoma project. He told me how thrilled he was to receive them. Other managers give their people trinkets, such as pens and USB flash drives.”

“Oh, I hope taking the time to know people well enough to reward them with something that will please them isn’t a secret,” she said. But you’re right. Some managers do reward people with trinkets. I don’t believe in that.”

I probed, “Why?”

She looked up for a few seconds, then slowly leveled her eyes with mine and said, “I suppose my behavior follows directly from a story my mentor told me years ago about a reward he received. At the banquet for the program he led, his manager gave him a gold watch.”

“A gold watch sounds like a great reward to me.”

“It did to me, too,” Eleanor said slowly. But it turns out my mentor is allergic to metal. It causes him to break out in hives. Although he never said anything to his manager, he told me he felt insulted by being given something that he could never use. He thought his manager should have known him well enough to give him something he would enjoy.

“The look of hurt on my mentor’s face still drives me to this day to learn enough about each member of my team to know the rewards that would please them.”

Eleanor continued, “You may be surprised, though, to find out that some people tell me that they don’t like receiving awards. They feel like they’re being bribed.”

“What do you do for them?” I asked.

Eleanor leaned back in her chair and said, “I explain to them that receiving a reward is part of a bigger process.”

“What do you mean by that?” I sputtered, caught off guard.

“When I give an award to someone at a big event, it exposes that person and his work to other members of the organization. And that exposure leads directly to more opportunities in the organization for him.”

“Those rewards you gave me did bring me opportunities. No question about it.” I said.

“I haven’t had anyone insist he didn’t want an award after my explanation. But if anyone ever does, I won’t force him to accept an award. I’ll find another way to communicate his value and the value of his work to the other members of the organization.”

“Are there other questions I should be asking about rewards?” I asked.

Eleanor looked up and didn’t say anything for a few seconds.

“I can’t think of anything.”

“Then tell me your thoughts on recognition,” I said.

“I invest significant energy recognizing things that team members do to help the team be more effective. The essence of what I do is what my mentor called ‘Catch Them Doing It Right.’”

“What did he mean by that?”

“He believed that the behavior of people in organizations is shaped by every organizational action and, just as importantly, every organizational inaction. He thought of recognition both as feedback and as action. He coached me to provide immediate feedback to employees when I caught them doing something right. And he also taught me how to leverage other team members to provide similar feedback.”

“Whoa!” I said. “I remember we had a segment in status meetings where we appreciated people for something specific they had done that helped us. You said it was something you learned from a famous family therapist. That’s recognition?”

“You got it,” Eleanor said. “The part of recognition that’s the most overlooked is providing the feedback as close as possible to when the behavior happens.”

“What else should I be asking you about recognition?” I asked.

“You should be asking me why it’s important to recognize a behavior as soon as possible.”

“You’re right. That’s exactly what I should be asking. Please tell me why.”

Eleanor’s eyes sparkled as she said, “It’s to increase the chances that the behavior is repeated by that member. Then the other members who hear the recognition consider exhibiting similar behavior. I like to think of it as planting the seeds of effective behaviors.”

“Is there anything else should I be asking you about recognition?”

She smiled. “I can’t think of anything. And now is a good stopping point because I have another meeting in five minutes. Did the discussion help you?”

“Yes, I got more help than I expected. Thanks for your help, Eleanor. Would it be alright if I sent you an email outlining my understanding?”

“Of course, I would like that. And please let Deanna know that I appreciate her for the coaching she gave Sanjay today on putting automated unit tests in his code. That’s going to pay dividends in speed and quality as we go through the development of the new product. Normally I would send her an email, but I think it would be more powerful coming from you,” she said with a wink.

Sunday, March 5, 2006

The Appreciation Gap

©2004 Esther Derby

In a recent workshop, I described an exercise for expressing appreciation. “That won’t go over here,” stated Patty, one of the managers in the workshop. “These are engineers; they don’t want that mushy stuff. Besides, they know that we value them.” Patty didn’t notice that several of the engineers were shaking their heads in disagreement.

The engineers in Patty’s company aren’t the only ones starved for notice and appreciation. A recent Gallup Poll report quoted this statistic: “…the number-one reason people leave organizations is that they don’t feel appreciated, notes the U.S. Department of Labor.”

Given the high cost of replacing knowledge workers, reducing the number-one reason for turnover seems like a good investment. And when you consider that this investment doesn’t cost a dime, why not eliminate the appreciation gap?

An Appreciation Primer

When you offer appreciation, appreciate the person, not just the work. Most people like to hear “you did a good job.” But a comment on the quality of work is an evaluation. I like to use this form, which I learned from the work of Virginia Satir:

[Name of person] I appreciate you for [contribution, action, quality].

I might say, “Tom, I appreciate you for moderating technical reviews. It’s really making a difference in our code quality.”

I?’l admit that this felt awkward the first time I tried it. But I also noticed that these words had a very different effect than “You did a good job” or “Thank you.”

Appreciation Guidelines

Be authentic. Authenticity means that you really do believe what you are saying. Pavlov proved that it’s possible to shape canine behavior by providing rewards for a desired response. People, however are not canines, and they are quick to recognize manipulation. Going through the motions isn’t enough.

Appreciate privately. Most people don’t need or want their manager to gush over every accomplishment in public. In fact, public recognition is uncomfortable for many people. A word in private will let people know that you do notice and appreciate.

Appreciate weekly. “Atta boy” once a year during a performance evaluation isn’t enough. Notice and comment on a contribution every week.

Traps to Avoid

Don’t dilute the value of appreciation. Some well-intentioned person devised the “praise sandwich” as a recipe for delivering feedback. A praise sandwich surrounds criticism between two bits of praise. I suspect this person wanted to ensure that the feedback recipient was in a receptive mood by making them feel good. In reality, the praise sandwich conditions people to expect a slap after a positive stroke. If you have feedback to offer, do it! Don’t dilute the value of appreciation by only giving it along with bad news.

Token rewards anger as often as they delight. One colleague received a movie ticket from his boss after he’d worked well into the evening to fix a critical defect. His response to the reward was one of anger. “After I already spent one evening away from home, he wants me to spend another one? without my wife!” he stated in disbelief.

Don’t wait. When Sara handed in her resignation, her boss told her she was the best project manager he’d ever worked with. “Why’d he wait until I quit to tell me?” Sara fumed later. “Maybe if he’d let me know that he noticed what I did for the company I’d still be there.” A few simple words a week could have kept Sara on the job.

You may feel awkward when you first try giving appreciations–I know I did. Practice in a low-risk situation, maybe by telling a store clerk you appreciate her for helping you find just the right item. Watch what happens and practice until it feels natural. Then try out this simple practice at work.

How Much Work Can You Do?

Developing and Managing Your Project Portfolio

©2005 Johanna Rothman

This article appeared previously on stickyminds.com.

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
Melody
Manager
Management Management Management Management
Unstaffed
work
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.

Summary

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.

What’s on Your Not-To-Do List?

©2005 Johanna Rothman

If you’re like most of my clients, you have too much to do. Recently, an Engineering Director, Stephanie, explained all the things she “had” to do: monitor the projects, participate in the requirements sessions, draw up a yearly budget, write three performance evaluations, monitor training classes, visit customers, assist technical support and more. Some of the items on her list were clearly her responsibility, but others were not. Her not-responsibilities were preventing her from doing her necessary work. Stephanie needed a to-do list and a not-to-do list.

Here are some signs that you need to create a not-to-do list:

  • You’re always working overtime.
  • You never have time to sit and think.
  • You manage crises well, because that’s the only kind of management you ever do.
  • You’re the bottleneck for work that’s not getting done on your project.
  • Papers sit in your inbox for weeks, and you’re hopelessly behind in your email.
  • You take refuge in the technical work because you’re uncomfortable with the management work you’re supposed to do.
  • You get depressed looking at the ever-growing pile of paper on your desk.
  • Your to-do list is a write-only list; things go on but never come off.
  • You are doing more work but your manager is less satisfied with your performance.

Your not-to-do list is the list of everything that’s not part of your job to address or solve directly. Here are some suggestions for creating a not-to-do list:

Clarify your role. Try defining your job description with a one-line sentence. What does your company pay you to do? How broadly are you interpreting that? Should you make it narrower? One Director of Engineering said, “I’m responsible for the care and feeding of the engineers and the product.” He stopped allowing the salespeople and the support staff to lean on his organization, by putting training and other procedures in place.

Work at your level. Check to see that you’re working at the level appropriate for your title. Many people retain pieces of previous work out of habit after a promotion or a reorganization, rather than working at the most appropriate level If you’re now in middle management, think hard about whether you should be doing technical work. If you are doing technical work, who’s doing the strategic thinking?

Make decisions when you add value. When it’s time to make decisions, check a couple of things: are you the right person to make the decision? Are you too tired to think straight? Will you add value to this decision? If you’re the right person to make the decision, clear your head, think the problem through, and then make the decision.

Delegate or manage your paperwork. If you need administrative assistance, or filing assistance, or other paper handling assistance, ask for it. Then, deal with the rest of the paperwork. If you don’t know what to do with your humungous pile, throw the whole thing out. If someone needs something from you, they’ll be back with another piece of paper.As you decide what you should do and not do, don’t just drop things. Explain your decisions, possibly by negotiating with the people affected by your decisions. And when you make your not-to-do list practice living with it for a few weeks. See if other people are working on handling the items on your not-to-do list. If no one’s working on that list, does it matter, or will your project risks increase? If your risk increases, explain which work you’re not going to do to manage the risk.

If you’re working on issues that belong to other people, stop. Draw your boundaries, and make the rest of the people in your organization live up to their job descriptions; don’t just take on more work.

Do We Have to Choose Between Management and Leadership?

©2006-2007 Esther Derby

This column originally appeared on stickyminds.com

In a recent discussion on the state of a software company,
a programmer declared, “We don’t need managers around here,
we need leaders!”

I’m always puzzled by statements like this.

“How do you see the difference between management and
leadership?” I asked.

“Managers do things right, and leaders do the right thing,”
the programmer replied, repeating a Warren Bennis quote.

“But what do they do differently?” I pressed.

quot;Managers manage, and leaders lead,”
the programmer replied with conviction.

Here’s how leadership professor John Kotter describes the difference
between management and leadership (which I paraphrase here):

Management is:

  • establishing timetables and steps for achieving needed results and allocating resources to make it happen.
  • creating structure, staffing and delegating responsibility,
    and having the authority to accomplish goals.
  • monitoring results, identifying
    deviations, and planning and organizing to solve problems.
  • producing key results expected by various stakeholders.

Leadership is:

  • establishing direction, and developing a vision for the future.
  • aligning people, modeling the vision, influencing, and creating
    teams and coalitions.
  • inspiring people to overcome barriers to change by satisfying
    basic human needs.
  • producing useful change.

Reading these lists, it’s clear to me that organizations need both.

Here’s an example. A test manager takes a job with a new testing group.
He talks with his team, his manager, and the internal and external
customers for his unit’s work.
Based on what he hears, he articulates a mission for the group: “We
provide assessments of product quality and help product owners understand
risks.” That’s leadership?setting a direction.

He works with the team to identify all the work they’re currently
doing, work that’s in queue, and projects scheduled for the next several
months. Together, they assess what they can accomplish,
what they won’t do, and whether they have the right mix of
skills to do the work. That’s management.

He supports the team as it self-organizes to accomplish the work.
The organizing part is management (done by the team), while supporting
self-organization is leadership?meeting human needs for autonomy.

The test manager works with the team to identify the resources they
need?machines, tools, and training?and then adjusts the
budget to acquire the necessary resources. That’s management.

He’s showing leadership when he meets with members of the team to
understand their aspirations and help them articulate professional
development goals. When they work together to build skills into daily work,
that’s management.

As the team works to test its products, the manager and the team work
together to develop metrics and dash boards that show test progress and
communicate the quality of the product?management again.

He makes sure the development manager and product owner define
release criteria, leading through influence. He also brings change to
the way the company makes ship decisions. When a testing project
starts slipping, he pulls the team together to assess the issues and
replan their approach–management, according to Kotter’s definition.

And so it goes?a little management here, some leadership there.
The balance shifts, depending on the situation. The test manager combines
management and leadership activities to attend to people and accomplish
meaningful work.

I’ve worked with people who were all leadership. When they lacked
management behaviors?follow-through and attention to practical
implementation?they left chaos in their wakes
(and didn’t actually produce much useful change). I’ve also worked
with people who were mostly management, which only worked when they
had enough personal warmth to navigate human relationships.
(In accounting areas, you don’t necessarily want creative ideas or
big charisma?think Enron.)

Viewing leadership and management as dichotomous sets up a false
choice. Most positions in organizations need both, and that’s what
effective managers deliver.

Managing a Struggling Employee

©2003 Esther Derby, www.estherderby.com

Sooner or later every manager faces the same dilemma: What do I do when I inherit or hire an employee who turns out to be a poor fit for the job?

Tom was the development manager for a supply chain product. He had an important project to deliver and was staffing up to meet the workload. The company had recently discontinued another product, InventoryPro, and HR was trying to find jobs for all the people who had been displaced within the company. When it was time to recruit candidates, Tom looked internally first .

Sara, one of the InventoryPro team, had the qualifications, at least on paper. But Sara also had a reputation for having bounced around the company for more than a decade. She?d been on ?get well plans? and on the edge of being fired three times, but had always pulled it together long enough to climb out of probationary status.

Tom rationalized an explanation in his mind:

She just needs a fresh start. She?s bright and she?s got 12 years of experience. With the InventoryPro situation, I?d have to go through all sorts of hassle for an external hire when there?s someone from the InventoryPro team who could do the job.

So Sara started on the project. Tom?and the rest of the team?soon experienced first hand the behaviors that had landed Sara on employment probation three times.

Within three weeks, Jessica, the team lead, was in Tom?s office. ?Tom, I?m worried about Sara?s impact on the project. Every meeting turns into a debate. It?s starting to wear on me and the team. Plus the work she does isn?t?well, it isn?t very good. I?ve had to ask her to redo 3 out of 5 deliverables so far. I?m worried that with Sara?s rework, we?re falling behind schedule.?

?You?ve got to give her a chance, Jessica,? Tom said. ?Maybe she didn?t understand what she was supposed to do. She?s new to the team, after all.?

?I don?t know, Tom,? Jessica said. ?I reviewed the completion criteria for each deliverable with her, and gave her examples from the last project. I wouldn?t expect to coach even a junior employee this much.?

?I?ll have a talk with her and sign her up for a communications skills class.? Tom said. ?And I?ll talk to her about the quality of her work. But you need to cut her some slack and give her some time to fit in with the team.?

The next week, Jessica was back in Tom?s office. ?It just isn?t working out with Sara,? Jessica said. ?She sits through our work sessions glaring, and after the meeting tells the other team members how stupid my approach is. It?s really taking a toll on the team?they?re wasting energy bitching about Sara instead of working on the software! We?re definitely falling behind schedule!?

?I?ll bring Sara up to acceptable performance. I?ve never fired anyone,? Tom protested. ?I?ll turn her around: I?ll meet with her every day to coach her. It?s going to take time, Jessica. You need to be patient. ?

?How much time? How long before Tom decides he?s done enough to try to help Sara?? Jessica wondered.

Where to Begin

Tom made a poor tradeoff when he decided to avoid a hassle with HR and hire a person with a history of poor job performance. While Tom?s situation is extreme, sooner or later every manager is faced with a decision about how long to coach an employee who is struggling.

When you are faced with an employee who isn?t working out, ask yourself these questions:

  • How much rework am I willing to accept?
  • How much time am I willing to add to the schedule to accommodate poor-quality work?
  • What effect is this person having on the rest of the team? Am I willing to accept that effect?
  • What sort of message do I want to send to the rest of the team?
  • How much time am I personally willing and able to invest in coaching this employee?
  • Am I investing my coaching time where it will best serve the individual, the team, and the company?

If you?ve decided to coach an employee who is struggling, make a plan with a time limit.

Have a frank conversation about the gaps you see between the results you want and the results he?s achieving.

If you are both willing to work to close the gaps, develop a training and skills-building plan and agree when and how you?ll reassess progress.

If you don?t have other appropriate work and can?t accommodate the time investment to build skills, coach the employee out of your group. Your HR department may offer support to help him find another job internally or externally. Although it may be tempting to help the person yourself, don?t do it! You are not a job placement service, and getting involved in the job search will make it harder for you to fire the person if he doesn?t find other work outside your group in a reasonable amount of time.

When the employee doesn?t recognize the skills gap or there are behavioral problems, establish a ?get well plan.? Determine the changes and actions that you?ll need to see and set a time frame. My preference is 30 ? 60 days, with weekly checkpoints along the way. Your company may have specific guidelines, so check with your HR person or the company lawyer. Be ready to terminate employment if the employee isn?t willing or able to meet the goals of the plan.

What happened with Sara? Three months later, Jessica had moved Sara off the supply chain project. The team couldn?t recover the time and productivity they?d lost while Sara was on the team, but they were starting to settle in and re-gel.

Tom devised a one-person project for Sara to work on. It wasn?t really important work, but it kept Sara busy while Tom continued to follow up on her work and coach her twice a week. I doubt Tom will ever fire Sara, since doing so would admit he?d failed to bring her performance up to a suitable level.

Many managers, like Tom, have a hard time making the decision to stop coaching and move an employee on to another job inside or outside of the company. Some will spend months or even years accepting marginal performance and lowered productivity for the entire team rather than make a difficult decision.

Take a look at the bigger picture of the work to be done, the productivity and the morale of the team. Then ask yourself: Where should I invest my time?

Performance Without Appraisal

©2007 Esther Derby

The idea of merit rating is alluring. The sound of the words captivates the imagination: pay for what you get; get what you pay for;motivate people to do their best, for their own good.

The effect is exactly the opposite of what the words promise. Everyone propels himself forward, or tries to, for his own good, on his own life preserver. The organization is the loser.

Merit rating rewards people who do well within the system. It does not reward attempts to improve the system.

W. Edwards Deming in Out of the Crisis

In an earlier column, I suggested that ScrumMasters should steer clear of annual performance reviews. Rating and ranking individuals interferes with a ScrumMaster’s responsibilities as a coach in service to the team. In fact, I went further than that: I suggested that managers and the rest of us steer clear of performance reviews, as well.

My suggestion does run counter to widespread practice. But I’m not alone in questioning performance evaluations and rankings.

W. Edwards Deming identified performance appraisal as one of the Seven Deadly Diseases of Management. Deming is clear and concise in stating the negative effects of performance appraisals and merit ratings: “It nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, nourishes rivalry and politics.” [Deming p. 102]

More recently, Stanford University professors Robert Sutton and Jeffrey Pfeffer combed through data and studies related to widespread management practices. They reference a survey of 200 human resource professionals which reports that forced ranking—a common component of performance appraisal programs?results in “lower productivity, inequity and skepticism, negative effects on employee engagement, reduced collaboration, and damage to morale and mistrust of leadership.” [Pfeffer and Sutton, p. 107] They go on to describe the damage done by merit pay plans.

In short, the evidence supporting the benefits of rating, ranking, and then tying pay to the rating—the stuff of performance evaluations—is thin to none. Deming had it right.

My readers did raise legitimate concerns:

Without performance appraisals…

How do we determine how much to pay people?

How do we know who to promote or fire?

How do people know they need to improve?

Organizations do need answers to these questions. Performance appraisals and pay-for-performance (PFP) aren’t the only way to answer those questions, or even the best way. In this column, I’ll walk through some alternatives to the prevailing practice.

How do we determine how much to pay people?

One reader pointed out, “people get their salaries on an individual basis.” True. Tying annual salary actions to ratings and rankings is just one way to determine what those actions should be. There are other rational and non-capricious ways to adjust individual salaries:

  • Adjust based on the cost of living so that the buying power of salaries keeps pace with economic conditions.
  • Allow all employees to share in the company’s success through profit sharing.
  • Adjust salaries based on the current market rate for skills and roles.

Another reader posed the rhetorical question, “So all certified scrum masters earn the same amount?”

Performance is a function of the person and the environment. Systems thinking and lean production at Toyota tell us that gains in productivity come from inspecting and adapting the system, not from focusing on individual performance. An improvement mindset, thinking for the long term, eliminating waste, respect for people, and removing impediments bring high performance.

Still, there are people who are clearly outstanding performers (both outstandingly good and outstandingly poor), who outperform the limits of the system. Once again, pay increases based on performance ratings is only one way to accomplish the goal of recognizing outstanding individuals.

People—and their jobs—evolve over time. A ScrumMaster may start off coaching a team on the basics of Scrum, and over time, take a bigger role working on systemic issues that hinder the team. Or he may develop exceptional coaching skills. If someone is truly performing above others within the same job it may be time to promote him or reclassify his job so that it’s at a higher pay level.

How do we know who to promote or fire?

Other readers asked, “Without yearly ratings, how will we know who to promote?” Looking at how a person has evolved in his job and the level of responsibilities is one way. Another option is to treat promotions as
seriously as hiring: create a rigorous internal application process that involves interviews and auditions.

The truth is that many outstanding performers aren’t doing it for the money. They stay for love of their work and are most rewarded by new and challenging assignments.

The reverse question came up, too: “How will we know who to fire?”

It doesn’t take a rating to fire someone. If someone isn’t doing his job, there’s no reason to keep him on the payroll until the annual review cycle comes around. A ScrumMaster will know when someone isn’t doing his job or is making it harder for other people to do their jobs. He can coach the person, or if coaching is not or is no longer an option, work with a functional manager to move the person off the team. (Some teams manage their own team membership, and people who need to go move off the team, without a manager’s involvement.) And, poor performers will hang onto a job even if they aren’t receiving raises. They won’t be improving, though. They’ll be harboring resentment and telling themselves that they really are above average.

As with identifying outstanding good performers, consider the environment, as well as individual skills. Ask whether someone is truly underperforming, or whether the system is limiting his performance.

I spoke with a new agile coach recently who was beginning to doubt he was in the right role. “I just can’t get this group moving in the right direction,” he said. “Maybe I should go back to being a developer.”

When he described the situation to me in detail, I began to wonder if any new coach could move this group in the right direction. The project has several stakeholders who disagree about the direction of product. The team is split into three factions, which swirl around a long standing conflict between two team members. One member of the team is skeptical of agile methods and baits the coach at every opportunity. When he’s not baiting the coach, he’s working to bring other team members to his point of view. The new coach is struggling in his job. The person who is supposed to mentor him is missing in action. I don’t think firing him—or giving him a low rating—is the answer.

It would be more fruitful (and more difficult) to look at the system that assigned a brand new coach to this project and failed to provide support.

How do people know they need to improve?

How will people know they need to improve if they don’t have an annual review? The answer to this question is simple (though not easy): their ScrumMaster will tell them.

A letter or number rating or ranking is an evaluation. It may tell someone he needs to improve, but it doesn’t tell him what specifically he needs to do differently. In order to improve, people need clear behavioral descriptions and they need to understand the impact of behavior or results. Some managers provide specific examples along with the letter or number evaluation grade. However, most humans resist labels, so they may be busy with the emotional response to the rating, and not ready to fully listen as the manger gives examples.

Scrum runs on frequent feedback loops. That includes feedback to people on their work interactions and work results. Feedback on an annual cycle is worse than useless and is totally out of congruence with agile methods.

When organizations adopt Scrum, sooner or later they bump up against the problems caused by asking people to work collaboratively and then measuring and rewarding them for individual effort. But Scrum is all about making issues visible, so we can inspect and adapt. The time has come look at the evidence about pay and appraisal systems. We may want to succumb to the allure of the “merit pay” words, but performance appraisals are a barrier to delivering valuable software; it’s time for them to go.

Further Reading

Out of the Crisis. W. Edwards Deming

Hard Facts, Dangerous Half-truths and Total Nonsense: Profiting from Evidence-based Management. Jeffrey Pfeffer & Robert
I. Sutton

Real-time Feedback

How to Talk About Work Performance: A Feedback Primer

Peer to Peer Feedback

What Every Manager Should Know About Feedback

What Did You Say? The Art of Giving and Receiving Feedback. Charles Seashore, Edith Seashore and Gerald M. Weinberg

The Secret Ingredients of High Morale

©2004 Esther Derby

This column originally appeared on Stickyminds.com

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.

The Liar’s Contest

In this game,
the only way to win is to stop playing.

(c)2004, 2005 Don Gray and
Gerald M. Weinberg

It may look like a crisis, but it’s only the end of an illusion.

- Rhonda’s First Revelation

The Setup

Sharkey, the sales VP of UberDenke Software Products, firmly believes he needs to have the next release of the UDCRM product in three months. Engelbert, the software engineering VP, estimates a minimum of twice that long – six months – to implement all the new features. During the discussion, Sharkey drops some thinly veiled threats:


  • Do you think we need to consider outsourcing this development?
  • I wonder why our competitor manages to get software out, but we can’t?
  • Perhaps we need to see the company president about the schedule.

Getting the message, Engelbert eventually agrees to “try to get the software done” in three months. Engelbert calls a meeting of the development group leaders and shares the story. “Marketing insists
that we ship the next version of UDCRM in three months. Sharkey already has a quote from an outside vendor, so I had to agree to the schedule. Let me know how we’re going to get this done.”

The developers head to their cubes and start to ponder how they will get the work done in three months. No matter how much they try to shorten their schedule, their estimates range from three and a half to eight months to deliver the next version of UDCRM. Engelbert figures that Pamela’s estimate of three and a half months is close enough to three months, so he shaves off two weeks and declares that as the team’s schedule. He rewards Pamela by making her project lead.

Objectives for Play

In the abbreviated story above, there may or may not be a valid reason Sharkey wants the three-month date. There may be legal considerations (HIPA, EPA, IRS) involved. Perhaps COMDEX is in three months and UberDenke needs to be ready to demonstrate the product. Or maybe a key client has agreed to pay to have UDCRM shipped in three months. Sometimes the “Big Boss” has determined that a date (usually 1 January) is a good day to start using a new system. And just maybe, Sharkey fabricated the date out of pure imagination.

Likewise, Engelbert may or may not have had valid reasons for his initial estimate of six months. Based on the new features and changes to infrastructure, six months could be a valid number – even optimistic. Perhaps previous experiences with marketing have always ended with Engelbert’s estimates cut in half, so this time he doubled his best guess for how long the next release would require.

When Sharkey makes up the needed date, and Engelbert starts by doubling his estimate, they become enmeshed in a Liar’s Contest. A Liar’s Contest is a dynamic interaction arising from a conflict between two people who hold different values for an outcome. The winner is the contestant who emerges from the game with his lie unchanged. The loser is the participant who believes the other contestant’s lie and changes his lie to match. Neither of them is ever forced to tell the truth.

Participants

A Liar’s Contest can happen between the same or different corporate levels as well as between organizations. Sharkey and Engelbert play the game as peers from different parts of the organization. Engelbert and the developers play Liar’s Contest as boss and subordinates. During the competition, one participant generally starts with some type of an advantage over the other.

The participants’ negotiations tend to be zero-sum situations. Winning for one becomes losing for the other. Generally, the interactions between the participants focus on a single value (three months, six months), not a range of values. They never discuss probabilities, even though the future is always uncertain. You can often stop the Liar’s Contest dynamic by creating win-win situations, agreeing on a range of values, or allowing probabilities into the discussion.

And even though Sharkey and Engelbert finally “agree” on a value for the outcome, the real outcome value will almost certainly be something else:

- A miracle happens. No risks occur and the salaried programmers work long unpaid overtime hours, and the product ships on time. This outcome reinforces Sharkey’s original request of three months. “Those programmers! Always padding their time estimates! I KNEW IT!”

- A miracle fails to happen and the product ships “on time” with serious or fatal defects. Sharkey points out that Engelbert agreed to the schedule, so the current mess is his fault. For extra affect, Sharkey can mention that “The only reason we’re not losing more customers is because of the frantic work of the sales staff.”

- A miracle fails to happen and the project ship date slips to six months – or, often, much longer because trying to do a six-month project in three months usually takes much longer than a well-planned six-month project. The product finally ships with minor defects. Sharkey points to lost customers
and lost revenue and blames Engelbert for the dip in quarterly revenues.

It’s interesting to note that in all cases, Engelbert and the software developers are “wrong.” That makes them the losers, but it doesn’t guarantee that Sharkey won’t lose, too. If he’s still responsible for sales, he may suffer the consequences of the failure to produce a miracle.

Choose Your Position

In a Liar’s Contest, one participant usually comes into the competition with one of five distinct advantages:

Positional Given most corporate structures and climates, it’s difficult to argue with a liar from above you who delivers the “Make it so!” ultimatum. That’s why Liar’s Contests often trickle down through several levels of an organization, producing incredibly far-fetched values of estimates.

Negotiation Experience Some people have more experience negotiating, which gives them an advantage when they press for their chosen outcome. They tie into the culture better (”Be a team player”) and have alternate options (real or fictitious) prepared as threats prior to starting the Liar’s Contest. (”We’ll have to go outside if you can’t do it.”)

Interpersonal Skills The ability to understand people provides additional leverage points. We all want to be successful and to feel competent, yet while the feelings are mutual, the participant who first brings them up tends to put the other person on the defensive.

Psychological Strength Anyone who comes to the Liar’s Contest off-center, entwined in other stressful events, or with generally low self-esteem will be at a great disadvantage to a more congruent opponent.

Nothing to Lose The less you have to lose by lying, the more easily you’ll win most Liar’s Contests. Your potential loss involves both the size of the loss if the lie is discovered and the chance that your lie will be discovered.

When a time delay exists between the negotiation and the outcome, it’s possible that neither party (like Sharkey and Engelbert) will be in the same position, or even with the same company when the outcome is
delivered. If the time delay is long enough, or the record keeping is bad enough, nobody will remember the original lie. Perhaps the reason projects keep such poor records of past estimates is that the people love to have Liar’s Contests and not pay the price of losing.

Penalties

After Engelbert and Sharkey have played a round or two of Liar’s Contest together, several different effects may be seen in the long term. Sharkey may no longer accept any of Engelbert’s first estimates – he always pressures for a decrease. Engelbert may compensate by padding his original estimate. Since the “pad” can be negotiated away, the reduction dynamic is reinforced. Engelbert may offer more honest first estimates. This does not change the underlying system, so the personal interactions won’t change. The system goes through another evolution and repeats the previously described activities.
This dynamic looks like Figure 1

Figure 1 - Liar's Contest Basic Dynamic

Figure 1

If the Liar’s Contest continues to result in reduced delivery times but worse quality, secondary negative consequences appear. The developers will have a reduced view of Engelbert’s overall management abilities. The long hours developers work attempting to deliver the software will result in mental fatigue and burn out, a further drop in output quality (now on a downward spiral to disaster), and interpersonal stress (family life suffers, feeding back to even poorer quality work). If the economy and locale permit, developers will start leaving for greener pastures in more honest environments. Finally, customers may purchase the competitor’s software due to release quality and cycles.

All in all, Liar’s Contests establish the relationships and conditions for bad things to happen, both now and forever more.

Game Over

To end the Liar’s Contest, both parties must realize what is missing in their interaction: the other person and the context of the discussion. In our story, each player in the Liar’s Contest saw only his own role. Sharkey saw Engelbert only as an impediment to his success. Engelbert saw Sharkey only as an obstacle. Neither saw the other as a human in the same boat as himself, nor did either player see himself as just one part of the bigger system. The reality is that Sharkey and Engelbert are both parts of an interconnected system. For Sharkey’s sales to increase, the developers need to deliver a quality product. For client expectations to be easily managed, the sales force has to provide realistic delivery dates.

While early delivery may result in increased sales, these sales come at a cost. Increasing sales may mean more customers, but poor quality software leads to increased support costs. Thus, the company may be less profitable than before. Customers may lose time fighting a faulty product. As support degrades, they tend to switch to a competing product. What both the company and customers need is not software in three months, but software with
sufficient quality as quickly as possible.

When the goal is stated this way, both players can support it. This agreement allows for a number of possible interventions that could end the Liar’s Contest:

1. Include pertinent contexts in the negotiations. If Sharkey explains why the dates are important, it could give Engelbert an opportunity to suggest trade-offs, so they could deliver the most valuable product possible within the time constraints. If Engelbert points out the quality trade-offs that the short schedule forces, Sharkey may see that it could cause customers to choose competing software. Sharkey can then work with Engelbert to find a date that will work for both of them.

Ideally, Engelbert would show the trade-offs by bringing real customers into the discussion, but salespeople who like to win Liar’s Contests generally work to prevent actual contact between customers and developers. If this happens, Engelbert should ask the customers if they want to talk directly with him. If the customers do want to talk to him, Engelbert should ask them to insist on it. He shouldn’t volunteer more than that. Concerned customers will make it happen. If the customers are not concerned about lies, Engelbert shouldn’t be concerned either.

2. Avoid all or nothing discussions. Offer options during the negotiations. Consider a range of features over a corresponding delivery time frame. Say, “If you really need that delivery schedule, here’s a list of functions. Start cutting them one by one and I’ll tell you when you’ve cut enough so we can make the schedule.” Or, if it’s feasible, you might say, “If you give me this and this by such and such a date, then we could make that schedule.” Be sure to ask only for things they can actually get for you – not, for example, promises of “perfectly clean component deliveries.” And be sure to have this in writing, in case they don’t deliver and still expect you to make the date.

3. Say “I don’t know.” Instead of saying “that can’t be done,” Engelbert can engage Sharkey in trying to solve the problem by saying, “I understand what you want, but I don’t know how to give it to you. Do you see something I don’t? Can you show me how to do this?”

4. Let someone else do it. Sharkey might threaten Engelbert, “If you can’t deliver, I’ll find someone who can.” Engelbert may defensively insist there’s no need to go outside, but properly engaging outside help can create the opportunity for the inside developers to learn new software packages, techniques, and skills. Or, if the outside developer fails, the sales organization has a chance to learn more reasonable expectations about software development.

5. Add another information path. Include the company president, developers, customers, or other parties who have skin in the game. Again, invite them to ask themselves in, using their power to get what they want and need. If they don’t want in, then it’s no longer a problem.

Conclusion

Nobody has to engage in Liar’s Contests – unless they enjoy it more than they despise the consequences. Understand the dynamics so you can show other people the consequences of starting a Liar’s Contest. A copy of this article might serve that purpose quite well. It has for us.

< Publication Notice> – A version of this article was previously published in Better Software, May/June 2004

Planning for Delays

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

As some of you know, a group of consultants are producing a conference for our colleagues and clients. It’s called AYE, for “Amplifying Your Effectiveness.” One of the main goals of this distributed project is to apply our own methods of amplifying effectiveness to the project itself, and thereby to learn what works and what doesn’t.

My first big learnings have been in the area of unplanned delays. The project members are distributed all over the United States, and often travelling from their home base — a situation that’s more than familiar to many Contract Professional readers. I was concerned about the difficulties of conducting distributed projects, but one advantage of this potential handicap is the availability of an email record of what’s happening. So, when I started being aware of delays, I surveyed my email and came up with a list of what had been holding us up and frustrating me.

I suspect the list itself will be a nice reminder to me for future planning, so I also thought it would be useful to many Contract Professional readers. After laying out all the delays and what we’re doing about them, I’ll present a few general principles that might also be helpful to others:

1. One project member’s email is somehow delayed in cyberspace for 2-3 days, without anybody knowing it. The result is messages arriving in the wrong order, and producing confusion that produces more confusing messages. We vow to notice dates on email.

2. Rick’s color monitor fails, and Rick is our webmaster (a single point failure). We talk back and forth for a week, and by then his monitor is fixed. We lose a week.

3. I forget to sign one of two signature lines on a bank form establishing the project bank account. This delays the payment of bills for 10 days, which might have caused rippling delays — but didn’t because people had their own budgets and could pay the bills and trust they would be reimbursed.

4. Kevin breaks his hand, which is especially tough because he can’t use his Braille reader. This delays lots of things Kevin is involved in, but the primary delay is in delivering his article for our pre-conference book. This turned out okay, because he wasn’t the only one whose article was delayed.

5. Dave, who is developing our wiki-web site, gets the flu. This delays the entire wiki testing for a couple of weeks, but it’s not yet on the critical path.

6. Some security certificates (whatever they are) expire on my browsers, and my attempt to update them crashes my system. This non-understood bug delays many tasks for several days (but the effect was somewhat ameliorated by having an alternative browser).

7. Several people take vacations they’ve been planning for a year or so (how inconsiderate of them!). This wouldn’t have been much of a problem if we’d thought to put these vacations in our plan.

8. Naomi has a serious family situation, so she decides she must cut back on her participation until it’s resolved. This adds extra load to several other people, but we were not overloaded, so the schedule effect is minimal once Johanna, our project manager, reallocates the tasks. We are able to reduce Naomi’s participation to the one area where her contribution is least replaceable, and we can do that because we know exactly what Naomi is best at (helping other writers).

9. People who were not at our initial planning meeting have to be brought up to date — not just on our plans, but on the logic behind our plans. We haven’t planned for this, so it’s a real delay — but has an excellent side effect of making us rethink some of our logic before it’s too late to change.

10. James joins the team and has to be brought up to speed. Again, more delay, but with the benefit that James is a talented tester, and subjects many of our plans to tests that we haven’t thought of. James is also an excellent writer/editor, and can take up some of Naomi’s tasks. So, we paid with some delay, and were repaid with some later catching up. In other words, educating James about the project turns out to be a sound investment. Late in the project, however, it wouldn’t have had time to pay off.

11. Our phone and email lists are somewhat out of date at the start of the project, causing irritating delays until we stop and fix it. This contact information should have been done at the very beginning, as it is a core competency for a distributed project. Also, we needed plans for updating this information, because the project is about a year long, and over that period of time, some contact information will undoubtedly change.

12. Marie’s son gets sick, which takes her attention away from AYE business for several weeks. I begin to wonder why all these people are being so inconsiderate of our conference’s problems!

13. I find a strange new mole on my neck, and have to have what the doctor calls minor surgery. (Minor surgery is surgery done to someone else.) Then she finds another suspicious mole, and I have more minor surgery. Then I have a dental emergency (I’ll spare you the painful details). I begin to understand why all these people are being so inconsiderate of our conference’s problems.

14. We are putting together a book of essays by the conference hosts, to introduce people to our work. By definition, we have to have an essay from every one of us, but a few people are at the tail end of the curve with respect to personal pictures, bios, and essays. There are a variety of fine reasons for their delays, but the fundamental reason this is so troublesome is the structure of that part of the project. Since everybody has to have an essay in the book, finishing is like trying to get that last Pokemon card, or last number for a bingo. The mathematics of this kind of requirement ensures that such a project will cause anguish, and we eventually decide to relax the requirement that everybody contribute. If a few are missing, we can live with that. Relaxing this requirement relaxes those of us who are responsible for the book sub-project — and curiously enough, seems to cause all the pictures, bios, and essays to arrive on time.

15. Unfortunately, some of the articles submitted aren’t up to quality standards we had set, and they have to be recycled. We could save quite a bit of time by lowering our quality standards, but we decide against this, since quality is one of the key goals of our conference. What good would it do, we reason, to preach quality when we ourselves don’t practice it.

16. There are lots of typos in the material we prepare for our web site (ayeconference.com), but unlike many web developers, we believed that web sites do have to be tested. Therefore, these delays were anticipated and planned for by the web and project teams, and so fit within the schedule.

17. From time to time, some team member panics about some item or another — which takes time and effort to soothe. Our perfectionism is a major cause of these panic attacks; satisficing (learning to think about what was acceptable quality, rather than perfect quality) is a major cure.

18. Then there are holidays, delaying things in a variety of ways. Why couldn’t Jesus have been born in August, we ask? Poor planning, we concluded — was it by God or by us? Probably us.

19. And of course there is bad weather, which turns out not to hurt us as much as we expected because our travel is mostly virtual. We are lucky there, because the infrequent travel is more by personal preference than project planning. Most of us travel much of the time, and we’ve learned Freedman’s First Law of Consulting: Don’t fly on the East Coast in Winter.

20. We are hurt much more when my ISP (Internet Service Provider) starts delaying delivery of my email by 1 to 7 days. We are hurt even more when Steve’s ISP, which hosted our email lists, starts failing intermittently. Once we realize what is going on, though, we are able to bypass the convenience of group lists and simply maintain our own teams’ lists until Steve gets things straightened out with his ISP. Steve eventually realizes, though, that he had chosen his ISP because they were the low-cost provider — a lesson for next time.

21. Then, once we have all the essays and bios and pictures, we realize that some people haven’t kept the paperwork concerning their articles that they had previously published elsewhere. As one contributor says, “It just didn’t seem important to keep those legal things — at the time.” Lesson obvious, and lesson learned — I hope.

Conclusions

Well, there are lots more than twenty-one, but I think I’ll stop here. Some of us will publish the entire project’s delay list in the future; it will probably be a book. And we’re planning to conduct a retrospective at the conference itself. For now, though, I think you might like to look over the list once more and compare some of your conclusions with mine.

God may have other priorities higher than your project. Leave some slack for Acts of God.

Perfectionism kills schedules; reasonableness saves them.

Certain project structures make success as likely as winning the lottery. Search out and eliminate this lottery effect from your project plan. Not only does this eliminate “bad luck,” but it also lowers psychological pressure on participants, which leads to “good luck.”

Quality is negotiable, but not infinitely negotiable.

Plans are predictions; plan to test them early and often, and then adjust them.

Machines fail. Software fails. People are even less perfect, but they’re more adaptable, so they’re handy to have around to back up the machine systems.

If you have a single point of failure, it will fail at a single point in time. After that, if you have any brains at all, you’ll remove it.

Cross-training is one of the surest ways to protect against those single points of failure. So is a good asset control system for all your project’s assets. If you fail to follow this system because “it doesn’t seem important,” you’re sure to lose your assets.

You won’t be aware in advance of all possible single points of failure, but if you do some risk analysis, you’ll be aware of many of them, which will leave you more time to deal with the ones you weren’t aware of.

You won’t appreciate other peoples’ delays until they happen to you, but try to learn to grant them a generous interpretation. This may calm you down sufficiently so that you can actually become part of the solution, rather than adding your blaming to the problem.

And, finally, I often hear my clients telling me that their project will make its schedule “if everything works out right.” Well, I’ve been in the project business for over forty years now, and I’ve seen several thousand projects. I’ve never seen one where “everything works out right.” This has led me to formulate Jerry’s Iron Rule of Project Life:

It Always Takes Longer

Defy this Iron Law at your peril. Plan for delays, and plan to be adaptable and forgiving when delays occur that aren’t part of your plan. You’ll be more successful, and you might even be happier. As of now, we’re on schedule for November, and we’re rather happy about it.

Advice for Software Development Managers

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

Software Development Magazine recently interviewed Jerry. Here are some of his answers.

Q: What?s the most important piece of management-related advice anyone has ever given you?

GW: If you blame your employees, you’re a bad manager. You hired them, accepted them, supervised them, and directed their training. You?re responsible. If you don’t like what’s happening, look to your own behavior. But, if there’s credit to be given, it’s theirs.

Q: What about when a manager has been hired into a group where some or all employees were already hired by someone else?

GW: You don’t take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off — or you don’t take the position. I don’t know why managers don’t understand that. They take on new assignments like high school kids on their first blind date.

Q: What if an employee begins to exhibit bad behavior after he or she has been hired — behavior that wasn’t apparent in the interview phase?

GW: Well, that happens, and that’s what managers get paid for handling. It can be a setback, but it’s your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I’ve been trying to remedy for years — so in a sense, I’m to blame, because I’ve succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn’t need managers.

Q: If you were to publish a third edition of The Psychology of Computer Programming, what new insights would it include? (Dorset House Publishing released a Silver Anniversary Edition in 1998.)

GW: I might add something about how to make yourself so valuable that your work will never be outsourced — something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that’s just not being done because the odds of success are so poor.

Q: Is this bad behavior coming from the developers themselves, or do you mean to say the entire industry is to blame for not staying on top of innovation?

GW: It starts with the developers, and managers, too. But the overall result is, as you suggest, the entire industry getting too involved in navel-watching and competitiveness over the wrong values. For a long time, customers had nowhere else to go for service and had to put up with whatever we gave them. Now they have choices, and they’re getting even.

Q: In Are Your Lights On? (also available from Dorset House), you note that people like to complain. How do good managers draw the line between harmless venting and disruptive pessimism, if such a line needs to be drawn?

GW: “Drawing the line” is probably not the most useful metaphor. The approach I like most is to listen to the complaint for a reasonable amount of time, then say, “And what do you propose to do about this?” Depending on the reaction you get, take it from there.

Q: You once said, “If you can?t manage yourself, you have no business managing others.” Could you elaborate on that? What does it mean to manage one’s self?

GW: Well, perhaps you can look at Kipling’s famous poem,”If.” It starts:

If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting,
Or, being lied about, don’t deal in lies,
Or, being hated, don’t give way to hating,
And yet don’t look too good, nor talk too wise;

Most of this poem is still pretty good advice about what it means to manage yourself (except, unlike in Kipling’s day, it now applies to women, too).

Q: In your opinion, why do so many software projects go over budget or fail to meet their original requirements?

GW: There’s no single reason, but here are probably the top three:

1. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.

2. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have).

3. Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project?s success is determined by the leaders’ ability to manage themselves emotionally.

Q: If you were to find yourself on a development team, reporting to a project manager, what qualities would you want that manager to have?

GW: I’d want that manager to be a congruent, adult human being, capable of learning from others and his or her own mistakes. A good place to start honing these attributes is the AYE Conference.

Safety Margin

©2005 Steven M Smith

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clarify the Story

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

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

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

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

Storage managers typically answer the following questions:

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

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

A manager who answers as follows will trap themselves:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tell the Story

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“Oh, boy,” Jake thought.

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

Rethinking Stand-Up Meetings, Part 2

©2007 Steven M Smith

I argued in my first article about stand-up meetings that the right participants were the key to a successful meeting rather than whether the participants were standing up or sitting down. Despite my dislike for forcing people to stand up, I mentioned in that article my positive regard for other elements of the standard stand-up meeting.

What elements do I like? Why do I like them? How can we innovate?

Three elements of a SCRUM stand-up meeting stand out for me:

  1. Knowing the agenda
  2. Limiting duration
  3. Minimizing participants

Knowing the Agenda

A daily SCRUM stand-up has each team member answer the following three questions:

  • What did I accomplish yesterday?
  • What will I do today? and
  • What obstacles are impeding my progress?

All the participants know what is expected. I like this a lot. If the participants know what’s expected of them, they are more likely to prepare.

I think there are opportunities to innovate on this solid agenda. Rather than verbally report status information, ask each participant to write their status on sticky 3×5 cards. Ask for a separate card for each element of their answer to the three questions. For instance, 1) Completed refactoring of module Gamma, 2) Created automated test cases for module Delta, 3) Will begin coding module Delta (expect 3 days to develop), 4) Intermittent failures on server Toledo are slowing my efforts.

As you do the round robin, ask each person to read their cards and post them on a community white board. Using cards will cause the participants to prepare something before they arrive at the meeting. That will increase the pace of the statusing. It will provide information for publication to people who are interested in the project but could not attend. It can be compared with 3×5 cards from the day before to detect problems.

I also think there is an opportunity to add a fourth agenda item?What do I propose? For instance, I propose we divert our efforts on accomplishing X and use them to accomplish Y. The answer to this question notifies the team that a member wants the team to make a decision. As with the answers to the other questions, the team is notified but it doesn’t discuss or decide during the daily stand-up. That’s done at a separate meeting.

Limiting Duration

The objective for the duration of a daily stand-up meeting is 15 minutes or less.

I like short meetings. As a participant, I also like to have enough time to share my answers.

I suggest you divide 15 minutes or whatever you plan for the duration of your meeting by the number of participants. Is that enough time for a person to effectively status their work? For instance, if you have 10 participants, there is an average of 1.5 minutes available for each participant. Is that enough time? That’s 0.5 minutes to answer each question. That’s enough time for me to status, but is it enough for your participants?

I recommend that someone perform the role of time keeper. Alert each person, I like to use a chime, when they are 30 seconds from their time limit. And again when 10 seconds remain. Stop them and move to the next person when their time limit expires.

Please, don’t stop someone in the middle of their report in the first few status meetings. At a point where the participants have had sufficient time to practice delivering status, it may be time to stop them. Without being at the meeting, I can’t know whether stopping them is appropriate. But you can.

Time in a meeting is like money in the economy. It’s capital. Use it wisely and you will increase your return.

Minimizing Participants

A principle of a daily SCRUM stand-up is the separation of participants from observers. The less the number of meeting participants, the more time is available to each participant to share status information. This is a smart action and I like it a lot.

I interpret there is more to this element than merely minimizing the number of participants. It’s about gathering the right people together and demonstrating to them that they have the authority, power, and responsibility to produce the
product.

If your hiring process isn’t putting the right people in the meeting, minimizing participants will be less effective than it could be.

Gathering Feedback

There isn’t a feedback component that I am aware of in the standard stand-up meeting format. I believe a status meeting becomes more effective when it adapts to its environment through the use of participant feedback. Without
feedback to improve a meeting, it becomes a picture of a sprinting cheetah rather than a real sprinting cheetah. Pictures of cheetahs don’t turn when its prey makes a turn, but a real cheetah does.

Find out what turns your team needs to make by gathering feedback about the meeting. See my blog post Measure ROTI (Return On Time Investment) to learn how to gather the feedback. Note, I don’t recommend gathering feedback every meeting: I suggest instead gathering it every third or fourth meeting. When you do gather feedback, respond to it; otherwise, a picture of a snoozing cheetah is apt visualization of the state of your meeting.

Final Thoughts

Too many people believe that stand-up meeting are more effective than traditional status meeting because the participants are forced to stand up. That’s a fallacy. Increased effectiveness results from the other elements of a stand-up meeting — knowing the agenda, limiting duration, and minimizing participants. The elements are classic elements of any effective
meeting. The actual application of these elements is the root cause for a stand-up meeting being more successful than a traditional status meeting.

A possible benefit for forcing people to stand up is notification. Participants who have continually experienced ineffective status meetings — those with poor agendas, poor participant preparation, poor adherence to the meeting schedule, and poor choices about who will participate — may benefit from physical notification that the meeting has changed. Once the notification is complete though, standing up loses its value.

I know people from an earlier era who believe wearing a tie makes developers more alike and more disciplined. I don’t buy it. And I don’t buy the idea that participants should keep standing up once they understand the rules for participation. Forcing a developer to continue standing up is like forcing them to wear a tie. Both actions will make them uncomfortable and neither will improve their productivity.

Use the standard stand-up meeting format as a starting point. It’s a solid foundation. Don’t worship the format. Encourage innovation so that your status meeting better responds to the unique needs of your team.

For More Information

Jason Yip, It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings. It’s an excellent article.

You will find an abundance of information about this topic on the web. Search for “stand-up meetings” using your favorite search engine.

Rethinking Stand-Up Meetings

©2007 Steven M Smith

Stand up meetings are popular in software development organizations now.

What makes a stand-up meeting more effective than a traditional meeting to socialize status information?

Nothing. The effectiveness of a stand-up meeting, like the traditional status meeting, depends on the participants. If you have the right people at the meeting, you can be effective whether the participants are sitting down, standing up, or standing on their head.

The theory behind a stand-up meeting is that a physical reminder of the duration of the meeting will keep it shorter. The longer the meeting, the more your body signals it’s time to stop. The proponents of stand-up meetings like this natural time-boxing signal. Every participant feels the signal to some degree.

The signal may be too strong, however, for people who have a physical problem that make standing difficult. For instance, I twisted my ankle recently, it’s painful when I stand on it.

If I am a good teammate who listens and participates appropriately, does it matter whether I’m standing or sitting down with my ankle propped up? No, of course not. It matters how I participate, not the position of my body.

I have heard that proponents of stand-up meetings claim that the meetings helps build teamwork. If your teamwork is better, I am THRILLED for your team. But I doubt whether the stand up component made the difference.

When I started my career, I had to wear a tie every day. The next job required a suit. Management told me clothing built teamwork. I think standing up during a meeting is like wearing a tie. My teamwork isn’t any better wearing a suit and tie than it is when I wear shorts and a t-shirt And I don’t believe my team’s effectiveness changes whether they are standing up or sitting down during a meeting.

If you want to have effective meetings of any kind, you need leaders in the room. That’s the kind of people I referred to as “the right people” earlier. Leaders who organize the meeting; leaders who lead the meeting; and leaders who follow other leaders.

If you have people who see no value in meeting with their teammates, having people stand up might help the meeting from lasting too long. But there is more to an effective meeting than preventing people from being trapped in a room.

Don’t Tell Doreen

©2005 Steven M Smith

Jarrett, Doreen and I were on the verge of a closing a big sale. We had crafted the Statement of Work (SOW) for two weeks and had finally reached the point where it satisfied both the customer’s desires and the needs of our company.

But at the last second, before the document was sent to the customer, Jarrett, the salesman, decided to reduce the asking price.

He waited to tell me about the change until Doreen had left our office to fly back to headquarters, three thousand miles away, then added a caution: “And don’t tell Doreen about the pricing change.”

Each word hit my head with a thud. Doreen was part of our team. She had invested hours helping us change the SOW so it would satisfy the customer. After the sale, she would be responsible for the service we were offering and held accountable for its profitability.

Hoping that I had misunderstood him, I asked Jarrett, “What did you say?” The same series of thuds ricocheted off my head.

“But Doreen helped us. She deserves to know about the change,” I sputtered.

Jarrett calmly replied, “No, we need to get the document to the customer now and there is no time for further negotiation with Doreen.”

I thought the notion of withholding information from Doreen was ridiculous, and just plain wrong. She had gone well beyond the call of duty to help Jarrett and me, but Jarrett seemed, as if playing checkers, intent on jumping over her position.

My heart accelerated and I felt the thumps. A gentle voice inside me urged, “Slow down. Breathe.” I took a long breath. As my lungs inflated, I noticed that my spine straightened which caused me to sit up straight. I looked directly into Jarrett’s eyes.

I struggled to show my empathy with Jarrett’s position. “I understand your desire to save time.” I took another breath and continued, trying to make him see my position because he had ultimate control. “Doreen is a stakeholder in this document too. If you decide to not tell her about the change, it becomes your change and I will not support it.”

Jarrett’s eyes narrowed as he fired out the words, “I don’t need your agreement or support: It’s my decision and I’m moving ahead with it.”

Years ago, those words would have struck fear into my heart. I regularly have to deal with Jarrett face-to-face. He’s a malicious person, a sales person who is trained to manipulate situations, and he could easily destroy my reputation in our office. On the other hand, I rarely see Doreen and she can’t help me locally. But if I go along with Jarrett’s idea, I will violate my own principles and destroy how I feel about myself.

“It is your decision,” I said calmly, “I’m surprised though that you think Doreen and my support wouldn’t be an advantage when our management questions you about the pricing change.”

I had Jarrett’s attention, but he said nothing, so I went on. “You’re going to need my support and especially Doreen’s. Our customer listens to me and trusts what I say. Remember, I’m the one who helped them define their requirements. And you’re going to need help explaining to your management why a pricing change makes sense. Doreen is the only person who can do that for you.”

The muscles around Jarrett’s temple moved up and down as he repeatedly tightened his jaw. “I don’t like to be threatened,” he spit out.

“My intent is to help rather than harm you,” I said. “Doreen will find out about the change. She will trust neither you nor me and that will cost both of us dearly in all future negotiations with her. You may be willing to pay that price, but I’m not.”

His eyes looked toward the ground. Silence.

“I’ll think about it,” Jarrett said.

Did I make a difference? My answer arrived the next day when I received a copy of his message to the customer. Rather than discounting the services that Doreen and I had helped him develop, he cut the price on another part of the sale.

So, did Jarrett change for the right reason? The answer depends on how you define “right.” My definition is different than Jarrett’s. His principles are narrowly focused on doing whatever it takes to win this sale. My own principles are broader and focused on sustaining relationships that win business both now and in the future.

If you’re focused on short-term results, keeping secrets may have great appeal. But if you care about building relationships for the future, pay careful attention whenever you hear the words, “Don’t tell …” The words that follow will invariably violate a relationship.

Decide As a Team

©2007 Steven M Smith

Do some members of your team make agreements during meetings but fail to support them afterwards?If this behavior is happening, I suspect your team is using an obscure process to make decisions.

Identifying Obscure Process

An obscure decision making process is easy to identify. Ask each member to create a map of the process used to make team decisions. If the individual maps aren’t similar, obscure is an accurate description of the process.

Probe the maps of an obscure process further and you will find false assumptions. Members assume things about the behavior of other members that isn’t true; for instance, some members assume that their teammates will support the decision made by a team and how it was made with outsiders and yet some other members assume that their support is only necessary when they personally agree with the decision.

I believe an obscure decision making process disables teamwork. People aren’t connected by shared principles. They don’t cooperate. They work like a group of individuals. It doesn’t have to be this way.

I have worked with a simple, clear process for making team decisions for over a decade. I have found it highly effective. It’s designed for teams who make their decisions by consensus. If you are the leader of a team, you may object to the idea of a consensus decision. The idea may trigger the word “groupthink” to pop into your head. But as I will discuss later in this post, a leader has more control over a consensus decision than they might initially think.

Making Team Decisions

The aforementioned simple process is called Roman Evaluation. Figure 1 is a map of the process. Using the process creates visible feedback about the state of each member’s agreement on a proposed team decision. That feedback drives needed discussion and eliminates unneeded discussion.

Figure 1. A Map of the Roman Evaluation Process

Follow the following four steps to help a team reach a decision:

1. Propose

A proposal that defines a course of action desired by a member of the team drives the process. Without a concrete proposal, there isn’t any decision to be made.

The first four words of any proposal are “I propose that we…” This wording explicitly announces the proposer’s desire; for example, “I propose that we reduce the duration of this meeting to 60 minutes.”

Note, the word “we” is used to clearly identify that it is a team decision.

Post a written copy of the proposal in the room so that every member is able to read it own their own during the entire decision making process. The proposal may be amended so leave room for changes.

I would write the proposal mentioned earlier as, “Steve proposes that we reduce the duration of this meeting to 60 minutes.” Communicate it to the group using whatever medium you prefer, such as a flip chart, overhead projector or computer projector.

2. Discuss

Let the proposer speak first so he or she can provide context. Start facilitating a group discussion with an explicit duration. The purpose of the discussion is to understand the proposal and its impact. Using the example, I might ask the proposer: “What’s the problem you are trying to solve by reducing the duration of the meeting?” I might ask the team, “What do you think?”

My experience is that groups often exceed the time allocated for discussions so constantly monitor the time and periodically share how much time remains. Whenever either the discussion naturally ends or the time limit expires, close the discussion and vote.

3. Vote

A group recognizes their agreement faster with clear signals. Ask each person to signal their decision with one of their thumbs:

  • Up means “I agree.”
  • Sideways means “I will accept the majority’s decision and support it.”
  • Down means either “I disagree.” or “I have something to say.”

I suggest that you emphasize that a thumb up or sideways means the member will support the proposal. Spell out that support means they will say “We decided to…” when asked about a decision by an outsider (see my post entitled Word Choices — We — Part 2). And they will defend the logic behind why the decision was made. This understanding makes voting a serious responsibility rather than a ho-hum exercise.

The vote gives the team clear feedback about the state of their agreement on the proposal. It enables different choices to be made than are possible without feedback.

Record the vote and verify that you have the same number of votes as members. A consensus is any mixture of thumbs pointing up or sideways. Any thumb pointing down signifies dissension.

4. Process

As you tally the vote, write down the names of people with their thumb down. Ask each dissenter, name by name, what he or she would like to say about their vote. Don’t let anyone interrupt them. When each dissenter finishes, ask them whether their thumb is still down. They may surprise you. My experience is that many people want to say something and once they do, they move their thumb up or sideways.

If there is still dissent, ask the team whether someone wants to amend the proposal. If someone offers an amendment, discuss, vote, and process. Otherwise, reject the proposal.

Considering Consensus

As you may have guessed, I believe in consensus decision making. Some leaders have told me they don’t like it though. They believe it leads to “groupthink.” I understand the thought, but that doesn’t happen. If the leader makes it clear that in the absence of a consensus they will decide on the course of action, groupthink is impossible.

The leader is a member of the team. They vote on a proposal. And, like all the other members, they are free to vote so the team makes the appropriate decision. If they put their thumb down and an acceptable amendment can’t be found, then they are free to make the decision they think is best.

I suggest that leaders don’t make a habit of using this power. But, in my experience, some situations demand decisions in a faster time frame than a team may be able to process them.

Conclusion

Roman Evaluation has a powerful effect on decision making. It connects the members of the team. It creates shared principles. It increases cooperation. It helps build a solid foundation for teamwork.

When reinforced, the act of voting makes it clear that unless a member vetos a proposal, as a member of the team, they are expected to support the proposal. And that’s the kind of thinking that binds a team together.

If your team’s decision making process needs improvement, I can help. Contact me.

Hiring Testers

©2002 Johanna Rothman, www.jrothman.com

This article originally appeared on stickyminds.com

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 www.jrothman.com

Introduction
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.

Summary

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.

Managing the Group Meeting

©2003 Johanna Rothman, www.jrothman.com

Does your staff look forward to flu season so they don’t have to attend your group meetings? Are you looking for ways to escape your manager’s meetings?

Boring group meetings tend to be a result of inadequate agenda-setting and facilitation. The bad group meetings are just status meetings, one-on-one’s between the manager and whoever is talking. Even donuts don’t help a meeting like that.

Group meetings don’t have to be that boring or awful. They can be a technique for teambuilding, for increasing the group’s knowledge, and for problem solving. To do this, you have to have an agenda and an environment that supports group work.

If your group meetings boring or not useful, and you’re not sure what to do about it, try an agenda like this:

  1. Spend five-ten minutes on juicy information such as: corporate information, cross-department news, company gossip, and rumors. This is the time to spread good news and find out what other people think is going on. Managers can listen to what their staff thinks is important. Staff can talk to their managers about their concerns. Consider adding appreciations?”I appreciate you John, for taking the time to calm the marketing manager down. I was busy, he was ready to go beserko, and you took the time to help determine what his concern was, and then you started the problem solving. Thank you.”
  2. Take five minutes for someone to review a thorny problem they solved or would like help solving. Or, ask for new information that others may have about their projects.
  3. Use the next ten-thirty minutes on “the issue of the week.” If you are just starting group meetings, or if you want to restart them, one way to generate issues is to ask, “What do we need to do, and who do we do it for?” That question will spawn a list of issues for your group: who does what for whom, and what the obstacles are. Plan to reprioritize this topic list, as one of the issues of the week.
    • Facilitate the meeting, by choosing a facilitator and a note-taker for each meeting. (This is also a good way to help your staff build facilitation skills.)
    • Make sure the facilitator ends the meeting on time.
    • If you’re done discussing the issue of the week, end the meeting early.
  4. Use the last few minutes to wrap up. Either close the discussion, or plan how to carry over the discussion to the next week.

That’s it. No boring meetings, no individual one-on-ones. And you don’t need donuts to enjoy this kind of a meeting. Send out the agenda before the meeting. Make sure the note-taker sends the notes out within a day, and you’ve got a recipe for successful meetings.

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

©2000 Esther Derby www.estherderby.com

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: www.estherderby.com/writings/designinguseful.htm

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.

Pennywise

©2005 Esther Derby

This column originally appeared on Stickyminds.com

Back in the late 90s, both demand for qualified people and salaries were high. Hiring managers scrambled to make offers within hours of seeing a promising resume and bidding for the best people was intense. It was a sellers market and qualified candidates could pick and choose from among the top compensation packages.

Those days are gone, at least for now.

Many companies (and candidates) are taking a more sensible and reasoned approach to finding a good fit between the needs and wants of both company and candidate.

But in some companies, the pendulum has swung in the opposite direction. Instead of an obsessive focus on chasing the top candidates and offering top salaries, some companies are now focusing on hiring at the lowest salary possible.

My friend, Roxanne, works for such a company, Pennywise Corp. Pennywise immediately eliminates candidates who are asking for the high-end of the salary range for a job. Of the candidates who meet minimum skill qualifications, the job goes to the candidate with the lowest salary requirement. Not the best qualified within the range Pennywise can afford – Pennywise chooses on the basis of who will take the lowest salary.

The people Pennywise is bringing in with this strategy aren’t bad people. But as Roxanne points out, “The people the company is hiring don’t have the experience to do the work the company wants to do. With all the inexperienced people we’re hiring, we’re actually falling further and further behind.”

Even if you aren’t working with truly silly hiring policies, you’re probably working within a budget and have limits on what you can offer candidates. When you can’t find or can’t afford the perfect candidate, what can you do to enable less-experienced or less-skilled candidates to do the work you need done?

Here are some strategies to keep work moving forward:

Hone your hiring skills
In good times and bad, you want to hire the very best people that you can afford.

Look for value. The fact that a candidate lists a lower salary requirement doesn’t mean that he isn’t competent. It may mean that he has less experience or is willing to take a lower salary to move into an area where his experience and skills are not a perfect fit. These may be just the people you want to find.

When you interview, focus on functional skills and ability to learn. Look for how well the candidate’s work style and personality fits with the group. (For more on hiring, read Johanna Rothman’s forthcoming article, Ready, Aim… Hire, which will appear in STQE March/April 2003).

Prioritize relentlessly
Development managers and test managers are always juggling more work than the staff can handle. If you can’t adequately staff all the projects on your agenda, staff the highest priority projects appropriately. Put the lowest priority projects on hold. You can always pick up low priority projects again when the more important work is complete. (But check before you start them up again. Sometimes those projects slip from “low priority” to “no priority.”)

Avoid spreading people too thin
Some people believe that if you move forward a little bit on every project, some how, all the projects will be accomplished. This may work when there is no time frame and no quality criteria specified. For most people, 10% time here, 15% there, in bits and pieces adds up to much less than 100% productivity. To get the most work done most effectively, assign people to only one or two projects.

Manage coaching proactively
Mentoring and coaching is part of the job description for many tech leads, test leads and team leads. There are limits to how much coaching one person can do and still accomplish their own work. Don’t expect 40 hours worth of deliverables each week from someone who is coaching other team members. If you have an inexperienced staff of five or six and one team lead, count on one – two days of coaching time a week for your lead.

Schedule “coaching time” in blocks so that the lead isn’t subject to constant interruptions. An open coaching session where all less-experienced team members attend can provide a good learning opportunity. Each person will learn from the answers to others’ questions as well as their own.

Use reviews and walkthroughs
Reviews are almost always a good practice to consider and they are essential when you’re working with new or inexperienced staff. Technical review aren’t just for developers, any software product can be reviewed: requirements, use cases, designs, test plan, test cases, test scripts, install scripts, and of course, code.

In addition to finding errors, reviews provide passive learning. As with open coaching sessions, each reviewer will learn from the issues they find and from the issues that others bring up in the review.

Walkthroughs focus more on education than on finding defects. Walkthroughs can be an effective way for new people to increase their product knowledge.

The pendulum may have swung the other way for a time, but no matter what the economic conditions, hiring the best people you can afford and managing proactively won’t go out of style.

How to Kill a Software Company

©2002 Don Gray

A Software Project By Any Other Name

Most software practitioners and managers are aware of a project’s three legs. These legs are features, schedule and quality. (1) While all of these are important for a successful project, one must be dependent on the other two. (2) Failing to acknowledge this will guarantee that if the project does succeed, it will be due to the sacrifice of the quality of the participants’ personal life (health, finances and relationships), the fortuitous combination of the team’s skills, and a good dose of luck.

Interestingly enough, we seem to succeed at software projects often enough that an while individual project or multiple projects fail (for whatever reason)3 enough projects succeed that the act of creating software is valuable enough that the “pockets and bean counters” continue to fund additional aberrations of reality.

Close But No Cigar

So being unable to deliver good stuff (or anything) most of the time is not sufficient to kill a software company. Nope, to kill a software company requires a solid understanding of three slightly different “legs”. These legs are “If It Ain’t Broke, Don’t Fix It”, “It’s What The Customer Thinks”, and “The Number of Nerds are Finite”. Anyone of these legs can be sufficient to do you in. To fail quicker, you need to have at least two, and for complete, total, and a quick freedom of your future, you should strive to grab all three legs.

If It Ain’t Broke Don’t Fix It

Seems obvious doesn’t it?

You’ve finally shipped something that people might want with hopefully good enough quality that people actually buy it. Using it would be nice too, but isn’t necessarily needed5. In fact, based on the product, it’s possible that it’s so hard to use that the tech support costs will be more than the revenue generated by the product. But assuming that’s not the case, now is the time to relax, and take it easy. This would be nice except that ?

Plagiarism is the sincerest form of flattery

And some company out there is going to flatter you. Even if you do have bullet-proof exclusive “rights” and the money to defend those “rights” in court, eventually the competition is going to provide a solution to your customers that is going replace you in their mind, on their computer, and from their wallet. In an industry where events are measured in Internet Time6 not updating your product reduces your time to market to 0(t), which is probably about how long you’ll be around.

The Only Constant Is Change

If you don’t keep changing with change, you’re going to change anyway. The difference will be an opportunity to have (hopefully) some input or influence in the change (8), or suddenly you (and your company) will be the byproduct of the change.

It’s What the Customers Think

What if you’re cursed with a company that realizes the need to follow the market changes?9 All is not lost! Just as important as how your company deals with technology is how your company deals with people10. This means that if you can frustrate, aggravate, or discourage the people who do buy your product, you can still kill your company.

Of All The Things I’ve Lost

I miss my mind the most. This is where I kept who and what is important in my life. The good news for you is your customers keep who and what are important to them in their minds. The point here is that you can be replaced in your customers’ minds in two convenient methods. The first is complacency (remember the “If It Ain’t Broke ?”). The second is to make sure that every time the customer interfaces with your company, it is a bad experience.

Training?

It left on track 9 at 8 this morning. Didn’t we tell you? For maximum effect I recommend you schedule software training classes randomly, and create a semi-correct training manual11. For extra effect, have a new employee who doesn’t understand the problem domain, hasn’t used (or contributed to) the product, and doesn’t like working with people12 teach the class. To help confuse things, have non-native employees create your documentation. The unique language constructs will help aggravate your customers. For added effect, randomly change type sizes and fonts.

If you do a bad job at bad training, the users will understand how to apply the software to solve their business problem. This reduces the technical support burden (less cost to your company and less aggravated customers) and could lead to a reverse in negative training cash flow as the users recommend the training to other companies.

For More Help, Deposit Another $25

It used to be a Quarter ( $ 0.25), but everything is more expensive these days. If you’ve done a good job at bad training, no one is going to understand how to use the software. The problem they wanted to solve by buying the software won’t be solved (but that’s not your problem), and the probability of losing the customer’s business is increased (especially if they lose their job because of it). For added assurance, have the same employee teaching the class provide the technical support when they’re not teaching the class. This should really discourage the users.

For Extra Credit

You can figure out additional ways to alienate customers. Possible areas include order processing/shipping, invoicing, licensing … and(13)?

Where’s A Nerd When You Need One?

Last But Not Least

You should figure out where your product is in its life cycle. This will allow you to violate the following Quality Perceptions over Product Lifetime table (14) intelligently. You should leave nothing to chance.

Product Life/Market Pressure Introduction (Enthusiasts) Early Adopters (Visionaries) Mainstream (Pragmatists) Late Majority (Conservatives) Skeptics (Laggards)
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.

In fact armed with this chart you should be able to “spiral” back to “It’s What The Customer Thinks” (15) and review your plans for frustrating, aggravating, and discouraging your users. The truly attentive student now realizes that there are 5 * 3 * 3 (or 45) different things they should be doing to alienate their customer base.

The Good News Is

It is a limited marketplace. There are a few applications that are relatively common, but most software companies have a much smaller possible client base. To calculate the number of people you possibly need to deal with, the equation is PND = TP – TAA – TUCP.(16)

Risk Is Risky

Do Them All

And leave nothing to chance. The future is out there. Bright, rosy, and just around the corner. If you follow these simple steps, I’m sure you’ll be able to kill your software in no time.

But In the Interests of Science

I should mention that I’m sure there are other ways people have killed their companies. If you have a really creative story, and would like to share it with me, my email address is don@donaldegray.com.

For First Time Offenders

What you might want to do is keep a diary of how things are going. Don’t be discouraged if it takes longer than you expect. Users can be loyal much longer than they really should. There are reasons for this, but they are beyond the scope of this article. When you finally succeed, send me a note and let me know about it. Feel free to use the same email the story tellers are using.

Notes

  1. Actually, there are a couple of other “three leg” choices, but you get the point. If you don’t control at least one “leg”, place your bet on long hours, unhappy users, and very probably a disastrous project
  2. I first learned about this in an article by Rick Zahsiner on “Time-boxing”
  3. Industry literary coverage is thorough in its numbers. Pick some value between 30 and 80 percent on the number of projects that fail for whatever reason. It would be nice to have a breakdown on the failures by category, but that seems to be not as spectacular and a whole lot harder to determine.
  4. The current quintessential example of this is the stock market current darlings “Internet Companies”.
  5. Does “shelf-ware” mean anything to you?
  6. I dislike phrases like this, but it looks good in print and I hope gets the point across
  7. Things like operating systems, languages, and such.
  8. Notice I didn’t say “control over change”. This was not a mistake.
  9. There is a difference between the bleeding edge and the leading edge. You figure out where you want to be, but being on the bleeding edge is a better way to kill the company. Read on and find out why.
  10. Face it, if we were good at dealing with people, we’d have chosen a career like selling shoes or doing something with a higher success rate than writing software.
  11. This is much better than a manual which is totally correct or totally wrong. This way the user isn’t sure which is wrong, them or the manual.
  12. In case you forgot, see 10.
  13. If you have an example you’d like to share (from either side of the relationship, my email address is don@systemssmiths.com.
  14. I’m sure when Johanna Rothman published this table in Reflections, Volume 1 Number 2, Page 4 “Project Toolbox: What’s the Focus of your Project?” she had no idea it would be used for such an interesting use. But a tool is a tool, right? And if your only tool is a hammer, everything looks like a nail.
  15. Blaise Pascal noted “The last thing one knows in a work is what to put first”. I think I got that right although I may have flopped 2 & 3.
  16. Where PND is People you Need to Deal with, TP is the total possible population, TAA is the Total number you’ve Already Aggravated, and TUCP is the Total Users using a Competing Product. This represents a single point in time. The equation with respect to time will appear as decreasing Log curve.

Managing in Mayberry: An examination of three distinct leadership styles

©2001 Don Gray and Dan Starr

Near the Blue Ridge Mountains in North Carolina, not far from where you think it should be, there really is a town called Mayberry.

Although the main highway bypassed the town years ago, the namesake for the popular 1960s television series is still a bustling community, and a fair amount of traffic enters Mayberry’s downtown from the north on the US Highway 52 business spur every morning. In town for a week of consulting work, we were able to observe the recent road construction along that route and watched a trio of local citizens demonstrate their own unique administrative styles. Let’s take a look at how these characters traffic management closely parallels common styles of software project management.

When road work just north of town closed Business 52, all the traffic entering town from the north had to take the 52 bypass around to the west side of town and enter the downtown on Key Street. Unfortunately, this meant traffic would have to make a left turn onto Key Street, crossing fairly busy east-west traffic (see Figure 1).

Mayberry Roadwork

The town council feared that during the morning rush the traffic waiting to make the left turn onto Key Street would back up on the southbound off-ramp all the way to Highway 52 itself. This could cause a serious accident, since Highway 52 has a 65 mph speed limit. So the council decided to station one police officer and one or two rescue squad volunteers at the intersection to make sure that traffic on the ramp did not back up.

Three Approaches to Managing

Being a take-charge guy, the officer on duty (we?ll call him Barney) arrived at the scene Monday and quickly sized up the situation. He decided that what was needed was a traffic light at the intersection of Key Street and the ramps. Since it would take the county months to approve a light, he decided to operate as a “human traffic light,” directing traffic manually. Each direction got its turn: westbound Key (including left turns onto the southbound ramp), then eastbound Key (including right turns onto the southbound ramp), then the off-ramp (which could turn either way onto Key). Barney?s plan didn’t actually work all that well. Traffic stalled in both directions on Key Street. And there were a couple of close calls on the ramp; traffic backed up almost onto Highway 52 once when Barney let a few cars turn left onto Key Street. By the end of rush hour he was hot, tired, and a little discouraged, and he had written a fistful of citations to drivers for making unmentionably rude gestures at a law enforcement officer.

On Tuesday, one of the rescue squad volunteers (a helpful local woman known as Aunt Bea) said she knew how to take care of the situation. She figured that traffic could probably take care of itself as long as drivers didn’t have to cross each other?s paths. So she let traffic go both ways on Key Street, and let people make right turns onto and off the ramps. When somebody had to turn left, she’d stop the other lanes and let them go. Aunt Bee’s approach worked better than Barney’s (at least nobody made rude gestures at her), but there was still a lot more congestion than we expected, and by the end of rush hour Bee was glowing profusely.

On Wednesday Sheriff Andy showed up, bringing a lawn chair and a thermos of lemonade. He set up the lawn chair on a shady spot from which he could see the intersection and a fair way down the off-ramp, and sat down to sip lemonade. When traffic started to back up on the ramp, he got up, stopped Key Street traffic, and let the ramp empty; then he went back to his lemonade. Other than that, Andy pretty much didn’t seem to do anything. Despite his apparent inaction, the intersection just seemed to work. People were calm and relaxed, with the drivers making right turns creating breaks for others making left turns, and everything worked a lot like it did before anyone showed up to help?just a little better.

Putting on our consultant hats, we realized we?d just witnessed three distinct styles of management?Barney’s micromanagement, Aunt Bee’s motherly management, and Andy’s masterly management. Since these styles are also common in software project management. Let?s look at each of them in more detail, and see what we can apply to our own software projects.

A Question of Style

Each of our managers made different assumptions that shaped their style?in particular, assumptions about the people being managed, and about the role of the manager. These assumptions determined how they approached the critical activities of managing. In his book, Quality Software Management, Vol. 1: Systems Thinking, Jerry Weinberg highlights five critical activities:

  1. understanding the problem to be solved,
  2. planning the solution approach,
  3. observing what the people being managed are actually doing,
  4. using rules and process models to determine what to do next, and
  5. taking action to guide the group toward its goal.

Together these activities form a feedback system that ?steers? the project team. How they are executed (i.e., what the manager defines as the problem, how the manager plans, what observations get made, which rules get followed, and how the corrective actions get taken) makes all the difference?determining just where the team will go, how the team members will feel about the software project as a whole, and ultimately how satisfactory the results will be.

Micromanagement

Barney practiced micromanagement, which is based on the assumption that the manager has to see to it that everything gets done. Most micromanagers don?t deliberately meddle out of a need to be in control; they?re just operating under the assumption that if they don?t do it, it won?t get done. Micromanagers also tend to make the related assumption that those being managed will do what they?re told to do; no more, no less.

These assumptions describe machines better than they do humans. Indeed, when Barney said we needed ?human traffic lights,? he was describing a situation in which both the manager and those being managed were more mechanical than human. Perhaps this is why so many good programmers become micromanagers when they get their first promotion?they?re just ?programming? the ?bio-robots? who work for them!

Using Weinberg?s model, we can see how Barney?s assumptions defined his view of the critical management activities:

  1. The problem to be solved was to personally make sure everything was done in an orderly fashion.
  2. The plan that followed was for Barney to pretty much do everything himself. He would personally direct the movements of each and every vehicle. This meant that the plan had to be simple enough that he could be in control of its execution at all times.
  3. Even with the simple plan, Barney was far too busy directing traffic to observe much. Standing in the middle of the intersection, he wasn?t in the right position to see up the ramp when traffic began to back up onto Highway 52.
  4. Even if he had made better observations, his manager-centered process model didn?t allow him to do much. The underlying assumption that he was personally responsible for each and every car going through the intersection meant that he couldn?t delegate much – he couldn?t count on the drivers to do anything other than what he told them to do.
  5. Barney?s actions were pretty limited; because he had to control each vehicle, he couldn?t leave his spot in the middle of the intersection. In the end, he couldn?t do much beyond try harder at what he was already doing?waving his arms more frantically at the folks, in the hopes that they’d get through faster.

Because the manager must make (or at least approve of) all decisions, only one thing happens at a time and everything else lines up waiting for a turn. When simplicity, centralized information, and oversight are turned from virtues into vices, it creates a choke point that affects project planning and execution.

Simplicity Since the entire project plan must be under the control of the manager at all times, the plan must be simple enough that a single person can comprehend it in its entirety. This sets an upper bound on project complexity?if the problem to be solved is beyond this bound, the manager has to simplify it somehow (e.g., letting traffic go in only one direction at a time). This serialization of activities is a common simplification in micromanaged projects as well, and it wastes both effort and time. When serialization isn?t enough, the manager may start leaving ?non-essential? activities out of the project plan. Micromanagers are notorious for over-simplifying, to the point where their software project plans may leave out something essential for a successful product launch.

Centralized information Since the manager is the only one who can make a decision, it?s critical that he get lots of quality information about how the project is doing. Unfortunately, the only observations allowed are those that the manager puts in the project plan?but that manager?s far too busy making each and every decision to actually observe much of anything. So in practice, micromanagers are often flying blind, making decisions on little or no actual information.

Oversight The need to get explicit approval for each action adds to the amount of time required to accomplish tasks. So micromanagement tends to be inefficient, with a lot of people waiting around for the manager to tell them what to do next. The manager-as-bottleneck is a key structural problem. The practice also leads to people problems, such as initiative squelching. The manager?s assumption implies that the people being managed have nothing to contribute beyond the functions defined for them by the manager. What if the workers want to do something other than follow the rules?because they see a better way or a problem with the plan? Forget it. The micromanager will not allow it to happen. This creates short tempers and long days for those who are micromanaged.

Most people don?t like this style of management. Some will respond with a sort of dead, mechanical compliance, waiting dutifully for their next set of instructions from the manager. Others may choose some form of subtle rebellion, such as ?working to rule??following the manager?s instructions to the letter, no more, no less, even when those instructions are clearly a recipe for failure. And others will rebel more openly, taking advantage of the manager?s continual distraction to get away with whatever they can. Alas, these responses to micromanagement tend to set up a positive feedback loop that reinforce the micromanager?s assumptions and leads to even more micromanagement. Micromanagers tend to be very busy people.

So, is micromanagement ever appropriate? Certainly, when the problem to be solved is small enough for one manager to truly comprehend the entire project plan, and the people doing the work are willing to follow each and every command of the manager. While this situation can occur now and then, it’s not very common in the software world.

A common cause of micromanagement is the newly promoted, technically competent manager rushing in to help a floundering employee or rescue a particular part of a software project. This creates a co-dependent dynamic where the manager becomes the rescuer, and the employee becomes helpless. This ensures that the next time there is a problem, the manager will step in again, and so on, until something happens to break the pattern.

While micromanaged projects can (and often do) result in successful product launches, it?s often more in spite of their management than because of it. There ought to be a more efficient and less aggravating way to handle the situation.

Motherly Management

Aunt Bea chose a kinder, gentler style that we call motherly managing, allowing the drivers to do some things for themselves, and helping them when she thought they needed help. But her underlying assumption was still pretty close to Barney?s: the people being managed might be able to do a few routine things without being told, but all significant decisions?especially when there was some form of contention or competition?were still firmly under her control.

If the micromanager views the people being managed as machines, the motherly manager sees them more like children, able to do a few routine things but still needing protection from anything potentially dangerous. Like the micromanager, the motherly manager is not necessarily malicious or desperately in need of control. Aunt Bea had no great need to have power over the drivers; she just knew that they couldn?t make major decisions without her help. She simply couldn?t visualize the situation where one person could be turning left into the gap created by another turning right, because she couldn’t see who was controlling the relationship, and she knew that two drivers certainly couldn?t cooperate without somebody to coordinate them.

Aunt Bea?s motherly assumptions defined her view of the key management activities:

  1. The problem to be solved was something like ?take care of the people who have to cross other traffic.? Like Barney, she saw the problem in personal terms; it was her problem, not the drivers? problem.
  2. Because Aunt Bea saw the drivers as human beings who could do a few things for themselves, her plan was a bit less rigid than Barney?s. She could allow at least a few routine things to happen in parallel, but under exceptional conditions she would take full control of everything, which meant reverting to serial execution.
  3. Aunt Bea?s more distributed plan required somewhat more sophisticated observations than Barney?s. She had to observe those situations in which her help was needed?in particular, left turns. Notice that she wasn?t observing whether people were having trouble making left turns; her underlying assumption said that a left turn signal was a request for help. Like Barney, she spent her time in the middle of the intersection, a point from which she couldn?t see up the
    ramp very well.
  4. Because of her motherly assumption that the people being managed couldn?t handle any form of contention or conflict, Aunt Bea?s process models dictated that she must personally resolve these things. So her response to just about any out-of-the-ordinary condition was to stop traffic and go back to taking turns.
  5. Like Barney, Aunt Bee was working from a very limited set of actions, in part restricted by her need to be in the position of control at the center of the intersection. If those actions didn?t work, about all she could do was more of what she was already doing.

Like micromanagement, motherly management can work when its underlying assumptions are true and the problem and solution aren?t too complex. Trouble is, most software development shops aren?t day care centers, and most development is non-routine and requires that a lot of conflicts be resolved. Interfaces, partitioning, decomposition, protocols?these are all ?left turns? in the view of a motherly manager, who must personally make sure that everybody plays well together. This creates a structural problem similar to micromanagement. Similar, but also different. Since some work can take place independently under motherly management, the manager is less of a choke point than in the case of micromanagement.

But because the process is still highly manager-centric, the actual amount of work that can be done in parallel is often less than expected. We end up with a process that?s very nearly effective: almost parallel, relatively observant, and coming awfully close to giving workers independent responsibility:

Parallel (almost) Only pre-defined ?routine? things can take place in parallel. As long as traffic went straight ahead or turned right, Aunt Bea?s plan seemed to work. But she couldn?t predict how many people would want to turn left. When lots of people started turning left, her plan fell apart. In the same way, the actual performance of a motherly-managed software project depends heavily on just how much of the development is really ?routine? with no need for interactions or conflict resolution. If there are a lot more ?exceptions? than expected, a lot of developers working in parallel according to the project plan may be sitting on their hands waiting for the manager to make a decision. This can make a project plan that was parallel in theory become serial in practice.

Myopic Motherly managers make more observations than micromanagers, but they still confine those observations to specific conditions noted in the project plan. If the conditions defined by the manager are in fact not the key exceptions that need to be managed, the motherly manager will be spending time and energy observing the wrong thing, while missing the observations that are really necessary for project success.

Nannying Motherly management can be less oppressive than micromanagement for the people being managed, because the ?mother? allows her ?children? to do a few things on their own. The individual developers can go ahead as long as they aren?t going against the flow or getting into conflicts. But at the first indication that something non-standard is going on, the whole process stops until the manager decides what to do. The manager must handle all the decisions that really matter?and this squelches the individual contribution to solving the overall problem just about as effectively as micromanagement. There is a great deal of variation here?a manager who views the employees as teenagers is less openly controlling than one who views them as toddlers. Still, most of the people who work in the software business have college degrees, and we wonder if we?re making the best use of their expensive educations when we manage them as though they were children.

If we are going to find a style that?s more efficient and effective than micro and motherly, we must start by changing our underlying assumptions. Barney sees the people being managed as machines to be programmed; Bea sees them as children to be helped. Now let?s see what happens when Andy views them as adult human beings.

Masterly Management

Andy took an approach that at first didn?t look like ?management? at all. He just sat in his chair, sipping lemonade and watching traffic on the Highway 52 off-ramp. When it started backing up badly, he strolled out into the intersection, stopped traffic on Key Street, and let the off-ramp clear; then he went back to his lemonade. He seemed to be ?working? a lot less than Barney or Aunt Bee, yet traffic flowed smoothly. We refer to Andy?s style as masterly management ? because of our three traffic controllers, only he was truly the master of the situation.

The keys to Andy?s management style were his underlying assumptions: that drivers are adults, that most of the time they can take care of themselves, and that his role as a manager is to support these competent adults so they can do the real work of getting themselves safely through the intersection. This is vastly different from Barney?s and Aunt Bea?s assumption. Andy felt secure enough about his own competence and the drivers? know-how that he could remove himself from the center of the job.

Because Andy did not place himself at the center of the management task, he could be much more flexible and effective at the key management activities:

1. Andy saw the problem to be solved as moving traffic efficiently and safely through the intersection. He also realized that most of the time this intersection didn?t need any help; people made turns here every day without any supervision. What made this a unique problem that might require some management intervention? The detour increased traffic on the Highway 52 off-ramp, and that might, on occasion, cause traffic on the ramp to back up onto the highway and cause a safety hazard. Notice the difference?while Barney and Aunt Bea defined the problem in terms of what they had to do, Andy defined the problem in terms of results, independent of who actually ?did the work.? By doing this, Andy positioned himself to observe and “steer” the system that did work, rather than as the person doing the work.

2. With his understanding of the real problem to be solved, Andy was able to construct an effective plan for its solution. The drivers could be responsible for getting themselves through the intersection. He and his ?management team? would monitor the off-ramp and make sure that it could be emptied when (and if) it backed up far enough to pose a safety hazard. While Barney might accuse Andy of not having much of a plan, the fact is that Andy?s simple-looking plan actually allowed some very complex things to happen. Because he didn?t attempt to control low-level actions by the drivers, Andy?s plan delegated management work to individual drivers. This allowed them to operate in parallel, which they did?drivers waiting to turn left off the ramp took advantage of gaps in traffic created by drivers turning right.

3. Now that he had both a problem statement and a plan, Andy could identify which observations he needed to make. To keep traffic from backing up onto Highway 52, he had to watch the ramp?not the intersection. So he positioned himself off to the side, where he could see the ramp. This is another critical difference in Andy?s style. Standing in the middle of the intersection, Barney and Aunt Bea were taking in a great deal of information?most of it irrelevant to solving the real problem. They weren?t in the right place to make the observations that really matter. Of course, Andy didn?t ignore what was happening in the intersection?but he didn?t make the intersection his primary focus.

4. Andy?s management style used two process models. First, if traffic?s backing up on the off-ramp, stop traffic on Key Street and allow the ramp to drain. Second, if something blocks the intersection, get it out of the way immediately. The rest of the time, Andy?s process model says ?let the drivers take care of themselves.?

Both of these models are more subtle than they look. The first model allows Andy to do some fine-tuning as the morning progresses. How far up the ramp is ?too far? for traffic to back up? At first he took a conservative approach, draining the ramp when it was backed up about halfway to the highway. Later, after observing how quickly Key Street traffic could be stopped to drain the ramp, he changed his definition of ?too far? to something more like three-quarters of the way up the ramp. This meant even fewer interventions were needed, because often traffic would back up to the halfway point and then drain back down by itself.

The second model contains a flexible definition of just what triggers action. Andy?s looking for a symptom, which could have a variety of root causes. If something blocks the intersection (e.g., a driver too timid to turn left), Andy?s model will handle it.

5. Finally, Andy took a lot less ?overt? action than either Barney or Aunt Bea. Most of the time it appeared that he was doing nothing at all. Yet, when action was required, he knew what action was appropriate and effective. But it would be wrong to say that Andy?s actions were simpler than Barney?s or Aunt Bea?s. In fact, his infrequent interventions required more skill. After all, Barney and Aunt Bea were already standing in the middle of the intersection, and had the drivers? complete attention. Andy had to enter an intersection full of moving vehicles, get the drivers? attention, temporarily interrupt their self-management, get the drivers to carry out his instructions, and finally re-establish the self-managing system. This is a task requiring some skill.

Like the other two styles we?ve discussed, masterly management works when its underlying assumptions are valid. In software development, where the people being managed are skilled, competent, educated adults, these assumptions are usually true.† Masterly management, therefore, addresses the structural and behavioral problems we saw with micro and motherly management:

The delegation inherent in the plan means that most contentions and minor conflicts get solved without the manager?s intervention, so most of the time the people aren?t waiting for the manager?s attention. When a problem does require the manager?s attention, that problem doesn?t have to wait in line behind a bunch of minor conflicts.

This support for parallel activities means that masterly management can work with projects that are just too complicated to be understood in all their detail by a single manager?and most software projects would fall into that category.

Because the people being managed are also delegated a self-management job, they are able to contribute observations that a micro or motherly manager is likely to miss.

Masterly management involves managing the project rather than the individuals. Most of the time, the people doing the work are free to pick their own methods within some basic guidelines (for instance, driving on the correct side of the road, or using the corporate standard tool set). This allows creative energy that might otherwise be spent on finding ways to ?beat the system? to instead go toward creating profitable products.

In short, a masterly manager like Andy observes and steers a system. If the problem is well understood, the plan is appropriate, and the people doing the work are competent, the controller often doesn?t need to do much. Unlike micro and motherly managers, masterly managers spend most of their time in observation and thought rather than in frantic activity. But don?t be fooled?when Andy was sitting in his chair sipping lemonade, he was more effectively in control of the situation than either Barney or Aunt Bea.

If masterly management is so good, why don?t we see it more often? Because in some ways it?s unsettling, especially for the manager:

Looks can be deceiving Masterly managed projects often give a certain appearance of chaos. When Andy managed the intersection, traffic was turning every which way, which was disturbing compared to the neat and orderly behavior when Barney was in charge. However, more traffic moved through the intersection, and did so more safely, under Andy?s chaotic-looking management style. Many software projects already look like chaos. Will going to masterly management make them more so? We doubt it; we suspect that much of the apparent chaos in software development comes from resistance to micro and motherly management.

Power is as power does Masterly management requires a different mindset. Most people associate the word manager with the word power. Yet moving from micromanagement to masterly management involves giving up much of the apparent power and authority of the managerial position, and giving it to the people being managed. The masterly manager has more real power, according to writer Barry Oshry (quoted in Weinberg?s book Becoming a Technical Leader), if we define power as the ability ?to act in ways which enhance the capacity of our systems to thrive and develop in their environment.?

Measuring what counts In some organizations (particularly those where micromanagement is the rule), a masterly manager may have a hard time getting promoted. After all, you won?t be doing much visible managing compared to the micro and motherly managers around you, and it will be easy for the micromanager who makes promotion decisions to conclude that the project succeeded in spite of your ?inaction,? not because of it.

But masterly management also has rewards. Masterly managers often don?t have to work as frantically as micro and motherly managers. As a masterly manager, you?re less likely to find yourself in the office at three in the morning, trying to resolve yet another trivial issue. And you?ll get the satisfaction of knowing that you?re truly an effective leader when the project team says, ?We did this ourselves.?

Micro, Motherly, or Masterly Management

The best way to determine your management style is to ask questions and observe what is happening.

Do the people reporting to you scatter like leaves in the wind when you show up? Do you feel like they are performing to the letter of the law and not the spirit? Do you jump in and start coding when there is a problem? If so, you?re probably micromanaging.

Do you organize workflow for a minimum of interaction so things go smoothly in the team? Do you step in and try to make everything all right for everybody? In crunch mode, do you revert to micromanaging? Your heart may be in the right place, but you may be in motherly managing mode.

Do you spend a fair amount of time observing what is happening, thinking about the impact the events will have on your team and project, and planning what to do? If so, you may be masterly managing.

If you would like to change your management style, there are some important questions to think about. First, how did you come to have your current management style? For most of us, the way we manage is influenced by the people who?ve managed us, and by the environment in which we manage. Acknowledging these influences, and the constraints of your current work situation, may help you determine whether it?s time for new models. It?s important, too, to examine how you feel about your style. If you?re happy with the status quo, change may not be necessary. But if you feel overworked, and seem to be constantly fighting fires, then maybe a change is in order.

And finally, what would you like to have happen? We saw that Barney, Bea, and Andy?s view of the ?problem at hand? shaped their unique responses, and the same is true for you. Once you know what you would like to have happen, you can create and implement the plans that will allow you to achieve your goals and keep your traffic running smoothly.