Chapter 7

Within the feature factory, it would be unimaginable to be completely transparent about delivery and its challenges—why bother, when we’re stifled by rigid dicta at every turn? And the same lack of autonomy makes it pointless to be curious about options for varying goals and tactics, since no variation would be achievable anyway. But as we’ve built Trust, removed Fear, defined Why, and honored Commitment, we’ve become much more autonomous and unconstrained; and this level of transparency and curiosity is now possible with our final conversation: Accountability.

Executives will find that accountability leads their departments to learn about and correct errors like prioritizing the wrong feature or overspending on cloud servers much earlier and much more efficiently. Team leads will use the Accountability Conversation to clarify sprint and team goals, discover options for achieving those goals, and radiate their team’s intentions for feature builds and architectural changes. And individual contributors will no longer say, “We’re stuck supporting old browsers” or “Some idiot told us to skip the tests.” They will know what the constraints and freedoms are for their work, and where they can exercise creativity in meeting targets.

•Give briefings and back briefings that let the team efficiently and accurately render an account of its actions.

•Use the Accountability Conversation to radiate intent, so that everyone concerned with your work can provide help, advice, or corrections in an efficient and supportive way.

“Not another one!” exclaimed Danny. “That’s the second feature this week that’s been delayed. At this rate, we won’t have anything at all to demonstrate on Friday.”

As the CTO of a rapidly growing startup, Danny has more teams working for him than ever before. Back when the company was smaller, he was able to divide his time among all the engineers and know exactly how each was doing. But these days, there just isn’t time to talk with every team member during every sprint; and he’s losing touch with day-to-day progress.

The email he’d just read was typical: the mobile developers were behind again, and one of their app changes wouldn’t be ready by the end of the sprint. They weren’t alone; nearly every week, at least one team had bad news for him, and often two or three would report slippages.

Danny knew all too well that development doesn’t always go to plan. And in fact, he enjoyed the part of his job where developers came to him with problems—he loved discussing technical options and working with product designers and the business to find creative solutions. With many of the older teams, this dynamic was still working well, and the developers did come to him with problems; there were minor snags and bugs, to be sure, but he didn’t fear a nasty surprise at the end of a sprint. However, some of the newer teams were much more unpredictable, with major features slipping by weeks and sometimes months.

Danny put his head in his hands and tried to come up with a plan. Should he introduce a daily progress report? Hire a delivery manager? Replace one of the team leads? He wasn’t sure what step to take next, but he knew something had to change.

Danny’s response is a common one. If we are being repeatedly, unpleasantly surprised—missed deadlines, system downtime, budget shortfalls—we want to take action to end those surprises. The normal approach is to ask for more detailed information, to provide more specific instructions, or to put in more detailed controls. Or sometimes all three! Unfortunately, these instinctive responses often make things worse, because they miss the root of the problem: accountability.

What do we mean by being accountable? We mean simply being obligated to render an account of what you have done and why. A feeling of accountability, held by each person, is one of the keys to success. Accountability is akin to ownership, to responsibility, and to agency. If I am in control of how I spend my time, then only I am able to provide the information on why I have done what I’ve done, providing the reasoning and the intent behind my actions.

Notice that we are defining accountability very differently from most people. When we hear a manager saying she will “hold someone accountable,” our instinct may be to duck under the nearest desk; the phrase connotes correction or punishment for doing something wrong. (See the sidebar on the next page for a historical perspective that may explain this fear.) The person being held accountable is expected to feel contrite, to learn from their mistakes. By contrast, our definition suggests that you can be accountable for a success, a failure, or a neutral result. But “Let’s hold someone accountable for doubling sales last month!” is probably not a sentence any of us hear very often.

Our version of accountability—the obligation to explain our results—is key to the self-organization that Agile, Lean, and DevOps teams aim for. Each team member is empowered to make their own decisions about how to allocate time and energy. However, with this empowerment comes an expectation to share what those decisions are and why they were made. Sometimes the Accountability Conversation takes the form of sharing intentions: “Here is what I’m planning to do and why.” Other times it is a debriefing or a formal report on a past event. Whatever form this accountability takes, Danny will be able to scale his efforts more successfully if he suppresses his instinct for control and, instead, builds a culture of accountability within his team.

This probably sounds simple to do; and yet being effectively accountable is a learned skill. It requires, as usual, difficult emotional work, cultural change, and much practice. In particular, an effective Accountability Conversation requires high Trust (“I believe you will share my story about how I performed”), low Fear (“I know you won’t overreact to my account of what I did”), an agreed Why (“We are headed for this vision, and here’s how far we got today”), and a clear Commitment (“Here’s my account: I committed to do A and what actually happened was B”). You’re more likely to succeed if you and your team have had each of these conversations before embarking on the Accountability Conversation.

Sidebar: Medieval Accountability

Why does the word “accountable” typically have a punitive connotation? We think it might have to do with the origins of the word. “Accountable” literally means “rendering an account,” with “account,” in turn, coming from the Old French for “reckon” or “enumerate.”1 The word first entered English in medieval times, when it was used to describe the actions of twelfth-century sheriffs. These sheriffs or “shire-reeves,” unlike their gun-slinging Wild West descendants, were essentially revenue collectors for the far-flung Angevin Empire. Each was given a “farm,” an amount to be paid to the king every year, and was free to extract that amount from his territory more or less as he pleased. Many sheriffs profited handsomely by demanding much more than their assigned farm from their overawed citizens, keeping the excess for themselves.2

The administration of Henry II (King of England, 1154–1189) decreed that the sheriffs would be summoned to his court every Michaelmas (the 29th of September), where they were to bring the annual receipts—in cash, of course (no checks or credit cards in the 1100s!)—to be counted and handed in.3 Arithmetic was an uncommon skill, so the treasurer and his assistants used the Exchequer, a sort of chessboard, along with a set of counters to represent and compute the money owed to the Crown by the sheriff, and any setoffs from that amount.4 The exchequer board came to represent the whole process, which became known as “the Exchequer” of a particular year.5 Each sheriff came forward in turn to describe that year’s income and to remind the treasurer about any exceptions or deductions. When an agreed total was computed, the sheriff would hand over a bag of silver pennies to settle his debt.6 A sheriff who was found to be short of the correct amount could be fined or imprisoned on the spot.7 So if you think reporting a missed sprint goal is worrying, imagine what a fraught experience it was to be accountable in the twelfth century!

I’m Nicole, a product director with responsibility for multiple teams in our organization. Bobby is the product manager for one of these teams. He frequently seems to misunderstand what I’m asking him to work on, meaning that we often have to stop halfway through a feature or project, reset expectations with the developers, and change half the code. It’s getting bad enough that I’m considering firing Bobby, but I’ve started to wonder whether my own management style and communication approach might be contributing to the problem. Starting with the first R (Record), I’ve documented our last interaction to see whether I can find ways to improve.

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

I felt pretty good about this conversation at the time; however, when the team demonstrated the new report a week later, I was a lot less happy. The team had used comma-separated values instead of Excel format, hadn’t included Australia as a region, and made a bunch of smaller errors. Why can’t Bobby get these things right?

Is it reasonable to expect accountability from your team? Are employees self-interested, moved to action only by direction from above, and incapable of explaining their actions? Or are they interested in success, motivated by a desire to do well, and responsible for their behavior? Management theorist Douglas McGregor, in The Human Side of Enterprise, called these two views of employee motivation Theory X and Theory Y (see Table 7.1).8

Theory X is closely related to the Taylorist view explored in Chapter 1. It says that workers are lazy and dumb, and must be presided over by managers. When they screw up, they need to be sent to the naughty corner to learn from their mistakes. “I’m not getting results from my workers? The solution is more management,” says the Theory X manager. “If I’m not getting the insight into progress that I expect, and if I’m not hearing about issues in time to fix them, then I’ll hire a manager to get that information.” Accountability for individual contributors is nonsensical if you subscribe to Theory X. The workers have no investment in their own actions nor do they have meaningful involvement in the planning, so it is silly to ask them to explain those actions or the consequences. Instead, you should ask the relevant manager—it is their job to know.

Theory Y is a fundamentally different view of humanity. It says that people want to be engaged, that they want to take ownership, and that they carry the drive for success within themselves. If we believe Theory Y, then the Theory X model of management is not just harmful, it’s wasteful. We get better results more cheaply by using the drive for success inherent in each individual. And in a Theory Y organization, accountability is vital. Our motivated, responsible workers need and want to tell managers and collaborators alike about their activities and results; and they also thirst for accurate feedback on those results, to adjust their actions appropriately.

Looking back at the Agile, Lean, and DevOps principles from Chapter 1, we can see a strong bias toward Theory Y:

•Give motivated individuals the environment and the support they need, and trust them to get the job done.

THEORY X	THEORY Y
Attitude
People dislike work, find it boring, and will avoid it if they can.	People need to work and want to take an interest in it. Under the right conditions, they enjoy it.
Direction
People must be forced or bribed to make the right effort.	People will direct themselves toward a target that they accept.
Responsibility
People would rather be directed than accept responsibility (which they avoid).	People will seek and accept responsibility, under the right conditions.
Motivation
People are motivated mainly by money and fears about their job security.	Under the right conditions, people are motivated by the desire to realize their own potential.
Creativity
Most people have little creativity—except when it comes to getting around rules.	Creativity and ingenuity are widely distributed and grossly underused.

Niels Pflaeging, “Why We Cannot Learn a Damn Thing from Toyota, or Semco."

Table 7.1: Theory X and Theory Y

This is no surprise, of course; as we’ve looked at each of the previous four conversations, we’ve seen story after story of software teams succeeding through behaviors consistent with Theory Y, like building trust, explaining motivation rather than imposing a vision, and providing context to drive commitment. In fact, we agree with Niels Pflaeging that adoption of Theory Y is a precondition for success with Agile, Lean, or DevOps methods.9

So what puzzles us is why Theory X is still so pervasive in teams that are, at least in theory, adopting people-centric software methods. Why would anyone retain a cultural schema that actively discourages accountability (in our sense)?

We’ll leave an exhaustive answer to the social scientists, but we suspect a contributing factor may be the examples shown in television and movies, which supply our first models of leadership. Some films portray the strong, decisive leader barking orders—someone who is firm but fair. Tough. Not afraid of calling out someone who is screwing up. The other trope is the ineffective manager, Dilbert’s “pointy-haired boss,” who is always asking for status reports and nitpicking the details while missing the big picture. Neither of these approaches are examples of effective leadership, in part because they are at odds with true accountability (the decisive leader won’t listen to the account, and the indecisive one can’t make up their mind about what to do with the information). Both styles lead to unproductive conflict in the organization—but conflict is exactly what creates drama, which is what sells movie tickets and Netflix subscriptions, thus accounting for the popularity of these approaches in films and television.

In contrast, media models of interdependence and self-organization are much more limited. The only prominent dramatic portrayal of a Theory Y leader we can think of is Patrick Stewart’s Captain Picard in the Star Trek franchise, who regularly gathers all views from his crew members before reacting to a new observation or event, and then frequently delegates the bold, dangerous intervention to others. Superhero groups like The Avengers, or the protagonists of the occasional ensemble movie like Stand By Me, portray interdependent groups of people with very different skills who overcome obstacles by using whatever strengths each can contribute; they are also accountable to each other for their decisions and their consequences. But these are exceptions that seem far from daily life.

What can you do to overcome this bias toward Theory X? As with most changes like this, we recommend that you enlist sympathetic team members to help you identify and overcome Theory X beliefs and habits in your organization. For instance, you might renew your commitment to psychological safety (see Chapter 4), share business context as Anna Shipman and her team did (see Chapter 6), and celebrate those who take on additional responsibilities. Simply by holding the Accountability Conversation, you will be sending a powerful cultural message about autonomy and internal motivation.

Another obstacle standing in the way of the Accountability Conversation is naïve realism.10 This is the view that we see the world objectively and without bias, and further, that other people will come to the same conclusions as we do, based on the same observations. When we adopt this simplistic view of the world, we see less need to communicate and certainly see no requirement to render an account; after all, everyone else observes the same things we do, so why would we need to explain our actions or their results? Of course, this approach is misguided, and we need the Accountability Conversation precisely because others may have information we don’t possess; and they may draw different conclusions about results than we do.

There is a structured way to eliminate our bias toward naïve realism, and from a surprising source: the practices of the Prussian military in the nineteenth century. Stephen Bungay describes this method, which he calls “Directed Opportunism,” in his book The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results.11

Bungay begins with a description of “friction,” the sum of all those ways Murphy’s Law (“whatever can go wrong will go wrong”) does its work. The results of friction are three gaps that arise in our attempt to convert the outcomes we desire into plans, our plans into actions, and those actions into the outcomes we intended (see Figure 7.2 on page 164):

•The knowledge gap is the difference between what we would like to know and what we actually know.

•The alignment gap is the difference between what we want people to do and what they actually do.

•The effects gap is the difference between what we expect our actions to achieve and what they actually achieve.

The management-centric approach to the three gaps above is to try and eliminate them. To close the knowledge gap, leaders seek more detailed information. To close the alignment gap, they give more specific instructions. And to close the effects gap, they implement more detailed controls. Fully closing the gaps is impossible, however, and our increasingly determined attempts to do so cause suffering. In response to such authoritarian micromanagement, “commitment is replaced by compliance, energy is sapped, and morale declines.”12

As an alternative, Bungay offers his Directed Opportunism method, which he reverse engineered from the strategic and tactical innovations of Prussian military leaders during their wars with France, Denmark, and Austria during the 1800s. The Prussians found that communicating plans and intentions clearly, both up and down the chain of command, was vital for mastering the increasing complexity of nineteenth-century warfare. Thus the core of Directed Opportunism is a protocol between the parties: one person uses a briefing to describe where we are going, and the other uses a “back briefing” to explain how we plan to get there.

In a briefing, one person communicates her intended outcome, provides constraints within which that outcome should be sought, and describes freedoms available during execution. For example, Bungay tells the story of a commander who told two of his generals to move their divisions north to surround the French (outcome) without being slowed down by engagement with the enemy (constraint), and by using whatever route made the most sense for them (freedom).13*

By providing the desired outcome and its associated freedoms and constraints, the person providing the outcome is being accountable. They are providing information only they can provide, such as priorities and the trade-offs they value. This is very different from the Theory X approach, with plans handed down from on high, where what the organization wants to achieve is, at best, intermixed with how things should be done; and there is little to no freedom to stray from the dictated path.

Besides being wasteful of human resourcefulness, this approach of planning from the top often falls into the knowledge gap, where the managers doing the planning lack the knowledge and experience of those closer to where the work is done. How could the Prussian commander possibly know the right route for his subordinates to choose from miles away, and without the benefit of modern battlefield information sources, like drones and radios? Far better to equip them with clear intent and allow them to make the right choice based on the local data that only they have.

A good example of a clear briefing was provided by Boeing during the design phase of their 777 airliner.14 Designers were struggling with lowering the overall weight of the airplane while also keeping the cost within the planned budget. How could they get the best trade-offs between weight savings and cost savings in the design for the whole craft? Should they, for example, use a more expensive rudder to save weight while changing to more efficient but heavier landing gear? With hundreds of engineers working in separate groups on a large number of subsystems, it was very difficult to see where it was even possible to make such a swap of cost for weight on widely separated, unrelated parts of the airplane.

The solution Boeing found was to provide a briefing to engineers about what trade-offs they could and should make on their local subsystem in the form of simple cost guidelines. An engineer could spend up to $300 to save a pound without approval; spending up to $600 per pound needed only a local supervisor’s okay; and even more, up to $2,500, could be spent to save a pound if a program manager gave the go-ahead. These guidelines clarified the constraints within which the engineers needed to work, providing a framework that allowed them to make decisions while ensuring that those decisions were aligned with the overall goal of minimizing cost and weight.

If we stopped the Directed Opportunism protocol with just a clear briefing, we would already have a great improvement, with at least one party providing accountability. However, even with a detailed briefing, it is easy for misunderstandings, both large and small, to arise. To account for and detect these imperfections, we also schedule a response to the briefing: a “back briefing” led by the executing party, which is meant to describe how it plans to achieve the desired outcome and to confirm that this plan matches the original outcome, constraints, and freedoms. This accounting for what people plan to do and why they plan to do it—this sharing of reasoning and intent—ensures that there is alignment across all parties.

In The Art of Action, Bungay shows us the letter written by von Moltke, the chief of the Prussian General Staff, the commander mentioned earlier, who wanted two of his armies to pursue and surround the French. His letter describes the situation, his intention, the role of each general, and special directions in case the French crossed into Belgium. The letter finishes by providing a deadline for the generals to inform him of the instructions they would be issuing to their armies.15 The generals’ responses were back briefings, which allowed von Moltke to coordinate the movement of his own army with that of his subordinates, and to correct any misinterpretations.

With one of our own clients, a children’s retailer, we set up a system of back briefings in which the COO would review product plans with the leadership of each team. Before one of these sessions, we could see how excited the product manager was to share the plans for the revised e-commerce shop through which parents would be able to purchase from a widely expanded range of products. During the meeting, however, the COO looked less and less pleased as the product manager showed screenshots and early prototypes of the new pages. Eventually he said, “But where do we explain the benefits?” It turned out that in focusing on supporting new product types and exciting new ways to buy them, the team had forgotten that the site had to sell the products as fun and educational, something the marketing group was relying on it to do. It was painful to revise the plans but much better to have caught the problem early, before much code had been written. Clearly, the combination of briefing and back briefing is a powerful method for creating mutual accountability.

You can score a conversation as a briefing if it involves making a request. Display your score as a fraction over three, providing yourself one point for each of the three elements: intended outcome, constraints within which that outcome should be sought, and freedoms available during execution. If you provided some constraints or some freedoms but not all, give yourself partial credit, such as 0.5 if you described half the constraints. For example, if you shared your intended outcome and all the constraints but did not describe any freedoms, you score would be 23.

Similarly, you can score a conversation as a back briefing if you are responding to a request. As with the briefing, display your score as a fraction over three and give yourself one point for including each of three elements: your intended action, your reasoning for adopting that action, and your confirmation that your plans match the briefing provided by the other person.

Say you’re planning to drive to a holiday destination with your family. How do you decide who needs what information and when to share it? Collaborating on a road trip is very similar to interacting with your team using the Accountability Conversation.

The start of the journey is straightforward, but before we embark, we need to have a shared understanding of the information required for planning—the briefing. This includes the intended outcome (“We’re going to the lake house via Sacramento, where we’re picking up your sister”) as well as the constraints (“Avoid highway 5; too much traffic”) and available freedoms (“We can stop at your favorite restaurant”). Once this is clear, we should then return with the equivalent of the back briefing: the intended route, the reasoning for proposing that route, and a request for confirmation that the intended route seems satisfactory. But what happens once the trip starts?

A car driving down even the straightest of roads requires many imperceptible nudges to stay aligned with the white lines, and surprises like a vehicle stopping suddenly or a child running into the road require immediate adjustment.** Passengers don’t expect the driver to keep them informed of these constant course corrections, and similarly don’t expect the driver to ask permission to respond to an emergency. However, if the driver hits the brakes suddenly, giving the rest of the riders a jolt, the passengers do expect an explanation! They would also expect some communication if there was new information that changed the route or the constraints (“It’s raining at the lake; let’s head for the mountains instead”), whether it’s the driver or the kids in the back who have the new information. Everyone involved with the project has an obligation to contribute to their part of the Accountability Conversation.

Technologist Elizabeth Ayer suggests that just as drivers display continuous directional signals before and during a turn, you should be “radiating intent” at all times.16 We think this is great advice that can yield unexpected benefits: when we are transparent with our intentions, we allow other people to provide relevant information, adjust their plans, and even help us achieve our aims. Radiating intent indiscriminately allows us to get these benefits at times we might not have anticipated; signaling for a turn might help you the most when you (incorrectly!) think there’s no one there to see it.

When deciding what information you’d like to radiate, keep in mind these key elements:

•Share the current state: “We are trying to select a crash-reporting tool for our mobile apps with a cost that lies within our budget. We’ve spoken to two companies so far, neither of whom have products that meet our standards.”

•Describe plans and intended outcomes: “We are seeing three more vendors next week, and also exploring an in-house solution. We should have a workable solution by the end of the month.”

•Alert to obstacles: “It’s possible that the budget reforecast will mean we have to drop this project entirely. We’ll know by Thursday.”

With an appropriate Theory Y mind-set, and by using the mutual learning tools you’ve been practicing in previous chapters, you should find that the Accountability Conversation is informative and valuable for keeping your project on track. But be wary—the Accountability Conversation is not a once-and-done affair.

“He trusts, but he doesn’t verify,” said the head of Engineering at one of our clients, describing the CEO. (The familiar phase “Trust but verify” was Ronald Reagan’s famous dictum, derived from a Russian proverb, about negotiating nuclear treaties with the Soviet Union.17) “He gave us the vision and the focus for our team,” she continued, “but without regular interaction, we weren’t able to stay aligned. We pursued a version of the mission that was flawed; and when he flew in from headquarters to see us, he said we had to scrap three months of work and start over.”

We find that one of the most difficult things about the Accountability Conversation isn’t having the discussion itself but remembering to continue having it. Like our client’s CEO, you may think that you’re done once you’ve agreed on the direction for a project—especially if you’ve used a briefing and a back briefing to double-check for alignment on the desired outcome, the freedoms, and the constraints. After all, won’t the other party resent our intrusion? Doesn’t Theory Y say we should trust others’ good intentions and leave them alone to get on with the task?

These are valid objections, as micromanagement is to be avoided whenever possible (we don’t want someone in the back seat telling us how to steer the car); but neither party to the Accountability Conversation should be disengaging lest disastrous misalignment strikes. The briefer needs to hear how execution is progressing, because they have an obligation to check alignment and the responsibility to coordinate their own actions. In addition, the briefed party needs feedback on their progress as well as updates on how the external situation is changing, especially if that affects the work to be done. The frequency of check-ins will vary with the importance of the project and its level of risk, but “set it and forget it” is not the philosophy we suggest when it comes to the Accountability Conversation.

Luckily, modern software development methods come with ceremonies and processes that are perfect for triggering the initial Accountability Conversation and providing regular opportunities to radiate intent and progress.

Planning. Scrum, XP, and similar methodologies give us a natural time for discussing accountability: the sprint planning session. Lean or Kanban teams have more frequent, pull-triggered planning activities but still need to break down tasks and agree on acceptance criteria, often during or just after the daily standup. During your team’s planning activity, ensure you include time to discuss all three elements of the Accountability Conversation: current state, intended outcomes, and potential obstacles. Going beyond the usual roadmapping and estimation activities to include more context will often prompt ideas and help from other members of the team. Publishing the results of your planning session in an email or company chat, for example, also encourages broader discussion and further opportunities to be accountable to those not directly involved in your work.

Information radiators.18 A common DevOps practice is to display system metrics—site visitors, memory used, response time—on big monitors in the team area. Agile and Lean teams often have burndown charts and kanban boards that are displayed electronically, or maintained on a whiteboard or easel. One of our clients maintains a board that shows all their prospective clients and their current stage in the commercial pipeline, to keep the technology team informed about likely incoming sales requests.*** In all these cases, the visible indicator is a perfect prompt for an Accountability Conversation based on the information on display. Those inside the team can invite others to visit their radiators for this discussion, or people outside the team can walk by and begin a conversation based on what’s displayed.

Retrospectives. An end-of-sprint or end-of-project reflection on recent progress is a natural time to be curious about how ongoing projects are progressing, especially when looking for obstacles that can be removed. Avoid turning the retrospective into a status report, which is not its purpose; instead, remember Theory Y by ensuring that the team is collectively driving the conversation, reflecting on its current condition, its plans, and what can be done to increase the chances of success.

Demonstrations. One of our favorite ways to radiate intent is to demonstrate working software. This can be at the end of a sprint, at the time of delivery to a client, or even better, just when the feature is done. Try to avoid “demonstrating” user-invisible changes like database updates; instead, focus on structure work, so the current and future states are obvious to nontechnical observers (the Walking Skeleton in Chapter 6 can be a big help). If possible, record video of the demonstration and publish it widely, to radiate information to those who are remote or can’t attend the demo.

A successful Accountability Conversation should feel positive for all involved, even if there are surprising results or significant obstacles to report. At the end of such a conversation, you will have shared the current state of the project, made next steps clear and discussable, and identified obstacles. Each of these should give all parties the opportunity to clarify and revise the intended outcome, freedoms, and constraints for the work to be done. In our experience, teams that do this successfully build the right software and are happy with their destination, even if it wasn’t what they imagined at the start.

Okay, let’s try scoring the conversation, even though it sounded just fine to me at the time; maybe I’ll Reflect and find something to Revise. I notice I didn’t ask any questions at all, so that’s a zero over zero straight off. I had some doubts about Bobby’s understanding in my left-hand column, but I didn’t share them, hoping that he would figure out what I meant. And a twitch I notice is that I tend to default to accepting a confident “got it” when, in fact, it might be wiser to ask more questions.

Scoring the briefing, I don’t think I included any of the elements fully. Being really charitable, maybe my explanation of the differences from the current report communicated half of the desired outcome. But I definitely didn’t mention freedoms (the developers would have been welcome to order the columns in any convenient way, for example) or constraints (the report has to be in a native Excel format, not tab- or column-separated). So at best, a 0.5 out of three here.

I’d like to get better by asking more questions rather than jumping to the conclusion that everything is okay. I think it will help to be more structured in my approach to briefings and back briefings, because that will prompt me to be more curious about what I’m saying and hearing. Finally, I’m going to try sharing more of my reactions rather than trying to look confident all the time. I hope this will help me work with Bobby and others more effectively, and avoid unpleasant surprises.

I checked with Bobby last week on the progress of the development team he works with. I wanted to handle this back briefing better, in line with what I learned from the earlier conversation. I asked a trusted friend to Role Play this discussion ahead of time, and that helped me be more curious as I went into the conversation.

Having this conversation really helped both Bobby and me. Sharing the plan of action uncovered a gap in alignment: we both came into the conversation thinking we had a shared understanding of what “simplified configuration” meant, but we were actually far apart.

Previously I would have just assumed we agreed on this and accepted Bobby’s assertion that the work would be done Friday. Instead, I asked Bobby for an account of what he planned to deliver and shared my emotions when I heard that he was planning something very different

As a result, our misalignment was in the open, and we could fix it before it did much damage. I still have some doubts about Bobby’s listening skills, but I can see now that I was contributing to the problem. I think I can work with him much better in the future by using the Accountability Conversation.

Grace says, “From talking with our clients, we know that end-user engagement is important to them. We came up with a good solution to the problem, namely emailing a reminder at the start of the week to inactive users. We were almost ready to roll out the weekly reminders, and so we scheduled briefing calls with our key accounts to let them know what was coming. Most of them were very happy with our proposal, but one client, Lisa, had a very different reaction.”

It is easy to believe that we understand both the problem and the solution when, in fact, we lack a key piece of knowledge. Grace had a solution that had been endorsed by several others for a problem she knew Lisa cared about; she couldn’t have known that emails were an unacceptable approach in Lisa’s organization. Being accountable means signaling our intent with others who will be impacted even when we think we are right. These opportunities come up most naturally inside the teams we work with daily. It is also worth looking for opportunities across departments and even across companies.

Andy says, “At the financial services company where I’m the Head of Engineering, when we perform an incident postmortem investigation, we are trying to understand not just what happened but also how the world looked to the people involved at the time. Our goal is to reconstruct a picture where the actions taken were the right ones; because no matter what we learn after the fact, we trust that the actions must have seemed right at the time. And whatever we do to make our systems resilient, it is the judgement and actions of the people in the moment that help us cope with the unexpected. Like when we recently lost data for one of our production systems and I asked Wayne, one of our system administrators, to account for his actions in restoring service.”

It is inevitable that things won’t always go according to plan, so how will people respond when that happens? In Andy’s organization, the message is that you are expected to use your professional judgement in the moment; and at the same time, you’ll be expected to account for your reasoning after the fact. The goal is not to punish people for the unexpected; it is to learn as much as possible from the experience. This frees people to improvise and create better outcomes than a by-the-book mind-set would produce.

“I got it!” exclaimed Mike, bursting through the office door with a huge binder. “I got it! We’re back in!”

Marcus, a product manager for London-based startup Arachnys, looked up skeptically. Mike had gone to see a major banking prospect to find out why they had said no to the company’s anti-money-laundering product a few weeks before. Marcus had expected Mike to return with a list of reasons the competitor had won, grist for the product-development mill to help them win the next bid with someone else. What had Mike cooked up instead?

Mike excitedly spread out the contents of the binder. “These are the specifications the bank gave the other guys. Apparently, after they got the deal, the other company took one look at these and said they wouldn’t commit to anything less than nine months for completion of the first version of the system, meeting all of these requirements. That’s way too slow; so when I asked if we could have a look, they said, ‘Sure!’ and handed me this.”

“Gee, did they leave out anything?” asked Annegret, with more than a hint of sarcasm. “Four types of authentication, integration endpoints for seventeen systems, and test data and protocols taking up—let me count—sixty-three pages. There are over a thousand line items in the requirements list.”

“Well, officially, all I said is that we’d give them our estimate,” Mike replied. “But Benny, the big cheese who makes the decisions, walked me out—and at the door, I told him privately that we’d have a prototype for them soon.”

Marcus and Annegret looked at each other, then asked simultaneously, with shocked expressions, “How soon?”

Marcus and Annegret could see immediately that the binder contained at least a year’s worth of work for their small development team. Six weeks was certainly out of the question. But because Arachnys was the kind of place where questioning a briefing or an assignment was de rigueur, they didn’t give up, and instead, began combing through the pages.

They found that many of the “requirements” were contradictory, a result of different departments adding their own wish lists to the document without regard to each other. Others were irrelevant to the regulatory requirement the system was supposed to address; and a few were downright impossible. Eliminating these nonsensical items reduced the demands substantially but still left hundreds of detailed items to be addressed.

They took another pass through the list, but this time, instead of eliminating features, they aimed to pick out only those that were absolutely necessary, to prove the bank could meet the regulatory standard. Like the Walking Skeleton of Chapter 6, these key features would form the backbone of the system and allow them to prove that a solution was possible, while providing a framework for continually adding more functionality. They circled each item that met their stringent test, then counted them up.

“We have been through every page,” Annegret replied. “There’s nothing else here.”

A couple of days later, surrounded by Chinese takeout boxes that testified to the midnight oil the two product managers had been burning, Annegret clicked “send” on their carefully crafted email to the bank. They’d analyzed each requirement and explained exactly why they’d whittled the list down to just six items. The email was their back briefing, responding to the bank’s requirements by sharing their reasoning and describing how they would be accountable for delivering the much smaller scope they’d defined, with multiple deliveries in the runup to the six-week target.

Mike phoned as soon as the email hit his inbox, checking in from an industry conference. “This is great stuff! I’m sure they’ll want us to build what you’ve proposed.”

“I’m not so sure,” replied Marcus in a tired voice. “We cut out nearly everything they asked for. The other company just said yes to everything. Why not stick with them?”

At that moment, Annegret’s screen lit up with a new message. It was from Benny, the “big cheese.”

Marcus and Annegret worked intensely with the developers to deliver the prototype, checking in often with the client as promised. Benny and his team were so delighted with the result and the clear accountability represented by the plan that they signed up for the full product, and rolled it out to hundreds of internal users.

Afterward, Marcus had the opportunity to ask Benny, “Why did you decide to go with us?”

Benny was clear in his response. “Because you said no. You thought about what you could and could not deliver, and you shared your reasoning with us. And then you delivered what you committed to. That convinced me I could trust you to follow through on the rest of the project.”

The Accountability Conversation had come up aces for both Arachnys and their client.

In this chapter, you learned to foster accountability by adopting Theory Y, to identify and use constraints and freedoms for a planned action by using briefings and back briefings, and to render an account by signaling your intent both broadly and clearly. Being accountable for successes as well as failures allows you to learn effectively from experience and promotes the productive reasoning that drives your conversational transformation. You can use the Accountability Conversation in many ways, including the following:

An executive leader can render an account of her strategic actions to those in her organization, helping them align with product and company goals.

A team lead can brief team members on actions like testing a new feature or performing a penetration test, and have confidence in accurate execution through back briefings.

An individual contributor can discover internal commitment and drive by seeing that his peers and managers view him as motivated and capable, perhaps by trusting him to try a new library or experiment with a creative redesign.

*	Unlike the military, in a business situation, the relation of the parties may not be leader and follower; a product manager could brief the marketing team on how to coordinate an upcoming feature launch, for example.
**	These statements are as true of a self-driving car as of a human-piloted one; somebody needs to be steering and making moment-to-moment adjustments, whether the driver is carbon- or silicon-based.
***	You can check out an example here: https://www.leadingagile.com/2017/11/information-radiators-information-vaults/.

What Nicole thought and felt	What Nicole and Bobby actually said
I hope this makes sense to you.	Nicole: Here’s the mockup of the new cash-flow report.
Good question!	Bobby: Okay. How is it different from the one we have today?
	Nicole: Well, for one thing, it’s to be updated daily. And it’s broken down according to our new global regions, instead of being aggregated.
	Bobby: Got it.
Is that all you need to know? I guess the mockup is fairly self-explanatory.	Nicole: When do you think you can have it ready?
Wow, that’s quick! Finance will be really pleased. I just hope you won’t miss anything like last time.	Bobby: I’ll have to check with the team, but I expect we can finish it in the next sprint.
	Nicole: That would be great!

What Nicole thought and felt	What Nicole and Bobby said
I wonder what he’s prioritizing.	Nicole: You’ve got a lot of different projects in flight. Where do you plan to focus this week?
He’s made a lot more progress than I realized. Um, wait—that’s my twitch firing. I should check this out further.	Bobby: I’m thinking we’re ready to finish the work on simplified configuration. I think I can get that done by Friday.
We haven’t discussed how he’d present the findings from this investigation.	Nicole: Great! So how do you plan to present the results?
What?! It sounds like he’s already moved on to implementation, and I haven’t even seen the proposal yet.	Bobby: Last week I reviewed all the current config options, and the team has removed most of them. I expect I’ll be able to demonstrate the new page with just five or six options.
Maybe he published his analysis and I missed it?	Nicole: Wait a minute—I’m confused. I was expecting you to examine and explain the need for each option, and I don’t remember seeing a review document from you. Have you already done the analysis and moved onto implementation?
Oh dear! I thought I had been clear.	Bobby: What? I thought you wanted me to get rid of as many options as possible. We decided that Monday, when we said we’d simplify the config.
I don’t want to be making arbitrary decisions.	Nicole: No, not really. What I wanted was to get your opinion on each option. Which of them do customers actually need and use?
This sounds more like what I was expecting to hear.	Bobby: Oh! Okay, well, that changes my plans for the week. We can pause the changes to the page, and I can focus on talking to more customers. We won’t have the new page ready this week, though.
I’m glad we had this conversation—we dodged a bullet here. We might have released the new page prematurely if we hadn’t checked in.	Nicole: That’s not a problem. It will be good to have greater confidence in our decision to keep, drop, or change the options, whichever we decide on.

What Grace thought and felt	What Grace and Lisa said
I know Lisa has been concerned about engagement for a while. I expect she’ll be happy with this, so I’ll just explain what we’re doing and why.	Grace: Hi Lisa, thanks for taking the time to hear about a change we are planning to implement. We are going to start sending an email on Mondays to any users who didn’t log in the previous week. We are doing this in response to clients who are worried that end-users aren’t always as engaged with the system as they’d like.
What?! You’ve complained to me about engagement again and again. I thought you’d be grateful.	Lisa: Ugh, please don’t do that!
Weird, no other customer has objected to the emails. I’m pretty sure engagement is still a problem for you, but I should check.	Grace: Oh, that’s surprising! I’ve spoken with several other clients, and you are the first person with that reaction. Looking at the latest usage report, I can see that 40% of your users are inactive. Do you see that as a problem?
Wow, sounds awful. No wonder she doesn’t want us emailing users directly. And I’m glad she has an idea about what might work for them instead.	Lisa: Engagement is definitely something we want to improve. It’s just that we already get so many emails sent from internal systems that it is impossible to keep up; and the last thing I want are complaints about getting even more. Could you send me a weekly report on inactive users instead? That would allow us to follow up internally.
This could be a good experiment. If it works, it might be something we can offer to other clients.	Grace: Absolutely. I can tell our team that you’d rather receive the information on inactive users instead of emailing the users directly. In our next quarterly review, we can talk about how those reports are working and if there’s anything else we can do in the system to help.
Me too!	Lisa: That’s great. I’m really glad you contacted me ahead of time rather than unleashing a flood of emails onto our users!

What Andy thought and felt	What Andy and Wayne said
We have a normal process for restoring data. Why didn’t they just use that?	Andy: Okay, that table was deleted and the service was offline. Why was it that you didn’t use the normal documented backup procedure?
That’s a good point. I’m sure we never expect this kind of partial failure.	Wayne: Well, that process assumes the entire database has been lost or corrupted. In our situation it was only one table, and as a result, most of the services were still operating normally. If we’d performed the normal disaster recovery process, it would have worked; but it also would have meant all the services would be offline for a day or more.
It must have been very stressful to realize none of the processes we’d practiced would apply.	Andy: I see, so you were in uncharted territory here.
I agree—that would have made the problem much worse.	Wayne: That’s right! Of course we could have just followed the book, but that would have made things worse. It didn’t seem like the right thing to do even though it was the documented process.
	Andy: So how did you figure out how to proceed?
I’m not sure I would have taken their approach, but they got their priorities right.	Wayne: Our first goal was to keep all the other services operating normally, and our second goal was to recover the lost table and restore the service that depends on it. We thought of multiple options for recovering the data, and not knowing which would be fastest, we started down several of those paths in parallel, with different people working on each one.
I’m glad Wayne was thinking creatively here. Playing it by the book would have meant hours of downtime and a much bigger headache.	Andy: That was sharp thinking! We should consider adding “try multiple solutions” to the runbook.