20 · Resistance Is a Signal: Decode It Before You Answer It

Companion Templates

The Challenge. Someone challenges you in front of the whole room. A team quietly stops cooperating. Are they being unreasonable, or did you miss something?

What You Will Be Able to Do. When you are challenged in public, do not defend, name the emotion first. Use the resistance decoder to turn delay, sniping and silence back into interest, fear, pride or a design defect. Give "the system can be used to appraise people" a governance pledge written into policy.

Week 20, Tuesday, the Claims Line Weekly Meeting

In week 17 the pilot closed out, first-touch handling time at -22%. The annual budget and headcount review in week 18 approved the expansion to go deeper. In week 19, auto review teams two and three came into the queue. It is now the second week after the expansion, that is, week 20, and Kevin Doyle is chairing the claims line weekly meeting. Item three on the agenda is the rollup view (Chapter 17), which gained a per-step dimension when the new teams came on, and this page of numbers summed by team and by step is in front of the whole claims line for the first time.

Among the bottleneck numbers broken out by step, the survey step is the sorest spot. Survey sits one step ahead of review, materials pass the surveyor before they reach the reviewer. The bulk of an exception claim's waiting time hangs on "waiting for documents," and "waiting for documents" is booked to the survey step. Kevin points at that page and says, "The claims on the survey side need tightening up."

The survey team lead puts his pen down. "Kevin, let me ask one thing first. This system of yours, is it here to appraise us? That BI system last time was yours too, and once it was built nobody looked after it."

The room goes quiet. Everyone looks at you.

You have three well-worn paths at this moment. Defend, lay out the facts, or go to Kevin after the meeting, or even to Grant Whitmore, and get the top to "align everyone's thinking." All three lead to a cliff, and this chapter's failure modes have one waiting for each. What they share is treating resistance as an obstacle to be cleared. This chapter is about the fourth path, treating it as a signal to be decoded.

Why This Is Hard: Resistance Is Data, Not Noise

An engineer's default model of resistance is noise, irrational, unprofessional, something to overcome. This is one of the most expensive misreadings a deliverer can make. Resistance marks, precisely, where the system touched a real interest, a real fear, or the pride of someone who was never consulted.

Behind every piece of resistance sits a piece of information you never drew into the stakeholder map. Suppress the resistance and you delete the data. The structure of this one at Anchor & Helm is worth seeing clearly. The survey team lead is not on your Chapter 5 stakeholder map. Back then the actual user (the person who uses the system every day) was the reviewer, and the surveyor was only a step upstream in the workflow. But once the queue absorbed the drafting of chase notices and the Tuesday and Thursday manual filter of overdue claims (Chapter 17), chasing went from scattered emails and phone calls inside Linda's team to a systematized action, timestamped, and able to be aggregated. The rollup view then sums "how many days each claim sat with whom" onto one page. The surveyors' work got turned into data, and from beginning to end nobody asked them a single question. The system's radius of visibility outran its radius of consultation, and the ring outside is the resistance band. Put plainly, the system sees more people than you asked, and those extra people are where resistance comes out.

So the lead's challenge is not unreasonable. The constraint interview this project owed him (Chapter 12) came knocking on its own, in the ugliest way it could.

Inside a company there is one more layer. The lead's line, "that BI system last time was yours too," is not asking about this system. It is asking about your department's track record. The front line's opinion of the Digital Center was built up over several years, and the last system dropped and forgotten, the last promise made and not kept, all of it gets booked to this account. An outside deliverer carries no such ledger. You do. So decoding inside a company means decoding the history along with it. Take the old debt on first, then talk about what is different this time. You take it on not by apologizing but by giving a difference that can be checked. Which of the five capabilities (the test Chapter 3 mentioned, for whether the receiving side can run the system on its own) belongs to whom, whose annual goals name this system, which escalation tree gets walked when something breaks (Chapter 22). Refuse the old debt and every promise you make afterward is discounted automatically.

Prior Art, and What AI Changed

The consulting tradition treats resistance as a physical phenomenon, and the way to handle it is naming, not rebuttal. Peter Block gives resistance a whole chapter in Flawless Consulting. Resistance is a normal physical phenomenon in consulting, an indirect expression of worry. Saying "I am afraid this thing is bad for me" outright is too dangerous, so it puts on a disguise, delay, a barrage of detail, "agreed in principle," a sniping remark. Reasoning with a disguise gets you nowhere. The reasoning answers the lines being spoken, not the worry underneath them.

Block's method has one move only. Say what you sense in neutral language. "I sense this plan worries you. Can you say more?" Then shut up. Naming gives the worry a way out of its disguise, and rebuttal only forces it into a costume harder to recognize.

The change tradition, Kotter's warning. The first cause of failed change is underestimating how hard it is to get others to work differently, and a wrong strategy ranks below it (quoted in Chapter 1). The corollary is just as direct. A launch plan that leaves no time for resistance is itself one of the causes of resistance.

The AI era added two sources of resistance that did not exist before. First, a sharp rise in visibility. An AI system turns work into data and makes it comparable by its nature. The decision trail, waiting time, the override rate (the share of system suggestions the front line pushes back), every one of these numbers, born to improve the process, can be picked up and used to appraise people. So the fear of being monitored is rational, not paranoid. Second, the fear of replacement. The system ate the front line's judgment (Chapters 6 and 11 did exactly that), and "it learned my judgment, and then what?"

The two share one thing. Neither can be answered with "the system does not mean it that way," because the system really does have that capability. Defending intent does not work on a fear of capability. The only thing that answers it is a governance pledge, writing "the system could do it and we pledge not to" into a written policy with an issuer and an appeal path. That is this chapter's second framework.

Framework One: The Resistance Decoder

The resistance decoder, a table mapping the forms resistance takes onto their common real causes and the matching first response. Full version in Template 20.1, skeleton below.

Form of Resistance	Common Real Cause	First Response
Delay, rescheduling, "too busy lately"	Interests not aligned, this is all cost to him	Go back and consult, work out what he fears and what he wins (Chapter 5)
A barrage of detail, endless technical challenges	Fear disguised as professionalism	Name it, ask the real worry out
Sniping at a meeting, a challenge in public	Pride, being turned into data, skipped over, compared	Do not defend, name the emotion first
Data withheld, a process forever "in progress"	An information gap plus risk, he does not know what you are up to	Go back and consult + a governance pledge
Agreed in principle, nothing moves	Interest or fear, politeness is the disguise	Narrow it to one concrete action, watch where it sticks
Silence, no objection and no use	The deepest kind, the conversation has been given up on	Go to them; check for a design defect

The last row of the table did not play out in this chapter's field, but it is right in front of you at this moment. The only person who spoke up at that weekly meeting was the survey team lead, and teams two and three, just into the queue, said nothing at all. The trouble with silence is that it produces no event. It will never come to you if you do not go looking, so the first step in decoding silence is not guessing what they are thinking, it is finding a count that can be falsified, daily actives, the decision trail, override records. Any one of them at zero over a long stretch turns an impression into a diagnosis. The second step is going to them, and not asking "why are you not using it," which is a demand for an admission of fault. Ask instead, "walk me through one of your recent exception claims from the top," and watch which step he routes around the queue at. The third step is keeping the second half of the rightmost column, check for a design defect, because his silence may simply mean the thing has no use at all in his workflow.

The next chapter shows that usage did collapse in one of these two new teams, and the real cause is not on the front line. It is that team's own lead, who missed the weekly queue retrospective three weeks running.

Three rules of use. First, form and real cause do not map one to one. The table gives candidates, the diagnosis comes from an interview, and you ask anchored on a specific instance (Chapter 6's three-layer probing method reports for duty a third time). Second, handle the emotion before the information. Naming first, decoding second, redesign third. Reverse the order and not one step works. Third, always keep one hypothesis alive, that he is right. The rightmost column of the decoder has an action called "change the design." Some resistance does not point at an emotion, it points at a place where you really did get it wrong.

Framework Two: The Three Visibility Pledges

The three visibility pledges, three policy answers to the fact that the system has the capability to appraise people, standard equipment for an AI-era deliverable (template at Template 20.3).

The data is used to improve the process, not to appraise individuals, written into policy, not said out loud. A verbal pledge expires when the person who made it moves to another post, and a policy has an issuer and an appeal path.
The team concerned sees its own data first. Any number about a team goes to that team before it goes to a meeting. People's hostility to data that is "about me and the last thing I hear about" has nothing to do with whether the data is good or bad.
Aggregate display takes priority over individual detail. The entrance facing upward defaults to the step and the team, and individual detail lives only in the team's own view.

If the business owner (Kevin's role, not a risk owner like Victor) will not sign, do not treat it as a communication failure yet, because that is an answer in itself. Ask him which of the three he is stuck on. Stuck on the first usually means he is himself being appraised on these numbers by his own manager, so fall back to signing the second and third, land what can be landed, and tell the front line honestly which one you did not get. Do not make a promise on the owner's behalf that he never made. Signing is not the end either. Give the pledge a recheck action, so every later time someone asks for the numbers split by person, you go back to it and ask whether it still stands. A policy pledge with no recheck is only the written version of a verbal one.

A written pledge has one hole peculiar to the inside. Once the data is in the company warehouse, HR or management can pull it directly, going around you, and one query ranks waiting time by person. The policy you signed cannot govern a pull you never hear about. So inside a company the three pledges need technical guardrails, three actions, all of them implemented on the data platform side. Splitting a table by person is disabled at the warehouse layer. The individual dimension is de-identified in the shared layer. A pull that needs individual detail goes through approval and leaves a trail, who pulled what on which day and why, checkable afterward. Only you can do these three, they are the one hard means of honoring the three pledges inside a company, and they go into the pledge text alongside the issuer and the appeal path.

One more action belongs to the inside only. Issuers move to other posts. Kevin will not run the claims line forever, and a policy draws its force from the position, not from the person who signed. So add a line to the pledge text, an issuer change clause. When the business owner changes, the successor reissues within thirty days, and where there is no reissue, the pledge is flagged red on the PMO's AI system transfer ledger and walked through at the quarterly business review along with the system's other transfer items (Chapter 22). You will be at this company longer than any issuer. Nobody will remind you of this, so you have to raise it yourself.

Note what the three pledges are. They limit the right to use, and take nothing away from the system's capability. The trust constraint matrix of Chapter 12 answers the risk owner's "why should I trust you," and the three pledges answer the same question from the front line. Same craft, different recipient.

At Anchor & Helm: Three Weeks of Decoding One Challenge

On the spot, Tuesday of week 20. You did not defend. You said, "That worry is fair. This system really can be used to appraise people, the waiting time is sitting right there, and I am not going to pretend it cannot. Let us talk about how we make sure it is not used that way." The air in the room changed. The lead was ready for a defense and not ready for an admission. Then you booked something. "I want to come sit half a day on the survey side this week and go through your claims from the top." Kevin nodded, the agenda moved on. You did two things and no more, naming, and moving the battlefield out of the meeting room and back to the field.

That sentence about coming to the field costs an internal reader far less to say. You need not go through a visitor process, and nobody has to approve your taking half a day in another department. You walk over. This right of access, being able to show up any time, is a lever only the inside gives you, and it has two uses. One, break the decoding interviews into several half days and follow the claims that actually happen that day, instead of saving it all up for one formal interview. What the front line says at its own desk is not the same batch of words it says in a meeting room. Two, use depth as evidence. You know what ranking people by name set off in this company last time, and which department's numbers have been untrustworthy ever since. You can look that history up and you remember it, and putting it into the draft pledge you hand the owner works better than any argument.

That week, the decoding interview. The surface cause is confirmed quickly, the fear of being monitored, and entirely rational. The queue really did make "how many days each claim sat with whom" visible across the board for the first time, and the rollup view really can rank people by name. But you dig further, following Chapter 6's discipline. You do not pick claims by sampling, you pick the few with the longest waiting time, because the mechanism hides in the extremes. The questions follow the three-layer probing method. First have him replay what he did first on that claim that day, then compare it against a claim from the same period that did not go overdue, then ask under what conditions he can afford to wait. There is a test for having dug to the bottom too. The answer has to land on a piece of design you can change, and stopping at "their attitude is the problem" means you have not got there.

You trace six claims "stuck at the survey step," following each one end to end, and dig out a second layer. In four of them the surveyor sent the document request to the repair shop the same day the chase arrived, and then waited. Waiting on the loss assessment list, waiting on repair photos, three or four days of waiting. Those three or four days are all booked by the system to the survey step. The real reason surveyors are slow to complete documents is that repair shops are slow to respond, and the system pinned the blame on the wrong step.

This layer is a debt you owe. Chapter 6's field archaeology put the folding stool beside Linda's desk. You did the archaeology on the fourteen steps inside the review step and never on a single step inside the survey step. Inside the lead's anger sits a real bug. Decode the resistance to the bottom and what comes out is a piece of workflow truth Chapter 6 missed. The repair shop has now crashed into your field of view a second time. Last time it was the list since promoted to an operating asset (Chapter 18), on the risk dimension. This time it is response time, on the efficiency dimension. The same blind spot, two alarms.

Week 21, the fix goes live. The queue adds a "waiting on external" status. While a claim waits on a repair shop, a customer or any other outside party, its waiting time is attributed separately and booked to no internal step. The rollup view's bottleneck attribution changes to the step, not the person. The numbers come out again, and the survey step's own waiting time drops by more than half. The bulk of it was "waiting on the repair shop" all along.

On Friday, Kevin issues the three visibility pledges, in writing, to the whole claims line, with one line at the bottom giving the appeal path. Anyone who believes the data is being used to appraise people can appeal directly to Kevin or to the union representative. You drafted it, but the issuer has to be Kevin. A governance pledge can only be issued by the person with the power to violate it. Your signature does not count. A reader doing this inside a company has all the more reason to accept that. You and the front line are colleagues, you cannot retreat to an outsider's position, and the policy still has to be signed by your business owner, drafted by you.

Week 23, the retrospective. Halfway through the weekly queue retrospective Linda chairs (it has existed since pilot week 2), the survey team lead walks in. Nobody invited him. He brings a page of numbers he broke down himself. "On the new standard, our own step's median waiting time is 1.8 days. Two new surveyors are dragging it, and I am already coaching them. Also, repair shop response time, should you not build a number for that too? The system watches us, it should watch them as well." From "is it here to appraise us" to "it should watch them as well," three weeks. The next stop on this line is Chapter 21. What a former opponent turns into deserves a chapter of its own.

Tally it up. Everything this resistance produced, a corrected attribution logic, a new status, a governance policy, a team lead who started checking his own numbers, none of it came from your original design. All of it came from decoding that one piece of sniping. Once resistance is decoded, the information in the opponent's hands becomes the system's improvement.

Failure Modes

1. Crushing emotion with logic. You pull up the metric definition document on the spot, prove line by line that the numbers are right, and the other person has nothing left to say. An engineer is trained to rule on right and wrong, while an emotional appeal is not asking for evidence, it is asking for acknowledgment. Every point you win is deducted from the other person's pride. In the Trust Equation this zeroes out intimacy, and a person beaten in public will never tell you the truth again (Chapter 5). You win the argument and lose the system.

2. Getting the sponsor (the executive who funds it and makes the call) to lean on people. After the meeting you report to Grant that "the survey team is resisting the change" and ask him to weigh in. Power can change behavior, it cannot change willingness. Grant applying pressure wins this one round, but the whole organization learns the same lesson, that raising an objection to this system gets it taken to Grant. From then on nobody tells you the truth, and the resistance goes underground into the most expensive kind, silence. You also push the lead into permanent opposition along the way, and the truth in his hands, that repair shops are slow to respond, will now never reach you. Inside a company there is one more layer to this bill. You and the person leaned on are long-term colleagues. He is your resistance this time, and next time he is very likely the dependency of another one of your projects, the one who has to hand over data and put up people. Win by pressure this round and what you bought is a person who can quietly block you every time you need his cooperation from now on, in a way that appears on no ledger and that nobody will attribute for you. An outsider leans on people once and moves to the next client. You do not move.

3. Reading silence as agreement. Nobody objects at the meeting, nobody asks a question at the training, and the weekly report says "feedback from all teams is good." Resistance that speaks up at least still cares how this ends. The deepest resistance says nothing, it just does not use the thing. The cost structure of a meeting makes silence the cheapest form of objection there is, especially just after the organization has watched how someone who did raise an objection got treated. The daily actives curve after the expansion will put this on the table, and that is the opening of Chapter 21.

4. Treating all resistance as misunderstanding. The response to every challenge is to "explain it one more time," to run another training. "Misunderstanding" is the attribution that protects pride best, the plan is fine and they just did not understand it, so the cure is always more communication and the design does not move a line. But some resistance points at a real design defect. At Anchor & Helm this time, an attribution error was buried right under the "it is here to appraise us." One test. On every piece of resistance, force the question, "if he is right, which piece of the design is wrong?"

Next Monday

Write down the last piece of resistance you ran into and run it through the decoder in Template 20.1. What form did it take? What are the candidate real causes? Was your response at the time naming, defending, or crushing?
Check your system. Whose work has it turned into data without ever consulting them? Radius of visibility minus radius of consultation, and the difference is your resistance band. Give the people in that band a constraint interview (Chapter 12).
If your system produces any number that can be used to appraise an individual, push the owner to issue a governance pledge this week (Template 20.3). Written, with an issuer, with an appeal path. A verbal version does not count.
Next time you are challenged in public, do two things and no more. Name it ("that worry is fair"), and book the field ("I will come over and watch for half a day"). Scripts in Template 20.2. A script is a crutch, not a line to recite.

Want an agent to get you started? In the repo you set up following Start Here, paste this to your coding agent:

In the the-last-mile repository, help me with the Chapter 20 Next Monday actions. This chapter has no script. Open docs/appendices/template-20-resistance-decoder.md,
build 20.1's decoder as an empty table. I will describe the last piece of resistance I ran into, and you record only the form and the candidate real causes in the table's columns.
Whether my response at the time was naming, defending or crushing is mine to judge. Then help me compute radius of visibility minus radius of consultation. The list of people
turned into data by the system but never consulted is mine to name, you only count. Draft the governance pledge from 20.3, leaving the issuer and the appeal path blank for me.
If any command errors, stop and show me the output.

Chapter Kit

Judgment frameworks. The resistance decoder (form → real cause → response action; name first, decode second, redesign third); the three visibility pledges (not for individual appraisal and written into policy / the team concerned sees it first / aggregate before detail)
Templates. Template 20, Resistance Decoder, Hard Conversation Scripts, Visibility Governance Pledge
Key judgments
"Resistance is data. Suppress the resistance and you delete the data."
"The fear of being monitored is rational, and the only thing that answers it is a governance pledge. 'The system does not mean it that way' answers nothing."
"You win the argument and lose the system."
"The deepest resistance says nothing, it just does not use the thing."