Steve Smith's Being Effective

Gandhi and Change Agents

Fri, 14 Aug 2009 11:49:36 +0100

Mahatma Gandhi epitomizes the effective change agent. In my opinion, he was not only the Twentieth Century's greatest change agent but also its greatest leader.

Are you looking for change agents in your organization? Let's explore desirable qualities for change agents exemplified by Gandhi.

He believed in the Hindu religion, which, from what I understand, holds the belief that a person's moral actions in this life affect their fortunes in this life and the next. He also believed in Dharma -- living a purposeful life. So look for change agents who have demonstrated their belief in ethics and purposefulness.

He was educated as a lawyer in a system of rules that were different than the rules of culture that reared him. He learned how to use these outside rules in creative ways to achieve purposes that the powerful outsiders didn't anticipate. So look for change agents who know the unwritten rules of the organization and how to use them to nurture change.

He expected a better system than the unjust system he was living in. Gandhi saw the effects of the system (ruling culture) and he found them unacceptable. So look for change agents who expect the system to be better than it is.

He had charisma and was a skilled-communicator. He was able to attract people to his cause through his personality, ideas and communication skills. So look for change agents who people like being near and listening to.

He was provocative. Change require shaking up the status quo and creating a period of chaos (model transformation). Gandhi excelled at non-violent shaking. So look for change agents who know how to constructively shake things up.

He was a brilliant negotiator. He knew how to quell disturbances by unorthodox methods, such as hunger strikes. So look for changes agents who are creative negotiators.

He allied with others. The movement he led wasn't purely Gandhi's. He allied with many people to bring about change. So look for change agents who know how to ally with other people.

Ethics, purposefulness, education, high-expectations, charisma, communication skills, provocative, negotiator and ally are qualities to look for in change agents. I doubt whether you have a Gandhi in your organization. Does a change agent need all of Gandhi's qualities to be effective? No. The stronger they are in the qualities that your organization will respond to, the more effective they will be.

Segment Your Audience

Mon, 03 Aug 2009 11:55:01 +0100

Tips for managers who speak to large audiences about change.

1. Know your audience

The members of your audience aren't like you. They don't think like you. They don't act like you. They are a mix of people who have different roles. They like to know that you are aware of them and their role so amplify your message by speaking directly to segments of the audience that have the same role.

2. Explain why the change is necessary

The most powerful messages I've heard share the impact on the audience members if the change does not happen. Use the audience segments to focus your message and speak to the impact on each segment and the audience as a whole. This message is more important than the analysis of how you came to the conclusion that change was necessary.

3. Ask each audience segment for specific actions

You can do a lot better than sharing broad generalities about better communication. Everyone already knows that. Share specific actions you desire from each audience segment. That message will increase the signal to noise ratio of your message a hundred times over generalizations. For instance, sales, I need you to query our customers about X and email that information to your managers; project managers, I need you to start providing information about cost on your status reports; support, I need you to reduce the number of calls required to answer a client's question.

4. Share the information you will use to make adjustments

Change doesn't move in a straight line from reality to desire. That only happens in someone's imagination. The change will require course corrections. Share the feedback information with the audience as a whole that you will use as a basis for making those corrections.

5. Ask for suggestions from audience members about other actions

Your view is from the top. Members of each segment will know about important actions that will help the change happen. Empower them to work with their management to make them happen.

Imagine you were in the audience: Wouldn't you like someone to connect with you and your role. It takes some practice but you can connect with audience members, which is the prerequisite for creating the motivation for someone to want to follow your lead.

The spark for this post came from Steve Roesler's post I'll Change If You Tell Me What You Really Want. You can see my first thoughts on this topic in the comment section.

Appeal with Emotion, Confirm with Logic

Fri, 31 Jul 2009 08:21:16 +0100

A friend shook me up yesterday when he asked me, "Do you appeal to potential customers using emotion or logic?"

I wanted to say both. But @#$!, the true answer was logic.

Logic is a good thing. But when people make decisions, emotion trumps logic.

What makes the heart pump faster for organizational decision makers?

Three compulsions stand out for me -- the desire for power; the desire for money; and the desire for recognition.

Power determines who gets to tell whom what to do. The more people you get to tell what to do, the more power you have. It's the desire to become the alpha dog. It's the desire to continue being the alpha dog. Some people seek it more, a lot more, than other people. Think Andrew Carnegie, Henry Ford, and Jack Welch. Anything that a service will do to advance this desire, the stronger its emotional appeal.

Money determines who is the most valuable. The more you make, the more valuable you are. It's the desire to make the most money. It's how some people score the game. When the character Little Caesar retorts, "Nothing is more important than the green," in Barry Levinson's movie Sleepers, he is revealing this compulsion. Anything that a service will do to increase the score, the stronger its emotional appeal.

Recognition determines who is the most revered. The more the person is called to be on stage, the more the reverence. Think of Donald Trump. These people want to be seen. "Look at me," is their mantra. Anything that a service will do to cause them to be called on stage, the stronger its emotional appeal.

These compulsions are neither good nor bad. They just are. They can be used for good purposes and bad.

By keeping these compulsions in mind, I can make my services more appealing to decision makers. And you can consider them when you are asking management to make a decision.

The logic I already have is still important. But I'll use it for confirmation rather than appeal.

The Target Law

Mon, 20 Jul 2009 12:32:18 +0100

Have you ever had trouble finding something and needed assistance?

I have. Let me share a discovery about finding things that I made last week.

I was shopping at Target* for some last minute items before taking an eleven mile hike to an alpine lake. I needed Ibuprofen and a Cliff Bar. I was able to locate the Ibuprofen quickly. It was in the aisle labeled pain relievers. But I couldn't find the Cliff Bar.

I only had a few minutes and Target is a large store so I asked a clerk named Eugene, "Would you help me locate Cliff bars, please?"

Eugene said, They are in the the middle of aisle 6A."

He started walking toward the aisle, which was 100 feet from where we were standing, "Thank you, Eugene. Please keep doing whatever you were doing. I'll find it."

Eugene replied, "Thank you. If you need more help, please come back."

I went to aisle 6A and the Cliff bars were exactly in the middle of the aisle. "Bingo," I thought to myself.

I was ahead of schedule. That relief may have caused my mind to access a couple more items that I wanted. I spotted my new buddy Eugene and glided over and asked him, "Eugene, where can I find Backwoods Off?"

He said, "It's nearby, let me walk you over."

I followed him over a few aisles and there it was on the top shelf. I quickly grabbed it thinking about the mosquito bites that I wouldn't have to endure when I reached the lake.

"Thank you. One more item, Eugene, and I'm good to go. Someone told me about a trail mix that you carry. Where would I find it?"

"I'm not sure. It might be near sporting goods. Let's walk over there."

We walked about 50 feet. Eugene pointed me at a large display of plastic bags loaded with various nuts, chocolates and dried fruit concoctions and asked, "Is that what you are looking for?"

"That's it, Eugene. Thank you. You've been a great help."

"You are welcome," Eugene said smiling as he turned and strolled away.

I headed toward the cash register feeling good because I was way ahead of schedule. I started thinking about the process.

When I knew exactly what I wanted, Eugene told me exactly where to find it. When I gave him a general idea of what I wanted, Eugene could get me in the general area. If I hadn't have recalled that I wanted the trail mix, Eugene wouldn't have been able to help me.

That's when I had an epiphany --

The more precisely you can tell someone what you want, the more precisely they can tell you where to find it.

I started thinking about the implications. And I realized something even more important, which I'll call the Target Law --

If you can't tell someone what you want, no one can help you find it.

It behooves anyone who wants something added to their life to take the time to articulate as precisely as possible what it is that they want (the target). You are much closer to being able to find it yourself or finding someone, like Eugene, who can help you find it.

What happens if you can only poorly articulate your desires? You've learned something. You've uncovered the desire to better articulate what it is that you want. Someone can help you articulate your desires better when you ask for that kind of help.

*Target is a discount-store chain that has 1,600 stores in the U.S.

Manager is Junior Engineering

Fri, 17 Jul 2009 12:07:52 +0100

My friend Mitch was telling me this morning more about how his company was losing hundreds of millions of dollars because they couldn't execute their plans (see my earlier post Key Person Won't Participate). He mentioned that he had a one-on-one meeting with his manager to discuss how his work would drastically alter one-third of their business systems. He probed his manager about how much the next level manager knew about his work.

I was intrigued by the answer Mitch received from his manager -- the next level manager didn't know much about his work because she was too busy working on the creation of forms for a process she was keen on creating.

Forms? What the heck was a second-level manager at a major corporation doing creating forms? The answers were revealing: She liked doing the work; she had done this kind of work earlier in her career; she believed no one else could do it as fast as she could.

Deja vu.

The word recidivism is defined as the tendency of individuals to fall back to earlier undesirable behaviors, especially crime. When that term is used in the criminal justice system, it means the percentage of former prisoners who are rearrested. You quickly find on the Internet that there is a 60% recidivism rate for released prisoners in the United States of America.

There aren't, however, published rates for a similar management tendency -- the propensity of individual managers to revert to an earlier, familiar role. Although this isn't a crime to society, I believe it is a crime to the organization. The reverter consumes the bulk of their time doing an old, familiar role thus, unconsciously, shedding the bulk of their management role. In other words, the manager abandons the bulk of the members of their team.

I use the term Junior Engineering to refer this tendency. I learned the term while consulting at Boeing. People there used it to describe the manager who started engineering and stopped managing. It was a common occurrence, especially with the manager who was new or whose program was in trouble. They tended to return to a familiar role from earlier in their career, which they had received recognition and reward. Rather than working to ensure the overall result by managing strategy, tactics, and people, they worked on completing engineering tasks.

Junior engineering managers behavior was very visible to the Boeing veterans. Some people were empathetic. They realized the manager had confronted a crisis and didn't know how to navigate their way through those stormy seas. But even the empathetic members who work for the manager realized that if the behavior continued, the program they were working on was doomed.

What do I recommend you do if someone in your management chain is junior engineering?

1. Be empathetic to the human being who is coping with a tough situation in the best way they can (for now).

2. Be careful. In many organizations, this behavior is undiscussable. And the undiscussability is undiscussable. If you mention the behavior without wise counsel, you could be hurt badly.

3. Seek wise counsel within your organization. Junior Engineering is common behavior. Others in your organization have experienced it and know what has worked in the past. Find these people and ask them for advice.

4. Seek wise counsel from someone outside your organization. Inside experts know about how things work inside your organization but may not be up to date on how others have effectively dealt with junior engineering outside your organization. An outside experts will offer different approaches to the dealing with the situation. Two experts that immediately come to mind are Esther Derby and Johanna Rothman.

5. If you have a personal relationship with the junior engineering manager, just tell him or her what you see, how it's impacting your work, and what you would like to see changed. Don't think for a second that your personal relationship enables you to skip carefully preparing your message. Write it down. Expect the person to be sensitive. Don't generalize: Keep the scope of the discussion to your work.

6. Seek a job in another part of the organization or outside the organization. If the behavior is stopping you from doing what you seek to do, go to an organization where you can. The junior engineering manager will be eventually discovered, but I've seen managers junior engineer for years before someone above them did something about it. Your energy is precious. If this will interruption will sap that precious energy, leave. Once the energy is lost, you may never be able to regain it.

7. You may choose to accept that the only acceptable solution for you is to cope with the problem rather than try to solve it.

I estimate the junior engineering rate for managers is 33%. Too high? Too Low? What are your thoughts about that estimate?

Key Person Won't Participate

Wed, 15 Jul 2009 18:13:33 +0100

Unable to gain the participation of a key person for a project retrospective?

A retrospective, sometime called a post-mortem or lessons learned session, is an event designed to discover and preserve the aspects of a project that were managed well; and discover and change the aspects that weren't. I consider this event a fundamental feedback mechanism for a learning organization.

My friend Mitch is a case in point. He won't show up for a retrospective.

Mitch builds business software infrastructure. For more than a decade, he has been doing this job for the same IT organization. The company that employs him is huge. Its business is complex. Its executives are demanding. Its systems must scale. But the investments in business software infrastructure consistently fail. And the failures disappear from view.

We're talking about the squandering of hundreds of millions of dollars. You would think that magnitude of failure would have everyone's attention, especially those demanding executives. Not so. According to Mitch, elaborate stories are constructed to explain the failures and important people invoke the magic words, "That's water under the bridge," which make the failures disappear.

Mitch clearly sees the failures and would like to do something about them. But he sees retrospectives as an equally large failure. When he looks back on the his participation in retrospectives for failed projects, he sees a consistent pattern. Each retrospective would find that a root cause for the failure was insufficient or inadequate sponsorship. And in every case, nothing ever happened to improve project sponsorship.

The past. Each project team reaches an organizational river that they cannot cross without additional resources. They need a bridge built because the river is wide, fast and rocky. No sponsor exists, however, with the power to authorize its construction.

The project team valiantly goes into the forest, cuts down trees, and lashes them together to create a makeshift raft. They try to cross the river at the exact point where they wanted the bridge built. Like a scene from a Western movie, the raft crashes into the rocks, the contents scatter and tumble downstream.

The exhausted members struggle to shore. They eventually reconnect. They realize the project is dead. Someone suggests a retrospective.

The present. You are organizing the retrospective. As you send a meeting request to the members of the team, you tug at your ear attempting to release the water trapped inside.

Mitch receives the meeting request. He thinks to himself, "It's best to not make a big thing about this. I'll tell her what she wants to hear. But I'm not going." He clicks "Accept."

You see Mitch's acceptance. You recall an earlier retrospective where Mitch hadn't participated. You remember he accepted that meeting request too. And you also recall that there were a few others who behaved the same way.

What can you do to gain Mitch's participation in this retrospective? I suggest the following strategy:

0. Review the results from previous retrospectives. What should have resulted but didn't? Explicitly redesign the retrospective to address those deficiencies. A design element to show that this time will be different is to bring in an outside facilitator to lead the event.

1. Gain the sponsorship of someone who has the power to do something with the results of the retrospective. Show this change by adding an agenda item for the team to share its findings with the sponsor at the end of the retrospective.

2. Make time for a face-to-face discussions with Mitch and all participants before the retrospective.

3. Ask each person, "What could prevent you from being fully present during the retrospective?"

4. Be willing to make adjustment, such as rescheduling or changing more elements of the design, to ensure the highest level of participation.

5. Review the retrospectives objectives and agenda with each person. Highlight the differences between this retrospectives and earlier events.

6. Ask each person for suggestions about what would make the retrospective even better for them. Consider them and change the design accordingly.

7. Remind each person that if the team wants things to change it must show the data, its meaning and significance in ways that will compel the sponsor to respond. Ask them to find relevant data and bring it with them to the retrospective.

8. Ask each person, "Is there anything that I should have asked you that I didn't?" For anything mentioned, asked them how they would answer their own question.

9. Tell each person how important their participation is to you personally.

10. Say, "Thank you."

Let's assume that Mitch is right about the root cause of the problem. What better venue is there for gaining sponsorship for the next project than a project retrospective? But breaking this kind of viscous cycle is always difficult.

Gaining sponsorship is more than having someone listen to the findings and recommendations. Success hinges on creating superb findings with data that backs them up and connecting them with the personal success of the sponsor. The more things that personally connect with the sponsor, the more likely that that person will be to take action on the recommendations.

Any attempt to force Mitch to participate is stupid and counterproductive. You may be able to force his body into a chair, but he doesn't have to bring his mind. Your best chance is through showing him that this retrospective will succeed and trigger action. So ensure that the person who agrees to be the sponsor will take action when presented with a compelling business case. Otherwise, cancel the retrospective because it will waste your time and everyone else's.

Tradeoff: Go For Quality

Thu, 22 May 2008 02:00:00 +0100

What typically happens when product development decides to create a superior product? Answer, slower delivery and costlier development than previous products. Why?

You don't get something for nothing.

Producing a higher quality product takes more development time, which delays delivery to the customer and drives up development costs. For instance, if you buy tailor made clothing, you receive a superior product. But the garment will cost you much more than off the rack clothing and you will typically wait weeks before you can wear the item. It simply takes more time for a tailor to create the customized garment. And that time and expertise increases the cost and delays the delivery.

This triangular relationship is a general law of development. Increase one of the variables -- quality, speed, or economy -- and one or both of the other two variables decreases. Every decision about these variables is a decision that involves making a trade-off.

Beware of the typical reaction of management to compensate for this effect by adding more people to the project, especially when the people are added late. This action may elongate the delivery rather than shorten it.

Unless changes are made to the development process and those changes work as planned, I suggest you make sure that your customer believes in the value you intend to produce. Don't lose the customer you are trying to please. Negotiate a scorecard with your customer to assess the value of your product plans rather than assuming you know. Development cost and speed are part of that scorecard.

Tell Me What You Want Me To Do

Tue, 15 Apr 2008 12:51:24 +0100

Are you overwhelmed by a mountain of email?

I suggest you take a page out of the playbook of my colleague Eric Sperley who knows how to ask for what he wants.

Eric sent the following message to the people who reported to him:

Guys,

Look, I am getting well over 250 emails a day. I can get 10-20 a day from each of you where I am just cc'd. I already have 71 email messages just this morning. I also get a ton of messages from the PMO, BSP's, and on and on. I am very concerned that I/You don't miss something important.

I may be missing something. If I am, please let me know. Otherwise, let us tighten this operation up a bit.

If I get an email from you, I should be on the To... line. I see no reason why I need to be on the Cc... line. Your email should say:

1) Eric, I need you to: (Tell me what you need me to do.)

2) Eric, you need to be aware of the following situation: (Summarize the situation and tell me why I need to know, i.e. history, risks, and what you think I need to do.)

3) Eric, I have a question: (State your question)

I will attempt to do the same. I will ask other teams to do the same. I do realize that teams do need to post status, but that is a different type of communication all together.

What do you think? If we could get everyone in the company to do this, we could free up a couple of hours a day of reading email.

Thanks,
Eric

This message was highly effective. It reduced the number of emails Eric and the members of his team received. And when someone received a message they understood what was being asked of them. The sender told them clearly either what they wanted them to do, what they wanted them to know, or what question they needed them to answer.

Messages like this from people whose opinion count the most in organizations would eliminate the deluge of worthless emails received by people in organization after organization. This simple message starts a revolution to improve communication. My, oh my, imagine that, you receive less messages and the messages you do receive are meaningful! That's something worth asking for.

You can start a communication revolution in your company -- ask for what you want -- send a message like Eric's now.

A Wild Horse Called Chaos

Mon, 14 Apr 2008 10:02:37 +0100

Is chaos like a wild horse?

The root for the word "manage" is an Italian word that means "to train a horse."

Inhumane horse trainers (managers) see a rebellious animal who must adjust to a new environment. They transform the horse through a process they call "breaking." They break the will of the horse so it submits to the will of the human. Their methods may include:

Saddling and riding the horse until its will is broken
Tying the saddled horse to a tree until it ceases to struggle
Drowning the horse until it submits

Humane horse managers see a frightened animal who can adjust to a new environment. They transform the horse through a process they call "gentling." The horse is led to trust human beings. Their methods include:

Observing the horse carefully
Familiarizing the horse gradually with the saddle and additional weight
Securing the horse's willing agreement

If a people manager sees chaos as rebellious, they may resort to tactics similar to a inhumane horse trainers. They may try to break the will of the people in the organization. That makes the surface of the organization look smooth, but underneath it's churning with fear and anger.

Effective organizational leaders, in my experience, see chaos as a period of adjustment. A time when things that were working have broke down and need renewal. A time when things can be reassembled in creative ways to respond to the disturbance between the organization and its environment. For instance, when the organization doesn't make its revenue goals for two consecutive quarters.

Leaders realize the things can't be recreated until the impacted individuals discover their own transformational ideas for how to respond so that it benefits themselves and the organization. They give people the time and space to respond willingly.

This is not some touchy feely nonsense. Would you rather own a horse that was gentled or a horse that was broken? I'll take the horse that was gentled every time. I want a partner rather than a servant.

Some people believe that a leader who is kind can't be firm. I guarantee you that a humane horse trainer is firm. You can manage horses and people both kindly and firmly.

Chaos doesn't have to be interpreted as a rebellion. If it's interpreted positively, as a signal that the organization is adjusting to it's environment, there will be more opportunities for growth and positive change

I suggest following the lead of humane horse trainers -- transform chaos through gentling rather than breaking.

Catch Them Doing It Right

Wed, 02 Jan 2008 10:02:37 +0100

Rewards can be powerful management tools, but only if you implement them effectively. Discover how the right timing and getting to know your employees better can improve the impact of your recognition methods.

My article Catch Them Doing It Right was published in the January, 2008 issue of Better Software Magazine. Check out a copy of the article on stickyminds.com by clicking here.

Ban Crackberries from Meetings?

Tue, 04 Dec 2007 18:13:26 +0100

Todd Wilkens advocates banning crackberries from all meetings. I agree with Todd that people distracted by emails and phone calls aren't focused and become impediments to an effective meeting. But, in my experience, too many organizations have terribly ineffective meetings. If your organization's meetings are terrible, will a ban on crackberries make them effective?

No.

A pattern of consistently terrible meetings is the result of a sick organizational process. Banning distracting devices will, at best, lead to a less terrible meeting. At worst, it will lead to angry people who believe they are being treated like children. Banning crackberries and laptops does not guarantee more focused participants; for instance, eavesdrop on the thoughts of Bryan:

Who they hell do they think they are banning my wireless devices? I'm at this meeting to listen and occasionally answer a few questions. Most of the time the stuff they are saying has nothing to do with me. Why shouldn't I be able to process my email so my time is used efficiently? Dumb asses! I've got things to do. I'll write emails on my notepad and transcribe them to Outlook as soon as I'm released from this prison. Everyone will think I'm taking notes about the meeting. :-)

A pattern of consistently effective meetings is the result of a healthy organizational process. Leaders in these organizations design their meetings. They define its purpose, objectives, participants, and agenda. They use the meeting's type as a pattern for focusing and organizing the meeting. They invite only the people who are needed and who will receive an ROI from participating. They treat the participants like adults. They have a process for each agenda item that helps the group produce the desired outcome. They share information about the meeting in advance so that participants are prepared before the meeting starts.They start the meeting on time. They manage the meeting so it finishes early or on time. They collect and use feedback to constantly improve their meetings.

A ban on crackberries is neither needed nor desired in organizations with highly effective meetings. Participants are engaged in a highly interactive meeting. Participation has value to the participant as an individual, as a member of a team, and as a member of the organization. Participants neither have the time nor desire to use their wireless devices. If they must take an interrupt, which they don't make a habit, they alert the group to that need and process interrupts outside the meeting room.

I'm sure it's difficult for people who haven't had a positive experience with meetings to believe a consistently effective meeting is possible. It's not only possible -- it's a reality in organizations who believe that meetings are the lifeblood of their business. It's also a reality under the wing of a strong leader who decides that meetings in their part of the organization will be conducted differently.

If you aren't fortunate enough to be a part of an organization with consistently effective meetings, engage in guerrilla actions to help create highly effective meetings. Start by buying a copy of How to Make Meetings Work by Michael Doyle and David Strauss and put what you read to use.

If your organization wants to heal a sick process that is producing terrible meetings, contact me. I will help.

The Recipe for an Effective Proposal

Fri, 30 Nov 2007 17:08:12 +0100

Does management reject your ideas? A typical cause for rejection is a failure to frame the idea effectively. Frame your idea effectively and it becomes a proposal, which will demand consideration by management. What is the recipe and key ingredients for an effective proposal?

The key ingredients are X (the idea), Y (the benefits), and Z (the cost of doing nothing). The following shows the recipe that turns an idea into a proposal:

If you do X, you will get Y.

Otherwise (if you do nothing) it will cost you Z.

Do I have your approval to do X?

Is that exactly what you should say to management? No, of course not. I designed the recipe and ingredients to help you spot a missing ingredient or portion of the frame. For instance, uneducated proposers typically fail to explicitly ask management for approval to do X.

For instance, David believes his company should buy software to track trouble tickets and issues. David talks to Ruth, his manager, about his idea.

David: Ruth, I think we should buy the ABC software to track trouble tickets and issues.

Ruth: I don't have budget for that.

David: But we can't make sense of what we are hearing from our testers and clients.

Ruth: No, now is not the time.

David: @#!~

David has articulated X but he is missing Y and Z. And he hasn't asked Ruth to do anything. Using the simplest version of the recipe, the conversation could be transformed to:

David: Ruth, if you approved the purchase of the ABC software to track trouble tickets and issues, you could justify to Stan (Ruth's manager) the additional people you want to hire by giving him unequivocal information about our clients and testers opinions about problems with our product. If we continue to be unable to clearly articulate the problems with our product, we will continue ineffectively prioritizing the use of our people.

Ruth: We don't have the budget for it.

David: Do we have the budget for continuing to do business as usual?

Ruth: @#!~

David: Do I have your approval to buy the ABC software?

Ruth: Let me think about it.

David: When should I check back with you?

Ruth: Friday.

Did David get what he wanted? No. But he is much closer than the first conversation. If Ruth says "No," he can appeal to Stan. If he appeals, David will want to change Y (the benefits) so they resonate with Stan. As you move up the management chain, its often important to articulate the benefits in economic terms.

The same recipe and ingredients applies to making a proposal to anyone, such as a teammate or client. Focus the benefits (Y) so they resonate with the other person.

I lead a terrific workshop on this topic. Read Chris Kay's feedback about the workshop. Please contact me about brining the workshop to your organization.

We Know Best

Fri, 28 Sep 2007 12:22:20 +0100

"We know better than they do about what's needed." Whenever you hear an influential member of your team utter those words, fasten your safety belt. The team is nearing the Twilight Zone.

The person saying, "We know better than they do about what's needed," is referring to the customer.

When decision-makers say "We don't have time for their feedback--we'll get it during the Beta," welcome to the Twilight Zone. The time period during which the development team completely severs its communication link with the customer.

It's costly to stop talking to your customer. And it's especially costly when the product's foundation is being poured. Failures during the Beta will reveal some of the design faults in the foundation. But discovery happens after substantial parts rest upon the foundation.

Propping up and repairing the foundation is, at best, difficult and costly. At worst, the foundation can't be repaired, which means:

starting over;
terminating the product; or
working around the cracks throughout the life of the product.

Why do decision-makers choose to sever communication with the customer? My experience is that decision-makers don't believe they will receive the results they need from the development process. Possible reasons include misunderstandings about the process and lacking faith in it.

Misunderstandings can be cleared up and faith restored through process renewal, which will also renew the organization and its individuals.

Renewal requires changing the organization's status quo so it can become more effective. Shouldn't that happen naturally? In some organizations it does. But in most organizations, it's an unnatural act so engaging outside help increases the success of renewal efforts.

Outsiders can see the obvious that people inside the organization who are wedded to the status quo can't. And an outside coach has tools for working through the inevitable resistance that bogs down efforts to change things that have become familiar to people in the organization.

Process renewal typically includes many of the following elements:

Creating a safe environment where everyone can contribute
Making the process visible so everyone can explore and improve it
Comparing the visible process with the process of similar organizations that are more effective
Renewing the process by closing the gaps between yours and the more effective organizations
Testing the renewed process by walking through it with the members of the organization
Transforming the process again based on feedback from the walk-through(s)
Running periodic retrospectives to discover the parts of the process that are working and the parts that aren't
Preserving parts that are working; renewing parts that aren't.

If your organization keeps straying into the Twilight Zone, renew your process. Don't buy into statements that imply that the development team knows things better than the customer. They don't. Stay in continuous communication with your customer throughout the development process. Use their feedback to build a solid foundation and reliable structures that don't cost you dearly to rebuild or work around later.

Ingredients for Successful Teamwork

Tue, 04 Sep 2007 23:36:26 +0100

I have had the good fortune to be a member of many successful teams during my career: But my career hasn't been all bliss -- I have also been a member of unsuccessful teams. In my experience, the recipe for the most successful and satisfying team experiences contained ingredients that were ignored by the unsuccessful teams. What ingredients fostered both teamwork and success?

Listening to teammates personal desires
Encouraging teammates to ask for help
Processing the team experience

At the beginning of a project, explore the desires of the members by using the focus questions: "What would you like to have happen for you during this project? Why?" It's a question designed to put the desires of team members on the table for consideration. For instance, a teammate may answer the focus question, "I would like to participate in the architecture work. I'm thinking about becoming an architect."

People who haven't experienced explicitly sharing their personal desires with others may have difficulty answering the questions. They may not trust the process. You can't force them to share their desires so don't try to. But you can lead by example by putting your desires squarely on the table to show them it's okay to share.

The obligation for a teammate is to listen to the desires of another teammate. The team isn't obligated to satisfy a member's desires. I am regularly amazed though by the power an individual gains by articulating what they desire. And how much more helpful I and other teammates can be in helping satisfy those desires when they are visible rather than invisible.

During the project, encourage your teammates to ask for help. Teammates learn it's okay to ask for help by being asked for help so ask them for help. For instance, when I had a family emergency, I asked a teammate to complete one of my tasks. I have found that the following words are particularly powerful, "I need your help." and "I need a favor."

If there is anything that is certain in a project, it's that the members of a team will need help from time to time. Asking for help fosters a healthy interdependence between teammates. And make no mistake about it -- the members of a successful teams are interdependent. If they aren't, it's not much of a team.

At set intervals, process the team's experience using a retrospective. I am astonished by how few teams actually process their experience. If all your team is concerned about is the product, you are abandoning one-half of your team's potential value. Your team's process is also a product.

If you constantly improve the process, it's value to your company will continue to grow. After all, the process used on this project will be the default process for producing the next product. Nurture rather than neglect your process.

When the members of a team can ask for what they want; can ask for help; and can process their shared experience -- the team's recipe contains key ingredients for success.

Rethinking Stand-Up Meetings, Part 2 (Revised)

Mon, 30 Jul 2007 10:49:42 +0100

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?

Rethinking Stand Up Meetings, Part 2 is posted on the Amplifying Your Effectiveness (AYE) Conference web site. It's a major revision of the ideas first posted on my blog under the same title.

Full Time Pay for Half Time Work?

Sun, 22 Jul 2007 22:27:07 +0100

Albert, without fail, has exceeded all of his production objectives for the past five years. He is a top performer who produces high-quality results. Colleagues like him. Clients adore him. But Albert never works more than 20 hours per week. That's less than one-half the amount of time his colleague's work.

Albert receives a compensation package equal or better than his colleagues. He has a single requirement for his manager and his organization, "Don't waste my time." You now control the organization. Would you continue to employ Albert under the same arrangement?

This isn't a trick question: Albert produces in less than 20 hours as much or more than his colleagues do in 40 to 60 hours.

I would continue this arrangement in a heartbeat.

But when I shared these facts with two development managers I respect and asked them whether they would continue the same employment arrangement, they both said, "No."

Whoa...

I was surprised by the development managers' responses. I probed them about their answer. The vagueness of "production objectives" seemed to be a problem. They abhorred the idea of full time pay for what they considered half time work. They also were concerned about the demand that Albert's time not be wasted.

I decided to ask a a different group of managers -- sales managers -- about hiring Albert to be a salesman, a job whose results can be described quantitatively. I shared these facts with 1 second-level sales manager and 2 first-level managers: If your hire Albert as a salesman, you are guaranteed that he will generate at least 105% of his quota but never more than 110% each reporting period; his colleagues will like him; his clients will adore him; but he will never work more than 20 hours per week and he demands that his time not be wasted.

I asked each of them "Would you hire Albert?"

I thought this was a no brainer question for a sales manager, but "No," was the verdict I heard from each of them.

Whoa...

I asked them, "What's preventing you from hiring Albert?" A manager sneered as he said, "The notion of him only working 20 hours per week is insulting and his demand that his time not be wasted is absurd. He is being paid to do what he is told. And think of what he could produce if he worked a regular (40-60) hours. If I can't motivate him to work hard, I don't want him" The creases in my forehead became more pronounced as I said, "But isn't the guarantee of him producing 105% of his quota worth something to you?" "Doesn't matter. I might be able to hire someone who would work more hours and make 200% of his quota," countered a sales manager.

Whoa...

I didn't expect this response. Perhaps I didn't structure the inquiry well or I asked the wrong groups.

Both groups seemed to fixate on the number of hours worked and didn't like Albert demanding that his time not be wasted. Unlike me, neither group was impressed about the guarantee of results.

I like the notion of paying for results that are certain. And Albert's time management is superb so I'll support his demand that his time not be wasted. All other things being equal if Albert, or someone else, can consistently produce the desired results in one-half the amount of time as their colleagues, I am more than willing to pay him at least as much as their colleagues.

How about you?

But Is It Possible?

Wed, 18 Jul 2007 22:59:17 +0100

Your manager, Ellsworth, asks you, "But is it possible?" He wants you to tell him that it is possible for you to satisfy a project milestone despite the argument you presented him for the past five minutes that the milestone was unrealistic.

You feel like you are on the witness stand. Jack McCoy, the character from the Law and Order television series, comes to mind. D.A. McCoy buttons his suit coat and approaches you on the witness stand. He sneers and asks, "Yes or no, Mr. Smith, is it possible to satisfy the milestone."

If everything went perfectly, you could meet the schedule. But in development, you know things never go perfectly.

Ellsworth asked you the same question about a previous project, you replied "Yes." But the required perfection failed to materialize and you were unable to meet the schedule. During your annual performance review, he reminded you that you didn't satisfy the schedule. Despite your reminder about the arguments shared with him that everything would have to go perfectly, he only remembers you saying, "Yes, it's possible." He uses the failure to justify giving you only an average salary increase.

You recall that Suzzanne answered Ellsworth's question with a flat "No." Despite her being right, Ellsworth branded her as someone who wasn't a team player. She told you that Ellsworth rated her performance poorly during her review, which resulted in no raise.

You are facing a double bind, which means you are in jeopardy regardless of whether you answer yes or no.

You could say, "Yes, I estimate there is a 1% chance of satisfying the deadline." But Ellsworth will only hear, "Yes, blah blah blah blah."

Step back and look at what is typically happening in this situation:

Upper management imposes a deadline for delivery. Why? They believe the revenue forecast will be impacted if the schedule isn't met

Working backward from upper management's deadline, middle management (Ellsworth and his colleagues) create a project plan consisting of a series of milestones. Why? They want to gain agreement between themselves about what and when things must happen to satisfy upper management's deadline

You hear about the milestones from your manager. Why? Middle management wants you to buy in to their schedule. An they want a sanity check for an egregious scheduling error they may have missed.

Now ask yourself, what haven't I heard about? You've heard about speed of development. Middle management assumed that costs would be similar to the last development effort. But what you haven't heard is anything about the quality of what you are supposed to deliver.

So another option for answering the question is, "Yes, and the quality of my part of the project will be poor. Ellsworth will again hear, "Yes, blah blah blah blah."

There is another possibility. It's risky; it requires a relationship with someone in upper management; and it requires you to be savvy about your company's business. Use your relationship with someone in upper management to propose an alternative approach for satisfying the revenue objectives of the business.

Ridiculous? Perhaps. But is it possible?

Office Hoteling

Sun, 17 Jun 2007 21:36:58 +0100

What is office hoteling? Why is the practice spreading? What are the unintended consequences of its usage?

Office hoteling changes the traditional model for how office space is used. Rather than assign permanent office space to each employee, hoteling is a system for assigning just-in-time temporary office space to employees. The hoteling systems I've experienced allowed me to reserve a small cubicle somewhere in the office for a single day. These systems ran on a first-come, first-serve basis.

Why is the practice spreading? The financial side of organizations love it. Hoteling minimizes the square footage of the office. The lower the square footage of an office -- the lower the cost to lease the space and the lower the business taxes, which are partially based on square footage.

What are the unintended consequences of this practice? There is less employee interaction and the quality of the interaction is poorer. More employees choose to work from home rather than having to schlep their stuff to the office each day and work in a tiny cube. This change results in lower transportation costs for employees. But it also results in conference calls becoming the primary means of interaction rather than face-to-face interaction.

The winners with hoteling are visitors to the office. When the office space was permanently assigned to employees, they might not be able to find a place in the office to work. With hoteling, my experience is there is always space available.

The losers are management but they don't notice the loss for months or years. In my experience, management retains their permanently assigned offices despite the introduction of hoteling. They don't immediately notice the impact of hoteling; for instance, they fail to notice that employees aren't stopping by their office to alert them about something they've seen or heard.

If your organization is contemplating hoteling, I suggest moving managers from their offices to permanent cubicle space. They will benefit from experiencing the change, which will enable them to take actions to fix problems, rather than merely observing the change to hoteling. Furthermore, I suggest converting all management offices to meeting rooms so more private space is available for employees to meet. Hoteling works best, in my opinion, when abundant areas of private space are available for people to use for meetings. If more meetings are happening in the office, more people will come to the office and that will foster productive, unintended face-to-face interactions.

I believe that face-to-face interaction, when possible, is the most powerful form of interaction. If an organization discourages the employees who live in the same area from going to the office through the practice of hoteling, then it should be prepared to suffer the consequences. The organization will enjoy less expensive office space and suffer through poorer communication and thus lower productivity.

Don't short circuit the ability of employees to interact through the practice of hoteling. If you must hotel because of a financial crisis, increase the amount of your office's private meeting space to facilitate face-to-face interaction.

Rethinking Measurement Concepts, Part 1

Sun, 10 Jun 2007 22:43:04 +0100

What is a measurement?

I would answer a careful observation.

Ponder the following questions as you encounter measurements today:

What observations do you trust?
What observations are you skeptical about?
What observations do you believe are phony?
What observations don't have any value?
What new observations would have value?

Brownfield Software System

Thu, 07 Jun 2007 23:06:02 +0100

The term brownfield site means real property, the expansion, redevelopment, or reuse of which may be complicated by the presence or potential presence of a hazardous substance, pollutant, or contaminant.

Source: U.S. Environmental Protection Agency.

Does the term brownfield software system have merit?

I'm not sure. Let's step back and explore.

I thought my use of the term "brownfield software system" was new, but a quick web search yielded a paper by Janet Lavery and Cornelia Boldyreff who use the term. In their paper, Lavery and Boldyreff say,

"Throughout the UK there are thousands of sites which have been contaminated by previous industrial use, often associated with traditional processes which are now obsolete, which may present a hazard to the general environment, but for which there is a growing requirement for reclamation and redevelopment." This quote was taken from the UK Government Environment Agency web site [1] and refers to land based brownfield sites. It could also refer to the challenges facing the software engineering industry today in transforming legacy systems with their dated software, distributed data, and entrenched business processes into useful, web accessible systems. Unlike the derelict land brownfield sites chosen for reclamation and redevelopment, software brownfield sites are usually functioning systems supporting an ongoing institution or business in its continued existence while not fully supporting or adapting to the changing needs of their user communities.

It seems to me that the Y2K crisis treated software systems similar to how government agencies treat brownfield sites, such as toxic waste dumps, so the concept is growing on me. I'm struggling with whether a maladaptive system is like poison. I think it is. It harms the people who use the system. If the Y2K problems weren't corrected, the brownfield software systems would have harmed people.

Do you think some legacy software systems are like brownfield sites? Post a comment. I would like to know your opinion.

People Act Like Themselves

Wed, 06 Jun 2007 22:59:01 +0100

When you interview for your next job, I recommend analyzing how people treated you during the hiring process.

Why?

The treatment you receive will mirror the treatment you will receive on the job.

For instance, analyze the responsiveness of the people involved in your hiring process. If people were responsive to scheduling appointments and answering your questions, expect that you will receive similar responsiveness working inside the organization. Otherwise, expect the same kind of unresponsiveness that you experienced during the hiring process.

Jason, a colleague and friend, is interviewing for a new job. He told me about his experience interviewing for an IT management position at an insurance company in the Seattle area. A manager inside the organization scheduled an interview with him. But to Jason's surprise, the hiring manager didn't tell him until a few hours before the interview that it would be a phone rather than a face-to-face interview.

Jason must have did well enough during the interview because the manager talked to him about scheduling a series of panel interviews with other managers. Thankfully they were to be face-to-face meetings, but it took three weeks to schedule the meeting. When the meetings finally happened, they consumed Jason's entire day. What was the result of the panel interview? He doesn't know. Although it's been over a month since the interviews, no one has contacted him.

It's not hard for Jason to imagine what it would be like working inside this organization. He doesn't care any longer whether they contact him. He doesn't want to work with the people who interviewed him. Would you?

My experience with the people who do the hiring is they can't help but act like themselves. However they treat you during the hiring process is valuable information about how you will be treated if you decide to work with them. You choose whether you want to continue being treated like you were during the hiring process.

Critical Lesson in Estimation

Tue, 05 Jun 2007 17:04:39 +0100

What critical lesson have I learned about the process of making an estimate?

Have your most pragmatic, experienced people do the estimate.

Minimize the number of people who are members of the estimating team. A team size of three, in my experience, is ideal. That's enough members to trigger divergent estimates, which creates arguments, which leads to better estimates. And it's also a team size that converges without the pain that happens too often with larger teams.

If your organization's management demands that inexperienced people attend the estimation meetings so they learn how to estimate, have each of these attendees wear a baseball hat with Observer labeled on its front panel. Make it clear to the observers that they are only to observe the process rather than to participate. The hats are symbolic and will remind you and them of their role as observers.

Why? Inexperienced people may not know what the don't know, which will slow down the estimation process without increasing the quality of the estimate.

For instance, I was a participant in an exercise at a workshop where we were ask to order estimated times for a series of a kitchen remodel tasks, such as changing the electrical wiring, adding granite countertops, and adding hardwood floors.

A few of us in the group had experience either doing the work or contracting the work. The majority of the people in the group had zero experience, but a few of them didn't want to opt out of the experience. They wanted to learn the process, which was laudable. But by participating, the inexperienced people only slowed down the experienced people. Again and again, I heard, "it shouldn't take that long..."

I felt bad telling the inexperience people they weren't helping, but I it was true. Meaningful participation happens when someone brings something to the table that furthers the process.

Don't ensnare yourself in the web of other people's inexperience. Insist that only pragmatic, experienced people do the estimation task. If you only have a single person with the proper credentials, let him or her make the estimate.

Process Revelation

Mon, 04 Jun 2007 18:44:28 +0100

A participant in a workshop that I led drew the above picture to describe the role he played in his company's process:

Do drawings help members of a team to better reveal their point of view?

In my experience, they do.

But more importantly, the process of drawing with virtually no constraints helps the drawer reveal their point of view to themselves better than when they are required to use prescribed symbols.

A drawing is a channel for conceiving and conveying ideas. Interpreting the picture with words provides the drawer with yet another channel for conceiving and conveying ideas. Increase the number of channels someone uses to describe something and you help them conceive more ideas and increase their ability to successfully communicate them.

A drawing is revelation.

Drawing is used with the permission of a source who wishes to remain anonymous.

The Effective Project Manager

Sun, 03 Jun 2007 22:48:20 +0100

What do effective project managers realize?

If a project fails, it's the PM's fault.

If a project succeeds, the PM credits the team for the success.

People versus Process Orientation

Thu, 31 May 2007 23:24:53 +0100

People have passionately argued about whether people are more important than process or process is more important than people. Tune in; for instance, a colleague writes passionately about the triumph of people over process. Another colleague writes passionately about the importance of heroes. A pundit writes passionately about how great systems (process) are more important than great people. And yet another colleague writes passionately about a method that helps competent people perform better.

I can reveal a lot about my biases by answering the following question: How do I feel about the thought of being employed by a company with a great process?

Threatened.

My first thought is of a totalitarian process that turns me into a gear inside a machine.

I want to be a person who is part of a team of people who use an evolving process rather than a cyborg working with other cyborgs following the rules prescribed by a totalitarian process.

My work experience is there is always someone in a company attracted to the idea of a totalitarian process because it appears to them as the most efficient way to produce something.

Perhaps in some industries there is a "most" efficient method. But in the Information Technology industry,I believe anyone designing the most efficient method for producing our products has a screw loose.Before anyone tries to create the most efficient method, we need to become consistently effective at producing products that please our customers and learn from those experiences. In my opinion, we have a long way to go.

There is a another part of me that likes and believes in process as long as it treats people as humans rather than machines. I have been a member of teams that have had a highly-effective process. It helped me structure my thoughts and feelings and use them to create better products for our customers.

I don't have to feel threated by a company with a great process. I need to investigate whether people who do the process have a say in the process. If they do, it's a worthy company.

It doesn't have to be about people over process orientation. It doesn't have to be great process over great people. People design process. Don't have outsiders design the process for a workgroup. Let the people who do the process design the process. And I gather this action is exactly what some of the best manufacturing companies do. We can learn from them.

Tradeoff: Go For Speed

Wed, 30 May 2007 18:00:56 +0100

The people whose opinion counts the most choose to go for faster delivery speed. Their thinking may be sound; in this case, they want to beat their competitors to market.

Choosing faster product delivery visibly sacrifices product quality and, in my experience, it often invisibly sacrifices the economy of product support. In this post, I answer the following questions:

What is a tradeoff?
What distinguishes a conscious from an unconscious tradeoff?
What is the impact of trading off quality for speed?
What can you do to change the choice?

A tradeoff is an engineering tactic for generating as much value as possible for your customer and your organization when circumstances don't allow you to satisfy every desire. I have yet to experience a development project where everyone's desires could be satisfied so I expect tradeoffs. And I want the choices about tradeoffs to be conscious rather than unconscious.

It's a conscious choice when I know:

What are we getting?
What are we giving up?
Why?

It's an unconscious choice when I or any member of the development team can't find answers to the above questions. And when the answers can't be found, the team is wishing rather than planning for success.

Let's return to the choice of going for delivery speed. In QSM Vol. 4, Jerry Weinberg insightfully points out the triangular relationship between the variables -- product quality, delivery speed, and development economy. In development projects, Weinberg says these variables are locked in a stabilizing feedback loop. A choice to increase any one of the variables will decrease one or both of the other variables.

For instance, if we choose to increase the delivery speed, we decrease product quality or decrease development economy or decrease both of them.

What are we getting? Faster deliver speed.

What are we giving up? Perhaps desired functionality. Perhaps a defect free product. Perhaps employee morale. Perhaps delighting the customer.

Why? Perhaps beating our competitors to market. Perhaps satisfying a big customer who will buy other products if we deliver early. Perhaps winning an industry award.

I don't like all of these answers, but I like that they are explicit. Regardless of whether I like them, they are all legitimate.

When development organizations go for speed, my experience is management rarely focuses on the additional support cost triggered by shipping a product faster. In these companies, development and support were in separate organizations. They each had their own budgets. Development had financial incentives to go fast and that choice had a big impact on support. What can be done about this problem? Create a strong feedback loop back to development. I suggest charging development for support. They won't like it, but the less the number of faults, the less they pay, which puts part of the economic impact of their development choices back on them.

What can you do to change choices? If the tradeoffs are unconscious, provide the team with your interpretation of what the team is getting, giving up, and why. And compare it to a tradeoff that you consider will provide more value. You may be surprised how making things explicit offers an opportunity for management to choose differently.

Reference

Jerry (Gerald M.) Weinberg, Quality Software Management: Volume 4, Anticipating Change, ISBN 0-932633-32-3, pp. 175-192.

Gradient of Agreement

Wed, 16 May 2007 00:17:39 +0100

I'm a big fan of Sam Kaner's Guide to Participatory Decision-Making, ISBN 0-86571-347-2. I highly recommend it to anyone who leads meetings.

In my post on Decide as a Team, I wrote about using a method called Roman Evaluation to reach a decision. Kaner talks about a more formal concept he calls Gradient of Agreement in his book.

I am less enthusiastic about the Gradient of Agreement today than when I was first introduced to it.

Why?

The following table compares Roman Evaluation versus Gradient of Agreement:

Roman Evaluation		Gradient of Agreement
Thumb up	I agree.	Endorsement	I like it.
Thumb Sideways	I will accept the majority's decision and support it.	Endorsement with a Minor Point of Contention	Basically, I like it.
		Agreement with Reservations	I can live with it.
		Abstain	I have no opinion.
		Stand Aside	I don't like this, but I don't want to hold up the group.
		Formal Disagreement but Willing to Go with the Majority	I want my disagreement noted in writing but I'll support the decision.
		Formal Disagreement With Request to be Absolved of Responsibility for Implementation	I don't want to stop anyone else, but I don't want to be in involved in implementing
Thumb Down	I disagree (veto) or I have something to say	Block	I veto this proposal

Although I know the Gradient of Agreement will work, especially with large groups, it seems overly complex to me compared to Roman Evaluation. And Gradient of Agreement has levels (blue font) that seem ambiguous to me. I question whether a participant could support the decision; for instance, it's hard for me to support a proposal which I don't have an opinion; or I don't like; or I disagree with; or I don't want any implementation involvement. I suspect a participant that voted that way would provide, at best, lukewarm support.

I prefer the simplicity and clear meaning that comes from using Roman Evaluation.

Exploring Requirements Podcast

Mon, 14 May 2007 22:32:16 +0100

Last year, my colleague Esther Derby interviewed me about leading requirements workshops for an Amplifying Your Effectiveness (AYE) Conference Podcast.

Esther probed me about my favorite questions to ask workshop participants.

I answered:

What are elements of the problem?
Why (is solving this element important)?
What will happen if you don't solve this element?

To listen to the podcast click here.

Be Ashamed of Your Silence

Sun, 13 May 2007 21:00:35 +0100

Robert, a project manager, told me he uses the weekly project status meeting as a bully pulpit to shame any member of the team who didn't satisfy their task deadlines. I've seen him in action -- his face becomes grotesque as he verbally assaults his teammates.

I believe it's wrong for Rob or anyone else to attempt to shame another person. But it's also wrong for a teammate NOT to satisfy a task deadline.

Is it shameful not to meet a deadline?

Yes.

Attempts by people like Rob to shame me in front of my teammates don't shame me. When I fail to satisfy a task deadline, I'm ashamed of my silence. Nothing prevented me from notifying my teammates that I wasn't going to meet a deadline.

On a functional team, you can notify teammates about deadlines that won't be met; and you can ask teammates for help. The sooner you ask or notify your teammates, the more effective a teammate you become. It may be possible to make the deadline with help from teammates. But that isn't a possibility unless you ask for it.

Your employer may have an unwritten rule (see my post about an impact of corporate culture) that says don't pop the collective fantasy about the schedule by notifying your teammates of an impending delay. Each time you follow the unwritten rule, the more ineffective a teammate you become.

You can choose again. Inappropriate silence hurts every member of the team, especially you. Find a different employer or a different team or a different mindset that enables you to be an effective teammate who can say, "I need help" or "I won't meet that deadline."

An Impact of Corporate Culture

Thu, 10 May 2007 23:04:12 +0100

Project Managers from ABC and XYZ, which are located on the opposite side of the same street, differ in how they report project status: The PMs from ABC are forthright with their sponsors, and the PMs from XYZ are evasive.

Why do the PMs at ABC and XYZ have opposite approaches to reporting status?

Their very survival depends on providing information according to the rules of their corporate culture. The cardinal sin at XYZ is failing to support the fantasy. The cardinal sin at ABC is failing to inform management about changes and their impacts.

Let's explore. Each company has the same number of PMs, and each PM at ABC has an identical twin working at XYZ so their isn't any differences in capability. All the PMs from both companies participate in the same intensive training on risk management.

What's the impact of corporate culture on applying the risk management training? The risk management done by ABC's PMs will be clearly superior to that done by XYZ's.

Why? Let's hear from Tom Demarco and Tim Lister :

It's okay to be wrong, but not okay to be uncertain.
If that rule describes your company, you're sunk.

The rules says you may miss your promised delivery date -- even miss it by a mile -- but in the months and days leading up to that date, you're not allowed to express any doubt that you will indeed deliver on time. Failure is tolerated as long as you don't commit the capital crime of admitting beforehand that you might fail. Another expression of the rule is that you can ask for forgiveness for being late (afterward) but you can't ask for permission (beforehand).

Until the people at XYZ whose opinions count the most recognize the impact of the culture on the work product and seek to change the culture, their investment in training will return only frustrated employees back to the business.

Reference

Tom DeMarco and Tim Lister, Waltzing with Bears: Managing Risk on Software Projects, ISBN 0-932633-60-9, p. 42

Problems: Cope, Manage or Solve?

Wed, 09 May 2007 21:55:56 +0100

When faced with a problem, I suggest considering three strategies:

Coping
Managing
Solving

Let's apply the strategies to the situation where you have a new pet who defecates in your house. You (I hope) don't like poop on the floors of your house.

You could cope with the problem by cleaning up the poop. Your strategy is to deal with the undesirable effects.

You could manage the problem by keeping the dog outside. Your strategy is to tradeoff more time bonding with your dog for eliminating the constant cleanup.

You could solve the problem by training the dog to signal you it needs to go outside to poop. Your strategy is to invest time training the dog to eliminate the problem.

Coping doesn't intervene. It deals with the problem's undesirable effects.

Managing intervenes. It makes a tradeoff and controls the problem's undesirable effects.

Solving eliminates the problem.

Each strategy is effective for a class of problems. I believe all of us cope and manage more problems than we realize. And that's okay.

But if the strategy you are using isn't working, you can choose again.

Consider some of the big problems you face this week.

Which strategy are you using?
Was the strategy intentional?
Would you like to change your strategy?

Be Up Front

Tue, 08 May 2007 23:30:49 +0100

You and Jeff are members of a project team. You've know Jeff for years. You like and respect him. He is new to the team. In what looks to you like an effort to prove his value to the other members of the team he has taken on too many tasks. He isn't completing his high-priority tasks on schedule. And he keeps taking on new tasks.

What do you do?

I suggest you have a one-on-one conversation with Jeff as soon as possible. Tell him about what you have observed. Find out whether you are right. You might not be. But that's less of a problem than suffering a project setback because you didn't act on your observations.

The earlier I detect the problem the easier it is to talk with the other person. When I deny what my senses are telling me, the harder it is for me to have the conversation. I suspect the same is true with many of you.

I might start the conversation by saying "Jeff, you seem to be having trouble completing your tasks. I've noticed that the high-priority task of gathering and analyzing feedback from our clients hasn't been completed. And you took on the task of writing an article for the next issue of IEEE Software, which seem like it will distract you from completing the client feedback study. What's the story?"

If you find yourself talking about the situation with Jeff behind his back or you hear another member talking about Jeff behind his back, I recommend that you immediately bring your observations to both Jeff and the other team members. This is no longer a problem with Jeff -- it's a team problem.

Over commitment is a solvable problem when the team faces it. If Jeff is overcommitted, everyone will suffer the consequences. He may need to hear from the team that it's okay to ask for help. He may need to reprioritize his work. He may need to decommit from tasks. It's up to the team to assess and deal with the problem.

Everyone is on the same train. If you see that the train is about to go off the tracks, stop the train and address the problem.

Elements of Effective Management

Mon, 07 May 2007 22:16:12 +0100

I am fortunate to have worked on a team led by Anne Cawley early in my career. Experience working with her enabled me to know, rather than speculate, about the power of an effective manager.

What elements of her management style made her effective?

Congruence: She conversed with members of her team as equals rather than subordinates.

Hiring: She has a keen insight into people and team dynamics. She hired people who were similar enough that they would bond with the team and yet they were different enough to generate powerful discussion, learning and commitment.

Work Ethic: She led by example. She was always willing to do her share of the work and more.

Meetings: She led our team meetings systematically. She made my previous managers look like amateurs. I never left her meetings feeling my time had been wasted.

Interaction: Despite the members of the team being located in three different continents, we had quarterly face-to-face meetings.

Process: Our group had a process and part of it was to innovation. Our process helped us produce high-quality products on schedule.

Consensus: She worked for consensus. But she didn't abdicate decisions to the team. She considered her vote as important as each member of the team.

Practice: She believed in practice. The group created and delivered lots of presentations to engineering organizations. The practice enabled us to deliver with authority.

Marketing: She assumed the larger organization would not fully see the value of her team. She constantly demonstrated the value of her team to the larger organization.

Fun: She knew that it paid dividends for the team to have fun together. At least once a year, we had events with our spouses at fun places.

Two decades later I still remember many lessons that I learned working with Anne and the other members of the team. Anne created the right results by doing the right things, the right way.

My previous managers taught me what not to do. Anne Cawley taught me what to do. Knowing what to do trumps knowing what not to do every time.

I'm grateful for the opportunity to experience true teamwork led by an amazing leader.

Communication Is Like Breathing

Sun, 06 May 2007 20:45:02 +0100

"Communication is to personal health, satisfactory interpersonal relationships, and productivity as breathing is to life. Effective communication can be both taught and learned. We were not born with the way we communicate. We learned it, mostly through modeling, in ways no one even knew or intended."

--Virginia Satir (family therapy pioneer)

For a tip on breathing better by communicating more effectively, see my post Elements of Effective Communication.

Source for Quote: The Satir Approach to Communication, ISBN 0-8314-0071-4, preface.

Types of Meetings

Thu, 03 May 2007 23:34:46 +0100

There are different types of meetings. Each type requires a different structures and supports a different number of participants. For instance, a status (feedforward) meeting has no limit to the number of participants while a decision-making meeting produces results faster with a small number of participants.

If you want to help your teams have more effective meetings, set the participants expectations about the meeting by stating in the agenda --

the purpose of the meeting.
the type of meeting

The typical meeting types are:

problem-solving
decision-making
planning
feedforward (status reporting and new information presentations)
feedback (reacting and evaluating )
combination meetings

For instance, the agenda states that you will be a participant problem-solving meeting to scale the application so it supports 500 simultaneous users. That description makes it crystal clear what you are there to do. And after you participate in a number of the same type of meetings, you will know that meeting's structure and your role.

Although it's in the list, I don't like combination meetings. Participants, in my experience, aren't as focused in a combination meeting; thus the results are poor. If you insist on combination meetings, I suggest your break them into segments of different meeting types. Despite segmentation, time management for a combination meeting is more difficult than a single type of meeting because you have more than one purpose to achieve.

If you want to save yourself and your teammates time and effort, propose to management that the purpose, type, and agenda of a meeting be clearly stated in the scheduling request for every meeting.

Reference

Michael Doyle and David Straus, How to Make Meetings Work, ISBN 0-515-09048-4, pp.159-166

Elements of Effective Communication

Wed, 02 May 2007 22:55:28 +0100

If you want to be a more effective communicator, keep your conversations focused on these three elements --

HERE

NOW

US

Conversations containing the opposites of the above elements --

THERE

THEN

THEM

-- will lead to ineffective communication.

For instance in a meeting of managers,

Ineffective: "They (the testers) didn't test the application properly so it crashes."

Ineffective. "They (the developers) didn't create the application properly so it crashes."

Effective: "We (the other managers and you) didn't manage the developers and testers effectively so users are experiencing crashes."

Talk about here, now, and us. Those conversational elements create an above the table conversation. Their opposites create a below the table conversation.

Waiting for Management to Set Direction

Tue, 01 May 2007 23:11:39 +0100

Several of my friends who work for the same large organization tell me they are bored with their job. I hear about them waiting for management to complete the process of setting a new direction for the organization.

What opportunities are available to employees when management is in the process of setting a new direction?

1. Offer to help management set direction

Start with finding out who is setting the direction. Large organizations like to use terms such as "management team" to describe the team who is setting the direction. Take a tip from my colleague Dwayne Phillips who asks his management, "May I have the names of the people on the management team?" He contacts the members of the management team and offers to help them.

2. Complete mundane, low-priority tasks

When the organization is busy, mundane low-priority tasks aren't done. For instance, deleting old files from the network drives; inventorying tools; and so on. I'll bet you could stay busy for weeks completing tasks that remove clutter so it's easier for you and your colleagues to work. Recruit some of your colleagues. Call it the spring cleaning project. The project isn't glamorous, but no one would argue that its long-term effect isn't positive.

3. Research

You have been saying for a long time that you want to research a new technology. You have the time now so use it to do the research. Share your finding and recommendations with your colleagues.

4. Write

You know things that would benefit people both inside and outside your organization. Write and article about what you know. At the very least, you can share the article with the people inside your organization. Perhaps you can find someone to publish it outside the organization.

5. Exercise

Increase your fitness: run; hike; bike; lift weights; play tennis; play soccer; play basketball; or whatever you enjoy.

6. Vacation

Can you think of a better time than now?

7. Do nothing

Doing nothing is always a choice. You may be doing it now. Are you okay with days of doing nothing?

8. Act like your working

Acting like you are working is harder than working for some people. Is it harder for you?

I'm sure I've only scratched the surface of opportunities available to employees while management is busy setting a new organizational direction.

What have you done in similar situations?

Saying No

Mon, 30 Apr 2007 23:21:21 +0100

One week before the application you have been working on is to be delivered, your client asks you to make a small change to a drop down menu. He knows there isn't time to process the change through change management so asks you to bypass it. You try to reason with him that a last minute change is a bad idea. But he insists the change is important to the business and it would mean a lot to him personally. You want to please him so you say yes.

Do you have a pattern of saying yes to requests when you would like to say no? What's the secret to saying no and making it stick?

The secret is practice.

People who are uncomfortable saying yes but say it anyway are stuck in the familiar. Practice created the familiarity. They have repeatedly stuffed their feelings and said yes when they would have liked to have said no.

It doesn't have to be this way. Communication is a skill. By practicing anyone can become familiar with saying no and enjoy the comfort of acting on your thoughts and feelings, which you have learned to repress.

Let's assume you have this problem of saying yes rather than saying no, which is what you want to say.

I suggest the following steps:

First, center yourself.

Put yourself in the process: Explore your thoughts and feeling about the issue. Use them to decide whether saying no is the appropriate answer. If it is, continue with the next steps. Otherwise, say yes and mean it.

Second, sincerely empathize with the other person's desires.

For instance, for the client who wants you to bypass the change management system, find out what the client sees as the benefit of taking that action. Empathize by saying, "Making that change would make it easier for Jane to navigate through the new use case." or whatever fits the situation.

Third, say no without equivocation.

For instance, say to the client, "No, I won't change the application without using the change management system."

Fourth, don't explain why you said no. It's non-negotiable.

For instance, if you followed the no in the example in step 3 with an explanation about why change management is important. You are opening an opportunity for the client to argue that the benefits to the business and themselves trump the benefits of the change management system. Don't offer the person any hope of you changing your mind. That action will make your no stick.

Fifth, repeat the steps 2 through 4 to whatever objections you hear.

People like to negotiate. You can listen and empathize. But stay on your message. It won't take long for the other person to realize it's a non-negotiable answer.

Expect difficulties with your delivery the first dozen times you say no. You will be in unfamiliar territory. Ask a friend to role play the situation with you so you can practice your delivery.

Expect that your delivery may sound blaming as you overcompensate for your earlier placating communication. Don't worry. It's part of the change process. Your communication will become congruent as you gain more skill at saying no.

Expect people who know you to be surprised when you say no. It's something they haven't heard from you. You are behaving differently. They will be unfamiliar with the new you. They will adapt to the new you and so will you.

You can learn to say no. Practice. Develop this skill and discover an unexpected benefit -- when you say yes, that answer will have more meaning than it did before.

Visual Project History

Fri, 27 Apr 2007 20:10:20 +0100

What element of a project retrospective, in your experience, separates the average retrospective from the outstanding? For today, I would answer, "A visual history of the project created by the participants during the retrospective."

What does a visual project history look like? Why is it a key element to an outstanding retrospective?

This photo shows a visual project history from a retrospective that I led.

The canvas for this retrospective is 15 feet long and 5 feet high. The yellow items on the canvas are post-it notes created by the participants.

The participants invested 2 hours creating this visual history of the project. To a person they thought this time was well invested.

Why does creating a visual project history lead to a more successful retrospective? It refreshes each participant's memory about the history of the project; it delays interpreting the history of the project until everyone has had a chance to contribute their viewpoint of the history; it enables a group memory of the project to emerge from the individual viewpoints; and it enable the participants to see and explore patterns in the history data.

After creating the history of the project, the state of the participants is heightened. You will hear more thoughtful answers to questions, such as: What did we do during this project that we would benefit from doing in the next? What did we do during this project that we would benefit from doing differently in the next?

Like a coach who uses exercises to warm up athletes before they perform, warm up retrospective participants by creating a visual project history before asking them to perform.

A Riddle about Projects

Thu, 26 Apr 2007 22:09:51 +0100

All of us have experience with projects.

In my experience, complex project never work exactly as planned.

What is the first thing about a project that must be adapted when things aren't working as planned?

Answer, the story about the project.

For instance, when a software project is about to miss a milestone, you may hear a story about testing requiring more time than expected.

Changes to projects require stories to explain the changes.

As my colleague Jerry (Gerald M.) Weinberg says, "We don't manage projects. We manage stories about projects."

What patterns do you see in the changes to project stories where you work?

BOGSAT Intervention

Wed, 25 Apr 2007 17:52:21 +0100

You have heard of the fog of war. But have you heard of a BOGSAT -- Big Official Group Sitting Around Talking? It's a disease that infects organizations.

Let me share with you a story about a BOGSAT intervention.

I am an expert at leading meetings. I have a natural talent for following and guiding a meeting so the participants produce results and the participants rate it as an effective use of their time.

I was asked by the owners of an aerospace program to lead their weekly leadership meeting. I had finished a consulting engagement for the same program so I had attended their weekly meeting five times to status my work.

As a student of meetings, I noticed that their weekly agenda averaged 6 items but their average completion was 2 items, leaving 4 agenda items unprocessed.

Shelley, the project manager, was leading the meeting. She was inexperienced. She scheduled too many agenda items and didn't maintain the boundaries of the discussions.

The meeting participants liked to talk. Bernard, the leader of customer support, summed it up the desire to talk nicely when he said, "We need to socialize more so we get to know each other."

"Please tell me you're joking," I thought, "you can socialize after the meeting."

But Bernard was deadly serious. He wanted to socialize during the meeting.

I met with the owners about leading the group, Robert spoke for the group, "We want your help changing the meeting so we produce the results we need to lead the program."

Despite hearing all the right words from the owners, a voice inside of me sent a warning by saying, "BOGSAT. You will be tested."

Those words would turn out to be prophetic.

The first meeting I led went well. I limited the agenda to three items. The participants followed my lead and we finished the agenda with a few minutes to spare.

The second meeting became a test that stuns me to this day.

We finished the first agenda item on schedule.

The second agenda item was a decision about whether to schedule a multi-day off-site meeting for the leadership team.

I told the participants we would go clockwise around the table participant-by-participant giving each an opportunity to speak.

Jacques, who was responsible for user satisfaction, said, "I need to know what's going to be in the first release of our product."

I felt an itch behind my ear. I scratched it

Shelley, the Project Manager, spoke next, "I need to know what Bob and John (the owners of the program) expect of me."

My eyes burned. I rubbed them.

I said, "We appear to be drifting from topic of whether we will have an off-site meeting."

I tried to focus the participants on the pluses and minuses of having an offsite meeting rather than on issues that could be discussed during that meeting.

But, Robert, an owner, said "Jacques and Shelley have brought up important questions. They must be discussed first."

My stomach twisted. "BOGSAT!" I thought, "The meeting is about to drift."

I heard myself say, "No, we don't have to discuss those questions."

Robert gave me a stern look.

I said, "This meeting is a mirror to what is happening in other program meetings. The leadership team needs to show that it finishes its work on schedule."

What was I doing?

I explained to Robert, "If we don't focus on a single agenda item the discussion will drift and we won't complete the agenda."

Robert asked me. "What do you think this meeting is about?"

"It's a leadership meeting. Leaders make decisions and keep pushing the program forward."

Was I out of my mind?

I didn't stop. I said, "If all the participants want to do is talk, why don't we all go to a bar. At least we can have drinks while we talk."

I was definitely out of my mind.

"If we are going to keep doing it this way, I'm done leading the meeting."

I stood up and took down my flipcharts that contained the agenda and the meeting memory.

I sat down.

Silence.

It seemed like an eternity until John, another owner, said, "We need to support strong meeting leadership."

A new choice was now available to the group. They accepted it.

I felt dazed. I was still there. I hadn't lost the consulting assignment.

I don't recommend this intervention for everyone. It worked for me. It might not work for you.

I do know that John, the owner I mentioned earlier, told me later, "What you did then was the best thing that could have happened. It changed us."

Complaint with Recommendation

Tue, 24 Apr 2007 23:10:08 +0100

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

Reenergize Action with Appreciative Feedback

Mon, 23 Apr 2007 19:06:28 +0100

All work requires energy. Middle-managers who divert all energy to new actions fall into a common trap: They fail to reenergize existing actions, which may kill the success of new actions.

Middle management success depends on fueling both new and existing actions. How can appreciative feedback help you discover existing, effective actions and preserve them?

On your own, you can identify a small number of the effective actions people are taking. But combine yourself with the other members of your organization and you can identify many more.

I suggest you use appreciative feedback during status meetings to discover effective actions that people are taking. Here's how --

During your status meetings, title your second agenda item Appreciations (for agenda item #1, see this post). I suggest 10 - 15 minutes for the duration. With the agenda that you send to all the participants, include a separate document that contains a replica of the following appreciation form:

Appreciation

________________________________
recipient

I appreciate you for

________________________________

________________________________ specific action

Your action enabled me to

________________________________

________________________________
specific outcome

________________________________
giver's name

Ask the participants to fill out an appreciations form for as many people as they would like. Emphasize to them that you would like them to fill out the forms before the meeting.

Here's an example of a completed appreciation --

Jerry, I appreciate you for analyzing and predicting the number of clients who are dissatisfied with our product. Your action enabled me to convince upper-management to invest in creating a focus group of key clients to advise us on prioritizing the fixes.

Why use a form? During the meeting, you will ask the giver and the recipient to come to the front of the room. The giver has all the talking points on the form. Without preparation, the giver prepares their delivery at the last minute causing them to ramble for minutes to everyone while they organize their thoughts. A giver who is unprepared decreases the number of appreciations shared.

When the time limit expires for the Appreciation agenda item, collect the remaining appreciation forms and post them in the meeting minutes along with the appreciations that were covered. It's less powerful than the giver delivering the appreciation to the other meeting participants. But if you stretch the duration of the agenda item too much, participants will tune out.

Before you have your first meeting with appreciations -- demonstrate the form and delivery in an earlier meeting. It's simple: Stand up. Move to the front of the room. Ask your recipient to join you. Smile. Look them in the eyes. Tell them what's on the form. Smile. (The recipient says two words, "Thank you.")

Emphasize the importance of the giver sharing a specific action and outcome. During the first few meetings when you do appreciations, if actions and outcomes aren't specific, ask questions to help the giver become specific. Everyone will benefit from the coaching.

I suggest you don't do appreciations every status meeting. A period of appreciation has the desired effect when it's special. I suggest doing appreciations every other meeting.

Appreciative feedback provides you and the entire team with information about effective actions and their consequences. You will discover effective actions which need recharging to preserve.

An appreciation lets a recipient know that someone recognizes and appreciates their work. For many employees, recognition and appreciation by a peer is the highest reward. Appreciations reinforce and reenergize a person's desire to take effective actions thus preserving them.

Rethinking Employee Rewards 3 of 3

Fri, 20 Apr 2007 15:42:14 +0100

My first post on rewarding employees explored the importance of providing a reward that is meaningful to the recipient. My second post explored the purpose of rewards, the timing of rewards, and my thoughts about rewarding all the members of a team rather than a few individual members of the team.

In this final post on rewards, I explore answers to the following questions: Do rewards work? Are they manipulative?

Rewards aren't effective for everyone.

I have friends who oppose rewards. My friend, Marty, tells me she feels manipulated by rewards. They remind her of grade school where if she did as the teacher told her, she would receive a high-grade.

Are rewards manipulative? Yes, they are. Face up to that fact: You want the recipient to repeat their behavior and you want others to notice the reward so they will exhibit a similar behavior. That's manipulation; regardless of whether the manipulation is in the best interest of the organization as a whole.

I had dinner with my friend and colleague Ken Estes a few months ago. He had recently participated in a workshop on animal training led by Karen Pryor. We were talking about what he had learned. Ken is sharp; rather than tell me what he learned, he asked me, "When Is a reward a bribe?" My mind plumbed its depths. Ten seconds later no answer had surfaced so I replied, "Uh... I don't know, Ken. When is it a bribe?"

"When the trainer shows the reward and issues a command."

Bingo!

If rewards are clearly specified in advance, people like Marty, feel bribed and they don't like it. I can empathize with her feeling. No one wants to feel like they being manipulated by a lousy dog trainer.

I have observed a glow on Marty's face and a sparkle in her eyes when a team member appreciated her for organizing and interpreting problem data, which she did exceptionally well. I suspect she didn't feel manipulated because no one said to her, "If you organize and interpret the problem data exceptionally well, I will appreciate you during a team meeting."

Someone noticed and took the time to share their observation with Marty. The person who noticed wasn't her manager. He was a member of the same team. A thoughtful appreciation from a member of a team about the work of another member is a powerful, underused reward.

I recommend scheduling time during status meeting for you and other team members to appreciate the work of each other. Make it special by not scheduling appreciations every meeting. In my experience, once every two weeks works well. I'll have a separate post on this topic next week.

If Marty is the North Pole of attitudes toward rewards, my friend Sandy is the South Pole. She wants to know the rewards in advance so she can maximize her gain. She doesn't feel any manipulation. She sees winning rewards as extra compensation.

Employees respond to rewards differently. People like Marty don't like being manipulated by rewards but will respond positively when you notice something they did well. People like Sandy don't feel manipulated at all: They feel compensated for their trouble. And the remaining people are in the middle feeling some degree of manipulation and some degree of compensation.

Employees talk about organizational rewards. They sometimes agree with them. They sometimes object to them. But, in my experience, employees respond to them.

The most effective programs reward to produce the desired results with the people who are doing the work. Designing these programs isn't simple and unintended consequences are possible.

Rewarding is like cooking a stew... Add good ingredients and spice to accent the desired flavors. Cooks who carefully taste and conservatively spice produce tasty stews. Careless tasting and liberal spicing produces disasters.

Rethinking Employee Rewards 2 of 3

Thu, 19 Apr 2007 22:27:22 +0100

In my first entry on employee rewards, I emphasized the importance of knowing the recipient well enough to reward them with something that is meaningful to them.

But there is more to effective reward programs than providing a meaningful award. Let's take a step back and explore answers to the questions: What is the purpose of a reward program? How can we innovate to make reward programs more effective?

Rewards reinforce desired behavior so they are repeated.

For instance, If Arthur creates exemplary C++ code that satisfies the organization's desired tradeoffs for quality, speed and economy; rewarding Arthur reinforces his behavior and sends a clear signal to the other people in the organization about what is desired.

Reward (reinforce) immediately after the accomplishment of the desired behavior.

For instance, rewarding Arthur for his exemplary code nine months after it creation, during the company Christmas party, poorly communicates management's desire. It has neither a chance of reinforcing Arthur's behavior or sending a clear signal to the rest of the organization about what is desired.

Reward all the team members for the accomplishments of a team.

A team is different than a group of individuals. See my entry What Type of Team are You Managing?

All the members of a team deserve a reward for their accomplishments as team rather than rewarding individual team members for their special accomplishments.

For instance, a reward for a team in the Seattle area, where I live, might be a one-half day trip to the Boeing Air & Space Museum complete with a special speaker who compares a period in the history of airline technology similar with what your company is trying to accomplish.

If you reward team members for their individual accomplishments, you are reinforcing that individual's behavior and sending a clear message to the other team members about the behavior you desire. This strategy can backfire.

Individual awards may trigger team members who covet rewards to consider their teammates as competition. Don't underestimate the power of rewards to produce unintended consequences.

I prefer rewarding the entire team, but I recognize there are situation where rewarding a member of a team for their accomplishment has merit. The example of Arthur that I mentioned earlier is a case in point.

Use your imagination for rewards. Test your ideas with members of your team to confirm they like the idea. Ask them for ideas.

Ask yourself the following question when you are considering rewarding someone:

What is a meaningful award for the team or individual?
What desired behavior am I reinforcing?
What am I communicating to the other members of the team or group?
What are potential unintended consequences?

Tell me about rewards you have received that you liked. Tell me about rewards you would like to receive. Tell me about any team awards you have enjoyed.

Click here to read my final installment on rewards.

Rethinking Employee Rewards 1 of 3

Wed, 18 Apr 2007 21:11:53 +0100

I surveyed ten of my colleagues from different high-tech companies about the state of employee rewards programs at their company. One colleague told me about the outstanding reward programs where he works. The other nine colleagues told me something much different. Their feedback is easily summarized as follows: "Our reward programs are pathetic!"

What's the difference in the thinking by managers at the company with the effective reward program and the managers at the companies with the pathetic reward programs?

The managers with the effective programs reward people with something that is meaningful to the recipient. The manager knows the recipient well enough to to pick a meaningful reward for them.

The managers with pathetic programs reward a person with something that is meaningful to the giver, the manager. The manager doesn't know the reward recipient well enough to pick a meaningful reward for them. The giver chooses the reward based on what they would like.

For instance, Barry, a vice-president, awards Jerry a Rolex watch for his contribution to the development of a new product. Jerry, the product's architect, worked seemingly every day for over a year to deliver the product. Barry believes that a Rolex watch is great award for anyone. Who wouldn't like a Rolex? Answer, Jerry. He is allergic to metal. If he wears the Rolex, he will break out in hives.

A manager who invests time learning about Jerry would discover that he loves classic photographic prints. If Barry had contacted Jerry's spouse, Margaret, he would have discovered that Jerry has always wanted a high-quality reproduction of Dorothea Lang's Migrant Mother photograph. Corbis offers a high-quality print for under $1,000, which is thousands of dollars less than the Rolex watch. Jerry would have been ecstatic about receiving the photograph.

A manager in a company with an effective award program goes the extra mile to reward an employee with something the employee will like. The extra effort does take time. And the extra effort pays dividends.

People who have experienced thoughtful recognition, know its power. If you haven't had the experience, you can help create it for someone else. As the saying goes, "What goes around, comes around."

I have much more to say on this neglected topic. This is the first of three installments; here is the second; and here is the third.

Tell me about the state of your company's reward program.

What Haven't You Told Me?

Tue, 17 Apr 2007 22:33:39 +0100

What vital element of business communication is the most forgotten?

Discovering what hasn't been said.

Marianne, Jamshid, Johanna, and Dave are participants in a project retrospective for the CRM system.

Lan, the retrospective leader, asks the group to brainstorm the question, "What problems did you experience working with your clients during the project."

Rather than asking the participants to define problems, Lan asked them to write elements of the problems on a separate post-it note.

He gave the group ample time to generate many elements.

Lan asked them to pick the three elements that were the biggest problems for them personally. He went round-robin through the participants asking each person to post their top three elements on a common white board and explain each element to the other participants.

After all the participants posted and explained elements of problems the had had with clients, Lan asked them to pick the two most important elements from their remaining post-its. He repeated the round-robin posting and explaining. He asked them to pick one of their remaining elements. He repeated the round robin.

There are now 24 elements on the board. You might think that the most important problem elements are on the board. Don't bet on it!

In this case, a client named Leonard was an alcoholic. He was having an affair with the head of their department. His behavior varied from abusive to overly friendly.

Not a single person posted a problem element mentioning Leonard.

Lan had done his homework and knew about Leonard so he asked, "What problems has this group carefully avoided mentioning?"

Lan didn't say another word. Johanna looked like a deer caught in the headlights of an automobile. 5 seconds passed. Jamshid was looking down at the carpet. ...10 seconds. Johanna looked from person to person. ...20 seconds. Dave looked out the door. ...30 seconds. Marianne said, "That's enough! There was a big problem with a client named Leonard.

That's when everyone came clean about Leonard and some other problems that might never have been mentioned.

Why did the group come clean? Although they were reluctant, they ultimately felt safe telling Lan. They trusted him with the information. Don't underestimate the importance of safety for hearing what hasn't been said. For information about measuring safety in groups, see my article Safety Check.

The question, "What haven't you told me?" is as valid with an individual as a group. It's a powerful question for more effective communication.

Start Meeting Punctually?

Mon, 16 Apr 2007 22:40:30 +0100

Twenty percent of the participants arrive late to the weekly meeting you lead.

What do I recommend you do?

It depends.

Do you arrive late? If you do, I recommend that you change your behavior. Participants respond to leadership cues. You are enabling participants to excuse their behavior when you demonstrate the meeting isn't important enough for you to be in the room before the scheduled start time.

If you are leading the meeting for a group, start the meeting on schedule regardless of whether you are the only person in the room. I am assuming you sent out a meeting notice with an agenda. Work through the agenda. Don't backtrack when the late participants arrive regardless of rank. Your actions will send a stronger message than your words ever could.

If you are leading a meeting for a team, I suggest a different strategy than with a group.

A team produces its results through regular interaction with its members. It's impossible to work as a team unless the members are in the room. Groups, on the other hand, rarely require the participation of all of its members. A group is working as a collection of individuals rather than a team. See my blog entry What Type of Team Are You Managing?

If you are leading the meeting but aren't the leader of the team, make the situation clear and let the team decide what it wants to do. See my blog entry Waiting for People Who Arrive Late.

If you are the leader of the team and you lead the meeting, does starting late reflect your preference? You can do something about the problem. Consider the idea I propose in my blog entry Fine Team Rather Than Individual?.

If you need help with improving the results of your team or group meetings, I can help. Contact me.

I Don't Disagree

Fri, 13 Apr 2007 21:22:34 +0100

A high signal to noise ratio will help you have an effective conversation.

I have noticed that the words "I don't disagree" (IDD) reduces the signal to noise ratio of a conversation.

What does IDD mean? What do I recommend if you are in the habit of saying IDD? What do I recommend if you hear someone say IDD?

Logically it seems like it means I agree --

Disagree means have a different opinion
Thus I don't disagree transforms to I don't have a different opinion
I don't have a different opinion is logically equivalent to I have the same opinion
I have the same opinion is logically equivalent to I agree
Therefore, I don't disagree is logically equivalent to I agree

Although I don't disagree (IDD) is logically equivalent to I agree, does its meaning reflect the intended meaning of the person who said IDD? No, in my experience, IDD rarely means I agree.

For instance, a colleague, Jason, responded, "I don't disagree." seven times to conjectures made by his colleagues during a meeting yesterday. On the eighth instance, when he said IDD loudly in response to my conjecture, I ask him, "Does IDD mean that you agree with me?"

I watched him carefully: He hesitated. His eyes looked up to the ceiling then down to the ground. Eventually he looked at me and softly said, "No, not really." "What did you mean by IDD?", I ask inquisitively. He paused for several seconds. He stared at the ground and then slowly looked up and replied, "I said IDD to prevent any arguments so I could talk." "Wow, thank you for the honesty.", I heard myself say.

After the meeting, Jason told me he wanted to share his own conjecture without sharing his opinion about my conjecture. For him, IDD was like executing a No Operation (NOP) command on the processor of some computers. This machine instruction takes one cycle to process but it doesn't change the state of the machine. In other words, it does nothing.

There are situations where consuming a processor cycle but doing nothing has value: NOP can be use to solve timing issues with connected components. But people don't say IDD to solve a timing issue. It creates ambiguity and, unlike a NOP, it changes the state of the conversation. The changes IDD create isn't signal but rather they are noise.

If you are in the habit of saying IDD, I suggest rethinking whether those words effectively communicate your desired meaning. If you want the floor, skip the IDD and say what is on your mind. If you hear others say IDD repeatedly, when it is said to you, ask the person, "Does that mean you agree with me?" I think you will discover it means something much different than, "I agree."

Short-Circuit Chaos?

Thu, 12 Apr 2007 22:20:29 +0100

Managers who like to be in control have a predictable reaction to their organization grappling with a change which creates chaos -- they want it to stop. When? Now, right now.

What happens if management decides to short-circuit chaos with a magical solution? What happens if management accepts chaos as a necessary but uncomfortable period of the change process?

In Greek mythology, Chaos is the disorder from which the first gods emerged. It's a raw place where things can be broken apart and recombined to create something new.

Managers who short-circuit chaos aren't necessarily resisting the change. They may fully accept the need for the organization to change. But they can't stomach the day-to-day disorder necessary for the organization to break itself down and rebuild itself.

These managers reach for their gun and load it with their own personal silver bullet and shoot at the chaos; for instance, a change effort to reduce expenses is averted by a magical tax write off. It solves the problem. Rather than killing the chaos, the manager has shot themselves in the foot. The revenue problem returns later and it's worse than before.

Can you imagine helping anyone learn anything without some period of chaos where their performance is erratic. Children don't learn to catch a ball without a period of chaos. Teenagers don't learn how to deal with the opposite sex without a period of chaos. Adults don't learn how to rear children without a period of chaos.

Chaos is a necessary part of learning. Short-circuit the chaos and you limit the learning.

So what should the wise manager do about chaos?

Utilize redundancy
Center themselves
Enter the chaos
Offer support

A wise manage will plan for a period of chaos and utilize organizational redundancy to minimize the impact the chaos has on the organization's customer. This strategy is a regular course of action in an engineering organization. They have engineers who sustain a product while another group changes itself to build a new product.

The same strategy can be applied to other business situations: One group keeps the business context in place for the customers while another group undergoes a change process. It may seem like it costs more money to process change this way. But what it really does is make the costs visible. Estimating the cost of making a change is a responsibility management has to the business.

If you are managing a group that is changing, I advise you to first center yourself. Enter the chaos with your employees. Offer your support. They will need it. Help them break things apart. And help them rebuild.

This process isn't new to any of us. We did it all the time when we were children. And, much of the time, we changed and thrived on changing. The same possibility is available to organizations.

For More Information

Wikipedia Chaos (mythology)

Steve Smith's (my) Satir Change Model article

Jerry (Gerald M.) Weinberg Quality Software Management: Vol. 4: Anticipating Change, ISBN: 0-932633-32-3

Rethinking Stand-Up Meetings 2

Tue, 10 Apr 2007 13:21:47 +0100

I argued in my first post about stand-up meetings that the "right" participants were the key to the success of a meeting rather than whether the participants were standing up or sitting down. Despite my dislike for the stand-up component, I did mention in my first post that there are components of a "stand-up meeting" that I do like.

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

Click here to read my first post on rethinking stand-up meetings.

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

Knowing the agenda
Limiting duration
Minimizing participants

Knowing the Agenda

A daily SCRUM stand-up has each team member answer the following three questions: 1) What did I accomplish yesterday? 2) What will I do today? and 3) 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 come to the meeting with their status written on sticky 3x5 cards. Ask them to create a separate card for each element of their answer to each of the three questions.

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. It will also increase the pace of the statusing. It will provide information for publication. It can be compared with 3x5 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? 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 a person to effectively status their work? For instance, if you have 10 participants, there is 1.5 minutes available for each participant. Is that enough time? That's one-half of a minute to answer each question, which would work for me.

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 that action 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.

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

For More Information

Jason Yip, It's Not Just Standing Up: Patterns of Daily Stand-up Meetings

You will find lots of information on the web about this topic. Use your faviorite search engine.

Rethinking Stand-Up Meetings

Mon, 09 Apr 2007 17:30:05 +0100

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.

In this post, I will lay out my problem with stand up component of the stand-up meeting. Tomorrow, I'll write about some of the positives I see in other components.

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.

Best Practice Assertion

Fri, 06 Apr 2007 11:57:27 +0100

How many times have you heard a supplier assert that they offer a technique that is a "best practice?"

What do they mean? How do you test whether a technique is a best practice?

The words "best practice" is hyperbole used by suppliers to make a technique sound more attractive. That's a harsh statement, but it fits the rhetoric I hear from suppliers.

Let's test whether my assertion is hyperbole.

Better/Best: When you're comparing the merits of two things or people, use better; when comparing three or more, use best.

-- Jan Venolia, WriteRight!, ISBN 2-58008-328-5, p. 129

Ms. Venolia recommends you write "best" when three or more things have been compared. It's rare, in my experience, to find that two things were compared, let alone three.

How do I know? I ask, "What other techniques did you compare to determine whether this technique is the 'best practice?'" After a period of pondering, a typical supplier will answer, "Compared to having nothing."

Ms. Venolia might suggest that the supplier assert, "Our technique is better than nothing." That's the facts, but do you know any supplier who would ever say that?

There is a further problem with the term best practice: A best practice for you must be the best for doing your business rather than someone else's. A best practice for a large company, such as an airline manufacturer, is unlikely to be the best practice for a small business in a different sector, such as a law firm, and vice versa.

Want to have more meaningful conversations with suppliers? Start by eliminating hype like "best practice" from the conversation.

I suggest you put your suppliers on notice. Let them know you will be asking questions about any claim they make that a technique is a best practice. Unless they are prepared to prove their claim, suggest to them that they substitute the words "our technique."

Clarity increases the meaningfulness of a conversation.

Need help creating more effective conversations with suppliers? I can help. Contact me.

The Wise Use of Extreme Introverts

Thu, 05 Apr 2007 12:38:53 +0100

The social awkwardness of an extreme introvert -- a loner-- confounds most extroverts. Extroverts prefer using social interaction as a big part of the problem solving process while a loner prefers solving problems without social interaction.

Can a loner be a contributing member on a collaborative team?

Yes.

But I need to qualify my answer.

A loner style is offset by specialized skills. If a loner has expert skills in an important domain, such as database design, it simplifies their ability to contribute to the team. And their domain expertise also makes their contribution visible to others.

Both the loner and their teammates will have to make compromises. The loner will have tradeoff the amount of time they work in complete isolation for membership on the team. The other members will have to tradeoff social interaction with all the members of the team for more expertise.

Loners are often the experts in an organization. They don't have to participate in every team interaction to have value. Good managers will manage their use and remind the loner and their teammates of the tradeoff and its value.

A little give by all parties and everyone benefits.

If you need help with the integration of an extreme introvert on to your team, I can help. Contact me.

Dealing with Method Zealots

Wed, 04 Apr 2007 14:02:00 +0100

Has a member of your team become completely concerned about how something is done rather than whether it is done?

Is it a problem when someone is completely focused is on how something is done? What do you do about it?

A good starting point for exploring these questions is a quote from John Gardner's book Self-Renewal:

...goals are achieved by some means, and sooner or later even the most impulsive man of action will discover that some ways of achieving the goal are more effective than others. A concern for how to do it is the root of all great craftsmanship, and accounts for all of the styles in human performance. Without it we would never know the peak of human performance.

Yet, ironically, this concern for "how it is done" is also one of the diseases of which societies die. Little by little, preoccupation with method, technique and procedure gains a subtle dominance over the whole process of goal seeking. How it is done becomes more important than whether it is done. Means triumph over ends. Form triumphs over spirit. Method is enthroned. Men become prisoners of their procedures, and organizations that were designed to achieve some goal become obstacles in the path to that goal.

ISBN 0-393-30112-5, p. 47

I have worked with method zealots. They seem to have a recipe for every situation. If the recipe produces a vial tasting concoction, it's your fault: You must have messed up because the recipe always produces the desired result.

Is a process zealot a problem? If they -- despite your efforts to open their eyes -- remain completely unconcerned about the results you need to achieve, they are a problem. They are oblivious to your needs. How can they assess the effectiveness of the methods they advocate without some focus on the desired results?

For instance, I have heard zealots argue that SCRUM is the one true way. I have heard other zealots argue that XP is the one true way. The desired result, which is part of the context for using a method, wasn't even discussed.

I respect a fine craftsperson. But even the finest craftsperson can't create a universal method that will work in every situation. Every information technology leader owes it to themselves and their investors to constantly test the effectiveness of the methods they are using.

What do I suggest you do about a process zealot? Replace them with a craftsperson who cares about both method and results. Methods are supposed to serve you rather than enslave you. Don't worship methods (or plans). If a method has you on a collision with an iceberg, change course.

If you need help changing course, I can help. Contact me.

Actions to Take for a New Teammate

Tue, 03 Apr 2007 11:56:46 +0100

What actions are available to you and every other member of your team to help a new teammate become a productive member of the team?

Move over. Give them space to operate.

Encourage their participation.

Provide advice when asked. Refrain from providing advice when not asked.

If you can't take these action, then it's time to review your hiring process.

What Type of Team Are You Managing?

Mon, 02 Apr 2007 17:55:07 +0100

Is your team more like a basketball or a track team?

What's the difference between these types of teams? Why is the difference important?

I have been a member of many basketball and track teams. Being a successful member of a track team is different than being a member of a successful basketball team.

Basketball is a team sport. At its core, track is not a team sport -- it's an individual sport.

A track "team" accumulates points when its members finish in the top six in a track event. Points are typically awarded at a big track meet as follows: first 10 pts, second 8 pts, third 6 pts, fourth 4 pts, fifth 2 pts, and sixth 1 pt.

The winning team accumulates more points than the other teams. Coaches who win the big meets have three fundamentals in common -- 1) they attract talented individuals to their team; 2) they teach them the skills necessary to win their individual event(s); and 3) they peak their performances for the big meets.

The sum of the points won by the individual members determines the track team's score. With the exception of the relay events, which require three simple baton exchanges, interaction between the members of a track team isn't a factor on how many points the team accumulates. Track, like golf and swimming, is all about individual performance.

I was the captain of my college track team. I wanted us to win. But I realize now that, for me, winning as a team was a bonus. My primary focus was how well I performed during the meet. When I did poorly and the team won, I was upset. I didn't feel like a contributor and the team's victory provided little comfort. When I did well and the team didn't, I was happy. I felt like a contributor.

I felt much differently in team sports, like basketball or football or volleyball. If I did well and the team lost, I felt poorly. When I was a member of this kind of team and we won, I felt good regardless of whether I played well. Even when I warmed the bench and only cheered for the team, I felt like a contributor.

Winning basketball coaches share the first three fundamentals of winning track coaches but they must do more: They must also help members interact better with the other members so the team scores points against their opponents and stops their opponents from scoring points against them.

A basketball team is a system where the whole is greater than the sum of its parts. Interaction between the members of the team is just as important as individual talent to the success of the team.

A track team with the best track athletes will always defeat a team of lesser athletes. That's not always a certainty in basketball: It often takes more than the best individuals to win. Five good basketball players who play as a team can defeat five great basketball players who play as individuals.

If you doubt me, check out the results of the 2004 Olympics. The Unites States' team had great players but they played as individuals rather than as a team. They won the bronze medal. Argentina had less talented players than the United States but they played as a team. They won the gold medal.

Why is the difference important?

If you are managing a team of individual contributors who all report to you because the reporting structure was easy for the organization, manage like a track coach. Help your employees increase their individual skills. Help them peak for the right events. Focus more on the individual contribution and less on team contribution. You want your people to cooperate with each other and help each other. But never forget your success as a manager is based on the sum of the production of the individuals.

If you are managing a team of people who have a shared goal, manage like a basketball coach. Help people understand their role. Help them improve their skills. Help them interact better with each other. Focus on the team more than the individual. You want individuals to excel but not at expense of the team. Never forget you win based on what the production of the team.

If you need help with either type of team, I can help. Contact me.

Managing Low-Energy Decisions

Fri, 30 Mar 2007 11:27:39 +0100

Teams will take action on high-energy decisions. Action is less certain with low-energy decisions.

How do you detect a low-energy decision? What do you do about it?

After taking a deep breath, Emily said, "I propose that we create a monthly newsletter about our service offerings and send it to our clients."

Her proposal responded to criticism from our clients about misunderstandings around our newest service offering. The proposal made sense.

During the discussion about the proposal, my teammates who spoke agreed with the proposal. I didn't detect any enthusiasm in their responses though. I detected a similar lack of enthusiasm in me.

Emily said, "I'll edit the newsletter. I'll need some of you to write articles."

I sighed. My schedule was full. But she hadn't said that all of us needed to write articles.

I wanted to be certain about my interpretation though so I said, "My schedule is packed and I don't have time to write articles." and ask, "Are you expecting me to write articles?"

She said, "No, I only need a few people to write articles."

"Works for me." I replied.

We moved to voting on the proposal.

My team uses the Roman Evaluation Process to make consensus decisions. We vote on a proposal using one of our thumbs. We signify our agreement with a proposal by putting our thumb in one of the following positions.

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

Emily had her thumb up. I put my thumb sideways. Six other team members put their thumbs sideways.

No one disagreed with the proposal so there is a team consensus to move ahead. Right? Wrong!

My team has used Roman Evaluation for years and we know our vote might indicate low-energy. Rather than move ahead with the decision, we discuss whether we have the energy to do the proposal.

Emily started the discussion by saying, "I'm not enthusiastic about the proposal either. If I voted again, I would put my thumb sideways too."

After more discussion, Emily withdrew her newsletter proposal from consideration.

We started exploring other ways of responding to our client's criticism.

The feedback from Roman Evaluation will help you with early detection of low-energy team decision so you can discuss the low-energy and whether it is wise for the team to proceed with the decision.

Despite decisions making sense, the work associated with low-energy decisions may not get done. These decisions deserve careful discussion and management so the desired results happen.

If your team is having problems with detecting and managing low-energy decisions, I can help. Contact me.

I Won't Stand In the Way

Thu, 29 Mar 2007 11:52:54 +0100

What do you do when a teammate says, "I won't stand in the way of the team accepting the proposal." and when asked directly whether they will support the proposal, they hem and haw without clearly saying "Yes."?

In my post on Decide as a Team, I discussed how a team can use the Roman Evaluation Process to make a consensus decision and, if properly executed, how all the members of the team will support the decision and how it was made.

An element of proper execution of the process is cutting through double-talk. If you have any doubt about whether another member will support a team decision, I recommend you put your thumb down when voting on a proposal.

Recall in the Roman Evaluation Process the first people to speak after a vote are the members with their thumb pointing down. The member with doubt can share it with the team. If the suspected member or members say they will support the proposal, the doubter has an opportunity to change their vote.

Note, doubts won't surface in a dangerous meeting environment. Unless members feel safe, they won't speak up about their doubts. See my article Safety Check for how to measure the safety of a meeting and actions leaders can take to create a safe meeting environment. If you need help making your meetings safer, contact me.

Let me share an example of a situation where a member of a team put their thumb down on a proposal, which they liked and wanted approved, because of their doubts about whether another member's would fully support the decision.

I was a member of a team who had responsibility for marketing a product. Robert proposed the team produce a brochure that contained pictures of the product. This was a new idea--previous product brochures had contained the company's log but did not contain product pictures.

Barry, whose organization would be responsible for producing the brochure, objected to the proposal because he didn't like the product pictures. He was passionate about his dislike. He wanted different pictures. But the desired schedule for the brochure prevented the option of taking new pictures. Despite his problems with the proposal, Barry repeatedly said, "I won't stand in the way of putting pictures in the brochure, BUT I don't like it."

Sheila, another member of the team, had invested her time in producing a mock up of the proposed pictures and she was satisfied with the results. She tried to convince Barry of the value of pictures but her mock up seemed to only cause him to dig in and reiterate his previous statement of not standing in the way of the team.

The other members thought there was value in having product pictures, even if they were less than outstanding. They thought the team was in consensus because of Barry's statements. They were ready to vote and move on.

Robert saw the situation differently. The discussion, which had extended over two meetings, had been heated. He was worried about Barry's support and also worried that the proposal would tear the team apart. He asked for a vote. Barry put his thumb sideways; the other members put their thumb up; and Robert put his thumb down.

Robert spoke first after the vote. He said, "Until we have a proposal that everyone can fully support, I will thumb down the proposal." His statement stunned me. I hadn't seen it coming. I thought the brochure with pictures was a solid proposal. The idea of a member voting with their thumb to the sideways and not supporting a proposal was alien to me.

I assumed support was an automatic because a sideways vote means "I will go a long with the majority and support their decision." But, upon reflection, I realized that Barry's statements didn't say anything about supporting the decision only about not standing in the way of the team's decision. That's two different things.

A year has passed since Robert put his thumb down. I clearly see that Robert had voted wisely. The team grumbled about the time that had been lost. But the team stayed together and they eventually created a proposal for a pictureless brochure that was supported by all the members.

Do you have any doubts about your teammates willingness to support a team decision? If so, put your thumb down and surface your doubts. This action reenforces the foundation of the team. Inaction cracks the foundation. If you need help reenforcing the foundation of your team, contact me.

Decide as a Team

Wed, 28 Mar 2007 12:15:55 +0100

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.

Word Choices -- We -- Part 2

Tue, 27 Mar 2007 11:00:21 +0100

In my first entry about the word "we," I argued using the words "We decided to..." often create ambiguity. I suggested asking yourself several questions to reduce ambiguity either when you hear those words or when you are about to say them.

In this entry, I will lay out the case for when using the words "We decided to..." is completely appropriate and the use of other words is inappropriate.

Recall a situation when a team you were a member of made a decision that an outsider wouldn't like; for instance, I was a member of a team who decided to prevent an outsider, Margaret, from video recording a training class she would be leading. I didn't like the decision.

Margaret is a close friend. I like helping her. I knew she would call me and ask me what happened. I pondered my choices.

I could say, "The team decided that video recording was something that they didn't want." But wasn't I a member of the team? Didn't I participate in the discussion? Didn't I have the power to veto the decision? My mind had clear answers, "Yes." "Yes." "Yes."

I could say, "Although I didn't agree with the decision, the team decided to..." It took a nanosecond for my mind to snap back, "Baloney."

The appropriate choice was to take ownership of the decision and say, "We decided to not allow video recording for your training session or anyone else's. We believe video recording will create safety issues for the participants of the class."

Ask yourself whether you can say, "We decided to..." with conviction about tough decisions made by teams you consider yourself a member of. If you can't, perhaps your team needs help creating a decision process that will allow you and the other members of the team to use those words. I can help. Contact me.

Fine Team Rather Than Individual?

Mon, 26 Mar 2007 10:03:23 +0100

Does your team fine individuals for infractions; such as being late to meetings?

Rather than fining individuals, would more behavioral change happen if the entire team was fined?

I participate in a basketball clinic every week. It's a mix of guys who love playing hoops despite their increasing age. After doing a series of exercises that fatigue everyone's legs, each person shoots a free throw. If less than 80% of the participants make their free throw, everyone runs lines (sprints) which, on top of the exercises we have already done, is painful. The drill is repeated until the desired percentage is met. When we satisfy of goal, we do an activity that everyone enjoys -- scrimmaging.

I've noticed several key things happen during this drill -- I encourage other participants to make their shot; I am pleased when they make their shot; I concentrate more on my shot because I don't want to let my teammates down; and I feel like other participants have a similar view.

The drill connects me tightly with the other participants. A penalty imposed on individuals wouldn't.

I have never seen this kind of team reinforcement done in the corporate environment. It seems much different to me than fining individuals, which I have never been a fan of. When the opportunity presents itself, I plan to experiment with this method.

I believe cooperation increases when the members of a team all have skin in the game. This method reconnects the members of a team with others who have disconnected themselves from their responsibilities as teammates. People who are truly members of the team will take action to fix the disconnect.

Do you have experience using this kind of reinforcement? Please share your experience with me.

Waiting for People Who Arrive Late

Thu, 18 Jan 2007 13:29:28 +0100

What does it say abut the participants of a weekly meeting when the meeting consistently starts 5-10 minutes behind schedule?

Answer, the participants are cooperating with each other to start late.

Let's explore:

Are you cooperating with the participants of your meetings to start late?
How do you feel about that?
How do you feel about feeling that way?

Let me share how I would have answered the questions in 1990:

Yes, I had often cooperated with others to start late
I felt powerless to change the status quo
I felt angry about feeling powerless

I have never liked feeling angry. But what could I, as a person who felt powerless, do about the situation?

I decided that I would arrive before the scheduled start time; I would encourage other participants to arrive early; I would work to become a meeting leader; and, when I became the leader, I would demand that people arrive on time.

Arriving early and encouraging other participants to arrive early helped. Working to become a meetng leader was a success. Demanding that meetings start on time was a failure.

Despite my embarrassment, let me share just five of the many interventions I tried as a meeting leader to cause meetings to start on time:

Rescheduling the meeting to a start time all participants agreed would work
Contracting with the participants to arrive on schedule
Locking the door to the room at the scheduled start time
Cancelling meetings when an agreed upon quorum wasn't present
Publishing the names of the late arrivers in the meeting minutes

After gaining feedback from these interventions, I realized that successfully starting the meeting with all of the participants required the cooperation of, surprise, all the participants. The decision about whether we started on time was theirs to make.

Rather than fighting the status quo, I thought, "Why not make the status quo visible so every participant can decide for themselves whether it is acceptable?"

So my Agenda Item #1 became Wait for people who arrive late. All the agenda items in my agenda have durations. I assign the duration for item #1 as the difference between the actual start time and scheduled start time of the previous meeting. The agenda item looks like following:

#1. Wait for people who arrive late. 10 minutes

Regardless of why the status quo existed, its existence is out there for everyone to see.

What happened?

Reactions varied: Some participants didn't react to the agenda item. They seemed to think it signaled nothing. Other participants commented that they thought the agenda item started the meeting out on a sour note and wanted it eliminated. And some participants thought starting late was unacceptable and they wanted to do something about it.

It's easy to sense which reaction creates an opportunity for change.

Using Agenda Item #1, offers the opportunity for people to choose whether they want to continue the status quo or start changing it. I wish I could tell you agenda item #1 always triggered a change that caused a meeting I led to start on time. It didn't. It does, however, always offer an opportunity for the participants to choose again. And sometime that's all that's need to trigger the change process that creates a new, more effective status quo.

You may be wondering, Does starting meetings on time truly matter? I believe it does. If people are the organs of an organization, then meetings are the organization's lifeblood. These gatherings are where people come to define, solve and status problems. The more healthy a meeting, the more healthy the organization. And, conversely, the sicker the meetings, the sicker the organization.

If the people who participate in a meeting can't cooperate to start their meeting on time, what chance is there they will cooperate to start a project on time? I you were a member of a relay team running a race against another team, would you agree that everyone on the team can arrive for the race whenever it fits for them?

The same people who participate in meeting are the same people who are responsible for the tasks in a project. A meeting is nothing but the simplest of projects. My experience is that attitudes of participants at meetings mirror their attitudes to their task work and the project as a whole. How could they not?

How healthy are your meetings? If they are sick, gaining cooperation about starting on time and actually starting on time will make them healthier. It's not easy to change the status quo, but it can be changed.

The Revenue Neutrality Paradox

Tue, 16 Jan 2007 15:56:43 +0100

My friend Dan is a staffer for a software company. I asked him recently what he was working on. He told me he invests the majority of his time on a project to change the way his company licenses its software.

As soon as I heard the words, "software," "licensing," and "change," I was hooked. I had grappled with a similar change for one of my clients. I was curious to hear whether Dan was experiencing a pattern that I had seen with my client's organization.

We talked about whether executives imposed a "revenue neutral" constraint on his work. That term means that regardless of specific changes in licensing, the amount of revenue the organization receives is the same as what they receive now. Dan told me that his company uses the term "revenue agnostic" rather than "revenue neutral." But he said the concept was the same.

In addition to revenue, in my experience, executives are also concerned how the change would impact their customers. Typically executives require that any change not disturb customer satisfaction. Dan said that customer satisfaction was a concern. He said his executive was also concerned about how revenue change would affect the various parts of the organization. Dan's comment reminded me that my client had a similar concern.

So there are three constraints:

revenue neutrality
maintain customer satisfaction
maintain the satisfaction of the company's divisions

A simple and totally reasonable set of constraints? They are reasonable. But are they effective? No, in my experience, they are ineffective.

Let's construct an analogy so we can test:

Imagine that for the past thirty years you had been charged for all your home's utilities -- gas, electric, water, garbage, sewer, and so on -- by the total square footage of your home. The billing system uses a linear scale, the more the square footage of your house, the more you pay. For instance, a 2,500 square foot house pays $600 for utilities and a 5,000 square foot house pays $1,200.

After years of complaints from home owners of every size house about the inequity of the charges, the local government decides to change how they charge -- they will charge you for resource consumption. You will be charged separately for gas, electric, water and so on.

The heads of the local government impose the three constrains on the planners.

Can the planners create a new billing system that is revenue neutral? They may be able to do it for the first billing cycle, provided the customers stay in the same pattern of usage. But once most customers see measurements about resource consumption, they will change their behavior, which will change their consumption pattern. So, long-term, the planners cannot maintain revenue neutrality. Can they predict how much revenue may change? Yes, as long as they don't have to be right.

Would you, the customer, be pleased with the new system? Let's look at your neighbor, Jane, with a 2,500 square foot house. Jane did nothing to change her resource consumption and rather than receiving a bill for $600, she receives a bill for $400. Is she pleased? You bet. On the other hand, your neighbor, Stan, with another 2,500 square foot house, like Jane, doesn't change his pattern of resource consumption but he receives a bill for $800. Is he pleased? No way. There are also homeowners who aren't effected by the change. Their bill will be about the same as it was before.

Some people in the community are winners (they pay less than before). Other people are losers (they pay more than before). And some people aren't effected (they pay the same as they did before). In my experience, that's the way it always is with a change to a billing system.

Back to revenue neutrality for a moment, Stan's resource consumption was being subsidized by other rate payers. If the $200 difference is significant to Stan, he may choose to lower his resource consumption so he doesn't have to pay as much.

Any change in behavior by Stan or anyone like him will change the revenue stream. Until the pattern of resource consumption stabilizes at a new level, I don't know any way to precisely predict what the total revenue stream will be 6 months after the billing system is changed. Revenue neutrality isn't sustainable. The revenue stream will change.

Will the utility supplier organizations be pleased with the new system? Similar to the customers, some organization's will win because their revenue stream increases and other's will be losers as their revenue stream decline. Again, we will have organizations who will be winners, others who will be losers and some who aren't effected. The winners will likely be able to add employees and perhaps increase some people's pay packages. The losers will likely have to reduce the number of employees and perhaps reduce some people's pay packages.

I hope you see that it isn't always possible to create a system that satisfies what look like simple and reasonable requirements.

What can you do about the paradox? I suggest for any licensing system you decide which customers will be the winners and which will be the losers. Deciding who will win and who will lose principle holds for internal organizations. Revenue collection systems are a messy business and full of politics.

Most importantly, work with someone high enough in your organization who can make decisions rather than recommendations. Changes that impact revenue, customer satisfaction, and the power of internal organizations can only be decided by people at the top of the organization.

Finally, if you worship at the altar of revenue neutrality, you will only make tiny changes to your systems so your current state equilibrium isn't disturbed. That may be alright if only simple tweaks are required. In my experience with billing systems, that's rarely the case. The systems are preserved too long and they become so brittle they become the focus of your customers instead of your products and services.

Word Choices -- We -- Part 1

Mon, 15 Jan 2007 09:40:25 +0100

You transmit and receive meaning through a communication system that uses tools, such as words, sounds, tones, rhythm, touch, movement and so on. Words are a powerful tool within the system. They are used more consciously than any of the other tools.

This entry is the first in a series of blog entries about word choices, I will focus on two perspectives:

1. How you, as a sender, can use words to send a message that reduces ambiguity

2. How you, as a receiver, can ask the sender questions to eliminate ambiguity triggered by their word choices.

Let's start with the word, "we." According to www.wordcount.org, it's the thirty-third most used word in the English language.

I believe "we" is often used to escape responsibility. For instance, when I hear "We decided to...", it's more difficult for me to interpret than when I hear "I decided to..."

Saying "I" makes the meaning explicit. Without a clear context, choosing to say "we" creates ambiguity.

Recievers, when you hear, "We decided to...", are you certain whether even the speaker was part of making the decision. If you aren't, ask for clarification. I recommend asking, "I heard the word, 'we.' Who does the 'we' refer to?" If you. the receiver, are still uncertain about whether the speaker is being referenced, I recommend you ask, "What was your role in making the decision?"

Senders, when you catch yourself about to say "We decided to...," I suggest testing it's transmission effectiveness. First, ask yourself whether saying, "I decided to..." is a more effective statement. If it is, no more tests are necessary.

Second, ask yourself whether you are a member of the group being referenced. If the reference includes you, proceed to the next test. Otherwise, you are on shaky ground. What will you say if someone asks you, "What was your role in making the decision?" If you are a spokesperson for an executive or a group of executives, avoid ambiguity and looking clumsy by saying "Joe CEO decided to..." or "The Board of Directors decided to..."

Third, ask yourself whether the meaning is clearer by specifying each member of the group referred to by "we," for instance, "Jacqueline, Anthony, Josephine and I decided..." If this test seems like too much trouble, what will you say if someone asks you, "I heard the word, 'we.' Who does the 'we' refer to?"

Despite that "we" is the thirty-third most used word in the English language, it's a word that creates ambiguity. Receivers, be ready to eliminate ambiguity by asking the recommended questions. Senders, choose your words wisely. Otherwise, hope no one who read this entry is in the room when you speak.

Tell Him?

Thu, 16 Nov 2006 13:33:54 +0100

It's ironic that the Baseball Writers Association of America named Joe Girardi the National League's 2006 Manager of the Year. Giardi was recently fired by the Florida Marlins despite managing a young, low-rated team into contention. It seems his problem wasn't performance but rather communication.

Baseball reporters speculate the Marlins fired Giardi because of a run in with owner Jeffrey Loria. During a game on August 6, Loria made his outrage about the calls of home plate umpire Larry Vanover loud and clear to both Vanover and everyone near Loria's seat behind home plate. In the dugout, Giardi heard Loria chewing out Lanover. He leaned out and yelled to Loria, "You aren't helping."

When asked about the incident, Loria replied, "Everything is, you know, fine. But I don't want to talk about it." After the incident, Loria talked about the success of the organization but never about Girardi's role in it.

So what does that story have to do with management? For me, it highlights a typical communication problem.

Reading between the lines, I interpret that Loria was mad that his behavior, which most people would agree is bad behavior for an owner, was commented about in public by someone who worked for him. If Girardi would have made the same comment in a private meeting, Loria may have taken no offense

Loria may have been upset that Girardi, a employee, made any comment at all to him about his vitriolic display. Some executives never, ever want the hear anyone "beneath" them make a negative comment about whatever they do.

If a manager above you wants to hear neither public nor private comments about their inappropriate behavior from subordinates, you already know what to do and don't need any suggestions from me.

I do, however, have suggestions about a situation where you have complete control. Consider what comments you will or won't accept from people who are below you. If you are behaving inappropriately, is it okay for them to inform you?

For instance, during a meeting, you loudly argue with a client. Is it okay for a manager in your organization to say to you, "You aren't helping."? How about an employee? Should they let you keep arguing? Will you be embarrassed about being called out? Does your personal embarrassment require retribution?

I suggest pondering these questions:

What are you willing to hear from subordinates in public?
What are willing to hear in private?
What communication is out of bounds whether it's public or private?
What are you willing to hear from an employee that you aren't willing to hear from a manager?

Answering those questions will enable you to gain clarity about the types of communication you desire from your managers and employees. That knowledge will enable you to craft and communicate your desires.

Dancing With Independent Employees

Thu, 28 Sep 2006 17:12:18 +0100

How would your management style change if all your employees were financially independent and their objective was to master their craft while contributing to society?

Think about it. Employees would be free to choose whether to stay or go. Oppressive management styles would result in empty buildings.

Once upon a time, I had a manager named Ellsworth who, during an annual review, told me he had stack ranked me the lowest in his group. I felt like he was using a stick to motivate me. I would have preferred a carrot. Perhaps he had hoped to stoke my competitive fire. He didn't know that I had a low opinion of the role played by the other people in the group and an even lower opinion of the idea of treating my colleagues as the competition. Ellsworth's disclosure motivated me to do something different than he expected -- I left the job.

Independent technical people aren't motivated to sit on the fence. They seek to contribute and grow. How could Ellsworth have motivated me? Ask, "Steve, who are your customers?" Expand the list by asking, "How about Terra? ... Justin? ... Kathleen?" Ask, "What is their feedback?" Ask, "How do you feel about that?"

Ellsworth's mistake was assuming he knew how to motivate me. Managers often unconsciously practice the belief that the same thing that motivates them will motivate someone else. Their belief backfires when people are motivated by different things, which is the norm rather than the exception. Independent employees will ignore management and follow their own music. Dependent employees will, however, act motivated because they need their jobs.

If you want to motivate your independent employees, find out about the music inside their head. Dance with your employee. Explore their music and the way they like to dance. Stay with the rhythm of their music, offer a new step and let them join you.

Independent employees appreciate a new dance step when they are dancing to their own music. They think of it as adding to their repertoire. And employees who are adding new dance steps continue to dance rather than exiting to find a new partner.

Unintentional Lesson

Sun, 16 Nov 2003 02:00:00 +0100

Ever had one of your buttons pushed?

During a terrific session at the AYE Conference entitled Software by the Numbers, I discovered a new button of mine. Let's call it the "Planning" button.

The objective of the session was to explore the pitfalls of objectively trying to measure creative work. After giving general instructions to everyone, the session leaders split the participants into two groups -- development and measurement. I was a member of the measurement team. Our job was to provide the customer with graphical information about the state of the project and its estimated completion.

The leads sent the development group to one area in the room and the measurement group to another. Both groups were given a few minutes to plan their work. Neither group was ready after the prescribed period so Dave and Jeff, our customers, were asked for a time extension. It was granted.

In a flash, the extension expired and Dave and Jeff ask us to begin development and measurement. I had taken the task to create the graph and plot the data. Before I could finish drawing the graph, the customers began demanding information. Boom. My button was pushed.

I got angry. I thought the demand was unreasonable, especially after I had told Dave that it would take a few minutes before we could provide him the first set of measurements. He made complaints. I got angrier. He asked when the project would be complete. I told him to buzz off, which surprised both me and Dave.

What was happening for me? Cumulative effect. Like a victim of radiation poisoning, I had gradually become contaminated, without knowing it, until I was sick. My contaminant was each and every training class that had asked me to do a group activity and provided me with insufficient time to plan and execute.

You may be saying yourself, "But some projects in the real world run just like that." I agree with you a 100%: Lots of real-world projects do run just like that. Developers rush into development. Measurers rush into measurement. Little time is spent on planning.

If you, the designer, intentionally made this dynamic visible so that you could process it, I salute you. Otherwise, you may have fallen into what I now see as a common trap. In a rush to get everything done during the time allotted, you may have taught an unintentional lesson.

What lesson does a student take away when too short of a time period is allocated to planning during a simulation? One lesson is that allocating adequate time to plan isn't that important and isn't ever done.

It's the wrong lesson.

Make Results Predictable

Wed, 04 Jun 2003 02:00:00 +0100

Your organization is in chaos. You want to create pockets of stability. What do you do?

Make the results of meetings predictable.

Winfrey is the manager of a geographically dispersed software development team at the XYZ Corp. Ellsworth, her manager, assigns Winfrey the management responsibility of hosting a biweekly training conference call. The objective is to keep Winfrey's team up to date on the latest technology.

This type of training is traditionally an erratic, one-way affair at XYZ. A conference call and web cast are set up. Participation is designated as mandatory Participants have no say about the topic and receive short notice of a session, often less than 24 hours. No participant is given an opportunity to review the content. An outside speaker, invariably from HQ, delivers the presentation. Whether there is a Q&A period depends on the skills of the speaker.

Sound like a recipe for failure? Not always. And that's the biggest problem. Sometimes the sessions are TERRIFC. And sometimes they are WORTHLESS. It's usually a different speaker each time so there is no way to predict the value of a session.

I've been in similar situations. I have had managers who would encourage me to attend, regardless of whether my return on time invested could be predicted. My objection to that concept is still echoing in my head. One of my managers continually tried to coax my attendance by saying, "How will you know unless you attend?". #$@%

Winfrey recognized the problems at XYZ. She made participation optional rather than mandatory. She made a commitment to the team that they would receive a minimum of one week notice before a session. She also committed to sending out a reminder 24 hours before each session. She and at least one member of her team reviewed the training presentation two weeks in advance. She talked with the speaker and highlighted key material and asked that irrelevant material be deleted. She made it clear to the speaker he or she had 45 minutes for the presentation and that there would be a 15 minute Q&A period.

Winfrey didn't stop there. She also committed to her team that each session would start on time and finish either early or on time. She made the duration of the meeting 75 minutes and used the last 10 - 15 minutes to gather feedback from the team about what went well and what didn't. She also solicited what the team would like to hear about in the future. She published minutes of the meeting that contained the presentation, and her notes about Q&A and feedback.

And, most importantly, Winfrey made changes based on the feedback.

Yes, there were occasionally still bad sessions. But, they were the exceptions. And the participant feedback made the value of each session clear. The participants saw that their opinion mattered and that their feedback predictably influenced the design of future sessions.

Make the results of your training session or any other meeting predictable. Each bit of predictability reduces chaos.

Go Dark Loudly

Wed, 21 May 2003 02:00:00 +0100

The answer is "X has gone dark". The question is "What frustrates me?". I don't like feeling frustrated.

As a member a geographic team, I communicate with my teammates by either email or phone. Sometimes teammates go dark -- they completely stop communicating. Paul went dark recently.

Attempts to contact him by email received no reply, calls to his office phone went unanswered, calls to his cell phone went unanswered, voice messages received no response? Was Paul sick? Was he on vacation? Was he taking quite time? Was he alright?

Several days later he replied to me via email saying he had been stressed and just didn't have the strength to reply. I know Paul. I like him. He behaved badly

I see Paul differently now. Sadly, I trust him less than before. He may act the same way again.

I would still trust Paul, if he had just sent me a message announcing his intention. Others have.

I am not without fault. I've gone dark before. It took time for me to realize the affect that action had on my teammates. Trust is important to me so I now notify my teammates in advance. It's the courteous, caring thing to do. And I always feel good about taking that action.

Virginia Satir, a family therapy pioneer, said, "Changing is a matter of becoming honest with your feelings." If you have a similar problem, then work on recognizing your feelings before they trigger "gone dark" behavior. When I start losing the desire to reply to messages, especially from my friends, I know something is happening for me and its time to get honest with my feelings.

Recognition and honesty make choices available to me. I can make an announcement and work at home; I can make an announcement and take a day off; or I can make an announcement and go dark.

My advice is that if you must go dark, go dark loudly.

Your Team's Answer is Wrong, Part 2

Tue, 20 May 2003 02:00:00 +0100

In response to my post entitled Your Team's Answer is Wrong, my colleague Bob Lee writes --

(You wrote) "The trainers passed out a copy of the correct answer for the case study to all of us." (emphasis added) The definite article the as opposed to the indefinite article a is a killer here. Had they framed their solution as a solution rather than the solution would you have the same issues? (Even a correct solution affords room for other and even better solutions)

Bob, you've significantly improved the frame, but the painting is still ugly.

The teams produced their solutions based on a set of conditions. Unless the conditions are the same as when the solution on the handout was created, then we are comparing a landscape painting by Monet with one by Van Gogh.

The workshop conditions are never the same. There is always something different that happens in a workshop. For instance, Jane asks a question that connects a set of ideas together that Sally, a participant at another workshop, never hears.

Despite conditions being different, participants do learn by exposure to alternate solutions. It's all in how it's done. The workshop leader knows the pattern of solutions that typically emerge during her workshop. She can finish each team's presentation with a debrief period to increase the learning of all the participants. Rather than tell the members of the team "You misapplied this method." or " you missed this fact.", she can ask questions and capture the responses on a flipchart so participants can make their own discoveries.

Handouts, such as a bibliography or an article, are appreciated by everyone. People like me though are poisoned by the receipt of "the" solution or, even, "a" solution. Lead me to the solution. Don't tell me. The best bet is to transcirbe what was posted on the flipcharts and send it to the participants. That material is the best memory stimulator for what was learned.

A workshop is supposed to be about learning rather than specific solutions. The trainer's job is to teach people how to paint rather than handing out her paintings.

Your Team's Answer is Wrong

Mon, 19 May 2003 02:00:00 +0100

I had a nightmare last night. I was reliving a workshop that I took during a prior job.

I think the nightmare was triggered by a box of material I found in a storage area that contained documents from that job. I noticed the box was labeled "The Dark Years."

I was a participant in a three day workshop. Each of the participants was a member of a team working to solve case studies. The workshop culminated in a scored competition between the teams.

Case studies are a big step up from the traditional "tell" training so I was pleased. I worked with the other members of the team using methods discussed in the workshop to interpret the case study and make recommendation for solving problems. I was pleased.

We made flip charts that listed the key finding and recommendations. I was pleased. We elected a spokesperson and she shared our findings and recommendations to the entire group. I was pleased. We listened to other teams' presentations. I was pleased. I thought we were done. And then it happened.

It was like enjoying the taste of a delicious apple and discovering a worm. The trainers passed out a copy of the "correct answer". And they kept doing the same thing case study after case study. I woke up from the nightmare flabbergasted and reminded myself that I know longer worked for that company.

The trainers had spent a lot of time designing and delivering a class and they spoiled it by trying to show that they were smarter than all the teams that spoke. The saddest part of the story is that when I told the trainers that the right answer was already posted on the walls, they didn't have a clue what I meant. Despite all their design work, they preferred a a modified version of "tell" training.

You might be asking, "What should the trainers have done differently?". First and foremost, they should believe in the power of the people in the room. If a trainer sees something missing, they can add it to one of the flip charts created by the teams. That way they become a member of the workshop rather than the trainer.

One little thing, like a worm, can spoil something good. Don't accept or make the mistake these trainers made.

See follow up entitled Your Team's Answer is Wrong, Part 2.

Measure ROTI

Sun, 18 May 2003 02:00:00 +0100

How can you quickly measure the Return on Time Invested (ROTI) by the participants of a meeting?

Have the participants rate their personal ROTI during the meeting using the following scale:

4, Superb: I learned something that will save me significant time.
3, Positive: I learned something that will save me time.
2, Balanced: I broke even.
1, Negative: My time invested exceeded my return.
0, Worthless: The meeting was a waste of my time.

Explain the process to the participants by sharing that you will collect data about the meeting so that you can improve the design of the next meeting. First you will gather each participants rating of ROTI using a round robin poll. Share that you will build a histogram of the ratings. Finally, you will ask some questions and document responses on a flipchart. Ask everyone to make sure that their information is captured correctly.

Collect the ROTI data with around robin poll. During this part of the process, do not accept any comment other than a numerical score. Build the histogram. The whole process should take less the 1-minute. Remember the names of people who gave the highest and lowest rating.

Explore the upper extreme -- Suberb or Positive -- of the histogram by asking the people who rated the meeting the highest, "What did you learn that will save you time?". This exploration may require getting around the typical bland responses such as, "We had a great discussion about X. Help the person be more specific by asking questions like, What specifically about the discussion helped your productivity? Or, how are going to use what you heard to do something different? Capture the responses on a flipchart.

Explore the lower extreme -- Negative or Worthless -- of the histogram by asking people who rated the return as low, What went wrong for you during the meeting? And, what needs to be changed at the next meeting so that you rate the meeting higher? If the person consistently gives the meeting a low rating ask her, "Is this meeting a good fit for you?" Sometimes a person doesn't need to attend the meeting and they know it and the other participants know it. Like the upper extreme, capture these response on a flipchart.

Now you should be left with participants who rated the meeting Balanced. Ask the participants, "Is there anything else I should capture about the meeting?". Document. If the ratings are all Balanced, explore why the meeting isn't saving at least one person time.

Please, do not rate the meeting yourself or provide any feedback. Your job is to listen and capture the participants' feedback.

If you, the meeting leader, use the feedback to tune the design of the next meeting to increase its ROTI, this process will work. Otherwise, the collection process is a Worthless use of time.

Influencing Management

Sat, 17 May 2003 02:00:00 +0100

In response to my post entitled Check the Box where I suggest that you choose not to argue with your manager about doing a task whose primary purpose is the furtherance of a PR campaign with their manager, my colleague Bob Lee writes "How much Fantasy Experienced As Reality is building up above?"

It depends on your point of view, Bob. For Susan, who is told to do a knowledge transfer with her teammates, when she only has information to share, she sees lots of fantasy building up. For Jerry, Susan's manager, he sees some holes in the story but puts a positive spin on the task. For Jerry's manager, he doesn't see any fantasy. In other words, the data he uses to measure reality says things are okay.

I've spent most of my career, like Susan, as a knowledge worker. My ability to be an effective change agent depends completely on my ability to influence my teammates and management. They aren't going to do anything differently just because I say so.

I need creditability with people who are managers. And that creditability takes many forms -- it could be about my knowledge and skills; it could be about who I am as a person; it could be about a shared interest. Whatever it is, that person will invest more time in communication with me than someone else.

Let's say I have creditability with Noel who is a third-level manager. Now I have periodic opportunities to make proposals to Noel. If our interactions create a return for Noel, I'll continue to have opportunities to speak with him. Otherwise, I'll lose access.

One way I can lose access to Noel is to tell him that things are failing because he is ignorant to what's really happening. That's like yelling "Fire!" in a crowded building. I may face arrest and prosecution.

One way that does work is to add something to Noel's repertoire that benefits both him and the organization. For instance, I might suggest to Noel that other companies have used meetings as a leverage point in change efforts. The rollout of the Excalibur product requires collaboration between geographically dispersed teammates at a much greater scale than ever before. Let's increase the quality of our organization's collaboration by recognizing a meeting leader each week whose participants provide feedback that says the meeting saved them time.

If Noel bites, there is feedback in the system about quality -- data about return on time investment for the participants -- that is more important than checking the task box as complete.

Check the Box

Fri, 16 May 2003 02:00:00 +0100

How many times do you complete a task that you don't believe in just so that you can tell your manager it's complete?

Susan was asked by Jerry, her manager, to do a knowledge transfer to her geographically dispersed teammates about a recent internal meeting at HQ.

The internal meeting had been the typical three day death by Powerpoint endurance event. Susan had not seen a single stellar speaker. She heard many "key" messages but not much about the reasoning behind the messages. Now her manager, Jerry, wanted her to share the new knowledge with the team.

Should she tell Jerry that the conference call was a waste of time? She knew there might be some information transfer, but their certainly wasn't going to be any knowledge transfer without her knowing the reasoning behind the messages.

I've been in similar situations. The question is about how concerned my manager is with the quality of the conference call. She may care greatly about the quality of the call. But that may not be the reason for the task. She may not even care enough to get the participants's feedback. It may be as simple as she wants to tell her manager that the task is complete.

If I sense that the reason for the task is so my manager can check a box with her manager, it's useless to argue about the merits of other methods for transferring the information. It's not about the return on time investment for the people on the call, it's about my manager satisfying her manager's expectations.

I'm merely a cog in a system that enables my manager to check a box as complete with her manager.

Although I don't like this situation one bit, it's fruitless to argue. If I argue about every ridiculous task that I'm ask to do, I'll decrease my chance of winning an argument about something that is truly important.

I suggest that you check the box and move on. Save you arguments for a situation where it's about a return on investment rather than checking a box complete for the next level of management.

Sales Project Management

Thu, 15 May 2003 02:00:00 +0100

I manage projects as an engineer. There are other people in my office that are sales people. They manage projects much differently.

Truly managing a project as an engineer requires identifying risks. That assessment isn't for the faint of heart. You must find things that could go wrong. Sales people are often distressed by this search. One sales person said to me, "This activity seems so negative."

I've always considered reactions like this as stupid. Without risk identification and mitigation, the project manager has lost control. But that's leaving out the sales person's perspective.

Sales people are the most measured people in an organization. They can't escape the specificity of their contract (quota). It defines a precise number for their revenue target and precise numbers for the required product mix. If they exceed the numbers, they make good money. Otherwise, they are pounded with a hammer. And if that doesn't work, they are fired.

You may think that sales people are slime balls. Some of them are, but most are hard working people who bet that they are better sales people than their competitior. To win the game, sales people focus on being positive about every aspect of their personal and business life.

For instance, John was a salesman who was a member of a group that I played racquetball with every Saturday and Sunday morning. I saw John in the locker room one day and ask him how he and Melony, his wife, were doing. "Great!" he said. He shared with me that Melony was taking courses at the local college and looking forward to getting back into the work force since Mark, their son, was now in high school. In John's quest to be constantly positive he left out some important news -- he was going through a divorce.

Although that example is aextreme, it does give you insight into the personality of some sales people. John works hard at crafting a story that is pleasing to the ear. Imagine how threatening the search for risks is to him. It scares him to hear other people talk about things differently than he does.

Sales people will accept risk assessment after the product is sold, but are deeply disturbed about it before the sale. It could disrupt their carefully crafted story. If you have ever heard the saying, "Don't confuse selling with installing.", you now have a better idea about what dynamics trigger that aphorism.

You're Too Good of a Speaker

Wed, 14 May 2003 02:00:00 +0100

"You're too good of a speaker." I've heard those words and they depressed me. Now they put a smile on my face.

I realize now that my friends, all excellent technicians, were telling me that they preferred a complex presentation that was a little rough around the edges -- just like the world they lived in

I had a difficult transition from technician to someone who also speaks to audiences about technology. It took years to learn how to effectively communicate technical information.

My problem was I sought to have every single member in an audience like both me and my material. Negative feedback from any member of a 100 person audience would put me in a funk -- no matter if it was just a single person. I now see that both my desire and reaction were ridiculous.

If every member of the audience is important, then no member of the audience is important. The most successful speakers strife to reach a target audience rather than everyone. And the feedback that counts is from the members of that target audience.

Coping with feedback congruently sometimes requires thick skin. For instance, negative feedback that I allow to depress me only makes me an ineffective speaker. Positive feedback that I allow to turn me into a babbling brook is just as bad.

Bottom line, if you want to be an effective speaker, know your target audience and cope with their feedback.

PowerPoint Confession

Tue, 13 May 2003 02:00:00 +0100

I confess. In the mid-1980s, I really liked Powerpoint. I was a Systems Engineer for the Amdahl Corporation who gave hundreds of presentations each year. Up until PowerPoint, my choices for media was either a slide projector or overhead projector.

So, I could use the corporate slide set or hand draw my own overheads. The corporate slide set, even with deletion and reordering, just seemed so boring that I couldn't do it. If that weren't enough, when the lights were turned low, I couldn't see the audience's reaction to the material. Hand drawing my own overheads created a more customized presentation than the corporate slide set, but it was a time consuming task.

Enter Powerpoint on the Mac. For you history buffs, it ran on the Mac years before it ran on the PCs. I thought Powerpoint would help me build customized overheads quickly. I succeeded at the customization, but I didn't succeed at making them quickly. Creating a good overhead with PowerPoint -- I'm talking about illustrations rather than just bullets -- takes even more time than hand drawing.

My mistake was trading off practice on presentation delivery for quality slides.

I loved being "on stage" with my great PowerPoint presentation material. Filling the audience with important concepts and leaving them with those wonderful Powerpoint handouts excited me. Unfortunately, the concepts were only what I thought was important and the handouts were probably thrown or filed away after the presentation. And the viewpoint of the people as an audience rather than as participants led me in the wrong direction.

Today, I rarely use PowerPoint so my presentation material is no longer a series of trapezoidal projections. I know that a speaker can connect with his or her audience better with stories, whiteboard drawings, and experiential exercises. That connection requires joining the energy of the participants. and spontaneity on my part. My presentation plan must change to fit the energy in the room. I believe connecting is a clear differentiator between a speaker and a leader.

So, after that ramble, what's wrong with Powerpoint? The technology gets in the way of the connection between the leader and the participants. Study the typical presentation: The focus is on the trapezoidal projection. The projection is often bigger than the speaker. If you are giving a presentation, there is no law that says that participants can't be given key handouts and told to refer to them. You can put a lot more information on a page using a 600dpi laser/inkjet rather than a projecting a 72dpi PowerPoint slides.

Powerpoint slides with just bullet points seem to me as crutches for the speaker. The speaker looks at them rather than the audience. There is no law that says you can't use note cards or an outline.

I believe that an audience only become participants when they are engaged. No one needs Powerpoint to engage the participants. Any presentation that I have given that has had experiential exercises has had more connection and feedback. Thus, learning happens for all the participants, including me.

Coping with a Double Bind

Mon, 12 May 2003 02:00:00 +0100

In my last post , I posed the question, "What coping strategies are better than ambivalence and apathy (in a double bind situation)?"

There is nothing wrong with being ambivalent or apathetic about an environment that constantly puts you in a double bind. These strategies are reasonable and always available. My question was intended to provoke thinking about whether the choice of a different strategy is possible. My experience says that it is.

I have had the priviledge of working for a few people who were outstanding managers. I have also had a manager, Ellsworth, who was a real stinker. No matter how great my work, Ellsworth would tell me that it wasn't good enough. At the time, I thought he was a complete idiot. I now believe that in his heart Ellsworth was trying to motivate me.

Ellsworth's misguided attempts at motivating me were ineffective. I went from enthusiastic to ambivalent to apathetic. And I tried to put a good face on this a situation because I needed the paycheck.

During Ellsworth's reign, I happened to join a yearlong Systems Effectiveness Management (SEM) program led by Jerry Weinberg. Seven women and seven men who worked at different companies and supported each others lives both professional and personal. This experience showed me the power of a support group:

If Ellsworth was my only source of feedback about my performance and capabilities, then I was going to be in a constant double bind. With feedback from Don, Johanna, Bob and the other SEM members, I got a different perspective, which didn't leave me in a double bind.

Ellsworth's feedback became irrelevant and as well as the paycheck from that company.

So, if you are in a bad situation, create a means for getting feedback from someone whose opinion you value more than your manager's.

The Double Bind

Sun, 11 May 2003 02:00:00 +0100

Are you in a relationship where no matter what action you take that you are admonished by a person whose approval you seek?

For instance, a mother gives her son two different shirts as gifts for his birthday. He wears one of the shirts to his birthday party. His mother sees him and her first words to him are, "You didn't like the other shirt?"

Gregory Bateson, Anglo-American psychologist, created the double bind theory to explain the situation where a person receives conflicting signals from another person. Bateson believed that this situation is a crucial factor in cases of schizophrenia and autism.

I see a similar situation with conflicting signals far too often in corporations. For example, If an employee produces the agreed upon results, their manager admonishes them for not having produced more, having a poor attitude, or some other infraction. Nothing is ever good enough.

Although most employees don't go into a psychotic state. I believe that a continuing state of corporate double bind leads to employee ambivalence and, ultimately, apathy. Only an insane person would say, "Thank you, may I have another dose."

What coping strategies are better than ambivalence and apathy?

I'll answer that question in my next post.