Chapter 5

So far, we have added tools to our conversational toolkit that can help us to build trust and reduce fear. These techniques address issues that prevent collaboration and reduce problem solving that might trap any team in the factory mind-set. Removing barriers to success was our first goal, but with the next tool, we begin the process of building up a positive framework for our team to work within. Building a Why gives our company a strategic direction that guides large and small decisions, and provides a strong motive for success. Independent decision-making and team motivation were not concerns in the noncollaborative factory, but they are vital once we break free of it and begin to operate autonomously.

Our central message in this chapter is that the Why you build must not only explain the impetus for your collective action as a team but be created jointly, with all those involved. An executive who imposes a Why from above—or worse, with only a sham consultation—does more harm than good. Jointly creating a purpose means that a chief architect can concentrate on pointing to the cloud as the next evolutionary step, that a tech lead can get her whole team behind the quarterly goal, and that a tester can decide with confidence which component she should automate tests for next.

•Distinguish interests from positions, and uncover the former during a conversation that is stuck in an endless debate involving the latter.

•Combine advocacy and inquiry in a way that lets you be curious about the other person’s view while transparently sharing your own.

•Jointly design a solution—such as a team Why—by using the previous two techniques together with clear decision-making and a timeboxed discussion, allowing all participants to be heard and yielding a result that everyone can say they contributed to.

Simon Sinek, in one of the most-watched TED Talks ever, argues passionately that to be successful, organizations must always lead with their Why, the central reason for their existence and action. “What” and “How,” the strategy and tactics that define their route to the Why, come later; to succeed, customers, employees, and investors need to first hear, understand, and align with the organization’s purpose.1

In his talk and his follow-up book, Start with Why, Sinek cites a number of examples to support his argument:

•Explorer Ernest Shackleton, before attempting the first crossing of the Antarctic in 1914, reportedly advertised for people to join him thus: “Men wanted for hazardous journey. Small wages, bitter cold, long months of complete darkness, constant danger, safe return doubtful. Honour and recognition in case of success.”2

•In a major rebranding in 1997, Apple’s ads urged us to “think different,” without mentioning their products at all. Establishing their company’s mission so clearly with customers, and in a way completely divorced from their existing computer products, allowed them to dominate new categories in the following decade, such as music players, smartphones, and tablets.

•Dr. Martin Luther King Jr.’s inspiring 1963 speech described a vision of a new world where people would “... be judged not by the color of their skin but by the content of their character.”3 King had almost nothing to say about how his listeners would reach this promised land—and crucially, the speech was called “I Have a Dream,” not “I Have a Plan.” Yet Dr. King managed to captivate and convince an audience of more than 250,000 people solely by talking about his beliefs.

In each case, a bold leader attracted followers and believers with a compelling argument for what the group was aiming to accomplish and achieved dramatic success, without dwelling on strategy or tactics. In our experience, a powerful Why also helps with a smaller, tactical change in just the same way.

It seems to follow naturally that if we want our team to scale similar heights, we need to share with them a genuine commitment to an inspiring Why. With a clear direction and internal commitment, they will be able to self-organize and succeed just like Shackleton, Apple, and King. Right?

With the utmost respect, we have to disagree. Starting with Why is dangerous and unlikely to succeed.

Yes, a clear purpose must be agreed upon if a team is to make productive use of techniques like iterative delivery and periodic reflection for improvement. And yes, alignment on this purpose must come before we can agree to scope, milestones, deadlines, targets, and everything else that we need to make the Agile engine go. That’s the reason that the next two conversations, Why and Commitment, come in that order; and we will have a lot to say in both about how to build the internal commitment needed to align on the team’s and the organization’s Why.

But far too often, we have seen leaders try to inspire their teams without first having the Trust and Fear Conversations—and with dismal results. Without aligned stories that let everyone share a model of expected behavior, no one is ready to believe there is anyone steering the ship, much less believe there is anyone prepared to agree on a direction. And when unfettered fears dominate the team’s thinking, they can’t make room for the Joint Design of goals that forms the heart of the Why Conversation.

We’re reminded of one team we worked with right after the launch of a software-as-a-service product that had taken nearly a year to build. Lack of iteration and customer involvement meant that the product was floundering, with salespeople unable to close even a single deal. Team members looked and felt demoralized, and no one seemed to know how to fix the software to make it marketable. It seemed obvious that what this group needed was a good dose of Sinek-style Why to help them re-engage with customers and iterate their way to a solution.

But when we dug deeper, we quickly found that there were underlying issues of trust and fear that meant this group was in no way ready for the Why Conversation. Leaders had made unilateral and unpopular decisions about team organization and product marketing. This had lead to badly misaligned stories about their motivation. And shortcuts like skipping code reviews and pushing features live without product owner involvement had led to understandable fears from the team about code and release quality. Trying to give this group an inspiring Why at this point would have been like Captain Bligh delivering a motivational speech to the crew of the Bounty just before the mutiny.

After lots of intense work with the organization, we unearthed a number of actions that helped to improve trust and mitigate fears, including:

•Redefining the team lead’s role and coaching him in collaborative leadership, including making and fulfilling promises to include the whole team in decision-making.

•Making quality fears discussable and reshaping the release process to address them.

Only after taking these actions was the team able to have a meaningful Why Conversation, discussing company and team goals and the reasons why the product launch had failed so badly, and then beginning the process of addressing missing features through iterative delivery (which is no longer a source of fear). The product is now selling briskly.

As you can see from this example, a team without a Why can be misaligned and directionless, while a powerful Why provides psychological safety and a clear alignment on goals. These techniques for jointly designing a powerful Why rely on a foundation of solid trust and reduced fears so that the team can work and build on the skills learned in the previous chapters, like Coherence Busting and TDD for People.

So ensure you’ve got those bases covered before proceeding. If you have, let’s get started!

I’m Bobby, the team lead for a group in New York building the embedded software that runs inside an e-learning tablet for kids. Darius is my counterpart in hardware, building the tablet itself. Between us we’re responsible for shipping new versions of the product, from chips to firmware to apps. The problem is that Darius is seven time zones away, so we almost never get to talk live. I think his team should shift their working hours so we overlap more. I woke up at the crack of dawn to discuss this with Darius on the phone, but the conversation went awry quickly. I’ve recorded it and will be analyzing it to find out what went wrong.

Reminder: read the right-hand column first, then go back and read right to left.

Darius is terse and uncommunicative in email and chat, but I thought he’d open up on the phone. Boy, was I wrong! He’s even more stubborn in real life. Seems to me that we don’t agree about the causes of delays or how to communicate better, or even why we’re making these tablets in the first place. I don’t see how I can work with Darius at all.

Your purpose in the Trust and Fear Conversations was to uncover and make discussable previously hidden ideas (stories and fears, respectively). You might imagine that the Why Conversation will be easier, because you can just tell your colleagues all the inspiring reasons that their work is important. Right?

Sadly, that’s very unlikely to work, because odds are that your inspiring reasons are not going to be meaningful to some or all of the rest of the team. We know of one executive in the banking industry who spent years telling everyone that his company existed to make markets efficient. That was true, and the company was indeed very successful at removing financial inefficiencies; but this Why made exactly zero impact on product design, hiring, or employee motivation, because it just didn’t matter to most software developers and product managers working there.

Instead, we are going to suggest you do something much harder: jointly design the Why for your organization. This is harder than it seems, because it means negotiating and compromising, one step back and two steps (we hope) forward—a seeming waste of time. It’s also harder because it means the death of the ego for all sides; we can no longer believe that we are the only source of truth and direction in our working lives. It’s especially difficult for executives or founders who sincerely believe that they are the only ones who know, or should know, the right direction for the organization. But Joint Design is the only way to create internal commitment and self-organization in a team.*

We will describe Joint Design itself in the next section, but before that, we have two specific techniques to offer: Interests, Not Positions and Combining Advocacy and Inquiry. Both are useful in any situation where you need to collaborate with others in an area of contention.

Arthur Martirosyan, a negotiator for the humanitarian organization Mercy Corps, tells the story of a successful negotiation using the “interests, not positions” technique from the book Getting to Yes: Negotiating Agreement without Giving In:4 An oil company discovered large new reserves in postwar Iraq and prepared to begin drilling immediately. Unfortunately, the oil lay directly under fields being tilled by tenant farmers, who were not ready to give up their crops. Even more unfortunately, their threats to arm themselves and shoot up the company’s office were completely credible in a society still recovering from a civil war and riven by sectarian violence. This seemed to be an intractable standoff, with neither side willing to give up their positions: the oil company wanted to drill, and the farmers wanted to farm. Stalemate!

However, Martirosyan detected an opportunity to refocus the discussion on each side’s interests: he observed that the oil wasn’t going anywhere, but the farmer’s harvest was near at hand.

Could the oil company wait a short time to take over the land? Yes, as their interest was in protecting their claim and exploiting the resource for many years to come.

Could the farmers harvest and then leave? Yes, as their interest was in selling the crops they had worked hard to plant and to grow.

The resolution was obvious as soon as the conversation shifted to interests: the crops matured, the farmers harvested, and then the drills moved in, right after the tractors left. Some of the farmers even got jobs on the oil field!

Difficult conversations in your organization are unlikely to involve evicting tenants or dodging (literal) bullets, but your colleagues may have positions that are just as entrenched as those of the oil company and the farmers, if not more so. It’s important to try to identify these positions ahead of any difficult conversation, as well as some thoughts on possible corresponding interests. (Don’t forget your own positions and interests!) As usual, enlisting the help of someone from outside the organization can often help you in identifying these, as you may be blind to them.

Table 5.1 provides some examples of positions and their corresponding interests.

Distinguishing positions and interests during conversations can often help you and the rest of the group avoid getting stuck in unending and fruitless debate.** If you see hardened and opposing positions emerging, or if you feel your position is becoming immovable, aim to identify and share the reasoning and the interests that led to these positions.

For instance, two of three startup founders were arguing vigorously over what sales strategy to adopt—one passionately in favor of expanding within existing customers, the other just as firmly espousing opening additional markets with new products. The third founder watched in silence for a while, until we invited her to interject. At this point, she drew a chart on the whiteboard that illustrated a new way of understanding the interests of the other two founders (see Table 5.2). By introducing the vertical axis, she made it possible for all of us to see that there was a shared interest in offering a mix of options to existing and new customers, ranging from known and loved features to totally new ones, born from research. The debate shifted to the much more productive topic of what this mix was currently and what it should be.

To prepare for the Why Conversation specifically, try to create a table like Table 5.1, where the positions are specific team or organization goals that you think colleagues may advocate, and the interests describe the broader principles that may be behind their advocacy.

As we noted in Chapter 2, our natural tendency is toward unilateral control and vigorous advocacy; we believe that if we just tell others what our views are, they will be forced by logic and our brilliant rhetoric to agree with us (since we are right anyway). Argyris tells us that paying attention to our conversations will help us unlearn this habit,5 and methods like TDD for People and Interests, Not Positions lead us away from this one-sided advocacy toward transparency and curiosity. We are not the only ones with the truth; and asking genuine questions will help us understand how others see the situation, allowing us to come up with new solutions together.

But there are dangers in tilting too far toward pure inquiry. Consider how one of us approached a conversation with a colleague, Sergiusz, about how to get user input on a new report. Because both Jeffrey and Sergiusz did conversational analyses, we have access to the thoughts of both—a unique three-column conversational analysis. Sergiusz and Jeffrey wrote down the conversation together, and thus, both of their thoughts were recorded (Sergiusz’s is in the left-hand column and Jeffrey’s is in the right-hand column). What was actually said appears in the middle column.

Sergiusz and Jeffrey’s Conversation

Note: read the center column first.

As you can see, although Jeffrey thought he was working toward a mutual understanding of the situation by presenting a series of questions, Sergiusz felt he was being “led down the garden path,” and became increasingly concerned that Jeffrey had a hidden agenda. The conversation had a completely unintended effect: instead of increasing mutual learning, it led to mistrust and fear for Sergiusz.

We call this the Perry Mason Trap. When we ask a series of questions without explaining our reasoning or stating our views behind these questions, we run the risk that our conversation partner will think we are—like the twentieth-century TV lawyer—leading up to some unpleasant surprise. (“Aha! So you admit you drive a bright pink sports car—just like the one seen speeding away from the scene of the crime!”)

To avoid this trap, aim to combine advocacy of your own position with inquiry about that of your conversation partner, as espoused by Peter Senge in The Fifth Discipline: The Art & Practice of the Learning Organization.6 This takes a lot of practice to do skillfully, so here are some example approaches to achieving this difficult combination:

•“It seems to me that we have to cut the hiring budget to match these reduced revenues. Do you see this differently? For example, are there any other areas we could look at cutting, or is making cuts the wrong way to respond?”

•“I wonder how many different ways we can offer this product. I’ve thought of two—on the home screen and as an add-on at checkout. What other ideas can you think of?”

•“I hear some of our client implementations are behind schedule, and I’m wondering if we should delay some of them. You’re closer to the delivery teams; how do you see the situation? And what solution would you suggest?”

A fortunate side effect of combining advocacy and inquiry is that you also remind yourself to include your own observations and ideas in the conversation, sharing your Ladder of Inference—something that is surprisingly easy to forget once you start aiming for greater mutual learning. Once you’ve managed to be transparent about your own view and curious about the other persons’ ideas, you are well on your way to mining much more value from your conflicts.

Soon after the invention of cake mix, one of its early manufacturers*** noticed a problem: many housewives**** refused to buy it. This is odd, its executives thought; why would anyone prefer the messy process of measuring and sifting and stirring when they could just add water to some powder from a box?

This had the company stumped for a while, until someone had the bright idea to actually ask some customers. They discovered that the cake mix method was too easy—it didn’t feel like baking if there was only one step to follow. Customers wanted to feel proud of making their family something sweet and delicious; but with the mix, they weren’t involved. They felt like they might as well have gone to the bakery and bought one of the cakes off the shelf.9

The solution was obvious: remove the powdered egg, and require the customer to break and stir in an honest-to-goodness real egg. The phrase “add your own egg” on the front of the box***** gave enough involvement and agency to the customer to make the process feel like real baking again, and sales shot up.******

We often see teams trying to make decisions—about process, or estimation, or tooling, or budget, or even who sits where—in a centralized, nonconsultative way. Leaders pursuing efficiency and correctness make fundamental decisions and then communicate them to the team, expecting enthusiastic adoption of the new plan. All too often, as with the cake-mix customers, the reaction is decidedly less positive, with reluctant compliance at best or flat refusal at worst. And of course, this is catastrophic when it involves the most fundamental decision of all: the definition of the team’s motivating Why.

Instead, for decisions big and small, use the process of Joint Design, with each member of the team “adding their own egg.” Here is the process:

•Establish and communicate who will make the final decision (known as a decision-making rule11).

First, observe that the techniques of the previous section—Interests, Not Positions and Combining Advocacy and Inquiry—will be very useful in your Joint Design discussion. When you ask genuine questions, listen for and inquire about the interests behind the answers you hear. And when you invite opposing views, remember to also advocate appropriately. If you can do this, even with only partial success, you will be helping everyone provide useful information and feel like part of the decision.

Notice a Joint-Design process doesn’t need to be the same as a democratic or consensus-driven one. The decision rule can mean that there is no need for everyone to agree with the decision, or even for most of the group to endorse it; and the timebox—the fixed amount of time set for the discussion—ensures that we won’t get bogged down in endless debate. The key elements are inclusion (“I was part of the decision, and my objections were heard”) and information flow (“I was able to share what I know”). Over and over, we see that we make better decisions and earn meaningful internal commitment when we follow this process.

To score a Two-Column Conversational Analysis for Joint Design, look at the five elements listed above and award yourself a point for each one you can observe in your discussion. Did you include everyone who was relevant and available? Did you pose genuine questions and encourage views that don’t match yours? And was the conversation limited both by an agreed time limit and by a decision-making rule? Scoring five of five means you succeeded in making a decision that is likely to have everyone’s internal commitment.

There are many flavors of Joint Design. We’ve seen it used in groups of two and groups of two hundred, in short meetings and over many weeks, with small and large decisions. To illustrate just one variety, consider the fifteen-person engineering team we worked with whose release process was error prone and slow. Everyone agreed some automation and discipline would help, and we had a pretty good idea what an improved process might look like. It would have been easy to simply design a new deployment protocol and implement it.

Instead, remembering the cake-mix lesson, we gathered the team together and drew the current process on a whiteboard, marking the areas of friction and inefficiency in red. We set a timer and made this announcement:

“This is today’s release process, and here are the bits you’ve told us aren’t working well. For the next twenty minutes, we’ll listen to any and all proposed changes; and using this eraser and pen, we’ll update the steps accordingly. When the timer goes off, we’re going to publish whatever is on the board as our new release process and ask all of you to try it. If it’s a disaster, we’ll buy everyone a beer in two weeks. Who wants to start?”

Ideas flew in from all sides, including several we wouldn’t have thought of, making use of tools we didn’t know about and contextual information from several specialties like QA and system administration. Further, it turned out we hadn’t understood the existing process correctly, and we had to add a few steps to our diagram to make it work at all. In just a few minutes, we had a much better design on the board than we would have come up with by ourselves—and everyone in the room felt like they were part of that design. They enthusiastically implemented the new system—which was indeed smoother and less buggy than the old one—and we didn’t have to buy anyone a beer.

We believe “adding your own egg” is vital to successfully determining your team’s motivating Why. Now let’s see how that works.

How do organizations normally define their purpose, decide their strategy, or start on a major transformation? In our experience, it’s typically a task addressed by a board of directors, a small group of leaders, or just a couple of executives. They retreat in some way (to a boardroom or an off-site location), argue and debate and cogitate, and return to present a mission statement or a roadmap or a values definition. Then the rest of the company is expected to applaud politely and return to work.

If you’ve been paying attention to the last few sections, you probably won’t be surprised that we are very skeptical about this approach. For one thing, the deciding group is probably lacking important information held by those outside it, so their decision will very likely be deficient in important ways. Also, and perhaps even more importantly, the rest of the organization will have little or no investment in the decision, so it will be easy for them to ignore it or pay it no more than lip service—hardly a motivating, vigorously championed Why.

The problem is that there’s no obvious practical alternative to the dreaded off-site meeting. Should the group vote on its mission? Discuss until a consensus emerges? Pick options from a hat? With more than two or three people in the organization, these rapidly become unwieldy and inefficient options.

That’s why we advocate a Joint Design approach to the Why Conversation, whether your team is tiny or huge, as we outlined above. Be as inclusive as you can. Invite alternative views, and combine advocacy and inquiry using genuine questions. Establish a decision-making rule and (if appropriate) limit the time for the discussion.

What does this look like? Well, consider one of our clients, who embarked on a Why Conversation to set new guiding values after a significant expansion. The organization established the overall goal of resetting company direction for their new growth phase and explained the business drivers behind the planned expansion. Then they made a significant effort to poll everyone for their views—no small feat for a small HR team covering several offices with new staff—resulting in a list of over one hundred value ideas, with more than 60% employee participation. Smaller groups then discussed and debated the values, with facilitators asking questions and ensuring everyone’s views were heard. After a set period for this discussion, the board met, reviewed the leading ideas, and selected three values for the company, which were enthusiastically received.

At the same time, two product managers who worked closely together within the company were reshaping their own Why. Until we met them, the two had functioned as order takers within what amounted to a feature factory (see Chapter 1), transmitting requests from executives to the developers with little or no filtering or feedback. With gentle encouragement and lots of genuine questions, we helped them discover that they wanted to take a much more directive role.

Interestingly, by involving developers and stakeholders and listening for the interests of each, they found that more filtering and product direction was exactly what their teams and their managers wanted too. It only took a week or two for them to begin using their new purpose to define and focus on a new product direction. Combined with the overall renewal of values and purpose in the company Why, the clearer product and personal Why for the PMs resulted in a much faster cycle time, dramatically increased customer feedback, and the launch of a new product in less than a month.

Bobby’s Why Story Continued

Reflecting and Revising

Time to Reflect by scoring my conversation with Darius. I had two questions, but they were both leading rather than genuine, as I was trying to get him to adopt my position that we should shift working hours. I didn’t share my negative views about Darius and his team, even when I got really frustrated at the end. And I really react badly when I think someone is ignoring me or shutting down, as Darius seemed to early on; that’s either a twitch or a trigger that I should watch out for.

Turning to Joint Design, I can give myself a point for timeboxing, since the inconvenient hour provided a natural stop to the discussion. But I don’t get any other points: I could have included other members of Darius’s team; I already noted I didn’t ask genuine questions; I ignored Darius’s opinion about documentation completely; and we certainly didn’t have an agreed decision-making rule, since I felt I had to escalate to the CEO in the end. One out of five isn’t very good.

To Revise my conversation, I’d definitely like to be more curious and find out what Darius’s views really are. We might be able to come up with something better if I could just get him to open up; avoiding my tendency to shout when I think I’m being shut down should help. It would also be useful to understand what motivates him—for instance, why is he so firmly opposed to increasing communication?

I flew out to see Darius, figuring we’d have a better conversation face to face. On the plane, I worked to Role Play both sides of the conversation with my revisions in place. On arrival, I tried to involve other people from Darius’s team in our discussion, but he told them not to come. I was worried we’d have another fight and my journey would be wasted.

Bobby and Darius’s Revised Conversation

What Bobby thought and felt	What Bobby and Darius said
This seems pretty obvious to me, but let’s be sure Darius sees the problem as I do.	Bobby: Darius, would you agree we’ve had some problems coordinating hardware and software?
Okay, we agree something isn’t right.	Darius: Certainly—we still haven’t been able to release the new product after three months.
I’m going to share my position so we can discuss it.	Bobby: Indeed. For a long time my position has been that we need to talk more.
That’s what I keep hearing from everyone over here. Why on earth is it difficult?	Darius: I know, but you don’t seem to understand that this is very difficult for us.
	Bobby: Is it the time difference that makes it tough?
Ah. I didn’t realize the team sees language as the barrier. He’s right that their English is poor, but I thought they wanted to improve. I bet this is why he didn’t have them come along to this meeting.	Darius: Not really. We can and often do work to your schedule. But most of us, except me, speak very little English.
Let’s be sure I’ve got Darius’s position clear.	Bobby: So your position is that we should avoid in-person discussions? Does that include bringing others to this meeting?
Not the first time I’ve heard this.	Darius: Yes. There’s no point in us trying to talk more if we can’t understand you. Just send us the detailed specifications and we’ll build them.
Let’s try to get to the interest behind Darius’s position.	Bobby: That’s what we’ve been trying, but it doesn’t seem to be working. Tell me, why do you say “send the specs”? What good result would come from doing that?
Great, I definitely share that interest.	Darius: We could get on with our hardware build, as efficiently as possible.
	Bobby: I can’t argue with that. It seems like we both have a strong interest in efficiency. Is that right?
She sure is efficiency focused—it was her idea to hire in this country, so hardware designers would be near the factory.	Darius: Certainly. Our CEO talks about nothing else, it seems.
I have a sneaky idea. Would it work for Darius?	Bobby: Hmm. Would it be more efficient if the specs were easier to read?
Sounds like better specs would indeed be more efficient.	Darius: Of course. We waste a lot of time over here debating what the requirements mean. But how would we do that?
We might have to stick to written communication, but with a translator, we could eliminate a big barrier to understanding.	Bobby: Well, I was thinking of hiring a technical translator to convert the documents into your language.
Oh, that sounds promising for my interests too.	Darius: I like that! The translator could help us understand you on video calls too.
	Bobby: I hadn’t thought of that, but it’s a great idea. Shall we write a job ad together?

We turned out to have a common interest in efficiency—our shared Why is building the product efficiently. Once we focused on this, we found a creative solution to the communication challenges that addressed both of our interests. The translator is helping us a lot now, and we also found a new engineer who speaks the hardware team’s language—and she’s teaching the rest of us to speak it too.

Theresa says, “I’m the newly hired engineering leader for a team that’s frankly been way off track for some time. The company needs them to start delivering to business priorities, and I need their internal commitment to a new direction.

“I decided to call a Why Conversation meeting with developers and product managers to agree on and jointly design the way forward.”

Theresa continued in this way throughout the hour; and though not everyone agreed at the end, they all understood the Why behind the choices the group had made. All were willing to work toward the three focus areas left on the board and understood, even if they still disagreed, why the others had been left out for now. Theresa had used genuine questions combined with advocacy and inquiry to ensure information flowed freely and everyone got to participate. The time limit and decision-making rule stated at the beginning guaranteed a timely decision. The team was ready to build!

Terrence says, “I’m the product manager for our line of casual online games. I’ve just presented a new plan for developing new games to the executive team, and the CEO and chief designer, Barry and Victor, have stayed in the room to talk with me further. This doesn’t bode well ...”

Terrence thought he and the executives were aligned on their Why but found out suddenly that this wasn’t the case. He focused on common interests and kept combining advocacy and inquiry, eventually discovering the source of the misalignment. The three were then able to realign with a common understanding of the proper place for automation in their game design process.

Michelle was swimming in oceans of data. After several years at a small startup, with only a few customers, she’d joined a team working on one of the largest marketplaces in the world, with millions of users around the globe. As a product manager, she felt she’d died and gone to heaven. No more coaxing users into research sessions or releasing new features on a hunch and a prayer; now she could simply dip into the data and locate improvement opportunities based on the actual clicks and purchases of real, paying users.

In the first few days after her weeklong orientation, she began investigating the wide variety of products offered. As you’d expect in a widely used retail service, a few “whale” products were wildly popular, while a “long tail” of much less sought-after items were rarely bought individually but dwarfed the whales in aggregate. She categorized and queried the product database over and over as patterns and hypotheses began to emerge.

At the same time, she got to know her team, a small group of seasoned engineers. Though she’d only known them for a short time, she could tell that they were tight-knit and functioning well, with high trust and low fear. In fact, despite the very high visibility of their service, she was amazed to see them bravely making substantial changes to core components like the recommendation engine, willing to run an experiment and roll it back right away if it didn’t work. “This is my kind of place,” she thought. “I can really make some improvements fast.”

One hypothesis jumped out at Michelle from the results of nearly every query she ran: she was sure that many of the products had to be duplicates. After all, they were being entered by ordinary users with only simple validations, and surely one person’s “red” would be another’s “burgundy” or “cherry.” It was hard to confirm this from queries in the local, aggregated database; she’d need an engineer to write and run a function on a large server farm to check her guess on the real petabyte-sized data set. But if it were true, it would unlock many opportunities to combine products and boost sales substantially, with much more effective marketing and recommendations. She confidently headed over to the engineers’ desks.

“Hey Alan,” she said to the developer who, since he was eating lunch, looked most interruptible. “I’d like to run a large query to look for duplicate products. Here’s what I’ve been doing locally. Can you put the request on your backlog and run it, say, later this week?”

“Well,” she replied, “if we can combine identical products, the recommendations will be—”

“I’m trying to tell you. Once we know what’s duplicated, we can combine them and—”

He waved his pizza at her and she stopped, confused. “I don’t think you’re listening to me. I want to know why we should investigate duplicates.”

“No,” he said, “it isn’t. I’m not going to work on this until you can tell me why it’s worth doing.” And with that, he took a final bite, opened his editor, and began typing, the conversation clearly over.

Michelle was shocked. She’d never been challenged so directly by a developer before. But when she thought about it, she had to say he could be right. She really couldn’t say exactly why fixing duplicates was more valuable than what Alan was doing at the moment; it just seemed right to her. She resolved to find out and give him a convincing Why.

Michelle returned to her desk and began thinking about Alan’s question. You wouldn’t design a system with duplicates on purpose, would you? she thought. But I guess they could be harmless, or hurting sales less than something else we could fix instead. How could I prove that isn’t the case without running an expensive query that requires engineering help?

Then an idea struck her: The top fifty “whale” products accounted for a huge percentage of marketplace revenue, and because they were so important, Michelle had their sales data right there on her laptop. What if one or more of them suffered from duplication? A quick calculation on a scrap of paper confirmed what Michelle suspected: even with very conservative estimates for duplication rate, consolidating matching records for just a few of the most popular products would produce revenue gains that exceeded the team’s entire quarterly target.

She sprinted back to Alan and tossed her figures onto his keyboard. “Look! That’s why we need this query,” she exclaimed.

Alan read the calculation and looked up at Michelle. “Are you sure this is right?” he asked, surprised. “Why haven’t we been working on this already?”

“I don’t think anyone thought to check,” she replied. “Have I explained the reasoning well enough?”

“I’ll say!” said Alan, smiling broadly. “I’ll drop my current project and get this query run by the end of the day.”

As it turned out, not only did Alan find significant duplication, but he also found a number of quick wins that would address it. Engineers dove in from all directions to code, test, and deploy the changes, with immediate effects on revenue and customer satisfaction. The company now has an entire team devoted to de-duplication work, ensuring that the gains Michelle and Alan envisioned remain in place. And all because Michelle and Alan had been able to find—together—an exciting, motivating Why.

In this chapter, you learned how to unstick a conversation by moving from interests to positions; how to move the conversation forward with transparency and curiosity by combining advocacy and inquiry; how to jointly design decisions with your team; and how to use the above techniques to identify a motivating Why with your team to which they are internally committed. Unified by a jointly designed Why, you and your colleagues will be able to have productive conflicts instead of interminable debates—a key step in your conversational transformation. You can use the Why Conversation in many ways, including the following:

An executive leader can explore technical or product contributions to team purpose and organizational goals that he might not have considered on his own.

A team lead can provide effective guidance to her team on topics like which technical shortcuts to take or what features to prioritize, using agreed and well-understood team and company goals to explain her decisions.

An individual contributor can bring his experience of testing, deployment, and/or coding to bear on changes to team process or direction, producing better decisions with his and others’ internal commitment.

*	In addition, you’ll likely need to renew your Why periodically, as team members come and go and the environment changes. All the more reason to become skilled at the Why Conversation!
**	Remember the Ladder of Inference from the Trust Conversation (page 61)? A battle that is position-based like this often involves lots of action advocacy from the top of the ladder, without any sharing of the reasoning (including the interests) that led to the differing conclusions. We have heard this aptly called “dueling ladders.”
***	While it is typically assumed to be Duncan Hines, the latest research suggests that P. Duff and Sons of Pittsburgh were actually the first to make this realization.7
****	Apologies for our gendered language. This was in the mid-twentieth century, when most cake bakers were, indeed, housewives; and this was how marketers talked about their customers at the time.8
*****	For an example of this on an old cake-mix box, visit https://www.thissheepisorange.com/office-psychology-let-your-people-add-an-egg/
******	Though the story is well known, we are indebted to Gerald Weinberg’s Secrets of Consulting for this version, and the memorable phrase “add your own egg.”10

What Bobby thought and felt	What Bobby and Darius said
Surely, you’ll see the benefits of increasing communication.	Bobby: We’ve got to get more overlap between the teams. Would you be willing to start and finish later to make that work?
Well, stonewalling isn’t going to get us anywhere.	Darius: No, that won’t be possible.
I don’t think Santa Claus is going to shift his delivery date for us. Our mission is to make kids happy and smart; missing Christmas would achieve neither!	Bobby: Huh?! But our communication has to improve. The product has to be ready on time for Christmas, and the delays are killing our plan.
I can’t believe this. Our documents are perfectly clear! His engineers just don’t want to read them.	Darius: You don’t understand. Staying late won’t fix the delays when the problem is bad documentation.
I’ll try again to make the case.	Bobby: If it is documentation that’s at fault—and I don’t think it is—how can we ever find out where it’s wrong if we don’t talk more?
I agree, talking to you won’t help. You make a brick wall look transparent!	Darius: It won’t help. If we get good specs, we can build to them. That’s the only way.
I’m out of options. I can’t do anything when you’re digging in your heels.	Bobby: I give up. If you won’t move your working hours voluntarily, I’ll have to ask our CEO to make you do it.

Position	Possible Corresponding Interests
We must release feature X this quarter.	Keeping up with competitors Delivering on customer promises Protecting reputation for on-time delivery
We must eliminate our technical debt.	Delivering quality products Keeping developers happy Recruiting new technical staff
We have to stop buffering incoming feature requests.	Increasing delivery predictability Improving team throughput Keeping up with industry practices
We need to use containers to deploy.	Reducing deployment failures Diagnosing production problems faster Learning about new technology
We need a system of salary grades.	Ensuring equitable employee treatment Avoiding lawsuits Retaining staff
We have to fire Jane.	Resolving performance issues quickly Reinforcing our culture and values Reducing the staff budget

What Sergiusz thought and felt	What Sergiusz and Jeffrey actually said	What Jeffrey thought and felt
I think we should have a follow-up meeting with Rob, but I don’t think it is useful to pursue others.	Sergiusz: I think we should send the analysis to Rob. His comments will tell us whether we’re building the right thing.	I’m not sure about that. I think he’s got a lot of interest in the topic, but he’s just one stakeholder among many.
Hmm, okay. Let’s see where this is going.	Jeffrey: What makes you say that?	Maybe there’s something I don’t know. I wasn’t part of earlier meetings with Rob’s team.
I think he manages the users who are going to read the report.	Sergiusz: Because I got the impression that his team runs similar reports, and he’ll know what they should look like.	I don’t think he is a manager; just an interested and vocal user.
This is turning into a duel, not a discussion. I don’t think these are genuine questions.	Jeffrey: Well, there are others who are interested too. Who is the report for?	I suspect there’s an executive above Rob who makes the real decisions. I’m not sure you have enough understanding to start building. I’ll test my understanding and make sure we are aligned on the customer and the goal first.
I really don’t think this is the issue we should be discussing. We just need to get feedback, not relitigate the purpose of the report.	Serguisz: It’s for operational managers, the ones keeping the system running smoothly.	I’m confused and a bit concerned. What problem do you think they are solving?
I don’t agree. But maybe if you score this point, we can get on with deciding how to get feedback.	Jeffrey: Nope, it’s for the business sponsor, the one who controls the budget. What will she do as a result of getting the report? Why are we building it in the first place?	Are you just making stuff up? You don’t seem to understand the customer need at all.
This is really going off the rails. Why are you cross-examining me? Are you trying to make me look bad? I wish I could escape to a meeting, or a root canal or something.	Serguisz: I’m not sure. It might not lead her to do anything differently.	She’d do nothing differently? Why would we build it then?? I think we are really misaligned here. This is a great chance to make sure we’re on the same page. Good thing I can spend some more time with you on this.

What Theresa thought and felt	What Theresa and the team said
I’ll lay out the ground rules to start: I need information flow from every-one, and a clear decision at the end.	Theresa: Thanks for coming, everyone. We’re going to spend the next hour setting our team direction. I expect everyone to participate and propose ideas, but I may step in to make a decision if needed. At the end of the hour, whatever is on this whiteboard will be our direction for the next month. Everyone got that?
	Engineers: Yes, we’ve got it.
	PMs: Okay.
Let’s get the team involved from the start in setting the topics.	Theresa: Okay, working with the PMs, I’ve prepared these sticky notes describing various items we might work on. First, have a look at all of them and tell me if any are not worth even examining. And if any important ones are missing, add your own sticky note.
Good point. Glad he’s participating.	Patrick: We forgot single sign-on.
	Theresa: Go ahead and add it. Any others?
I agree, but I might be missing something, especially since I’m new to the team.	Quentin: Test automation is up there, but shouldn’t it be a routine part of coding, not a project?
Advocacy and inquiry seem to be working here.	Theresa: I tend to agree, but what do others think? I see nods, so I’m removing it. Other thoughts?
Nice observation. Glad she’s engaging.	Roberta: There are three usability changes that are almost the same.
Let’s move on to categorization.	Theresa: That’s a good observation. Let’s group them together under the heading “usability.” What other categories make sense?
	[Over the next few minutes, six categories emerge.].
No more than three areas with this small team—that’s a limit that I want to set clearly. It sure seems to me that we need usability improvements to stop customer churn, but I’m genuinely interested in other ideas.	Theresa: I want to focus on just three of these for the next month, given our limited capacity. I see usability as vital but don’t have a strong opinion about the other two. Which three would you pick? I’m especially interested to hear from you if you disagree with me.
	Sam: I’d take automation, onboarding imports, and pricing simplification. All three reduce costs for operations.
	Roberta: Why not usability?
	Sam: Easy—no cost reduction.
I’m curious here. Is there a strong reason for reducing cost that I don’t know about?	Theresa: What do others think? Is cost our driving consideration this month?
That’s how I see it; I wonder if anyone disagrees?	Patrick: I don’t think so. It’s important, sure, but we need revenue more.
Hmm. We just raised a million dollars. I’m not sure this is right.	Sam: We always need to conserve cash. The company can’t run on fumes.
	Roberta: The CEO said yesterday that we need to land prospects, and we all know prospects convert when they aren’t frustrated by poor usability and too many clicks.
Time to make a ruling and keep us on track.	Theresa: This is a good debate, and I’m glad we are having it. I’m going to step in and say—sorry Sam!—that pure cost-reduction initiatives like automation have to be out this month. [I removed the automation sticky notes.] We’re after new sales first, and we’re willing to put up with some uncomfortable costs to get them.
	Quentin: What about imports? Those help convert customers, and at the same time, they make setup a lot smoother for operators.
	Theresa: Very good point! What do you think, Sam?

What Terrence thought and felt	What Terrence, Barry, and Victor said
I thought you told me to make the process simpler!	Victor: We shouldn’t be automating the process of developing new games!
I didn’t expect Barry to agree. This is serious.	Barry: Yes, your plan is going to endanger playability and quality.
I’m going to try to find my feet here by advocating while inquiring.	Terrence: Slow down—I’m confused. I thought a simpler product-design experience would help us iterate better. Am I missing something?
	Victor: Of course we want a better design process, but not a button that deploys the whole game in one go.
I’ll keep inquiring. What is their interest?	Terrence: I’m still confused. The games don’t go live to real customers, only internally. Doesn’t that help us test and improve faster?
Aha, that’s the issue.	Barry: Yes, but part of the process that’s important to us is storyboarding and experimenting offline. Your button is going to encourage the artists and coders to commit to code and designs too early.
I didn’t realize the designers wanted to work offline.	Terrence: I get it. So the current process is slower than it could be, but you value that slowness.
	Victor: Right. In the early stages we need to get the feel of the game.
	Barry: Once we’ve approved it creatively, then we can speed up and automate.
Let me check my new understanding. They do want automation but for operators, not designers—right?	Terrence: I think I see. We share an interest in eliminating the rote work involved in deploying a new game, but the initial creative steps need to remain offline and reflective.
	Victor: Exactly. What differentiates us is that we take time to design, unlike the competition, who slam out two or three crappy games a week.
That’s it. I missed the need for offline work, but I was right about the value of automation.	Barry: I’ll be the first to say that we should be reducing cost and delay. But not by cutting out fun and originality.
Okay, let me try out a solution here. Does this match our new alignment on where automation makes sense?	Terrence: I definitely agree about emphasizing quality over quantity. Could we use the new deployment mechanism, but only in Operations, not Creative?
	Victor: Fine with me. Just don’t let the designers anywhere near it.
Barry gets it—cost savings without compromising quality.	Barry: The automation would save a lot of wasted effort by system administrators running scripts, right?
	Terrence: Exactly. I’ll have a revised plan to you this afternoon.