Template 20 · Resistance Decoder, Hard Conversation Scripts, Visibility Governance Pledge
Companion chapter(s): Chapter 20. The three tools are in order of use. Decode first (20.1), then have the conversation (20.2), and when it hits the fear of visibility, give the governance pledge (20.3). License: Every template in this book may be modified freely and used in your work, no attribution needed.
20.1 Resistance Decoder
Rules. The table gives candidate real causes, not a diagnosis. The diagnosis comes from an interview anchored on a specific instance (the three-layer probing method, Template 6.3). Order discipline. Name the emotion first, decode the real cause second, change the design last. Reverse the order and not one step works.
| Form of Resistance | Common Real Cause | Response Action |
|---|---|---|
| Delay, rescheduling, "too busy lately" | Interest. This is all cost to him, with nothing he fears or wins at stake | Go back and consult. Find the fight he is already in, and help him win once first (Chapter 5) |
| A barrage of detail, endless technical challenges | Fear disguised as professionalism. Occasionally he really does know | Name it. "I sense there is another worry behind the detail. Can you say more?" And go through the detail seriously at the same time, because he may be right |
| Sniping at a meeting, a challenge in public | Pride. Being turned into data, skipped over, compared | Do not defend, name the emotion first, book the conversation into the field (one on one) |
| Data withheld, a process forever "in progress" | Information gap + risk. He does not know what you are up to, or who carries it when something goes wrong | Go back and consult + a governance pledge. Open again in the other person's language of power (Chapter 5) |
| Agreed in principle, nothing moves | Interest or fear, politeness is the disguise | Narrow it to one concrete action and one concrete date, watch which step it sticks at |
| Silence, no objection and no use | The deepest kind. The conversation has been given up on, or he was never invited into it | Go to them and shadow. Force a check of the design defect hypothesis |
Shorthand for the four real causes. Interest (what does he lose) / fear (how will the data be used, what will replace him) / pride (is he the last to know) / information gap (does he know what you are up to). One piece of resistance often comes in layers, one real cause on the surface and another underneath.
The Anchor & Helm surveyor row (the full decoding of the Chapter 20 instance):
| Item | Content |
|---|---|
| Form | Sniping at a meeting. "This system of yours, is it here to appraise us?" |
| Surface cause | Fear (monitoring), and entirely rational. The queue really did make "how many days each claim sat with whom" visible |
| Deeper cause | A design defect. The real reason surveyors are slow to complete documents is that repair shops are slow to respond, and the system attributed it to the wrong step |
| Response action | Name it on the spot → the decoding interview in the field that week → change the design ("waiting on external" status, bottleneck attribution to the step) → the governance pledge (the three pledges, issued by Kevin Doyle) |
| Verification | Three weeks later the person concerned comes to the retrospective on his own, carrying his own numbers |
20.2 Hard Conversation Scripts
A script is a crutch, not a line to recite. Use your own words, but keep the function of every sentence. A script read out loud is worse than a defense.
Opening without defending (when challenged in public):
- "That worry is fair. This system really can [be used to appraise people / see everyone's data], and I am not going to pretend it cannot. Let us talk about how we make sure it is not used that way." (Function, admit the capability, do not defend the intent)
- "I sense this plan worries you. Can you say more?" (Block's original form. Function, name it, then shut up)
- "You know this step better than I do. I want to hear from you first, where it is wrong." (Function, hand back the pride)
Probing to confirm the real cause (one on one or in the field):
- "Was there a specific claim last week that made this number feel unfair to you? Let us start from that one." (Function, anchor on an instance, get out of the abstract argument)
- "If these numbers were pulled tomorrow, would your worry go away? What would be left?" (Function, separate the fear of visibility from the other real causes)
- "In the worst case, who do you worry will use this data, and how?" (Function, turn the fear into a concrete scenario, because only a scenario can be answered by policy)
- "Under what conditions would this system feel like it is helping you rather than watching you?" (Function, get the other person to state the acceptance condition)
Closing with a commitment and a follow-up:
- "I will come sit half a day with you this week and go through the claims from the top. You will hear back from me by Friday. If we recorded it in the wrong place, we change the system, not the wording." (Function, give a date and give a way out. "Change the system, not the wording" is the key pledge)
- "I will draft these three pledges, [owner's name] issues them, and they go to the whole line. Which one do you think is missing?" (Function, turn the other person into a co-author of the governance pledge)
The banned list (every one of them defends intent and dodges capability). "The system does not mean it that way." / "The data does not lie." / "This is a company-level decision." / "Do not get emotional."
20.3 Visibility Governance Pledge Template
Generic template, Governance Pledge on the Use of [system name] Data:
| Pledge | Landing Mechanism | What a Violation Looks Like (for Self-Check) |
|---|---|---|
| One. Data the system produces is used to improve the process, not to appraise individuals | The performance appraisal metric list may not cite any individual number the system produces. This clause goes into the policy document, and no verbal version is accepted | Someone's waiting time or override records show up in a performance review conversation |
| Two. The team concerned sees its own data first | Any material containing a team's numbers goes to that team's lead [N] working days before the meeting | A team sees numbers about itself for the first time in a meeting room |
| Three. Aggregate display takes priority over individual detail | The upward-facing view goes no finer than the step / the team. Individual detail is visible only inside the team's own view | A table ranking individuals circulates outside the team |
| Four. Technical guardrails (the hard means behind the three pledges) | 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, on which day, why, and what was pulled) | Someone goes around approval and one query ranks the data by person |
Issuing elements (missing any one voids it):
- Issuer. It has to be the person with the power to violate the pledge (the business owner), not the project team. A pledge issued by the project team binds nobody.
- How it takes effect. Issued in writing, sent to every team the system covers, entered into the policy document. When the system extends to a new team, it is reissued along with the extension.
- Issuer change. When the business owner changes, the successor reissues within thirty days. 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 other transfer items (Chapter 22).
- Appeal path. Anyone who believes a pledge has been violated raises it with [the issuer] or [an independent third party, the union representative / HR], with a written reply within [N] working days. Appeals do not go through the project team.
Anchor & Helm version (Friday of week 21, issued by Kevin Doyle, sent to the whole claims line):
One. All data produced by the exceptions queue and the rollup view (including waiting time, bottleneck attribution and override records) is used to improve the process and is not a basis for any individual performance appraisal. The claims line's performance metric list may not cite the above data. Two. Any page of data summed by team goes to that team's lead two working days before the meeting. Three. Upward display goes no finer than the step and the team. Individual detail is visible only inside the team concerned's own view. Issuer: Kevin Doyle (Director of Claims Operations). Takes effect: from the date of issue. Appeals: anyone who believes the above pledges have been violated may raise it directly with the issuer or the union representative, with a written reply within five working days.
Code Hooks
This appendix has no code companion. (The queue config sample for the "waiting on external" status and bottleneck attribution belongs to the code hooks of Template 17.)