The Trust Conversation

Building trust is the most fundamental step in helping your team escape the Taylorist feature factory and build a high-performing culture. An executive who believes employees are not acting in good faith will not be able to accept commitments or provide support to meet them. A tech lead who conceals information from her team will never overcome fear. And a developer or product manager who suspects colleagues of harboring ulterior motives will be unable to propose or agree on an effective Why.

Because it is an absolute prerequisite for success in the other conversations, we start our “instruction manual” by investigating the elements of trust, analyzing trust-destroying and trust-building conversations, and constructing an effective recipe for the Trust Conversation.

By the end of this chapter, you will be able to:

•recognize low-trust relationships by finding misaligned stories,

•communicate vulnerability and predictability to be transparent and prepare the way for trust building, and

•unlock your curiosity by using “TDD for People” to discover differences in reasoning and to align your story with that of others.

Trust Comes First

Let’s start our examination of trust by hunting it down in hidden, nonobvious places. We’ll meet some of the key employees at a troubled but imaginary tech startup. Their woes are varied, but none of them have any idea that a hidden problem—a lack of trust—underlies all their difficulties.

The two founders battle every Friday over the Gantt chart.

“We can start the Facebook integration in six weeks.”

“No, we need to move it to early March. We have to do the video upload first.”

“But what about the new authentication system?”

None of these weeks-away events ever happen as planned, of course—someone is ill, or a critical bug pops up, or a feature has to be rebuilt. But still they fight over the future as if they can control it. Recently, they’ve been wondering whether a better roadmapping tool or some estimation training would help them get more accurate predictions.

The tech lead is at the end of his rope. After years in the trenches at multiple companies, he knows exactly what the team needs to deliver on time: good specs, accurate estimates, another QA. He explains this carefully and clearly, over and over, but doesn’t seem to make any headway. He gets sullen, partial compliance from the developers, no recruitment budget from finance, and outright opposition from the product manager. No one seems to understand that he’s in charge of delivery and the others need to fall in line with his plan. He’s working on a responsibility matrix to show everyone what their roles are, which he thinks will finally get everyone marching in the same direction.

The product manager is trying to get the bug rate down. Developers never seem to understand how the whole system fits together. Each sprint, she gives them more and more detailed specifications to work from. The defect backlog keeps growing nevertheless, so recently she’s been writing test plans to go with the specs too, with no visible effect. Last night, working late on yet another intricate feature description, she fell asleep at her desk and dreamed about a giant bug monster eating her product. On the train home, she decided that tomorrow she’ll draw a big mind map on the whiteboard, showing the interconnections of the system components, so everyone can see what impact each change might have and where to test.

The problems these team members have are common. You’ve probably encountered one or more of them if you’ve spent any time at all on a software team. And their intended solutions are just the sort that Agile coaches, Scrum conferences, and software vendors recommend: another process, a different tool, more information flow. There are books and courses that will tell each of them, in step-by-step detail, exactly how to implement their plans. They can cite the Agile Manifesto and the Scrum Principles to give weight to their proposals. In fact, there’s nothing wrong with any of these solutions except for one thing: every single one is guaranteed to fail.

Let us say that again in another way—there is nothing that our protagonists can do on their own to get better delivery or fewer bugs. Certifications look nice on the wall, a shorter sprint will result in more frequent releases, and a longer retrospective will produce more actions, but none of these changes will make a dent in the outcomes that matter.

To see what’s really going on, let’s examine the inner monologue of each participant—that is, what stories they are telling themselves:*

•Founders: “We can’t possibly understand the technical issues, but there must be some way to go faster.”

•Tech lead: “I know what to do, and I just need everyone else to follow me in implementing the obvious path forward.”

•Product manager (PM): “Developers are unable to comprehend the whole product; I have to give them the data they need to do their jobs.”

•Developers (remember them?): “Nobody tells us anything because no one cares about us. We should just put our heads down and keep coding.”

Armed with this (imaginary) telepathy, we can start to see why the intended unilateral changes are not going to work. The founders, believing they can’t understand the technology, will put rubbish assumptions into their shiny new road-map software and get garbage predictions out. The product manager doesn’t see role definition as a problem—her role in explaining features is perfectly clear—so she won’t engage with the tech lead’s responsibility matrix. And the developers are convinced they are being left out entirely, so the PM’s mind map will be yet another wall decoration to ignore.

The underlying problem is that the inner stories of the team members in this conversation do not align. Each story explains the situation in a coherent way, offers predictions about others’ behavior, and helps the storyteller develop solutions—but none of the stories agree with each other. It’s as if Ptolemy, Newton, and Einstein all got together to build a spaceship to Mars! No amount of process innovation or clever tooling is going to get that rocket to the right destination.

We have a name for aligned stories: Trust. If I say I trust you, I mean that I have expectations about what you will do that have been met before and that I believe will be met again. When I trust you, I can use the story we agree on to predict your behavior and evaluate my possible actions, so that we can cooperate effectively. We are likely to come up with jointly designed plans that we can execute in tandem, and we can explain our common story to others so they can align with us too.

Our definition of Trust is stronger than the typical one; if you look up the word in a dictionary, you’ll find something about believing that the other party is truthful, reliable, or capable. Such a belief is certainly helpful for building a solid, trusting relationship among team members, but it isn’t enough. I can have faith that you are genuine and dependable, and yet still have beliefs about your actions and motives that prevent our stories from aligning and poison our ability to cooperate.

By contrast, if our stories are fully aligned, you will never need to worry about me misunderstanding or undermining your efforts. With aligned stories, the founders will be able to involve developers in their prioritization discussions to keep goals realistic and achievable; the tech lead will discover that he doesn’t have all the answers and that team members can work with him to improve the structure and process more effectively; and the product manager will find that she can replace detailed specs with conversations with motivated developers.

In the rest of this chapter, we’ll explain exactly how to work with your team to align your stories through the Trust Conversation, starting with helping you to be vulnerable and predictable, and then showing you how to use Chris Argyris’s Ladder of Inference.

As Enterprise Agile/DevOps Lead, Coach, and Manager Brad Appleton says, “The first thing to build is trust!”1

Nell’s Trust Story

I’m Nell, the CTO of a small, online retail business. The CEO, Ian, doesn’t seem to trust me; he’s always overruling me on one decision or another. Our latest interaction really got me steamed, so I decided to analyze the conversation. I started with the first R: Record.

What Nell thought and felt	What Nell and Ian said
Not this again. Why can’t you leave us alone?	Ian: I’ve had it with our payment provider. We have to replace them.
They’re the best in the business. Any alternative will be much worse.	Nell: Why would we do that? We’ve only been using them for three months. There were some teething problems, but everything’s running smoothly now.
The income would be categorized right if they’d put in the correct data like we’ve trained them to do. Garbage in, garbage out.	Ian: Smoothly? No way. They’ve messed up our invoices every single month. Finance is having to manually reconcile. Again.
We aren’t going to annoy our customers and my entire team just because the accountants can’t read basic instructions.	Nell: Argh. I’ve told you before, they haven’t set up the reporting correctly. The payments integration has been very reliable, and customer complaints are way down. If we just get the right product metadata—
Pulling rank, again! Why employ me when you’re going to decide everything yourself?	Ian: Totally unacceptable. Finance is the lifeblood of this company, and if they’re not happy, we have to replace the vendor. That’s final.
Another payments integration three months after the first one. How am I going to explain this to the team?	Nell: Okay, if you insist.

Trust with Ian is at rock bottom. He seems to think I’m incompetent, and I definitely believe he’s micromanaging and playing politics by knuckling under to Finance. I feel trapped in the situation, unable to escape his controlling behavior. I’d like to build trust to escape this painful experience, but I’m not sure where to start.

Aligning stories in the Trust Conversation is going to require something very difficult from you: sharing your current story. This means opening up your feelings and thoughts to someone else. By doing so, you risk getting hurt—a prominent example of the difficult emotional work we told you to expect back in the Introduction.

It will help you in the Trust Conversation if you’ve established yourself as being willing to be vulnerable beforehand—you will be more used to it yourself, and others will see you as approachable—as someone who is inviting others to share their stories as well.

To get past your natural instinct to protect your story, try getting yourself to blurt out “unsafe” things; for example, ask “dumb”-sounding questions or share your doubts about how you drew a particular conclusion. When you are transparent about what you know and what you don’t know, you are being vulnerable, because you may not appear as rational and as knowledgeable as you might like. By contrast, trying to feel safe and avoid vulnerability—say, by pretending to be aware of something you haven’t heard of—usually gives false information that moves your stories further apart; and if you are found out, it signifies to your conversation partner that you are not being honest about yourself. It verifies that your stories are indeed misaligned and degrades their trust in you.

In Rising Strong: How the Ability to Reset Transforms the Way We Live, Love, Parent, and Lead, Brené Brown uses the phrase, “The story I’m telling myself is ...” when sharing internal reasoning.2 For example:

“The story I’m telling myself is that no one here cares about doing the washing up, so the office kitchen is always smelly.”

“The story I’m telling myself is that our users are cheapskates who demand the least expensive option.”

“The story I’m telling myself is that you aren’t working on this project because it’s boring.”

This phrase helps you to stay in a “learning mind-set,” because it means being explicit with both yourself and others that your reasoning is based on limited evidence and that you are perhaps reasoning incorrectly. This is a useful antidote to the instinctual view that “what you see is all there is,” described by Daniel Kahneman in Thinking, Fast and Slow;3 it reminds you that there’s a lot that you don’t see. It also helps build empathy in the listener because he or she can understand where your story came from without being threatened by the narrative.

These unfamiliar techniques may seem awkward at first, but with practice, the idea of sharing your internal reasoning while also sharing that you aren’t attached to it comes to feel natural. You’ll see several examples of this type of behavior in the sample conversations near the end of this chapter.

Vulnerability alone isn’t enough. If you want to align your story with those of others, then you will also have to give them evidence that your story is actually predictive, that it matches your actions.

The opposite behavior is everywhere, usually in the form of unintended hypocrisy: the earnest dieter who discusses his latest weight-loss plan while having a burger with everything; the taxi driver who bemoans the awful drivers as she runs yellow lights and cuts off cars; the poster on the wall that proclaims “We respect our people” while bosses stand beneath it to berate their underlings.

Before you dismiss these as applying only to others, we recommend you think carefully about your own theories and actions—if you are human, we are sure you have several examples of story-behavior mismatch in your own life.

Preparing well for a Trust Conversation means overcoming, as much as you can, this natural human tendency, and aligning your own behavior and theory to demonstrate predictability. When you inevitably fail to do so, admit your error and ask others to help you align better in the future.

Aligning your actions to your own story is hard enough. But even when you’re truly acting consistently with your beliefs, you may still have to do more to convince others that you are predictable.

Billy, a programmer one of us knew some years ago, had a firm theory about his bosses: they were out to get him, giving him impossible assignments and fantasy deadlines, and any new initiative had to be a sneaky trick by those nasty managers. He put this theory on show when his team gathered for its first Agile planning session, the intent of which was to sort through possible projects and select those that might make sense to pursue for the first sprint. As soon as a list of ten potential features went up on the board, even before the team had estimated any of the stories at the highest level, Billy announced in a loud voice that this meeting was the last straw and that he was going to quit. Puzzled, his manager took Billy aside and asked what was going on. “No one could do all ten of those projects in one sprint!” exclaimed Billy. “You’re just trying to work us to death so you can replace us with outsourced drones.”

Billy’s negative story about management was so deeply engrained that he literally couldn’t hear his manager explain, at the start of the planning session, that the team would be selecting only those stories that could comfortably fit into the sprint. There was more evidence, in the form of the planning session itself and in other Agile practices being introduced, that Billy could rely on his manager to look out for the team’s needs, but he wasn’t able to align this with the story he was telling himself yet.

Through a Trust Conversation with Billy, we learned that his theory had been firmly reinforced by employment in multiple abusive jobs, including one where senior leaders routinely erased team estimates from the kanban board and replaced them with their own (“I’m sure we can do this ten-point story by Friday,” they’d say). It took many repeated experiences with managers who claimed to respect team needs, and then actually followed through with that respect, to build trust with Billy and create an alternate shared story.

We often find that you can establish initial predictability with small, highly visible steps that don’t necessarily relate directly to the main issues of the Trust Conversation. For instance, in Billy’s team of programmers, a constant irritant was repeated requests from nontechnical staff to fix the printer or the internet connection. His manager announced that this practice would end, and when no outsourced IT service could be found quickly enough, he proceeded to crawl around on the floor himself, chasing cables and resetting routers. This clearly showed Billy and his colleagues that when the manager made a promise, it would be kept, and it helped establish a clear reputation for predictability that was very useful in building trust in other areas.

The Conversation: TDD for People

Kent Beck says that Test-Driven Development (TDD), the practice of writing a test concurrently with the code it exercises, gives him “a sense of comfort and intimacy.”4 That is exactly the feeling we want you to have during the Trust Conversation, and the tool to help you achieve it is the Ladder of Inference, another concept from Chris Argyris and colleagues (see Figure 3.1).5

Adapted from Peter Senge, The Fifth Discipline.

Figure 3.1: The Ladder of Inference

Observe that the Ladder tells a coherent story: from data, you derive meanings, which gives you assumptions, conclusions, and beliefs; and from these, you determine your actions. The goal of the Trust Conversation is to align your story with that of your conversation partner, and the Ladder provides an obvious way to structure that alignment: first align on the bottom rung, then rung 2, and so on, until your stories match.

This would be easy if both parties’ ladders were visible, but as you can see from Figure 3.1, only the bottom rung (observations) and the top rung (actions) exist outside your head, where others can see them. Everything else is invisible—which is where TDD for People comes in. As Argyris, Putnam, and McLain Smith say:

When writing code with TDD, you proceed slowly, in confident, small steps. Similarly, when using the Ladder of Inference, you are going to ascend in small, tested steps, each of which increases your confidence. At each step, you’ll ask a genuine question of your partner about her reasoning at that rung and if needed, explain your own reasoning as well. (We described genuine questions in more detail in Chapter 2.) This will reveal both sides’ ladders rung by rung, so you can understand where they differ. When your test fails—that is, when you are surprised by or don’t understand the answer to your question, exposing a misalignment—you’ll stop, refactor your understanding, and retry the test. At the end, you and your partner will have more closely aligned your ladders and, therefore, your stories; and where you still don’t fully agree, you will at least understand each other’s motives. As a result, you will have built substantial trust for the future.

Let’s go through an example: Suppose your team is working on a system that sets and adjusts prices for customers, and you have noticed one recently added team member, Helen, griping that the pricing algorithm is too complex to maintain. Since others, including you, are working on this code happily, you believe there is a misalignment that is affecting trust, as Helen’s complaints sap morale and she resists all suggestions for improving the problem code. You are starting to suspect that she and perhaps others are going to refuse to update prices until the whole subsystem is rewritten, which you don’t think the company can afford right now.

Rung 1: Observable Data. “Helen, I heard you say in the standup that the pricing code is overengineered. Did I understand you correctly?”

“Yes, anyone can see it’s impenetrable.”

You have established the basis for the conversation—that Helen sees a complexity problem. Your test is green; move to the next step.

Rung 2: Data Selection. “Got it. For me, the important part of any complex code is its architecture—how it’s divided into chunks—because that’s hardest to change. Is that the area of most concern for you too?”

“Absolutely. I mean, the comments and variable names suck, but we can refactor to improve those over time. I can’t see how any new joiner can hope to understand a forest of tiny classes like we have, though.”

After hearing your reasoning, Helen has confirmed agreement. Green again. (Notice we don’t have to agree with Helen that the architecture is actually objectively complex—just that she perceives it that way.)

Rung 3: Meanings. “Okay. So that means to me that you are going to find it hard to add new prices to the system. Is that right?”

“Of course! That’s why I asked to be reassigned to the edit page design.”

Your stories continue to match; Helen agrees that the perceived complexity is a barrier to her work. Green test: onward!

Rung 4: Assumptions. “So are you assuming that the pricing algorithm is just too hard for you to work on?”

“Sure, but it’s not just me—Ramona says she can’t make heads or tails of it either.”

A new fact: Helen isn’t alone in her assessment of the code. But this is another green test—your stories continue to match. You may be starting to wonder where the misalignment is, or whether it exists.

Rung 5: Conclusions. “I guess you’re thinking that we’re ripe for a rewrite of that code then.”

“What? No, that would be a waste of time. You and the other experts can keep hacking at it while us newbies stick to the user interface.”

RED! Here’s the misalignment. You thought Helen was angling for an expensive overhaul, but she’s suggesting that only experienced team members work on the complex algorithm. Time to refactor!

Rung 5: Conclusions, again. “Ah, I didn’t understand your thinking. You’re concluding that the pricing complexity means new joiners like you can’t work on that code, is that right?”

“Of course; that’s what I keep saying. We just don’t have enough experience to make changes safely.”

Now we’re green again; we understand Helen’s thinking, even if we aren’t aligned with the actions it leads to. On to the next rung but with new understanding.

Rung 6: Beliefs. “So it sounds like you believe that making some tasks off-limits to newer team members is a good idea. I have a different belief, though—that we should raise everyone’s skills until they can work on any feature; so everyone learns and we get the most from every developer. What are your thoughts?”

“I did think that I had to stick to the easier bits. But I can get behind the training idea, if we can afford it.”

Here’s alignment happening in real time. Now that your conclusions match, it’s easier for Helen to bring her beliefs in line with yours. Green!

Rung 7: Actions. “Great! I’d be willing to book Maria, our pricing expert, to spend the next week training you and Ramona on the pricing algorithm. Would that work?”

“Sure! I didn’t know that was an option. I’d be willing to give it a try!”

We’ve reached an action that Helen agrees with, thanks to aligning our stories. Even better, Helen can apply the common story to other potentially challenging areas, asking for training or help to raise her skills rather than complaining about being unable to contribute. In other words, we have built trust with Helen.

Scoring TDD for People

To score a conversation with TDD for People in mind, label your statements and questions in either column with the rung they correspond to. If you start at the bottom of the Ladder, with Data, Selections, and Meanings, and then move up to Assumptions, Conclusions, and Beliefs as the conversation progresses, you’re on track. But if you’re spending most of your time at the top of the Ladder, consider ways to consciously bring yourself back down to the lower rungs before proceeding.

Let’s return to Nell’s conversation, found on pages 57–58, and see if she can use TDD for People to come up with a more honest conversation.

I started by doing the basic scoring for my conversation. I have one disingenuous question, which I asked only to get Ian to change his mind—a unilateral, Model I approach that didn’t work. I shared only one or two items from the left-hand column. And my “Argh” halfway through was a pretty obvious tell, showing I was giving up in frustration.

Then I scored the conversation for TDD for People, which was even worse. I spent almost all my time in Conclusions or above, with only a couple of visits to Data or to Meanings just to bolster my argument. I definitely wasn’t being very transparent or curious here.

Finally, I decided on some revised actions to take next time. I’m going to try forcing myself to ask about Data, Meanings, and Assumptions before going further up the Ladder. I’m also going to try sharing my reasoning more and noticing when I’m starting to get frustrated. I tried to Role Play with my friend, the sales director, who also clashes with Ian, which gave us both some practice in going slowly up the Ladder.

Improved Conversation

Ian proposed we adopt Blaze as our new payment provider. After I rejected it as being too difficult to work with, he scheduled a meeting with its team anyway. I’m angry that he doesn’t trust me to make the decision and is overruling me yet again, but I also want to understand his reasoning by trying out the techniques I developed in my analysis.

Nell and Ian’s Revised Conversation

What Nell thought and felt	What Nell and Ian said
Let’s get the facts straight first—stay at the bottom of the Ladder.	Nell: I see that the Blaze team is coming in on Wednesday, is that right?
What a waste of time! Their references were terrible. Wait, I’m racing ahead and starting to get frustrated—I should stay focused on the next rung.	Ian: Yes, it is. I thought we should have a look at the system in person.
Okay, he did invite them. Let’s find out what that means while sharing the meaning it has for me.	Nell: That means they’re still in the running to become our new provider, right?
At least he read my report.	Ian: Well, not really. Their current users told you their support was useless, didn’t they?
This doesn’t make any sense. Is he up to something?	Nell: Yes, but now I’m really confused. Why did you book the visit if I’d eliminated them?
I never heard of using a vendor as a practice target before. Can you do that??	Ian: Well, I want to make sure we have a solid filtering process for the next few candidates, and I thought we could practice with Blaze.
Hmm, this isn’t what I feared. The meaning he has is different from what I thought it would be.	Nell: I get it—kind of a dry run.
That would definitely be good for my team—some of them have never done any software selection before.	Ian: Exactly. The other vendors can’t visit in person, and I thought it would be easier for our team to try out their questions with someone in the room before doing it over the phone.
How is Blaze going to feel about this?	Nell: That makes sense. Seems unfair to the vendor, though.
	Ian: Maybe, but the reps do have the chance to wow us during the visit and turn us around. I’ll be surprised if they do, though.
Boy, do I feel better having clarified Ian’s thinking. He wasn’t overruling me after all!	Nell: Me too!

Wow, that shifted my thinking completely. I only got a short distance up the Ladder of Inference, to the Meanings rung, before the realization hit me. Now, instead of the story I started with—“Ian doesn’t listen and just does what he wants”—I am starting to believe that “Ian listens to my opinions and wants my team to learn to select vendors well.”

If we keep confirming this shared story, it will become much easier for me to trust him in the future and for us both to jointly design solutions to our partner-management problems.

Example Trust Conversations

Now let's dig a little deeper and look at some more examples of the Trust Conversation in action.

Ursula and the Development Team:
Explaining Reasoning

Ursula says, “As the founder of our startup, I’ve tentatively decided to hire a new CTO, even though he had a disastrous on-site interview with most of the development team. I want to explain my thinking to the team—Al, Betsy, and Carlos—and answer what I expect will be tough questions from unhappy engineers.”

Ursula and the Developers’ Conversation

What Ursula thought and felt	What Ursula and the developers said
Best get it all out to start.	Ursula: I’ve decided to hire Zeb as our new CTO. I know that won’t be popular, but I want to explain why I’ve made this decision.
Ouch. Al’s no diplomat—but what if he’s right about Zeb?	Al: You’re nuts. He told us our main product was crap and has to be rebuilt.
Can’t hide from the truth.	Ursula: I know Zeb’s approach in the interviews was terrible. Are you willing to hear about how I made this decision despite that?
A skeptical crowd, as I expected.	Betsy: Okay, but this better be good.
Let’s start with observable data. Am I missing anything here?	Ursula: Great. I see Zeb as extremely experienced and very opinionated. Do you see him that way or differently?
Glad Zeb’s skills did come through.	Carlos: Sure, he knows his stuff all right.
We really need expertise—most of the team have never built anything like our product before.	Ursula: And to me, that means he has a lot to bring an inexperienced team like ours.
An excellent question.	Betsy: Yes, but how can he teach us anything when he’s being a jerk all the time?
I’m certain I can get Zeb to soften his approach, but I wonder if the team shares my confidence.	Ursula: My assumption is that he can learn to build relationships and manage well, if I coach him personally. Do you think that’s possible?
No surprise Al is opposed; he took the brunt of the criticism from Zeb.	Al: You’re a great coach, Ursula, but Zeb is beyond hope, even for you.
Can we agree to disagree here?	Ursula: I respect your view, Al; but I’ve coached many difficult people, and I see huge potential for learning in Zeb. Are you willing to let me try?
Glad Al is willing to give me a chance.	Al: I’ll be amazed if you pull it off, but okay.
How about the others?	Ursula: And of course you may turn out to be right, Al. How about the rest of you? Do you share my conclusion that Zeb is worth a shot, if I give him frequent, personal guidance? I’ll lengthen his probation period to three months to allow us all to see how he performs.
There we go.	Carlos: Sure.
	Betsy: I’m willing to try.
Ready to move ahead now that we have shared reasoning.	Ursula: Great, thank you. My belief is that we can find out in short order whether Zeb is right for us. I’ll check back every few weeks on how you’re feeling, okay?

Ursula could easily have just imposed her will on the team, unilaterally announcing Zeb’s start date. Instead, she shared her reasoning and partially aligned her story with the team’s. Not everyone agrees, especially Al, whose expectations remain very different from Ursula’s. But the differences are now discussable, and the team knows that Ursula will be accountable to them for Zeb’s coaching progress.

Isaac and Erin: Surprised by Feedback

Isaac says, “Erin runs operations, and I’m a developer. We often build features that are supposed to make life easier for her team, so we talk often. She asked for feedback as part of a ‘personal retrospective’ for self-improvement, and I gave it to her—but the conversation didn’t go the way I expected.”

Issac and Erin’s Conversation

What Isaac thought and felt	What Isaac and Erin said
I’d like to help. She needs to know how hard it is to approach her.	Erin: Thanks for helping me with feedback, Isaac. Where should I look to improve?
I’ll soften the blow—in fact, most of us don’t even try asking for more detail any more.	Isaac: Well, you could help your team file clearer bugs and feature requests. And as you probably know, some of us avoid asking you for clarification because you can be a bit intimidating.
Whoa! Why such a strong reaction? She did ask for the feedback, so what did she expect?	Erin: Intimidating?! Where does that come from?
She’s living up to her reputation, all right. I’ll stay at the bottom of the ladder to start.	Isaac: I notice that you’re looking red in the face and speaking louder. Is that—
At least I’m not alone in seeing this pattern.	Erin: Of course I am! I keep hearing that I’m “scary,” but I bend over backward to stay accessible and get feedback.
Okay, instead of guessing, I’ll find out explicitly what her reaction means.	Isaac: It sounds like hearing this really concerns you. Is that right? How are you feeling?
How can she not see how she’s scaring others off?	Erin: Annoyed and depressed—I can’t shake this undeserved reputation. It’s the opposite of what I want and what I observe. Is there a single real example of me frightening someone?
This conversation is a great example!	Isaac: Well, I’m feeling a little intimidated right now by your reaction.
Hmm, I actually can’t come up with another example. What does that mean?	Erin: That’s fair, and I’m sorry. The feedback is really hard to hear. But this doesn’t happen when someone asks me to clarify a bug report.
I hadn’t thought about it, but we actually never ask Erin directly. It’s always Maria who tells us to buzz off.	Isaac: Actually, you’re right. Come to think of it, it’s normally Maria in your team who has the most dismissive reactions.
A fair question.	Erin: So why do you see me as the intimidating one?
She does put the responsibility on Erin.	Isaac: I guess because she says you are telling her not to spend time helping us.
That was surprisingly helpful.	Erin: I think we may have found the problem—I haven’t been clear in my direction to Maria and the rest of my team. Thanks for thinking this through with me.

The Trust Conversation isn’t always something you can plan for; here, it snuck up on Isaac when he didn’t expect it. It would have been easy to react to Erin’s outburst in kind, with something like, “There you go again, blasting someone who’s only trying to help you,” but that would have been skipping all the way to the top of the Ladder of Inference and would not have built trust. Instead, Isaac managed to stay on the bottom rungs (Data, Selections, and Meanings), and after reflection, discovered his own perceptions and feedback weren’t as accurate as he’d thought. Erin and Isaac now have shared stories about bug reports and Erin’s wish to be responsive, which should help them work together with greater trust.

“I just want the developers to be happy,” said Paul Joyce, founder of Geckoboard, a maker of dashboard software. “Productivity and profit can come later. Right now, I’d just like to see them enjoying their jobs.” I (Squirrel) nodded and wondered what was making the engineers so depressed.

It was certainly obvious to me, after only a day on site, that something wasn’t right in Geckoboard’s small tech team of ten. In the spacious tech room, cluttered with board games and Ruby books, there were four standups every day but little to report in each. Retrospectives were stilted and unproductive. Meetings dragged on for hours with little energy or output. Conflicts over technology or process were expressed indirectly, if at all. There were plenty of projects underway—nearly as many as there were developers to carry them out!—but none showed signs of being finished anytime soon. Ironically, one of the company’s own dashboards hung on the wall of the tech room, displaying a huge graph that showed revenue remaining stubbornly flat, missing every monthly target so far that year.

Unsurprisingly, a similar malaise afflicted the rest of the business, whose desks were crowded into the other room of the small London office. Customer Service team members tried to talk positively about the product but couldn’t tell users when to expect bug fixes. Marketing and Sales wanted to splash new features to attract interest but had nothing to shout about. Paul himself was feeling disappointed and isolated, seeing no way to get the organization out of first gear. In fact, the only cheery presence in view was Mr. White, the office dog, who barked to announce arrivals, and chased toys up and down the hallway.

As I watched Mr. White run back and forth, I noticed something odd: he was going through the doorway between the two rooms, but no one else was. These two groups were separated by a wall, not only physical but psychological. They barely said hello to each other when they arrived for the day and said precious little else as the day went on. Unlike Mr. White, they stayed in their respective rooms and rarely ventured into each other’s territory. What had happened to divide these two groups, I wondered? Why couldn’t they cooperate?

Delivering and Engaging

The first step, I decided, was to show predictable progress. We consolidated the standups and shut down all projects but one, an integration with a popular product that seemed likely to get customers excited and paying more. Delivering incrementally on this single result built energy and interest within the development team, and productivity and mood started to lift. A natural leader, Leo, emerged from the team, and began removing obstacles and increasing efficiency. Gradually and gingerly, trust began to grow among the developers and product managers. They had had to be vulnerable to make their initial commitment, but eventually the predictable delivery of small wins increased their confidence in each other.

Even so, Mr. White was still the only regular commuter between the two halves of the company. The engineers described to me their negative stories about the rest of the business: “No one cares about fixing bugs,” “They don’t tell us what sales are coming next,” “Paul doesn’t care about employees.” And Paul told me about feeling isolated, disempowered, and uninvolved, even as the developers were starting to deliver more. There was clearly more to do.

To start, we created opportunities for interaction—holding show-and-tell sessions for Sales, inviting support staff to retrospectives. Crucially, we brought Paul into standups, where he was able to show some vulnerability by sharing his sense of isolation and his frustrations with the unmoving financial metrics. I also led a brief session for everyone on TDD for People, with the expectation that this tool would help the two sides share stories and increase trust.

The Trust Conversation

The crucial breakthrough came when Leo and Paul sat down for what turned out to be a Trust Conversation. Leo and I had role played it to prepare, and he knew he wanted to start by asking about the biggest obstacle to trust for him: the recent and seemingly sudden departure of two key employees. By asking questions like “When did you decide they had to go?” “What did they do wrong?” and “What did their exit mean to you?” Leo was able to share his story—that Paul had dismissed the two quickly and thoughtlessly—and understand Paul’s, which involved making agonizing decisions after sleepless nights, and much more negotiation and discussion behind closed doors than Leo had thought.

By the end of the conversation, Leo was starting to believe that Paul’s actions were much more compassionate and considerate than he had thought before; and Paul could see at last why some in the tech team, thinking he was “trigger happy” and ready to fire on a whim, had retreated from him, rebuffing his attempts to inspire and lead.

Today, four years later, Leo is now the VP of Engineering and works closely with Paul in a mutually trusting relationship. Employees use the Ladder of Inference regularly, and collaboration between developers and nontechnical people is common; some support staff even learned to code and formed their own development team. Customer engagement is up, and revenue is moving in the right direction.

Oh, and Geckoboard moved to a new office last year—with no wall down the middle.

Conclusion: Applying the Trust Conversation

In this chapter, you learned about the importance of internal stories, how to show others that you are willing and able to change your story through vulnerability and predictability, and the “TDD for People” technique for aligning your story with that of someone else to build trust. Aligned stories allow us to safely adopt the transparency and curiosity that we need for a successful conversational transformation. You can use the Trust Conversation in many ways, including the following:

An executive leader can create a trusting relationship with employees, giving confidence to all parties that the cultural transformation is headed in the right direction without micromanagement and continual supervision.

A team lead can align stories with her team to eliminate unproductive infighting and debates, and instead, cooperate to meet sprint goals and product targets.

An individual contributor can boost trust with his peers for more effective collaboration, so he can get and give more help with cooperative activities like code reviews, estimations, and pairing sessions.

*	Of course, we’re using the fact that our characters are fictional to share with you their inner thoughts. In reality, you’ll need to do a lot more work to discover what others’ stories are—which is what most of the rest of the chapter is about!