The Commitment Conversation

For the first time in this book, we’re about to talk about how to execute better. Using the tools introduced in this chapter will lead to effective, reliable commitments by your team. Execution is typically the first concern we hear about when diagnosing a troubled team: “Our processes are bloated and slow us down.” “Users haven’t seen improvements for months.” “We just don’t get much done.” So why have we waited so long to address it?

As we’ll explain in detail, the reason is that if you haven’t first built Trust, reduced Fear, and agreed on Why, execution will only get you to the wrong destination faster. This is exactly the failure mode of the software factory that we discussed in Chapter 1—detailed planning and rigid separation of responsibilities gives the illusion of control and precision, but actual delivery falls far short of the team’s potential, because the foundational elements are missing. Executives are puzzled by failure to deliver when the plans seem so precise; team leads scramble to meet impossible deadlines they can’t explain to their teams; and individual contributors are terrified into working late, or into the weekend, or for a new employer entirely.

The good news is that by applying the lessons we’ve covered so far, you’re now ready to use the techniques in this chapter to make effective, believable commitments that will be welcomed by an enthusiastic, autonomous team. After adding these methods to your personal conversational toolkit, you’ll be able to:

•Identify key words and phrases and agree on the meaning of these key elements, ensuring that everyone understands team commitments in the same way.

•Use a Walking Skeleton to provide a framework for a series of commitments and show progress toward each.

•Combine these techniques, along with the tools and techniques from previous chapters, to define and agree on your commitments while avoiding common pitfalls.

Compliance versus Commitment

“I really liked that we were able to get clear on the scope and research the new tool before we made our commitment,” says Bianca, a sysadmin in a team we know, during a retrospective on her team’s installation of a new container-management system, which had been completed with minimal downtime. “We knew what we had to do, and we knew how we were going to approach it. That allowed us to commit to the delivery, and the new system is brilliant.”

Carlos, a developer in a different team, has no faith in his management’s initiative to adopt Agile methods. “They say they want us to change how we work,” he says. “But they really only care about hitting deadlines. We’ll do this now like they’ve asked, but in a couple of months there will be some crisis and all this Agile stuff will disappear.” Carlos is going along with the plan by attending training on pairing, testing, and estimation, but doesn’t really intend to change his day-to-day work habits at all.

We can see from Bianca’s comments that she was part of a successful Commitment Conversation—a conversation in which everyone creates and commits to a shared definition of what it means to be “finished” with a project and how to get there—but Carlos is anything but committed. Bianca knew what she was signing up for and was part of the decision to switch container systems, while Carlos’s managers simply made decisions and passed down orders to start using Agile methods. Bianca backs her team’s new process, while Carlos is just waiting until he doesn’t have to follow his anymore.

We hear about “commitment” all the time. Often a team is committing to a deadline, but there are other types of commitment as well. An executive may ask her division to commit to abstract ideals and values, like professionalism or integrity. A regulator may tell a company to commit to very concrete actions, like writing documentation for operational procedures within five working days. We ourselves have frequently asked people if they are willing to “disagree and commit.” Why all these requests for commitment?

It is because we want to avoid the alternative: compliance.

Compliance is doing what you are told. At first, this doesn’t seem like a bad thing; after all, in many workplaces, compliance is the desired behavior, allowing a stable and effective process to keep running smoothly. However, compliance fails exactly when the process isn’t stable, when creativity is needed, when the team needs to identify and overcome unknown obstacles—that is, when you need to create new business value by taking on a new challenge, exactly the situation Agile, Lean, and DevOps software development methods were designed to address.

Compliance without commitment is just going through the motions. From the outside, it might look the same, but people on the team know something is missing. Compliance is showing up; commitment is engaging with your whole self. Compliance is filling the space; commitment is participating. Compliance can be enough for routine day-to-day tasks; compliance is not enough to generate change, to improve, to excel. If these are your aims, you need commitment.

Where does commitment come from? A person may be committed for many personal reasons. Sometimes commitment arises because of a problem someone experiences personally. One developer whom Jeffrey was training on testing said that her motivation was to be able to go home on time on a Friday rather than fix last-minute bugs. For others it is a question of mastery: they believe that a certain skill is part of being a competent professional, and they are therefore driven to have that skill. These idiosyncratic, personal sources of commitment are important, but by their nature, they are hard to plan for or rely upon; it’s unlikely that everyone or even most people on your team will come to commitment in these ways. The good news is that there is a highly successful way to seek commitment with every team and with every individual: we can ask for it in the Commitment Conversation, as we’ll explain in this chapter.

A successful Commitment Conversation builds upon the other conversations we’ve described so far:

If your team has low Trust, they’ll behave like Carlos, the developer who goes along with the process without really changing anything. Without stories that align with those asking for the commitment, the Carloses default to cynical beliefs and unproductive actions. “If we work hard to achieve this outcome, they’ll just ask us to work even harder next time,” they say.

If your team harbors unmitigated Fear about the repercussions of missed commitments, then they will be risk averse to a crippling degree, following orders to the letter. After all, if things don’t work, it isn’t really their fault; somebody else told them to do things that didn’t make sense. For people opting for this line of psychological defense, a micromanager is a perfect solution. One person likes giving detailed orders while the other likes being told precisely what to do. The results are generally not very impressive, but it is a comfortable ride—to nowhere.

And if your team was left out of designing the Why for the commitment, they won’t fully understand it or truly believe in it. Without the chance to put the proposal on the rack, finding all its weakness and edge cases, why should they trust it is a plan that will survive the difficulties ahead and deliver results? “Far safer to just go along with whatever comes down from management and wait for it to fail,” they’ll say.

But if you have overcome all these obstacles, you are ready for the Commitment Conversation.

Mandy’s Commitment Story

I’m Mandy, a product manager in a midsize software company. Our highly skilled Developer Relations team is building a new API (application programming interface—a way for programmers to automate interactions with our service) that the marketing department is very excited to sell. At our last sprint planning session, I tried to get the team to estimate a delivery date to help Marketing, but it blew up in my face. I think I should try to Record one of these conversations and analyze it to help me and my team reach an agreement, and a commitment, on a firm deadline.

Mandy and the Developers’ Conversation

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

I thought this was going to be a simple estimation, like all the others we do in our pre-sprint meetings, but boy, was I wrong! The team seems really negative about the new version, and I’m really surprised about how hard they think it is to complete. Not having an estimate is going to really mess up the schedule for Marketing. Can’t they see that I need them to make a commitment so we can plan?

Jeffrey thought he was being very clear. “Will the new login screen be done on Friday?” he asked during the Monday morning planning session. “Absolutely. We estimated it at five days, and there’s no reason why it shouldn’t be done by then,” replied the developers.

On the following Monday, the group reviewed progress from the past week. “I see the new login page isn’t working in production,” Jeffrey said. “Why wasn’t it done on Friday like you expected?”

“But we did finish exactly what we planned to do,” came the reply. “The code is live. It works for all our test cases. We’ve disabled it just for now because the single sign-on integration is playing up and the customer team is looking at it for us. It’s done—just not turned on yet.” And now we see the classic problem with this commitment: we didn’t agree on what it means to be done.

The team had had a very simple form of the Commitment Conversation, but Jeffrey had failed to prepare properly. He knew what he meant when he said “done,” and it was all clear in his head. What he didn’t do was collect and express his thoughts about exactly what he was looking for from the commitment. He wanted to know, “Will I be able to use this in production on Friday?” What he had actually asked was, “Will this be done?” Jeffrey would have done better to pose the first, more specific question, or alternatively to follow the second with, “And what will customers be able to use after five days?”

Our suggested cure for this type of misunderstanding is to align our language very carefully and explicitly with our conversation partners before and during the Commitment Conversation. As Roger Schwarz says in Smart Leaders, Smarter Teams: How You and Your Team Get Unstuck to Get Results, we should “use specific examples and agree on what important words mean.”1 This is helpful in any difficult conversation but particularly when discussing a commitment, because the cost of misunderstanding can be very high: unless we clarify precisely what we are committing to, any misunderstanding may not be evident until the time of completion, perhaps weeks or even months later, after much wasted effort. That’s just what happened to Jeffrey and his team.

Notice that we didn’t say that in Jeffrey’s case the team should agree on a single, public definition of done (DoD), an Agile practice particularly used by Scrum teams. We certainly think that a definition of done can be very helpful, and it might have indeed assisted Jeffrey and his team, but it doesn’t give a guarantee against commitment miscommunication. For instance, the team might have defined “done” as “passes all unit tests, product manager verifies functionality, code in production,” and by this definition the login screen was done. The problem was, as always, an interpersonal one; Jeffrey’s thoughts about “done” at the moment he asked differed from those of the developers; and the only way we know to unearth this kind of misalignment is to ask questions like, “What exactly do you mean by ‘done’?”*

“Done” is one important word, the meaning of which you’ll want to discuss and clarify for the Commitment Conversation, but there are likely to be many others. For instance, it’s notoriously hard to capture the target behavior of a complicated software feature like, say, price calculation: “It’s $5 per square meter, except for the granite finish which is $6. And members get 10% off. Except on Thursdays, when it’s 15%. And ...” It’s very easy to miss one of the special cases or to get lost in the details. Luckily, we have techniques like Gojko Adžić’s Specification by Example (SBE),3 which give us a structured way to have a discussion about real cases of the feature in use and make sure we are fully aligned on how it should work.

And when you’re asking for a commitment to a process or cultural change, it’s even more important to align on the meaning of your language by using specific examples. Sofar Sounds, a startup that runs house concerts in hundreds of cities around the world, had this difficulty with the meaning of “DIY” (do it yourself). Initially, attendees would put cash in a hat to support the organization of the event, and musicians weren’t paid for their performances—a very informal, DIY experience. When the company moved to fixed-price ticketing and partnered with Airbnb to sell tickets, it tried to communicate with its widely dispersed community about its continued commitment to the DIY spirit, with the additional income allowing Sofar to make some payments to the players and fund further promotion. But this language didn’t have the same meaning for many artists, who saw themselves performing for low fees while they imagined large amounts of ticket revenue went to a central, distant home office; it seemed to be less DIY and more “do it for them.” Only when Sofar shared detailed examples of event income and expenses were they able to overcome the objections. By showing that income was spent largely on local activities like promotion and improved equipment, they demonstrated that the events were still DIY affairs; and with that shared understanding, they were able to regain the commitment of performers to their shows.4

So when you are preparing for your Commitment Conversation, consider what words and concepts are liable to be misunderstood, and have explicit, detailed discussions about them with your team. If needed, make a glossary or poster with agreed-upon definitions for key words and phrases. And recheck those definitions at the start of each Commitment Conversation.

Scoring for Agreement:
Shared Meaning Fraction

When you want to check how you’re doing with agreeing on meaning, score a conversation by circling the most important words in the conversation and verifying that you and your conversation partner have confirmed your common understanding of the definition of each one. The important words will usually include nouns that name key elements of the activity you’re discussing (“user,” “price,” “preference,” “subscription”) as well as verbs and adjectives that describe how those elements interact (“secure,” “valid,” “authenticate,” “purchase”). Create a fraction showing how many of the words have confirmed, shared meanings (the numerator) over the total number of important words (the denominator):

$${\displaystyle \frac{\text{Words with Confirmed and Shared Meanings}}{\text{Important Words}}}$$.

A promise is a flimsy thing, easily made and just as easily broken. A commitment should be more than a promise—something you make with conviction and knowledge, and execute with creativity and skill. You will be able to make stronger, more confident commitments if you can do two things: keep each commitment as small as possible, and use a framework that makes it easy to deliver your small commitments over and over. The Walking Skeleton technique gives you both of these advantages.

Alistair Cockburn coined the phrase “Walking Skeleton” in the 1990s to describe a repeated pattern he observed in early iterative-delivery teams. As he tells it in Agile Software Development: The Cooperative Game, a project designer told him this story:

Here, the “ring” that bears the messages is the Walking Skeleton. Like a real skeleton, it gives the system a meaningful structure from which you can discern the final intended form—you can look at a skeleton and immediately distinguish, say, whether it belongs to a fish or a frog, even if you can’t tell exactly which species it is. And from just the above description of the ring system, you can determine quickly that it is going to involve some sort of internetwork communication. But unlike a real skeleton, the ring system “walks” because it actually performs a function, passing messages, even if they are initially just trivial ones.

As a result of these two characteristics of the Walking Skeleton, its structure and its function, it also provides a language for describing commitments and a mechanism for their delivery: “By Friday I’ll have the payment message passing around the ring, though it may not be validated yet.” And it lets the team keep each change very small and immediately deliverable; you can start with a null message, then gradually add content and additional types and routing, until you wind up with the final system.

In modern software design, the Walking Skeleton may manifest as a client-side interface, often in a browser, talking to a very simple back-end system with a database and appropriate integrations to third parties. For instance, London-based startup Unmade helps apparel companies offer customizable clothing using software that integrates with their retail and manufacturing operations. For a recent project, their Walking Skeleton had a stripped-down user interface—little more than a couple of color pickers—and a basic output file sent to the garment manufacturer in a single format, with fixed values for parameters like size and fit. Despite its simplicity, this was enough to produce an actual piece of clothing with user-chosen colors. From this simple interface, Unmade was able to add increasingly more customizations, sizes, and formats every sprint, producing better and better garments, until they delivered the project right on time.

With all of this said, there are two constraints to bear in mind when creating a Walking Skeleton:

1.Don’t leave out any limbs; an incomplete skeleton is worse than useless. Unmade’s system would have been no good as a framework for their commitments if they had entirely left out, say, customization choices or the ability to produce an output file, as they would have been unable to make a real shirt or pair of pants. How could internal and external customers have verified that each delivery along the way was adding value and meeting commitments unless they could look at and put on a physical garment?

2.Don’t confuse a Walking Skeleton with a minimum viable product (MVP). No one would buy from a shop that carried only one size, so Unmade’s first skeletal version of the product was a long way from commercially viable. However, it successfully exercised all the components of the final software system, generating tremendous confidence and providing a delivery mechanism that worked fantastically well to get to the ultimate goal. You may want to produce and use an MVP somewhere along the way as you add features to your skeleton, but your initial skeleton can be much simpler.

What about nonsoftware commitments? The Walking Skeleton is useful here too, with appropriate modifications. A common DevOps pattern is to begin monitoring and publishing information about a system characteristic (say, memory usage) and then use this as a Walking Skeleton, chipping away at the metric with a series of small commitments to reduce the footprint by 5%, then 10%, and so on. Another example: we used a monthly management study group as a Walking Skeleton to help an organization first investigate new ways of managing, then gradually introduced one such change after another, evaluating its progress with each other in the study-group sessions.

The Conversation: Making a Commitment

With the conversational skills you’ve now built up, the steps to a successful Commitment Conversation are easy—deceptively easy—to summarize. First, agree on the meaning of words you’ll use in the conversation, perhaps using some TDD for People or Coherence Busting to overcome misunderstandings and fears. Then use your Walking Skeleton to define one or more small steps forward, and agree with your conversation partner on a commitment for those steps. Finally, explicitly confirm the commitment, perhaps by asking everyone involved to restate and accept the commitment, or by posting it publicly on a board or a wiki page.

The three steps to a successful Commitment Conversation are:

1.Agree on the meaning of the commitment.

2.Agree on the next outcome to commit to.

3.Reaffirm the commitment.

Obstacles to the Commitment Conversation

The steps seem straightforward—but obstacles are waiting to trip you up.

The first obstacle is cultural: the idea that voluntary commitment is valuable may be a threatening, unwelcome concept in your environment. Where this is the case, compliance is the order of the day, because managers prefer the illusion that all they need is for their staff to do what they have been asked. After all, they don’t have to ask for commitment from machines. And thinking of humans as a kind of machine makes the job of management much simpler, as we pointed out in Chapter 1: you needn’t confront the fact that your team doesn’t trust you, or that you fear it won’t do the job well, or any number of other messy problems that come with those pesky humans.

Management is indeed much simpler if we believe that people doing what they’re told is enough. It is easier to staff projects if we consider developers to be interchangeable resources, one of whom can be instantly and painlessly substituted for another. It is even easier if we believe a single engineer can divide her time efficiently among two, three, or even more projects! These beliefs about substitutability and frictionless task-switching fit the Taylorist, person-as-machine model. However, humans aren’t like that, and admitting as much might undercut the basis of the management culture, forcing us to confront difficult interpersonal issues that would just be easier to ignore.

If you suspect you have a cultural bias against commitment, or if you encounter resistance that shows this bias does exist, you aren’t ready for the Commitment Conversation. Return to earlier chapters to address the issues of Trust, Fear, and Why that underlie this resistance first, and then you will find the conversation itself much easier to hold.

The second obstacle, paradoxically, is the existing commitment process your team uses, which may be sprint planning, detailed design documents, or simply nodding when the boss gives you a deadline. Whatever method you use, your team may be too comfortable with it—too willing to accept unclear language and overly aggressive deadlines without engaging in a fruitful Commitment Conversation about all your options and about productivity, and inward versus outward investment.

If this describes your experience, try jointly designing your way out of the situation, so your team has participated in designing and holding a Commitment Conversation that works for them. You may also find it helpful to use the Directed Opportunism “briefing” structure that we describe in Chapter 7 to help your team identify what constraints and freedoms they can exercise when helping to shape the commitment.

The final obstacle is partial acceptance. No matter what you try, you may find that some members of the group are still stuck in compliance mode and just can’t get to a commitment, thanks to indifference, hostility, or simply sheer stubbornness. Luckily, you don’t need commitment from everyone! You do need someone or some group who has internal commitment to make a genuine attempt. These people, if they achieve some measure of success, can become champions and evangelists who then engender a committed attempt from others. We’ve never seen a successful culture or process transformation project, for example, without the unwavering effort of at least a few committed individuals at the start.

When you’ve overcome these obstacles and have a smooth Commitment Conversation, it will feel great! We remember one of our team meetings a few years ago: We were planning a lengthy project one summer in a hot meeting room. Everyone had argued out all the meanings and defined many small steps on the way to the larger commitment we wanted to make, and we’d added up our estimates on the whiteboard to reach an overall delivery date some five months away. Silence descended, as no one wanted to comment on what was a substantial commitment, until one brave engineer piped up from the back.

“Gee, everyone, there’s nothing to be afraid of here. We understand the tasks, and we know each one is individually simple and achievable. If we can’t complete this set of tasks by that date, in fact much sooner, we should go into another line of work.”

We polled the team, who looked relieved as everyone agreed that the tasks were definitely achievable. Then we emerged into the cool air together, a committed team.

Mandy’s Commitment Story Continued

Reflecting and Revising

I’m going to start trying to understand my conversation by reflecting on it and scoring it. I asked two questions, and on reflection, I do think both were genuine—I really did want to know why version 2 was so much more complex than Version 1, and when the feature might actually be ready. On the other hand, my left-hand column shows that I had a lot of doubts about what the developers were saying, and I didn’t share them at all. I also notice I said “Really?” a lot when I was surprised or displeased, which seems like a tell.

How about agreeing on meaning? I circled five words or phrases that seem particularly important to the topic: “estimate,” “done,” “validation,” “complex test case,” and “ready.” Some of my doubts in the left-hand column were about what the developers meant by these words, but I never asked or clarified them specifically. So zero out of five there for me, I think.

To improve and Revise, I’d mainly like to be better at sharing doubts. I can try to notice when we have possible disagreements on meaning and express my concerns right away, instead of suppressing them. That should help me get to a clearer commitment—or at least I hope it will!

Improved Conversation

I sought out David, the tech lead for the Developer Relations team. I wanted to see if we could find a way to work together on creating a commitment that the team and others could both believe in.

Mandy and David’s Improved Conversation

What Mandy thought and felt	What Mandy and David said
	Mandy: I was really surprised by the reaction of the team to estimating for the new API.
Yep, I wasn’t dreaming. Something is wrong here.	David: Yeah, I got that too. And it’s not the first time they’ve expressed those concerns.
I especially value David’s view. Does he think we have a problem?	Mandy: Can you tell me more about the concerns? And what do you think yourself?
How odd. Where did March 4th come from?	David: It’s much harder than we thought. And Marketing says it wants it by the 4th of March, no exceptions. The team doesn’t see how to finish by then, and frankly, I don’t either.
Can David tell me more about this?	Mandy: That’s news to me—and an oddly specific date.
Ah, I get it. No one has asked me to get a commitment for early March yet, but I bet a request like that is on the way.	David: I thought so too, until I saw them laying out seating plans. They’ve rented a hall and invited all our customers for lunch to see the all-new, all-singing, all-dancing API!
I’ll remind Dave that features aren’t committed until we’ve agreed to them as a team. I wonder how far off we really are from Marketing’s target?	Mandy: Well, the good news is that we haven’t actually committed to anything yet, though it sounds like Marketing has. What delivery date might the team accept as reasonable?
Ouch. That’s a long time. But I don’t understand the meaning of that final phrase.	David: Definitely not before June; July would be better. The data needs a lot of filtering before it’s client-ready.
I think “client-ready” isn’t needed here, just “good enough to demo.”	Mandy: Wait, “client-ready”? What do you mean by that?
Ah, we have the same understanding of the word but a different understanding of the commitment.	David: Well, obviously all the validations have to be in place, and all the tests for edge cases. We can’t give bad data to clients.
The distinction is important—I bet he can suggest ways to simplify the scope if we can align on what’s needed.	Mandy: I’m not sure we’re talking about the same thing. The commitment we need is for something we can demonstrate during a sales pitch, like at this lunch you mentioned, or on a prospect visit. Does that match your understanding?
Yes, now he’s got it.	David: I think I see what you’re getting at. We just have to be able to show the basic workflow, not the whole working integration.
I need to share the constraint: we have to protect client data from inadvertent disclosure, or the regulator will come down on us hard.	Mandy: Exactly. Does that reduced constraint help at all? We can take reasonable shortcuts, just so long as we don’t put real data at risk.
Ah, I really like that, especially the dummy data.	David: Well, we could skip the validations for a start. And we could even use dummy data that we know would be simple to display.
Let’s see if we’ve cleared the commitment obstacle.	Mandy: Both of those scope changes would be fine. Would that help the team to make a confident commitment to March 4th?
That sounds very promising!	David: I’m pretty sure we can find a way to deliver without validations or real data. I’ll ask the team this afternoon and let you know by tomorrow morning what I hear.

I wanted to agree on time and scope with David, but we had to clarify several things first: why the team was concerned, when Marketing’s target was and why they had picked it, and what the constraints were on the team’s work toward the target. Clarifying the meaning of “client-ready” helped us move toward an informed commitment—one that meets the external constraint (deliver by March 4th) as well as an internal one (don’t expose customer data). I was really pleased with how this conversation went!

Example Commitment Conversations

Nash and the Sysadmins:
Designing the Walking Skeleton

Nash says, “I’m a nontechnical executive in the IT department of a major retailer. We need to set up new sites in seven countries around the world to support a new product line we’re launching this quarter. The current estimate from the tech team is six months to launch the new online services, which is way too slow; they tell me the biggest holdup is setting up the servers. I’m visiting a group of three system administrators, Abdul, Becca, and Molly, who work in our development team. My goal is to find out what options we have to get these sites up fast!”

Nash and Sysadmin’s Conversation

What Nash thought and felt	What Nash and the Sysadmins said
Let’s get the issue on the table. I want to check my information is right first.	Nash: The engineering leads tell me the earliest date we can get the seven new sites up is in February. Is that right?
Okay, confirmed the bad news.	Becca: Yes, that’s our best estimate. We’re confident about committing to provisioning all the servers then.
It’s so annoying that we can’t go faster. Surely it’s technically possible?	Nash: Argh, how frustrating! The problem is, February is about three months late. We need the sites by November at the latest, for Christmas. What options do we have to meet that target?
I’m glad Molly trusts my motives at least.	Molly: I believe you, and I’d love to say we can do it, but it’s just not possible. Even getting backups in place takes many weeks.
That sure sounds inefficient. I wonder why they haven’t done anything about this.	Abdul: Not to mention all the manual config. The process is clunky, but we know it works.
I’m assuming there’s some way around this. I should verify that I’m right.	Nash: I’m no techie, but those sound like things we could automate. Am I missing something?
That’s what I thought. Why are the internal barriers so high?	Becca: Sure! There are lots of tools that let you stand up servers quickly and repeatably. But IT Risk and InfoSec haven’t approved them.
This might be a way to get a Walking Skeleton going.	Nash: That’s true but only for live sites, right? Could we get internal services up faster, and then add patch management, backups and so on later, with the normal approvals?
	Abdul: Sure, but how would that help?
A series of small commitments, each met, should build a lot of confidence.	Nash: Well, if the sites are up, the developers can start coding and deploying much sooner, and we can show real progress to Marketing.
Molly’s right, but I may be able to help.	Molly: But that doesn’t get us to your deadline. We’ll be live internally faster but will still have to jump through all the hoops to make the servers production-ready.
	Nash: Let me worry about that. I suspect that showing regular, visible progress will smooth the way for approvals. Using the new tools, can we get bare-bones machines deployed this week, for example?
Better than I thought!	Abdul: Yes; in fact we can do it in all seven countries.
Great! Becca gets it too. A plan like this would help me find optimizations elsewhere in tech and get marketing underway too.	Becca: Agreed. What’s more, I’m sure we can whip up a roadmap showing our planned weekly progress for the next two months using the new tools for incremental setup. I’m not sure about anything beyond that, though, and I don’t think we’ll be done by that point.
I think we’re aligned now. Time for a final check on the plan and the commitment.	Nash: We don’t have to be; we can replan as we go, and we’ll learn more as we start to use the new setup. Am I right you’d all be comfortable committing to a two-month partial roadmap with weekly deliveries?
Well, I didn’t get certain delivery by Christmas, but a clearly committed team with a clear plan to execute is a pretty good alternative.	All: Yes!

Nash would have been most happy with an immediate, confident commitment to Christmas delivery of all seven servers. He was pleased, though, that the culture of psychological safety they’d worked to build meant the team could tell him this wasn’t realistic. The Walking Skeleton alternative looks promising (as it often does for DevOps challenges), but it may require some intervention from him to get clearance for incremental deployments—a reciprocal commitment Nash makes to the team that he wouldn’t have known was necessary without the Commitment Conversation. The Walking Skeleton lets the team work to a set of incremental milestones that are much easier to commit to, and this gives Nash enough to get other teams started. It’s a scenario where everybody wins!

Julie and Erik:
Committing to a New Process

Julie says, “Recently, I’ve been finding it really hard to work with Erik, who is the CEO and my boss. He likes participating in decisions like which feature we’ll build next or whether to hire another developer, but sometimes it seems to me that getting involved at a low level isn’t very efficient for him or healthy for my team. It’s hard for me—and others who work with Erik—to tell when he should be informed about or participate in a decision and when he doesn’t need to be involved. I’ve developed a document template that I think might help organize our joint decision-making. It lays out which decisions need Erik’s input and which don’t, gives space for presenting options, and reminds us to gather data about each option, like its cost and the time it will take to execute. I’m about to talk with Erik about committing to use this new process.”

Julie and Erik’s Conversation

What Julie thought and felt	What Julie and Erik said
	Julie: Did you have a chance to read the decision document?
This is a good start!	Erik: I did, and I like it! I made a few edits. I’m glad you’re working on it.
Let’s check our alignment on the basic idea first.	Julie: Super! I’ll look at those changes later. More fundamentally, did the idea of a decision process seem valuable to you?
Ouch. That’s true, but I think he missed the point.	Erik: Sure. It should help me keep us on track and aligned. I can read all the details and feedback to you on each decision you make.
Deep breath—a little apprehensive about challenging him like this.	Julie: I’m glad you said that, because I’m not sure I agree.
	Erik: Really? What do you mean?
Let me slow down here with a question. Are we agreeing about the underlying assumptions?	Julie: Well, the greatest value in this process for me is that it will help me know whether to involve you in a particular decision at all. Do you agree that it’s good for me to make some decisions without you?
A few months ago I wouldn’t have trusted this answer, but our stories are better aligned now. I really do think he wants to delegate.	Erik: Yes, of course. As the company grows, I can’t do everything; and I have to let other people take the reins sometimes.
This is my key point.	Julie: Okay, we’re aligned there for sure. So the part I’m most keen to agree on is how we’ll use the decision document in cases where I don’t need to involve you.
	Erik: Hmm, I don’t follow. In that case, why would you need to fill it in?
	Julie: Well, this section at the top describes when to use the document. If a decision doesn’t meet these criteria, we stop and don’t use the document at all.
I’m glad I probed and clarified. Now I’m much more confident that we’re aligned.	Erik: Aha, because it’s low enough level that I don’t need to be involved. I didn’t quite follow that section, but I get it now.
Final check—are we committing now?	Julie: So you’re okay if I, and others, use those criteria as a filter?
Sounds like a commitment to me!	Erik: Sure, though some of them need a little tweaking. The budget limit can be higher, for example. But I’m definitely keen to start using this now.

Notice how Trust entered at a crucial moment here. Given Erik’s history of micromanagement, Julie could have easily discounted his assertion that he wanted her to make some decisions independently, but having gone through a Fear Conversation, where Erik’s time was identified as a possible limiting factor in company growth, she chose to believe her aligned story that he really did. This is the building of a Commitment Conversation on the foundation of earlier conversations. Agreeing on meaning was very important as well—the two of them could easily have “agreed” to the process without Erik fully understanding that it included delegation criteria, meaning that he was committing to not doing some things. This would surely have led to a lot of confusion and frustration. We’re pleased to report that Erik and Julie adopted and still use the decision framework, with great results!

Anna Shipman, technical director of customer products at the Financial Times, had a compliance problem, as she outlined in her blog.7 There was nothing obviously wrong. Seven months into her role as technical director, her team of fifty-five engineers was successfully running the newspaper’s main website, as well as satellite brands, and Android and iOS apps. With almost a million paying users around the world,8 the site had to remain constantly up to date with the latest news, load instantly on all devices, and add new features daily. With both continuous deployment and A/B testing running on overdrive, the team was delivering improvements hundreds of times a week, experimenting nonstop, and keeping up with internal and external customer demand.

But Anna knew there was still something holding back the team. She could sense it in her own day-to-day work as she handed out assignments to her five principal engineers. Whether she did this in their weekly meeting, over Slack or email, or in person, a nagging feeling told her something wasn’t right. “I was still in control of the flow of tasks,” she said. “I felt there must be a better way to do this so that the principals know the problems ... that I need help with (and also know about the problems I don’t know about).”9 In short, she wanted commitment, not mere compliance.

Like many managers, Anna was finding that when you tell your staff what to do, they do it—and that was the opposite of the creative, innovative team that their Agile practices could support. Instead, her goal was for her management team to be self-organizing and autonomous, so that “each of them [would] be a good candidate to take over [her] job.”10 And that couldn’t happen while she was stuck in the role of chief task distributor.

Tearing Out the Filter

After seeking advice from colleagues and from peers about how to give more autonomy to her principal engineers, Anna resolved to have what we’d call a Commitment Conversation with them. Her goal was to jointly design a better way of interacting—one that would let them commit to tasks themselves, without undue dependence on her.

She started by explaining that she’d been filtering out contextual information from the rest of the business, such as incoming feature requests, status reports from other teams, and financial results. She said she “didn’t want to drown [the] team in emails,”11 so she’d protected them from this tsunami of outside input. For her, the emails and requests were distractions that she needed to shield her team from.

But the principal engineers responded in a surprising way: they asked to receive more unfiltered information, not less. This would allow them to make sensible prioritization and optimization decisions. Further, if someone brought up an issue, they would be familiar with it rather than baffled or confused; they would be able to make informed commitments and deliver on them. The meaning of the outside input was very different to them: it was valuable context.

“Essentially I thought I was protecting them and helping them do their jobs,” said Anna later, “but in fact I was actually blocking the information flow and making it harder for them to do their jobs.”12

Once they’d agreed on a common meaning for the incoming contextual information through a Commitment Conversation, Anna and her principal engineers committed to take several steps to share context among themselves:

•They set up a mailing list and asked others to use it for requests rather than just emailing Anna. She also forwarded emails to this list that she thought the group might find helpful. This formed the Walking Skeleton that would allow the group to take on the other initiatives.

•Anna brought one or more of the principal engineers to relevant meetings and sometimes even sent them in her place. Attendees shared meeting notes with the rest of the group on the mailing list afterward.

•The group extended their weekly meetings and used a color-coded kanban board to track tasks and share information about them.

•Anna spent more time on her team’s Why, sharing the results of her thinking on the mailing list, an internal wiki, and an external conference talk.13

“Solved before I’ve Heard about It”

The results from the commitment to share more context were dramatic. The group email address became the destination for most requests, allowing all of its members access to more information so they could react accordingly. The principal engineers were able to pass work to each other’s teams when they were overloaded, increasing the odds of a successful delivery. And “quite often,” Anna says, “someone will email or mention ... a problem that they have picked up and solved before I’ve even heard that it exists.”14 They had found and used untapped potential in the development organization—and it’s all thanks to the Commitment Conversation.

Conclusion:
Applying the Commitment Conversation

In this chapter, you learned to identify key concepts and clarify their meaning, to use a Walking Skeleton to provide structure to your commitments, and to make commitments effectively using these techniques and those from previous chapters. The productive Model II reasoning promoted by your conversational transformation creates the right environment for effective commitments, while delivery on those commitments promotes Trust and reduces Fear to move the transformation forward still further. You can use the Commitment Conversation in many ways, including the following:

An executive leader can align the work culture among multiple departments, like Engineering and Sales, by expecting believable, easily tracked commitments from each, and tracking progress on those commitments.

A team lead and her team can make commitments such as sprint goals and build-measure-learn targets with confidence and enthusiasm.

An individual contributor can participate in defining commitments and contribute to their fulfillment.

*

There is solid psychological research suggesting that concepts like “done” are not well defined inside our brains. Only through examples can we align about their meaning. For example, try asking ten people whether a clock is furniture or not—you will get a wide variety of answers! See Gregory Murphy’s The Big Book of Concepts for much more.2