Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
This chapter is from the book

The Power of Trust and Ownership

Now more than ever, we need to unleash the talent of individuals, teams, and organizations. This might be the only hope we have to not just survive but thrive. But, too often, we put a wet blanket over the fire of innovation and motivation. In the midst of uncertainty, we attempt to control outcomes by controlling actions. In a state of fear, we insist on obedience to what has worked in the past—even if it no longer works. We somehow believe that rigidity results in predictability. Worried about the future, we become opaque rather than transparent with our teams. And when push comes to shove, we doggedly trust just ourselves and our instincts.

We have always believed that no one person can know everything and needs to rely on the talents of others to be successful in a role, on a project, or in the marketplace. With the increasing pace of change, trusting each other is critical. It is impossible for a person to know it all and do it all when it is all different.

We maintain that highly motivated individuals and teams who are passionate about delivering results will figure out what to do and make sure the right things get done. If such people understand what needs to be done and why it needs to be done and have the tools to succeed, miracles seem to happen. And, given the ambiguity that accompanies the decisions we make, we need such miracles.

We wrote this book for two reasons. First, we want to share with you the power of leading with Trust and Ownership. Second, we would like to provide you with specific, pragmatic tools we have used—and believe you can also use—to create a culture of Trust and Ownership. The combination of Trust and Ownership unleashes individuals, teams, and organizations to do amazing things—even and particularly in the face of rapid change and uncertainty.

Let’s start with an example of how one rather unremarkable e-commerce team used Trust and Ownership to do something that had never been done before.

The company was deeply worried about customer retention. In parallel, the e-commerce product team had low credibility. After all, thought company management, customer retention is low because the web team is just not that good. When we say that the e-commerce team was unremarkable, we mean that the team was stocked with good, solid, hard-working, capable people. Not a single member of the team would have initially been considered some king of e-commerce or a customer retention superstar. The team had been through its share of turmoil. The company had tried different leaders and structures. They had moved the team into and out of different parts of the company. But not much changed. Some members of the team found other jobs and quit but most stuck around. Like we said, rather unremarkable. Finally, because nothing else had worked, the company became desperate and moved the team to be part of the information technology (IT) department. After all, e-commerce used technology; therefore, IT seemed the natural place for the team. This was not a conscious move but it started the team and the company on the path to doing what had never been done before.

The head of the IT department, the chief information officer (CIO), was not sure what to do with the team and so put the entire lot into the application development team. Steve, the newly announced manager of the application development team, took the change in stride and, not knowing any better, treated the e-commerce team like everyone else in his group. Let’s pause for just a moment. He treated them like everyone else in his group. What did that mean? Steve was a leader who believed in the power of Trust and Ownership. He did not pretend he knew much about e-commerce (although he did). He did not believe the word on the street that the e-commerce team was ineffective or rudderless. He treated them the same way he treated everyone else. Steve figured that all the team needed to thrive was to own the results (but what results?) and to be trusted.

Steve met with each member of the team individually and then met with them as a group. In every encounter with them, he affirmed that he knew they were talented and knew what to do. He spent time with them explaining the company’s goals and how both the IT department and the application development team directly supported those goals. He encouraged them to think big—really big. He asked them to link their work to the company goals. He shared his concerns about customer retention. He did not offer solutions but asked questions like “When it is too late to recover a lost customer?”, “When do you think a customer first starts to think about leaving us?”, “What are the indicators that a customer is trending away from us?”, and “How soon could we pick up those indicators?”

Steve posed such questions at what seemed to be random times. During a project review, Steve might gaze out the window and ask, “I wonder if there is a way to detect customer dissatisfaction before customers even make their dissatisfaction known to us?” He would then return to whatever he had been doing. But the team got the message; Steve was somewhat consumed with customer retention.

Steve showed the team he trusted them. This did not mean he was soft or a pushover. If the team told Steve that they would get something done by Friday, Steve expected it would be done by Friday. If it was not done by Friday, he wanted to know why. Steve did not accept excuses. If the team did not deliver, Steve wanted to know what the team would do differently the next time to make sure that they would keep their commitments. But if the team told Steve what they would get done, he left them alone to do their work.

Steve pushed ownership to the team. If the team had a problem, Steve would help them diagnose the issues without telling them what to do. He would say things like “This one is going to be a real challenge. I am really interested in what you come up with the solve it.” At first, the team was not comfortable with this approach—after all, the team had been kicked around enough that their confidence was low. But as time went on and they resolved issues, their confidence grew. As confidence grew, the team started to think about customer retention. After all, they were the e-commerce team. Customers used their products to search, review, reject, and purchase the company’s products. If they did not have insight into the mind of the customer, who did?

As the team worked on various projects, they thought about how those projects might be used to somehow, someway improve customer retention. The only data available to the team were traditional web analytics and click stream data. This helped them understand the navigation and friction points with customers. Could they leverage this to improve customer retention? In their product and project planning, they started to brainstorm about customer retention. They started by asking some “what must be true” questions. In their case, what must be true in order to detect which customers are thinking of leaving us? They jotted down things like

  • We need to know their previous buying patterns.
  • We need to know their previous website navigation patterns.
  • We need to know their full customer service history.
  • We need to know what products they returned.
  • We need to be able to match the patterns of similar customers.
  • We need to profile customers into behavior patterns.

In reviewing their list, they realized there was a whole bunch of information that they needed but did not have—yet.

Their next what must be true question was “What must be true in order to get this information?”

This list included

  • We need to rope people into the project who can get us the information.
  • If we don’t have the information, we might need to develop ways to get the information.

Their final what must be true question was “Even if we have the information, what must be true in order to use it?”

They had only one answer to this question: We need analytical tools that we can use to profile and then predict the behavior of individual customers.

At this point it was time to talk with Steve. The team met with Steve and walked him through their approach and logic. Steve offered a suggestion here or there and then asked, “What do you need me to do in order to move this forward?” The team needed someone on the project who could get the team the information. They would also need Steve to allocate budget for any analytical tools. Steve told the team that a member of the data team had expressed interest in doing some type of customer analytics and told them to see if they could convince this person to join. As you might expect, this person came immediately on board.

Having assembled the team, the group now needed to figure out how to operationalize their approach. They were dealing with an incredible amount of uncertainty. First, would the approach even work? Second, could they get the data they lacked? Third, would the data be meaningful enough to provide insight? Fourth, would the analytical tools work? Fifth, would the analytics yield answers that would increase customer retention? How could they best deal with this massive uncertainty? It was time to spend more time with Steve.

The team presented these challenges and asked for advice. “Hmmm,” answered Steve, “when I am confronted with a lot of uncertainty, I think of how I can break things into phases. During each phase, I eliminate at least one element of uncertainty. So you might want to think of what small steps you can take now—no need to invest a great deal of resource until you have more confidence that this will work—to find out what will and will not work. You can then increase your investment as uncertainty declines.”

The team got back to work and laid out what they thought was a logical, phased project plan that moved the project toward the end goal while also reducing the uncertainty of the future phases. They returned to Steve and showed him the plan. Steve asked some questions that helped the team refine the phases and they started work.

In the first phase, the team assembled the data they thought they needed. Most of the data was available but not in a consumable form. So the team took a slight detour and added a phase that incorporated data conditioning to the project. The first phase also identified a significant gap in the data. In order to group customers into similar patterns and profiles, the team wanted to get demographic and psychographic data that the company simply did not have. How could they get this? How much of this data did they need? And could they get by without it?

They identified their options:

  • They could, at a pretty high cost, buy the data. But it might be foolish to incur the costs on an analysis that might not even work.
  • They could buy the data for a subset of customers and use this as a test to validate the approach.

They had agreed to purchase the subset of the data when a member of the team asked, “How many of our employees are also customers? If there are enough of us, could we collect the data from employees and use that as our data subset?”

The data team ran a query that showed enough employees were also customers. But how would they get the employees to offer up their personal data?

The team went back to Steve and explained what they wanted. Steve thought, “Interesting idea but how do we get the employees to participate? We are pretty early in a very uncertain project. If we tell employees what we are doing, are we setting an expectation we might not meet? Or is this a way to get everyone invested in thinking about customer retention?” Steve offered to run the idea up the management chain. In selling the project, Steve kept things at a very high level and repeated, over and over, the experimental nature of what they were attempting. He assured everyone that their personal information would be secure (and it would).

Enough employees participated that the project moved forward. The team now had the data but needed to do the analysis. The company had some analytical tools but not anything that would do the type of profiling and predicting the project needed. What to do now? Someone suggested another meeting with Steve. Someone else said, “No, we can figure this one out ourselves.” Several team members volunteered to do the research to see what was available—at a very low cost—to do such analyses.

When the team got back together, they had identified a couple of open source options they could use to test their approach.

The results were encouraging. Several clear patterns emerged. Other patterns were mixed or confused. But the clear patterns were compelling enough to ramp up the investment and try data with non-employee customers. The company agreed to start by purchasing the external data for a subset of customers. The company also agreed to acquire advanced, non-open-source technology—on a trial basis—to do improved analytics on customer retention. Over the next several months, the pilots and tests continued and expanded with improving results. Throughout all of this, Steve remained tightly connected to the project team, not to tell them what to do but to guide and focus them on the desired outcome—improved customer retention. Steve also removed any barriers and championed not just the project but the project team.

This happened more than two years ago. The company and team have continued to refine the approach and the results. The company’s customer analytics are so good that the company can tell during the first customer interaction with their website, with high confidence, which profile matches the customer. This profile defines the customer’s buying motivation and purchasing triggers. The company appeals to this specific motivation in everything they do with that customer. The profile also tells the company the customer behaviors that indicate if the customer is trending away from the company. If the customer is trending away, the company invokes an intervention strategy specific to that customer type. Across all customer profiles, customer retention has increased an average of 12 percent, which has added millions of dollars to the bottom line. Along the way, the rather unremarkable e-commerce team—composed of the same people who were foisted on Steve more than two years ago—are considered geniuses in the company. Others seek them out for their opinions on a wide range of topics.

How did such a team and company transformation happen? Through the power of trust and ownership. Steve trusted the team to perform and built a very strong sense of ownership for company, departmental, and team results. This unleashed the team to become more than they had ever been. The team was motivated and innovative. The wet blanket of micromanagement was lifted off the team and life for everyone got better.

Please keep in mind that trust alone is not enough, nor is ownership. What matters is the combination of a culture of trust and a passion for delivering the right results.

  • + Share This
  • 🔖 Save To Your Account