THE AGILE CULTURE: LEADING THROUGH TRUST AND OWNERSHIP (2014)

Chapter 8. Tools to Deal with Walls

The Big Ideas

There will be barriers between us and getting to Energy and Innovation.

There will be resistance to change.

Focus on value not dates, manage up, and learn how to collaborate with non-collaborators.

It’s Hard

I sometimes think life would be so much easier if people would stop getting in the way. Sadly, that is rarely the case. If we are in any type of leadership position, we deal with people. And, at an organizational level, we deal with the organization’s culture. At the core, it takes collaboration to move teams or the organization from point A to point B. Ideally, we do this by creating a compelling and shared vision so that our teams and organizations, willingly and passionately, will move to point B. In reality, we might encounter people and a culture that are reluctant or hesitant to go along. This becomes a barrier that we must deal with, one we may come up against again and again.

We might hear things like the following:

Why should we do anything differently? Things seem to be just fine.

This sounds like another one of those management fads.

I am tired of change. Just leave me alone.

If the leaders are not on board, I am not going to do anything.

That sounds nice but will never work here.

Sometimes these walls come from rigid, unforgiving processes and rules.

What can we do about such “walls”? In this chapter, we present several tools that might be useful when you encounter a wall.

“I Need It by This Date! And I Need It All!”

Has this ever happened to you? You are tasked with leading the project that will create the company’s next killer product or that will replace that nagging legacy system or that will finally allow the company to analyze product and customer trends. Your marching orders are very clear—the project must be done by March 15. With the date fixed, you plan the project. You identify tasks, resources, costs, dependencies, and technologies and lay out a schedule. You manipulate tasks, resources, costs, dependencies, and technologies to achieve the project goal of hitting the required date.

When you meet with your project sponsor and stakeholders, are their questions all about the likelihood hitting that date? Whether intentionally or unintentionally, all things become subservient to hitting that date. Each time a dependency is late or a technology does not immediately work as advertised, you have to make project trade-offs. But the one thing you have learned is that you will not be able to trade off that date. So, you reduce the scope a bit and then a lot—whatever it takes to hit that date. Some things fall your way and, as the project nears its due date, you can, with confidence, claim that you will hit that all-important date. True, the project is different from what you first planned but you will hit your date. Your sponsor is relieved. Your stakeholders sing your praises. The product launches, the legacy system limps to the boneyard, and the analysis provides some insight. But the product does not do as well, the new system does not perform as well, the analysis of product and customer trends is not as revealing because, in order to hit that date, you had to make a few sacrifices—in some cases a lot of sacrifices. You did the best you could but because the date became the most important deliverable, you designed around the date—even if that required you to suboptimize the product, the system, or the analysis.

What about a different approach? We start the project the traditional way with a hard and fast due date. The project is a major—and innovative—upgrade of our customer portal. As we gather and sort through the high-level requirements, we ask, over and over again, what are we trying to achieve with this upgrade? How will we know that the project has delivered value? What are the drivers behind each required element of the upgrade? Who will use that piece of functionality and what do they want to accomplish? How would they benefit from the upgrade?

Taking this more customer-focused approach to the project changes the conversation and the insistence on meeting a specific date. To be sure, hitting a date still matters but delivering the desired value to our customers is the primary goal. As the project progresses, we make the traditional scope, time, and cost trade-offs but we make trade-offs that either retain or improve the value to our customers. In addition, our customer-value perspective encourages us and our sponsor to interact frequently with our customers—through a series of focus groups and product demonstrations—in order to determine which features and functions provide the most value. As we prioritize our work, the high-impact features float to the top and become the focus of what we will get done first. It turns out that our customers have a burning desire to know, in incredible detail, the status of their orders. It also turns out that some of the features we think are really cool and bleeding edge are just not that interesting to our customers.

When the project ends, we assess our performance. We delivered early the functionality that made the biggest difference to our customers and to the company. By continuously focusing on what creates customer value, we found the shortest, most direct path to customer value. As part of this ongoing prioritization we did not develop some of the features and functions that were originally planned—why build something our customers told us they did not really need or want?

But from a completely objective view, we were “late” with some of the low-priority features. Does this mean that the project was challenged? Only if the goal were to hit a date first and worry about value second.

As twisted as this logic sounds, how often is this our thought process? How often is a date how we define accomplishment? And, if this is common, let’s agree to stop doing so right now and focus on value first.

This focus on due dates will be one of the biggest walls you will hit. And you will come up against it again and again.

In real life there is always significant pressure to deliver the maximum value to the business and to our customers. This is evidenced by business managers demanding a long list of detailed requirements by a specific date. How do we deal with it? We need to understand the real issues and how best to respond to them.

The issue is a classic one:

The business needs the maximum delivery.

The development team has limited resources and time.

The effort required is uncertain.

How do we deal with this reality? The business must deliver as much value as possible but it is the development team that actually does the work with limited resources. Without goodwill and cooperation this often leads to unhelpful and wasteful conflict between the business areas instead of focusing on problems as a whole business.

How can we avoid this?

Start by collaborating to understand and accept the dynamics and the reality of the situation.

The business needs the maximum that can be delivered.

Both business and development teams are well intentioned and motivated to do the best that they can.

There is essentially a fixed set of resources and time available.

Because the effort is uncertain, we don’t know exactly what can be done.

If we overload the delivery team, they will be demotivated and deliver less than they might and at a lower quality than we want.

Iterative approaches help take the pressure out of the situation and enable maximum delivery.

Jointly focus on cash flow and speed to market rather than on some theoretical plan.

Get the cash flow going by delivering the minimal viable product as quickly as possible.

Prioritize. Create the product incrementally, tackling the highest-value items first.

Have the business and development leaders work together to enable increased effectiveness in the engineering team.

The business must be available for quick decision making when needed.

Invest in making the infrastructure and process as supportive as possible.

Remove interruptions.

Minimize unhelpful reviews.

Focus on delivery.

The foundation of dealing with this is a genuine partnership between business areas and development teams. A senior leader’s primary goal should be to jointly build a collaborative vision and alignment across the whole organization.

Managing Up

I once worked with a team that was not meeting their weekly commitments—consistently. I wondered why. Their work was always good when they did deliver. So I stopped by their work area.

“How is it going?” I asked. “You seem to be struggling with your weekly commitments. What is getting in your way?”

There was a pause. “Mr. Shore comes by and keeps giving us new tasks to do,” the team leader replied.

“You don’t stop everything and do them, do you?”

“Well, yes. We are going to work for him when this project is over!”

I now understood the problem and walked up to Mr. Shore’s office. “I know you are worried about getting the things built you will need in the future. And we will get them all done. Give us a list and the team will prioritize what they will do every week and they will deliver.” He did and the team was back on track.

A command and control manager is very difficult to deal with—but not impossible. As a team leader, if you have such a manager, you can manage up and protect the team. Or the team may select a leader from their team to manage this micromanager. How do they do this?

First, find out what is important to your manager and why. Most likely he wants control and certainty but how does he get them? Collecting metrics no one actually uses? Having people do it “his way”? Seeing progress on a daily or weekly basis? Measuring against a plan? Is he afraid of failure? In this situation, what can you do?

Generate Data

Somehow micromanagers think that collecting data will assure them that things are working. Whether the data is really useful or not, they still want it. The essential part is to not waste the team’s time. As the team’s leader, you need to minimize the impact on the team by gathering the data and creating the report, just as your controlling manager wants it. Protect the team.

“Do It My Way”

Use the Macro-Leadership Cube in Chapter 5, Ownership Tools, either as a drawing or a mental image. With your micromanager, identify and agree to the constraints and expected results but in quantitative terms. For example, it is not enough to have an expected result as increase sales. It must be by how much sales will increase. Five percent? Eight percent? Then ask the manager to step back as long as the team operates within the boundaries of the expected results and any constraints. As a first step, make sure the team agrees with the possible cube constraints and expected results before you talk to the manager.

Show Progress

Building an electronic stock exchange was a massive project. The project leader, Mr. Smith, was not technical so he focused on interfacing with the clients. After all, there were over 50 banks paying for the exchange, some very large and some very small. They all wanted their say.

I took the helm to deliver the product. After a close look at the effort, I realized that using waterfall methods would not cut it. There was way too much uncertainty to be able to accurately project the tasks and completions. We needed something else and the team figured it out. They started an iterative development process. The team designed, coded, and tested small bits of functionality and showed them to customers. The customers gave feedback and we adjusted accordingly.

However, Mr. Smith wasn’t technical. The only thing he knew about software delivery was to use waterfall methods. On such a high-risk project, was he willing to go for an experimental “made up” methodology like iterative development?

I wasn’t sure how well he would accept our approach and so I built a high-level waterfall chart. This chart had three of the familiar waterfall phases: design, develop, and test. I spread these three phases across the two-and-a-half-year project lifecycle. In the background, the development team continued to deliver small bits of functionality, fully tested, once a week, continuously integrating the bits daily and hardening the system every three months. I mapped this progress onto the appropriate phase on the waterfall chart.

I discovered that Mr. Smith often came into the office on Sunday afternoon to do his paperwork. I started going into the office on Sunday afternoons to have casual conversations about the project. Together, we would look at the waterfall chart. During the waterfall design phase, I would explain to him all of the design work we had done and were doing. During the development phase, I would describe all of the development that was done and under way. Same with the testing phase. And, because we were always doing design, development, and testing—I could truthfully tell him how what we were doing mapped to his preferred, comfortable, waterfall way.

He wanted to see progress—against his waterfall plan—and I showed him progress as he could understand it.

One of the ways to manage up is to translate your work into terms your micromanager understands.

Check In Often

Micromanagers want information, so give it to them. Let your micromanager know what is going on regularly. Find the best format for this: e-mail, reports, stopping by his office. Then talk about what the team has accomplished and what they are working on for the near future. Make sure that the team is pretty confident they can deliver on the tasks coming up. If you have issues, explain how you are solving them.

Collaborating with Non-Collaborators

“Steve, what are you doing here?” Steve was the leader of the workstation team for the stock exchange.

“You know why.”

“Actually, I don’t have a clue. What’s up?”

“If you don’t get John off the team, the team will throw him out the window.”

Okay. That sounded serious. After four prototypes on the user interface, John had volunteered to write the specification so other teams could develop the back end. Seemed straightforward to me.

“What happened?” I asked.

“Well, he wrote the spec but he didn’t write it based on the final prototype. He has written it on what he wanted the interface to look like.” In other words, the team had lost six weeks on an already tight schedule.

John is a typical non-collaborator. He decided to act on his own, fully independent from the rest of the team. Not only that, he was, in general, tough to work with.

When we think about moving from where we are and into Energy and Innovation, it is highly likely we will encounter walls—barriers that either slow us down or block us on our journey. And, no doubt about it, one of the most common and significant walls you will hit will be people who don’t want to change, who don’t want to collaborate. From the previous chapters and our own experience, we know that to create the high-trust, high-ownership, innovative culture we want, collaboration is key.

Non-collaborators can be both persons and processes. Non-collaborators come in many versions: people who resist new ideas that are not their own; like things the “way they are”; want it “their way” or no way; want to be the lone hero; are unfocused; or do not believe in the purpose. These human non-collaborators exhibit behaviors such as being disruptive or rude, withholding information the team needs, committing to one thing and doing another, working in isolation, and knowing it all.

Likewise, non-collaborators can be processes that require blind obedience, cause churn, burden teams, impose unnecessary work and effort, and promote process over results. Non-collaborators are difficult to work with—but not impossible.

How do we collaborate with non-collaborators? In this section, we offer techniques to collaborate with the non-collaborators you will inevitably encounter as you make your way up toward a healthy, energetic, and innovative culture. First, through an assessment process, you will gain insights on your non-collaborators to narrow down the techniques that you could use to collaborate with them. To figure out how to work with them, an understanding of what makes them tick will come in handy. Finally, what about you? Why do you want to work with these people and what risks are you willing to take? After all, something could go terribly wrong and you might be humiliated, isolated, demoted, and possibly lose your job.

With this information in hand, we look at several general techniques that help you work with many non-collaborators. Finally, with the help of our Trust-Ownership Model in Chapter 2, Trust and Ownership, the traits of your non-collaborators are mapped to this model to provide specific techniques for dealing with your non-collaborators.

Think of a Non-Collaborator

I bet that didn’t take long. It seems like there is always at least one. Is your non-collaborator your manager? A team member? Another team? Or a process?

A non-collaborating process is a process that keeps people from collaborating. For example, a stack-ranked, independent performance review system. If my raise depends on how high I am in the stack, I might not help others succeed and move up in the stack ahead of me. And I want the credit for my accomplishments; I don’t want others to have it. That’s not encouraging collaboration.

So, non-collaborators can appear anywhere in your organization.

Assessment

The collaborating with non-collaborators process starts by assessing your non-collaborator and looking at your motivation and risks in collaborating. We will first focus on the non-collaborator as a person or team, the more common type. Later, we talk about dealing with non-collaborative processes (a whole separate kettle of fish). This is followed by a separate section for assessing why you want to collaborate with this non-collaborator, what you are willing to risk, and how collaborative you are.

The assessment has many parts, so we have included a worksheet for you in Appendix D, Collaborating with Non-Collaborators Worksheet. In the meantime, let’s start the process.

Non-Collaborator Traits

I am sure you haven’t forgotten your non-collaborator. How do you know she is a non-collaborator? Does she have any of the following traits?

Obstructive

Hard to reach

Won’t attend meetings

Finger pointing

Not consistent

Can’t be trusted

Misses the big picture

Narrow world/company view

Self-promoting

Ladder climber

Has own agenda

Passive (no initiative)

Lack of interest

Lack of participation

Doesn’t listen to others’ ideas

Negative

Manipulative

Bureaucratic

Nonsupportive

Inflexible

Dismissive

Unkind

Stubborn

Difficult

Argumentative

Resists change

Defers decisions

Deflects

Disrespectful

Combative

Confrontational

Demagogic

Selfish

Takes credit for others’ ideas

Knows everything

Avoids accountability

Problem avoidance

Doesn’t work with the team

Not willing to help others

Works alone

Defensive

“That’s not my job”

Doesn’t complete work

Their way only

Withholds information

Self-serving

Unwilling to compromise

Does not follow the process

Blames others

“Can’t do” attitude

Now you have a better description of how your non-collaborator behaves.

Types of Non-Collaborators

It seems that most non-collaborators fall into three categories:

They don’t know how to collaborate.

They are afraid to collaborate.

“It’s all about me!” They think collaboration reduces their power and influence.

There may be more but these seem to be the most common. Let’s take a closer look at each of these.

Many times people don’t know how to collaborate. Or their experience has taught them not to collaborate. They don’t know even where to start or with whom they should collaborate. They might not trust the people they need to collaborate with.

Sometimes it is difficult to tell if they don’t know how or they are afraid to collaborate. In the workplace, people can fear many things—real or not. Common fears are losing control, failure, looking foolish or unqualified, and someone else taking credit for your ideas and successes. And in today’s economy, everyone worries about losing their jobs. This can be a risk if we are not seen to be adding value or if we lose control and fail. Other fears include discovering your new boss is a micromanager, landing in a career-limiting position, or being shut out of the inner circle.

Warren Bennis, one of the definitive pioneers in the contemporary field of leadership, reports that in collaboration people fear three things: losing their identity, losing their intellectual mastery, and losing their individualism [1].

As an example of fear affecting collaboration, in a stack-ranked performance review system, people fear if they collaborate, someone else with get the credit for something great they did. You can see the damaging effect fear can have.

Now we come to the non-collaborator I see the most, the “It’s all about me!” person. Not only are they difficult to deal with, they are difficult to like. Arrogance goes hand in hand with a huge ego. They not only feel they are superior to others, they know they are! They can be quite brilliant sometimes but at other times they just think they are. They have little or no self-awareness. They have a strong personal agenda: Their way is the best way for the company, when often it is not. It’s “my way or the highway” when dealing with them. Because their way is the best, they must achieve it. To do this they want power and control. They don’t ask for it, they take it. In other words, they must win.

They always want their fingers in anything under the spotlight. We taught collaborative leadership in a large company and Doris loved it. She became a trainer and brought the course to her entire division. But when she attended the Collaborating with Non-Collaborators course, she hated it and her evaluation showed it.

“How come Doris didn’t like the class?” the training coordinator asked.

“She’s a non-collaborator,” I answered.

“But she loves collaborating and collaborative leadership.”

“When does Doris collaborate?” I asked.

She thought a moment. “Only when the project is in the spotlight. The rest of the time, she doesn’t collaborate.”

“Correct.”

Often these non-collaborators are passive-aggressive, someone who is supportive and agreeable in discussion, yet after they leave the room they are negative and dishonest. They are polite, then suddenly angry. They come late to meetings to maintain control over the group. Obstructionist, victim attitude, always makes excuses, and difficult to pin down are all traits of a passive-aggressive person.

Enough about them. I am certain you have run across one of the “all about me” non-collaborators at least once in your life. When I think of a typical non-collaborator, I think of Dan. He had every one of the characteristics mentioned earlier: He knew what was best for the company; he had so many ideas and spent hours explaining them to everyone who would listen; he assumed he had power, yet he never committed to delivering on his ideas, or if he did, he never delivered any results. He withheld information to gain control and keep his power. He could do one thing and one thing well. When the company let him only do that in isolation, he left, much to the relief of everyone who had tried to work with him.

What Makes Your Non-Collaborator Tick?

Why does your non-collaborator do what he does? Why does a team behave the way they do? Well, if we knew the answers, dealing with him or the team would be much easier. However, with human beings, such things are difficult to know. We might get a sense of what drives him by looking at what actions he takes at work and how he views the world. Any insights you gain might shed some light on how you can collaborate with him.

When you answer the questions that follow, rely on what you think the answer might be. Your first reaction is often the right call. And you don’t need to be exact. All you need is a reasonable picture of how your non-collaborator sees and deals with the world, especially the work environment.

Motivation is the first place to look. What seems to get him excited about a project or an idea? How does he define success? Is it financial? Or job satisfaction? Along that line, how is he rewarded? And slightly differently, what recognition and acknowledgement does he want? What topics or initiatives in your organization is he interested in? Where is his focus?

Hidden agendas can be very difficult to deal with because they do not align with the purpose of the organization (thus, they are hidden). You might not be able to figure out what the agenda is but you should be able to detect whether he has one or not.

What is his leadership style? If you are dealing with someone who controls or micromanages, and you are a collaborative leader, be aware that your non-collaborator will likely push you. You must remain calm and ignore it.

Does he participate in company politics? Is he on a career path at the expense of the organization’s goals? And if so, who does he see as his competition? Is he a loner in the organization or does he have allies? And is he trusted by others above him and around him? Or below him?

Finally, what fears does he have? Fear of failure? Lack of recognition? Loss of power and control? Looking stupid? What do you see?

Why Do You Want to Collaborate?

I was facilitating a group of managers at an off-site meeting when one manager, David, rattled off a list of decisions he had made that affected the entire group. The silence in the room was deafening. “Well,” I said to the group, “There’s David, collaborating with himself again.” Everyone laughed, including David.

What are the reasons you want to collaborate with your non-collaborator? What is motivating you? How much are you willing to risk to make the collaboration work? These are all useful questions to help you deal more effectively with your non-collaborator.

Let’s take a closer look. What are you passionate about? What turns your lights on when you get to try something or do something? What projects at work make you want to come to work? Along with that, what do you do best? Are you good at mentoring, coaching, managing projects, teaching, doing? Most important, how do you define success? Making a difference in an organization, being an influencer, moving up the corporate ladder, a fancy title on a business card, a certain figure salary? What is important to you? Finally, what are your fears?

What about the differences between you and your non-collaborator? On the scales in Figure 8.1, mark where your non-collaborator sits and where you sit. For example, in the first scale, how far are they from the total non-collaborator end? How far are you from the total collaborator end? Do the same for the scales on trust and integrity. We talked about their importance in Chapter 2, Trust and Ownership.

FIGURE 8.1 Collaboration, Trust, and Integrity scales

You need to be clear about why you want to collaborate with this non-collaborator. What is your agenda? Is it for a business reason? Do you need information or actions so you or your team can succeed? Do you need your non-collaborator to stand back? You want to change your non-collaborator? While this last option might be your agenda, it is not likely you can change another person. You can only change processes or the way you interact with the non-collaborator.

Your Risks

How much are you willing to risk in trying to collaborate with your non-collaborator? If it doesn’t work out, you could risk losing your job or being demoted. Okay, that does sound drastic. However, it might happen.

On a less drastic level, you could lose respect from people and their trust. You might be moved out of the inner circle or be placed in the penalty box. You might be able to recover from this over time but you may also be limiting your advancement possibilities. Is dealing with the non-collaborator that important to you?

Do you care if someone else takes the credit for your ideas? This may matter if you are under stack ranking in your independent performance review.

What are your risks? Can you

Survive without your mentors?

Let someone else take the credit for your ideas and accomplishments?

Deal with any undeserved, negative labels?

Deal with public humiliation?

Handle your career being derailed in this organization?

Handle being fired?

Find another job as good or better within three months?

As you decide, consider all the successful risks you have taken in the past.

What Will You Do?

Do you think your non-collaborator will ever engage in collaboration? Or do you need to work around them?

Let’s look at the first option: he will at least respond to your efforts to collaborate. There are general techniques to help and there are techniques for specific cases.

Let’s start with the general techniques first.

General Techniques for Dealing with Non-Collaborators

When dealing with non-collaborators, communication, the content of the communication, and the way you deliver the communication can all be misconstrued. I have divided the techniques into these three categories with techniques for each category.

Communication

The language you use, the frequency of communicating, and your intent are important. Remember, your non-collaborator might be tuning you out, so extra effort needs to be made so she can hear you.

Speak So You Can Be Heard

“My developers don’t know how to communicate!” one manager said to me.

“Did you hire them to communicate?” I replied. “Would you like to send them to a communications course or have them write code?”

The answer seems obvious. When people are going on and on and the language seems more and more obscure, that’s when you need to pay attention. They have something important to say. Listen carefully. Learn to hear their language and speak it back to them.

Once I tried this with a non-collaborator and every time I would get close to understanding enough to talk to her, she changed the subject. I would set about trying again only to have her change the subject again. She was a brilliant woman but eventually left the company because people stopped talking to her.

Use a language your non-collaborator understands. Remember what is important to your non-collaborator from the questions you answered earlier in this section.

Communicate Often

And over communicate. State everything you know about the topic. When information is withheld, people are angry and afraid. Say everything and watch for signals that enough has been said. Check in with your non-collaborator on a regular basis so he knows where things are.

Practice a Forward-Going Approach

Don’t wait for your non-collaborator to come to you. Go to him. When I worked with a marketing team for an online shopping company, the marketers always wondered what was coming next from the web developers. “Just ask them,” I answered. “They’re sitting on the other side of the room.”

Content

What you are saying matters. What is most important is value to your business and value to your customers. Don’t communicate only the problems, come with a few possible solutions or pathways to getting to a solution. Finally, share all the information you can. Be transparent.

Focus on Business Value

“We need some help! Everyone is working like crazy, a lot of overtime at night and on the weekends. We need another person on the team.” I was desperate. As team leader, I was watching the team work harder and harder to get their work done, wearing themselves out, losing motivation, and beginning to make errors that caused more time in rework.

“What do you mean? The work always gets done. I thought software teams always worked that way.” That was the manager’s response.

I was floored. I didn’t understand. Then I realized I hadn’t helped my manager understand. He had a budget and his budget was tight. So I did my time-to-benefit for him. I showed how much sooner the project would generate the benefits if we added another resource to the team. The costs of the additional resources were so much smaller than the benefits of accelerating the project schedule. But until I spoke in the language that he understood (return on investment, time to benefit, business value), he saw only the additional and unacceptable costs. When presented with the data in his terms, he approved the new hire.

Delivering value to the market is the main reason we do business, but it is not a mathematical calculation. It is a conversation. Speak in terms of business model, time to value, revenue gain, and cost reductions. We can’t deliver products and services alone.

Bring Solutions, Not Just Problems

“Hi, Chris. How’s it going?” I had stopped by the coffee room for a minute. Even though I was an executive on the project, no one worried about telling me what I needed to know.

“Okay, but how long do we need to keep covering for George? It’s been three months and he is still learning.”

Oh, no, I thought. This is a critical member of a critical key team. We knew it was complicated to bring a new person onto the team—difficult enough that we estimated it would take about six weeks for someone to contribute to the team. With George, this time had at least doubled. Rather than answer Chris, I waited.

“Is there another place in the organization for him?” Chris continued. “He is a talented guy and he has learned a lot about the system. He’s just not the right fit for our team.”

I trusted Chris. He was a talented developer and a loyal team member, very committed to the success of the project. If Chris said he wasn’t the right fit, he wasn’t the right fit. After all, his team had picked George to work with them. I found another place in the organization for George and got a replacement for him on Chris’s team. All worked well. Rather than just present a problem, Chris provided a solution—move George to a team where he would be a better fit.

When people come to my office with problems and no solutions, I ask them one question, “How do you want to solve that?” Niel asks, “What do you want me to do?”

Managers and leaders hate hearing people complain, which, when they come with no solution, that’s what it is. People who bring only problems appear as whining, and that’s not effective. Bring solutions to offer for discussion.

Share Information and Be Transparent

Make sure you hold nothing back from your non-collaborator. If you do and she finds out, she will never trust you again, making it difficult to collaborate. This might be difficult if your non-collaborator is not trustworthy or has broken your trust with her. Protect yourself, but not at the cost of withholding information that may cause your non-collaborator or you to fail.

Provide information as soon as you have it and post it so it will not be lost when it might be needed again. Many times non-collaborators withhold information at the beginning of the project and when the project starts to fail, they jump in and provide the information so that they can be seen as heroes by rescuing the project. And what does the organization do? Reward the hero! We thus reinforce the non-collaborative behavior.

Communication Delivery

Who delivers your communication and when are important. Include more than you and your non-collaborator in all conversations. Have someone else deliver the message. And if you or your collaborator are having a bad day, wait to give him your message.

Have Three People in the Collaboration

“Sam, you committed to having your report in by Friday. How is it going?”

“I never said I would finish by Friday!”

How many times have we heard something like this? People will say something in a one-on-one conversation and then deny that they ever said it. This makes it difficult to move forward and solve the issue or exploit the opportunity—you are too busy arguing about what you agreed to.

An effective way to avoid an argument like this is the “three people concept,” which is based on game theory [3]. If there are only two people in the conversation and one withholds information, it is difficult for the other person to detect. If there are three people and one withholds information, the other two have a much better chance at detecting that information is being withheld. Always have a third person in the room when you have a conversation with a non-collaborator. This does not mean that the third person is in your corner. She can be neutral but she needs to be present.

Find an Influencer to Influence Your Non-Collaborator

I see it again and again: group decisions being filtered or altered by communication through the team leader only—providing a possibly unrealistic or an incorrect interpretation of what the team decides. One leader, Sally, was concerned with the decisions of a committee reported to her by the committee chair, always by phone and with just the two of them on the line. Because Sally knew all the people on the committee, she thought what the chair reported didn’t sound like decisions they would make. When she checked with the committee members, they said they certainly had not agreed with the decisions the chair had reported. In her next call, Sally confronted the chair with what she had heard from the committee members. The chair denied it and repeated her original set of decisions.

This went on for six months. No matter how many times Sally asked, the chair always said, “That’s what the committee wants.” Finally, Sally reached out to someone the chair respected and would listen to. This influencer got the chairperson to see the value in what the committee wanted to do and report it correctly.

Watch Your Timing

If your non-collaborator is having a bad day, stand back. Wait for a better time to collaborate. One time a member of my team completely blew up a project iteration. The team dealt with the fallout and moved on. Two weeks later, that team member came to me and asked for a raise. That is bad timing.

Be sensitive to what else is going on the lives of your non-collaborators. Are they under pressure themselves? Are they working on a tight project deadline? Are they distracted? If so, give them some room and time and watch for the right opportunity to have a real, meaningful collaboration.

Specific Techniques for Dealing with Non-Collaborators

With the help of the Trust-Ownership Model, we can map the traits of non-collaborators to each of the quadrants in Figure 8.2. Based on those traits, we can then think of ways to move the non-collaborator toward Energy and Innovation. Remember that this is a spectrum and your non-collaborator could sit in more than one quadrant.

FIGURE 8.2 The Trust-Ownership Model

Where do we start? By answering the question, “Where is your non-collaborator on the model?”

Now, let’s take a look at each quadrant.

Conflict

I was just going to bed when I noticed my dog, Missy, wanted to go out. My housemate said, “She’s okay. She doesn’t need to go out.” It sure didn’t look that way to me. If Missy were able to stand up, she would have been crossing her legs and doing an “I have to go” dance. So, I let her out. Of course, once she got outside, there were many more interesting things to do out there than just do her business. She refused to come back in the house. I was stuck. Here I was, standing outside trying to get a recalcitrant dog to listen to her very forgiving master.

However, my housemate always could get Missy to obey her, but my housemate was already asleep. What to do, what to do? Having no other choice, I got her up. As you might expect, she was not too happy. When she finally came outside, she said, “Why did you let her outside?” My response? “That’s not helping me get her to come inside.” “But I told you not to let her out.” And again, I replied, “That may be true, but that is not helping get Missy inside.”

This is an example of Appreciative Inquiry (AI),¹ a tool to stay out of the blame game (because there is absolutely no value, zero, in blaming people or processes) and focus on how to move forward. The old form of problem solving is to identify the problem, analyze the causes, and plan the actions. The basic assumption is that there is a problem to be solved. AI values what exists, envisions what can be, and discusses the next steps. This assumes an organization and the people know about and want to focus on the future possibility.

1. David Cooperrider is generally credited with coining the term “Appreciative Inquiry.”

Old ways of solving problems look back at what went wrong, what happened, who is to blame, and how we fix what went wrong. AI looks forward: what’s working, what’s possible, and how we can achieve it. We call this “falling forward” to remind ourselves that we learn more from how we recover from our mistakes than figuring out how we made the mistakes.

Often, non-collaborators don’t want to participate because they don’t believe in the solution. One way to engage such non-collaborators is to spend time, with at least three people in the room, brainstorming and discussing the pros and cons of various potential solutions.

When doing this, try to find something you can agree on—no matter how small. In one particularly tense situation, one person resisted collaborating, was uncooperative, and resistant to everything until I found she had a dog that she was fond of. Because I also love my dog, we found some common ground—completely unrelated to the topic of our conflict. With this dog-lover relationship, we had a starting point and things moved forward.

Micromanagement

Nothing, and we mean nothing, is worse than someone telling you what to do, how to do it, and by when. People are not chess pieces. And when someone treats them like they are, they give up and do the minimum to get by. They don’t feel trusted or valued.

What can we do about micromanagement? Understand why the non-collaborator micromanages. Is it fear of failure, fear of losing control? Is he afraid to be wrong? Using the Macro-Leadership Cube (see Chapter 5, Ownership Tools), build a cube together where the walls of the cube are results, budget, marketing window, resources, and so on. The results must be specific and measureable. Then ask the micromanager to step back while you or the team’s work remains inside the cube.

Sarah was going into a meeting with her micromanager boss. Tired of being judged by how she did her work rather than by the results of her work, she asked her boss if she had done something wrong. “No,” he answered. “Well,” she said, “that’s the way I feel when you tell me in detail what I need to do. When you do that, I feel as if you don’t trust me.” He was surprised and said he didn’t mean it that way and it never happened again.

Check in regularly so there are no worries about what you are doing.

The Passive Non-Collaborator

This type of non-collaboration could be due to fear, lack of understanding, cultural differences, and lack of interest in the goals. When dealing with passive non-collaborators, ask questions that attempt to develop some passion for the goals and results. Ask what they care about, what is holding them back from contributing or pursuing their passion, and advocate for them to pursue their area of passion (even if it means they find that passion somewhere else).

The Passive-Aggressive Non-Collaborator

In general, this is a competitive person with a lack of respect for others. Such a person is often all about self-preservation or pursuing a personal agenda. Whatever you do, do not engage in a power struggle with this person because once you engage, she has won. Wrap her in the process and make her step into her responsibility by making it the only step she can take.

“What if we don’t have a process to wrap them in?” someone asked.

“Make one up,” was my answer. “Where do you think some processes come from?”

Make them commit in public, with at least two other people in the room. Take the fun out of being dysfunctional. If people are disruptive, look closely to see if they are getting a reward and remove it. Even negative feedback can be a reward for some people.

When they say, “That will never work,” ask them how they would solve it. Again, make sure there are at least two other people listening. Whatever you do, don’t let a passive-aggressive person be in a leadership position—his team is often the target of his aggression.

Non-Collaborating Processes

At dinner one night at a conference with a peer, we talked about performance reviews.

“I can’t stay long, I have to do the performance reviews of my team.”

“Why are you doing them?” I asked. “Didn’t they set their own goals?

“Yes.”

“Then let them evaluate themselves and send it directly to your HR department. They know more about how well they have achieved their goals than you do.”

Weeks later I saw my friend at another meeting and asked how it went. “I did what you suggested, and it was great.” And her team agreed.

No doubt about it, independent performance reviews, especially those with stack ranking, will be the most difficult to overcome. Explain the Trust-Ownership Model to your HR department and ask them to take ownership of helping set up evaluations that help teams collaborate to reach the Energy and Innovation state. Ask “why” they do independent performance reviews, and explain their detriment to team collaboration. And bring data! Check out Alfie Kohn’s book, Punished by Rewards [3]. Start with Chapter 10, page 181.

Some years ago I was running the education department of a local university and one of the administrators came to see me.

“Don’t be cross, but I’ve done something against the rules,” she said. “One of our students was looking for a computer-based language training book, but all the ones we have are loaned out, so I just went to the local store and bought one without approval. It would have taken ages to get the spending approved and she needed it right away.”

Far from being upset, I was delighted. I publically gave her recognition in front of the whole team and I personally handled the escalation with the procurement process.

Whatever you do, don’t let a process cause you to fail.

Team-to-Team Collaboration

Whatever we say, no matter how much we would like to avoid dependencies in our work, we have to collaborate with other teams. And it is not always easy. First, each team may have their own priorities, especially if the two teams have different bosses. Sure, eventually, if you go up the food chain, we all have the same boss. But, who has the time or the credibility to not take care of things at our level?

In many cases, there is tension between marketing and engineering—two teams that should and must work together but have very different styles and goals. They rarely act as one team. They seem to see each other as the enemy.

The marketing viewpoint? “They don’t deliver.” “They take too long.” “Who knows what I’ll get and when?” “They make things too complicated.” “The customers aren’t happy. There are too many issues in the field.” “They have to do what they are told and they don’t.”

And engineering’s perspective on marketing? “They keep changing the priorities.” “They think it’s simple to build.” “They don’t really know what the customers want.” “We don’t get good direction.” “Our questions are not answered fast enough.” “They don’t understand technology.”

One way to set up such teams for success is the Product/Project Inception Planning tool we describe in Chapter 6, Business Alignment Tools. When the teams come together and collaborate with a common goal in mind, they agree as to priorities, risks, and opportunities to reduce complexity and uncertainty.

Remember, it is really one team. Refer to it as a “whole team” or “megateam.” Don’t quantify it by using “our team” and “your team.” It’s one team.

One of the important elements of this inception process is to build a common vision together. Use a sticky note exercise to brainstorm the product potential and the critical success factors. Openly discuss what everyone sees and find one vision together. As described in Chapter 6, use this vision to define decision filters the team will use to hold to the vision. Remember and use the vision and the decision filters at each meeting.

Validate each other. Discuss why you need the skills and abilities from each team to reach the vision and goal. Accept risks collectively. Risks are the whole team’s risks.

And hold past dodgers accountable. At the end of every action generating meeting, ask everyone, “How are we going to hold each other accountable?”

Working Around Your Non-Collaborator

Suppose you have tried all of these tools and your non-collaborator will still not collaborate with you. First, when you encounter him, reflect, don’t react. You don’t have to respond to a question from him right away. Take a minute. One of my favorite responses in such a situation is, “I’ll get back to you on that.” It gives me some time to process how I want to respond to my non-collaborator. And don’t take it personally. Don’t react if he has pressed one of your “hot buttons.” And if you can’t remain calm, leave the room.

If you are the leader and need to have the non-collaborator off the team but you can’t make that happen, sideline him. Make sure he has no critical path tasks or any task the rest of the team depends on. The team will instantly know what you have done. If you don’t deal with the disruptive non-collaborator, the team will be angry with you because they are carrying the burden of this obstructionist.

Whatever happens, make sure you protect your team.

What if your non-collaborator is your boss? Some techniques are included in the section, Managing Up. However, it may be time to move on to another position within the company—or to another company.

In Summary

It is much more important to generate value and reduce time to value than it is to hit a date. Ideally, we do all three. But if we must sacrifice anything, let the date move and focus intently on delivering value. Value comes when we innovate in what creates our unique value proposition and standardize around best practices for everything else. And remember, it is our customer who defines value.

When a manager begins interfering with the team’s focus and creates unnecessary distractions, productivity decreases. A leader, either of the team or in the team, can manage this manager using several techniques: providing the data and reports himself; using the Macro-Leadership Cube to help the manager understand the boundaries of the team efforts and let them work inside that cube; show progress and check in often. Work on keeping the manager from disrupting the team’s progress.

Collaborating is essential to the delivery of value to customers. However, there may be people who don’t want to collaborate. In this section, we talked about the steps and tools to try to collaborate with this resistance.

Identify why your non-collaborators do not want to collaborate.

Understand the system they work in, what motivates them, how they are acknowledged, how they define success, and so on.

Understand the system you work in and the level of risk you are willing to take on.

Use specific and general techniques to collaborate with your non-collaborators.

References

[1] Bennis, Warren. Beyond Bureaucracy: Essays on the Development and Evolution of Human Organization. San Francisco: Jossey-Bass, 1993.

[2] Nash, John. “Two-Person Cooperative Games.” Econometrica. Vol. 21, No. 1 (Jan., 1953), pp. 128–140.

[3] Kohn, Alfie. Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A’s, Praise, and Other Bribes. 2nd Edition. Mariner Books, 1999.