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

Chapter 5. Ownership Tools

The Big Ideas

If you provide the answers, you have taken ownership away from the team to find their own solution.

Ownership cannot be given. Leaders need to help their teams take ownership.

Leaders, focus is on “what” and “why” but never “how.”

The Macro-Leadership Cube is very useful in defining leader and team ownership.

Give or Take?

I remember my first major leadership job. I sat in my office for several days waiting for someone to come and tell me who I should go visit, what I should take on, and what needed to happen. Suddenly I realized no one was going to tell me! I had an area of responsibility with specific goals, and it was up to me to decide how to achieve them.

We have seen it many times. Most teams have never had ownership. When a leader walks in and says, “I trust you. You now have ownership,” teams often don’t know what to do and don’t believe they really have ownership. If they don’t understand the real goals of the business, they might go off and build something that does not align with the business goals or meet customer needs.

I asked several leaders I know how they help their teams take ownership. One thought for a minute and said it was difficult. Then he asked me how I did it. “Well,” I said, “I try one thing and if that doesn’t work, try another.” “Exactly. It depends on the person.”

In this chapter, we present ownership tools in three groups:

How to keep us, the leader, from taking ownership away from our team.

A collection of ideas for leaders to help their team take ownership.

A Macro-Leadership Cube that helps define the constraints and enables the team to move anywhere as long as they stay inside the cube.

Let’s take a look.

Taking Ownership

Ownership has many facets. Leaders can’t give ownership; teams must take it. But they need help. In most cultures, teams are deep into “just doing what they are told” and are afraid to do anything else. So leaders must step back and help teams take ownership. Leaders can, however, block teams from taking ownership through control.

Unfortunately, it is very easy for leaders to take away ownership. It can happen in an instant. It is difficult not to take away ownership. In fact, often we have no idea we are doing it when we do it.

In this section, we provide tools for both efforts: helping our teams take ownership and then keeping ourselves from taking it back. Let’s look at the easiest tool first.

Don’t Take Away Ownership

“I’m stuck. I can’t figure this out.” We hear this many times from our team members. And our immediate response? “Have you tried ___?”

We are natural problem solvers and we want to help by finding the solution. However, when you do this, you take ownership away from this person or team. You now own the solution.

In many IBM teams, the architects used to approve designers’ designs. Once they approved them, however, the architects owned the solution and if there were problems, the designers were off the hook—it wasn’t their problem, it was the architects’ problem. When this happened, thedesigners would set about building the approved solution. If it became apparent at any time that the approved design would not work, the designers thought, “It’s not my fault. It will work eventually. Bob approved it!” They kept working on a flawed design, wasting many hours.

No longer. Architects make themselves available all day to discuss with designers what they have in mind. The designers are fully responsible and accountable. The architects never approve any designs, either formally or informally.

Don’t Give Answers—Ask Questions

Our position in the company matters to some people. That means if you are a leader, subject matter expert, or thought leader, with lots of experience or many years with the company, people give your answer more weight and give their own answer less weight.

It is very easy for leaders to take away ownership by accident. One day one of my development leads stopped me in the hall and laid into me.

“This is just stupid. Why are you making us do it this way?”

I was completely taken aback and asked him what he was talking about.

“We’ve been told that you said we have to design the solution this way!”

Then I realized what had happened. We were all at the water cooler one day discussing potential solutions to this problem. I had simply said, “Would this work?” Because I was the senior manager, someone had taken my water cooler remark as a directive and decided that I was telling them this was the way the problem had to be solved. I quickly sorted this out but learned that it is incredibly easy to take ownership away from the team.

How do we not take ownership away from our teams? One way is to not give them the answers, no matter how hard they try to get one from you. Sound simple? Yes. However, it is not easy to do. To test this, find a peer you trust. Ask her to think up a problem that you could answer and have her work very hard to get you to give her the answer. You, on the other hand, will work very hard to not give her the answer but help guide her to discover the answer herself. Be careful you don’t give the answer away in the questions you ask.

How did it go? Most managers find this very difficult. It is hard not to give the answer, especially if you think you know the answer. (Remember, times have changed. Your answer may not be the best answer these days.) Pollyanna asks, “How do you want to solve it?” And Niel asks, “What do you want me to do?”

Here are some questions other leaders have found useful in helping their teams:

What problem are you trying to solve? What are your assumptions?

How would you describe the issue?

What options have you explored and why? What are the pros and cons? What solutions have you excluded and why? Is there anything that has not been considered so far?

Who have you discussed this with? Do you know anyone who has done this before? What have others done to solve this?

What is limiting your progress at this point?

Which constraint could we relax?

What feels right to you? What ideas do you have?

Reasonable next step? What do you think should be done? What do you need to determine the solution? Do you need a stakeholder view?

What would be best for our customer?

How are you going to get more data?

What will happen if you don’t address the problem?

What questions work for you?

This takes practice. Write your best question on a sticky note and put it in a place to remind you all the time of what to say. And when you do blunder, apologize immediately.

Don’t Leverage Your Position to Get What You Want to Hear

In what other ways do we take away ownership—unknowingly? Let’s take a look at another example.

What happens when you get estimates from your team? “How long will it take you to build this?” the manager asks. “Three weeks,” comes back the reply. And what’s the first thing out of the manager’s mouth? “Can you do it in less?” And because the manager is the boss and the developer might worry about his job or position and doesn’t want to seem unhelpful, he says, “Okay, two weeks.” Now who has ownership? The boss. Is the developer going to spend late nights getting it done? Not likely. Most people, when they are asked for something and commit to it themselves, will do all they can to make it happen, because they have ownership.

When Paul retired from IBM, he worked with us inside IBM as a consultant. One day we were in a conference room with our client taking a break. “Pollyanna,” Paul asked, “how do I get reimbursed for my expenses? Do you have a form?” “No,” I answered. “Give me an amount and we pay you.” “No receipts?” “No, I don’t want you wasting your time filling out forms or collecting receipts. Give me a number.” Our client shook her head thinking about all the forms she had to fill out, all the corrections she had to make, all the receipts she had to justify. She didn’t have ownership of company expenditures.

Don’t Correct Mistakes—Ask Questions

In another example, I went for a set of X-rays one day. (I’m okay. Don’t worry.) My doctor had ordered a set they did not do very often, and the technician was training someone new. She asked if I minded her showing the new technician how it worked. “No problem,” I said. After showing him how to do it, I let them practice on me. Then, one X-ray had to be repeated. “Let the trainee do it this time,” I suggested. She agreed. But she kept correcting him through the entire process. She took away ownership and his chance to really learn how to do the X-ray. All she needed to do was ask him to try again. Then he would try harder until he got it right.

Once, a CEO of a billion dollar company was shocked at my direction to not correct people. “What if my accountant comes in and I spot an error? Why can’t I tell him the answer?” he pleaded. “Well,” I said, “if you do, next time he won’t spend the extra effort to make it right. He will let you correct it. You have ownership.” He never forgot that conversation. Whenever we talked, he gave me his report, “I have not been correcting others’ errors. I ask them to check their work and make sure it is right before they give it to me.”

Help Teams Take Ownership

We were building a control system for an electrical power plant. The team had identified all the efforts and each person had volunteered for what they would deliver. The very next day, Jeff appeared at my desk. He had assumed responsibility for a key piece.

“Hi, Jeff. What do you need?” I said.

“Pollyanna, how do you want me to build this?”

“Well, build it the way you want.”

The next day, he was back at my desk. “Pollyanna, how do you want me to design this?”

“Whatever you think.”

The next day, he was again at my desk. “Pollyanna, how do you want me to do this?”

I was speechless. After a moment I said, “Jeff, you are here because of your ability, expertise, and commitment. Give it your best shot. I am here if you need me.”

So off he went. Then I was stuck. I couldn’t check up on him—that would have shown I didn’t trust him. So I waited it out. I saw he was interacting often with the team but he never came back to me. As we began integrating the designs and pieces together, his work required the least effort and had the fewest problems. He had taken ownership.

You can’t give people ownership. You can trust them and provide the goal and hope they take ownership, but you can’t walk away. Most people are so ingrained in the “just tell me what to do and how to do it” culture, they may not even know how to take ownership.

Let’s look at another example.

Independent performance reviews not only take away ownership of our evaluating our own goals, but stack ranking of those reviews also drastically reduces collaboration and teamwork. It seems that people think, “Why should I help Dan? If he ranks higher than me, he will get a bigger raise.” This is so counterproductive.

“We need our VP to get HR to stop these reviews. It is getting in the way of our being productive as a team,” Tony said at a recent meeting.

“Hmm,” I started to think. “We could ask for a minor change. We could try to understand why they need us to do reviews and find an alternative. We could . . .” Then I stopped. I was taking ownership away from HR.

“We need to find some people in HR who will listen,” I started, “and show them the Trust-Ownership Model. After explaining how it works and how performance reviews get in the way, we ask for their help in getting us to the green box.”

We explained the issue to the HR department and let them take ownership of improving the performance of the teams in their organization—the entire organization.

How can leaders help teams and people take ownership? It cannot be done without the team feeling they are trusted. That must be clear from you and clear to them. Let’s look at some tools for building this trust.

Create a Safe Place to Fail

We worked with an architecture firm with seven executives and over 100 architects. Every design put in front of a client had to first be approved by the one of the seven executives. This created quite a bottleneck. “It’s our reputation,” the executives explained. “It has to meet our standards or we are sunk.” That’s a good reason but it was really slowing them down in delivering to their customers. In addition, the 100 architects felt stifled. Even worse, they felt little ownership for their work product. Their attitude was, “It does not matter if I do great work—the executives will find something they don’t like.” So we created a process where the architect would present his design to the company before it went to the customer. Anyone could attend and make comments, including the executives. And because the review was in an open forum, it provided a safe place for the architect to “fail” and then correct before his design was presented to the customer.

Find a way for teams to test out their ideas before failing in public.

Let the Team Make Decisions

I can’t think of a single decision I should make for my teams. I am technologically dead. All I do is implement the decisions the team makes. Okay, I ask questions—to understand why they want to do what they want to do. I ask about how that helps them deliver the product but actually I have no clue if it is right or wrong. I have found that if I treat people as professionals, they act as professionals.

Recently, a colleague was talking about a team he was working with. Everyone was complaining about who didn’t do what and all the cliques that had formed in the team. It went on for hours. Tough. Someone was treating them as kids—and had not let them take ownership. They could not make any decisions about how to deliver and waited for someone to tell them.

A good question to ask teams is, “When you make a decision, are there any impacts on the business or on the customer?” Be sure there is no hint of judgment in your delivery.

If the team struggles with reaching a decision, introduce the collaboration process where they brainstorm using sticky notes, then group and prioritize them. This process is detailed in Appendix C, Collaboration Process.

Trust First and Be Trustworthy

“Suspicion is a permanent condition.” [1]

If a team doesn’t feel trusted, they won’t be able to take ownership. Why should they? If the team is not yet used to ownership or trust they might not believe that they have ownership. You will be tested—again and again. They will try to get you to take ownership. This is not because they don’t want to have ownership; they just may not be used to it or they don’t know how to take it. And they may not know the boundaries of their ownership. This is where the Macro-Leadership Cube (described later in this chapter) comes into play. Set the boundaries of the cube together with your team.

Trust first! Think of someone you are not sure you can trust. How long is it going to take for that person to prove to you that he is trustworthy? Too long. But if you start by assuming everyone is trustworthy, you generate the results of a culture of trust immediately. Rather than not trusting people until they prove trustworthy, trust them until they prove they cannot be trusted.

Sell the Vision

If the team is to take ownership it needs a clear understanding of the goals and business factors associated with the project:

Spend time with the team exploring and elaborating on the high-level goals of the project and the current business and market conditions.

When building the vision be careful not to get into too much detail. Focus on what drives value by sticking to higher-level stories, situations, and scenarios. This should keep you out of defining how the team is to do the work. If you are defining features and functions rather than results, you are at the wrong level.

When you review their work with the team, give clear feedback on their progress toward the desired results and, again, avoid the “hows” of their methods. Include information about the state of the market and the competition.

Connect the Team with Customers

Make contact with key potential customers and users, and help the team work with them to prioritize features and functions to be delivered. Make sure customers are involved with the team throughout their project.

When moving to iterative methods, IBM implemented a way for teams to securely provide customers with intermediate versions of their products. They also created a forum so that customers could give feedback directly to the development teams. As you might suspect, there was more than a little anxiety about directly connecting customers to software engineers! For the first IBM project delivered this way, the results were outstanding: New, market-leading capabilities were added during the development cycle, and the number of customer questions after shipment was dramatically lower. Most of the potential issues were resolved during product development.

Enable the Team

There are many ways to enable the team, and we want it be in the broadest possible way. Look to what they need and try to provide it. Look for inhibitors and try to remove them. Search for common underlying themes in the retrospectives or in issues that arise and try to address them. Be proactive.

Build the Team

Ensure the team is skilled and staffed well enough to deliver. Even if your resources are constrained you can always find ways to get more capacity and capability from the team—not by browbeating or intimidation but by moving them toward Energy and Innovation. If the team feels that some individuals are not suited to the team, help those individuals move on.

Equip the Team

Make sure they have everything they need to succeed. Compared to the costs of experienced employees, any tools, software or hardware that help them succeed and improve are a great investment. Be aware that sometimes teams will live with a bad situation because they are used to it, and used to the organization refusing any requests.

Support the Team

Build an infrastructure that supports the team. Find ways to limit non-customer-value work done by the team. Shield them from time and capacity wasters.

Other Ownership Tools

Talk about ownership with the team. Pure openness about your trust and faith in the team’s ability to deliver great things could be enough. Let them know you aren’t abandoning them. Explain to them that you will be available for times when they get “stuck,” but they are now the owners. During this discussion bring up prior examples of how individuals and the team have stepped up when it was required. Remind them of their positive actions during those times. Make comparisons between prior successes and the new ownership you are asking them to take on. Let them know you’ve “got their backs.”

Let the team work their way out of a particular problem. Going through trial and error and any resulting failures is critical in experiential learning. Provide the team with confirmation that you know they are taking a risk and that you are backing their effort 100 percent. Once they have solved the problem you can let them know they have taken ownership and have ownership from that point forward.

Use the “vacation method” on yourself. Let the team know you will be “out” for at least two to three weeks and not available for phone or e-mail contact. It might be a good time to take that trip to Fiji that you’ve always dreamed about. If you are willing to disconnect yourself from the project, the team will realize they must step up and take ownership. Upon your return from vacation, do not return to the “old way” of doing things. Recognize and reward the Team for their progress and keep the momentum going.

Another tool to use is to take on a new and different responsibility for yourself. Explain to the team your new duties and let them know you will not be able to spend as much time with them, but of course you trust them and know they will do a great job. Ultimately, you want to work yourself out of the job of running the team.

As you and the team mature, you can let them take on the biggest trust/ownership move of them all: Let the team know they are responsible for divvying up the year-end bonus, including yours. If your company has given you complete budget responsibility, see if the team will take the ultimate step of running themselves like their own small business.

Work with the team to minimize the amount of oversight. Limit the metrics gathered to measures that give an overall view of project progress and quality and provide really useful information for the team. There is a longer discussion on metrics in Chapter 9, Metrics, but for now focus on minimizing the cost of collection and reporting and maximizing the value to the team.

Macro-Leadership Cube

I once managed a nightmare systems implementation project to a very successful conclusion. In this project, I applied everything I had ever learned—and learned new things—just to deliver a highly constrained project in a rapidly changing environment. I felt as if I was at the very top of my project management game. In order to not let this newly found knowledge go to waste, I decided to train the project managers on my staff in all of the methods I has just used to pull off this project management miracle. I spent weeks documenting the details of the tools and approaches. Then I turned this document into a comprehensive training program and scheduled the first of what I expected would be several training programs. The night before the first session, I reviewed my 70-page treatise on highly effective project management. It was a thing of beauty. It described, in an almost minute-by-minute schedule, how a project manager should conduct the day, the week, the project. If a project manager followed my template, project success was nearly guaranteed.

As I finished my review, a troubling thought hit me. I had, in a mere 70 pages, described exactly how I thought someone should manage a project. But that was just me. Was I, by taking this approach, becoming a project management micromanager? The foundation of my 70 pages was certainly the belief that I knew better than anyone else. Did I? To be sure, I was pretty good but did I know it all? And by prescribing it all, was I limiting motivation, freedom, and innovation? I paused and thought through my approach again. What did I really want to accomplish? I wanted my project managers to not only be successful but also to have ownership for their work and to innovate and share their practices. I wanted them to love their work. Would or could they if I handcuffed them to my methods?

So I started over. I reviewed my 70-page masterpiece but this time looked for project management principles—principles that I found important and that might be helpful to someone else. Instead of laying out a detailed communication schedule and protocol, the important principle might be, “In the absence of communication, people assume the worst. Avoid this with frequent, meaningful communication.” No longer did I define what “frequent” and “meaningful” meant. That was up to the project manager and his project team and stakeholders. In the course of the next hour, I reduced my 70 pages of project management excellence to half a page of project management principles. The next day, I walked the project managers through these principles and gave them some examples. That was it. They now knew what I considered to be important, but how they applied these principles was entirely up to them.

To keep myself from ever becoming a micromanager, I have developed and use a simple graphical device. This device is a bit hokey, but it helps keep me on track. I call it the Macro-Leadership Cube (see Figure 5.1) to contrast it with micromanagement. The idea is that, as a leader, I should focus my attention on the “what” and the “why” of our tasks, projects, and processes but never the “how.” Visually, the “what” and the “why” form the walls of a cube.

FIGURE 5.1 Macro-Leadership Cube

These walls can include the Purpose and goals of the project, the expected Results, the available Resources, the targeted Time-to-Market, any Standards that apply, the Budget, et cetera—anything that defines the “what” and the “why” as well as any constraints that might impact the project. However, because they are so important, the Results must be one side of the cube and the Results must be qualified—that is, specific. We once worked with a nonprofit that lobbied their senators to not reduce the budget for services for the poor by very much. “What is very much?” we asked. The answer needed to be specific in order for it to be actionable. After a bit of discussion, they agreed that they could absorb cuts of no more than 3 percent.

The leader and the team members work together to define the walls of this cube and ensure that everyone understands and accepts this “what” and “why.” Then the leader stands back and lets the teams operate inside the cube. As a leader I don’t care how they deliver the results in the desired timeframe and budget as long as they do so without crossing any of the walls of the cube. The teams own the inside of the cube. That is their “how.” They can navigate and make the time/cost/task/resource trade-offs they need in order to deliver the results without crossing the walls of the cube. As a leader, I monitor only the walls of the cube. I never monitor what the team is doing inside the cube.

For example, my storage administrator Sam told me that unless we did something to expand our data storage, we would be out of room in about six months. Had I been a micromanager, and ignored my lack of deep knowledge of data storage technologies, I would have told Sam to buy more storage sometime before we ran out of space. Instead, I worked through the Macro-Cube of this project with him. We established the expected results: We wanted to double our storage capacity in fewer than four months for less than $X and without violating our storage standard. Those were the walls of his cube in completing this project. Sam owned all of the project “hows.” He met with various vendors and checked with his peers. He sometimes asked for my opinion, but I kept my answers to opinions—I did not want to take away any of his ownership or stifle his innovation by telling him how to do anything. When I asked for a project report, I asked him only about the status of the walls. Would he be done within four months, would we at least double our capacity, would we spend no more than $X, and would we maintain a homogeneous storage environment? If the answers were all “Yes,” life was good.

Sam discovered that about 75 percent of our current storage was duplicated files. For example, someone sends a document to 20 people for review and 18 of the 20 retain the document. Such activity resulted in 19 duplicate files. If all we did was de-duplicate such storage, we would more than double our capacity. His analysis also showed that a pretty decent percentage of our storage was allocated to rarely accessed data. Sam explored some ideas. What if we pushed that off to some type of archived storage? This archival storage could be slow compared to the more active storage while freeing up space. So he negotiated with our current storage provider and explained our desire to stay with them—but only if they helped us with some pricing concessions. With this done, he came to me with his proposal for expanding our storage. Through a combination of data de-duplication, archived storage, and price concessions, we could just about quadruple our storage capacity, improve service levels, slow down our rate of storage growth, spend about half of the budget, and do so well ahead of the schedule. Stated differently, Sam’s ownership and motivation generated a much better result than what I would have done.

This experience and countless others have taught us that we need to be careful about where we focus our leadership attention. The focus should be on “what” and “why” and never “how.” That does not mean we never do any “how” work. But our “how” work is tied to our leadership role. The “what” and “why” of our role are things like succession planning for the organization. We own “how” we deliver a successful succession plan. Our “what” and “why” include how our department will help the organization achieve its goals. Our “hows” then turn into the “what” and the “why” for our staff and teams. If we think of such cascading Macro-Cubes, alignment becomes more logical and visible.

This Macro-Cube concept also applies to processes and methods. Too often we implement processes that constrain innovation and destroy motivation. What if, from a leadership perspective, we focused the definition of process and methodology on the “what” and “why” of the process? One “what” in my software development process is that we achieve the shortest possible time between development and testing. Why? To reduce the time and resources it takes to eliminate bugs. The less time it takes to find and fix a bug, the lower the costs, the happier the customer, and the more resource capacity I create. But, I leave the “how” of this “what” to my teams. Should they co-locate testing personnel with my development engineers? That is up to them. Should they implement automating testing so that software engineers can know at least daily what bugs they created? They own that decision. Should the testing engineers write user stories to simplify the creation of the test cases? Whatever it takes to achieve the “what.” As long as the process satisfies the goals of this particular cube without breaking through any of the walls, I will be happy.

In this case, the Macro-Cube also includes a wall for process simplicity (the “what” for any process should include that it be simple, easy to follow, and not bureaucratic). Too often, we human beings, left to ourselves, will define and implement processes that are overly complex. And remember, complexity is the enemy of agility and innovation.

This Macro-Cube image can be a very effective tool for making sure that you, as a leader, do not encroach where you do not belong. It can also be effective in leading up with your own micromanaging manager, should you ever find yourself working for one. I once accepted a challenging assignment from the CEO of the company. Because of the dependencies and critical nature of this project, the CEO started to check in on my work with increasingly irritating frequency. My normally hands-off boss became, in just a few days, a micromanager. My frustration with him grew and his frustration with my frustration grew. One day, after he asked me to immediately make some very minor changes to how I tracked the project dependencies, I walked into his office with a blank piece of paper. I asked for just a few minutes of his time. I then drew the outline of a Macro-Cube for the project.

“Jon,” I said, “If I understand my assignment correctly, I need to deliver these results.” I then labeled the walls of the project cube. Jon wondered what I was up to but agreed with my assessment of the “what” for the project. I continued, “You chose me for this project because you think I have the ability to get this done. But you are treating me as if I am not capable of delivering this assignment.”

Jon looked shocked. “Not at all. You have my full confidence.”

I then referred to the drawing of the Macro-Cube and said, “You are asking, on a fairly regular basis, how I am going to deliver the results. In effect, you are climbing inside the walls of this cube with me and tracing my steps as I work to deliver the results. Normally, I would not mind that, but your tracking how I get this done is getting in the way. I spend so much time giving you updates that it is slowing my progress.”

“But I do need to know what is going on—this is a critical project!” he said.

I referred again to the drawing. “It seems that your focus should be on whether or not I deliver the expected results—the walls in this drawing—and not how I get that done. Right now, you seem more focused on how I am doing things than on whether or not I will deliver the right things.”

Jon paused for a moment and finally said, “I get it now. I should be asking you about the project deliverables and not the mechanics of your project management. Is that right?”

“That is it in a nutshell. Thank you.”

After that, when Jon asked me a question, he asked whether or not he was “inside my cube.” If I told him “Yes,” he backed off. If I answered “No,” I did a quick update on the status of the expected results (but never on how I was getting things done).

This visual is not perfect, but it can help both leaders and teams develop a feeling of ownership. At a minimum, this model asks us to define the expected results and other requirements, including timelines, available resources, standards to follow, purpose, and other considerations like uncertainty and complexity. With these defined, both leaders and teams know what they own—and don’t own.

Ownership is critical in changing and improving culture. It is hard to own something that is not well-defined. This model encourages that definition.

In Summary

Because we sometimes have a tendency to tell our team how to do things, we need to constantly remind ourselves to get out of the “how” business and stay in the “what” and “why” business. Once we have done that, we need to make sure that we do not take that ownership away; otherwise, we stand between our teams and their ownership and development. In this chapter, we have provided some tools for you to help your teams take ownership, for you to not take it back, and to work with your teams to define their ownership (the walls of the Macro-Cube).

Then, stand back and let them deliver.

References

[1] Buckingham, Marcus, and Coffman, Curt. First, Break All the Rules: What the Worlds’ Greatest Managers Do Differently. New York: Simon & Schuster, 1999, page 117.