up:: The Human & Organizational Side MOC
The Falsifiability Question
The falsifiability question is one sentence you can ask anyone slowing down a cryptographic migration: what would you need to see for this to look like the right call? Someone holding a genuine technical objection answers immediately and in detail, because they have already worked it out. Someone whose objection is carrying something else cannot name a condition, and when you satisfy the condition they do name, a new one appears. The question costs nothing, it diagnoses nobody, and it is the most reliable read available on which of the 2 conversations you are actually in.
The short version:
- In a security engineering culture, difficulty arrives as well-formed technical objections rather than as stated reluctance.
- Every one of those objections is a position a competent person could hold on the merits, which is what makes them impossible to sort by content alone.
- The sorting property is falsifiability. A real objection names what would change the objector’s mind.
- Getting it wrong is expensive in both directions, and the more expensive direction is dismissing someone who was right.
- The question is asked plainly and without edge, and the answer is the finding.
Think about a structural engineer objecting to a proposed load. Ask what test result would satisfy them and a real objection produces a specification: this beam, this loading, this deflection limit. If the answer is a general unease that reshapes each time a test comes back clean, you are dealing with something the tests were never going to resolve. Neither response makes anyone unreasonable, and telling them apart determines whether you commission the test or have a different conversation.
Why can’t you sort these objections by content?
Because the content is identical either way.
The objections that slow a post-quantum migration are recognizable and reasonable: the assumptions behind the new primitives have been studied for less time than factoring, parameter sets could change again, our threat model does not include an adversary storing traffic for a decade, migrating introduces more risk than it removes. Each of those is defensible, each has been argued in public by competent people, and each is also exactly what a displaced loss sounds like when it comes out of an engineer.
There is no phrasing that distinguishes them, which is why programs default to guessing based on who is speaking. That guess is usually wrong in the same direction, because the people most likely to hold both a real objection and a displaced loss are the senior practitioners whose expertise the migration unsettles, per The Undocumented Estate.
What does the question actually separate?
| A genuine technical objection | A displaced objection | |
|---|---|---|
| Can they name a condition? | Immediately, and usually in specifics | The answer stays general and shifts when pressed |
| What happens when you satisfy it? | The objection is withdrawn | A new condition appears in its place |
| How specific is it? | Points at a named system, protocol, client, or constraint | Points at the category rather than at anything you could test |
| What it needs from you | Take it seriously, because it is probably correct | Address what sits underneath it, per Change Management for Cryptographic Migration |
The second row is the strongest evidence and it takes a cycle to observe. Someone who said they needed a hardware vendor’s roadmap, receives it, and then raises a distinct concern about parameter sets has told you something the first answer did not.
Why is dismissing a real objection the more expensive error?
Because it is unrecoverable in a way the other direction is not.
Treating a displaced objection as technical costs time. You spend 6 months in an argument that evidence cannot settle, which is expensive and survivable. Treating a genuine objection as psychological costs the relationship, because you have told a competent person that their professional judgment is a feeling to be managed, and that verdict does not get taken back by a later apology. It also removes the person best placed to tell you what will break.
This is where a great deal of change-management material is quietly dangerous in a cryptographic context. Models that treat resistance as something to be processed have no category for the case where the objector is right, and in this field they frequently are. Parts of an embedded estate genuinely cannot be updated, some vendors will not ship in time, and no organization of comparable complexity has completed a full migration. Someone saying that is describing the situation.
Why won’t your vendor ask this question?
Because a vendor benefits from every objection being classified as resistance.
If the blocker is organizational readiness, the product remains the answer and the sale continues. If the blocker is a genuine technical constraint in the buyer’s estate, the response is that the product cannot solve it, which is a harder conversation and a smaller deal. So the incentive runs toward treating every hesitation as a change-management problem, and toward supplying material that frames it that way.
The same pressure operates on an internal program under delivery pressure. Reclassifying an objection as resistance is the cheapest way to keep a schedule, and it works right up until the constraint that was real arrives on its own timetable.
What do you actually do about it?
- Ask it plainly and without edge. The tone carries the whole thing. Asked warmly it is an ordinary engineering question, and asked as a challenge it produces a defensive answer that tells you nothing.
- Write the answer down. A named condition is a commitment on both sides, and it is what lets you observe the second row of the table when the condition is met.
- Satisfy the condition if you can. Fetch the vendor roadmap, run the interop test, get the parameter guidance. Most named conditions are cheaper to satisfy than to argue with.
- When a real objection is confirmed, change the plan. That is the point of asking. An objection that survives the test is intelligence about your estate, and folding it into the sequencing is what earns the standing to have the other conversation later.
- When no condition can be named, work the loss rather than the argument. The material in Change Management for Cryptographic Migration applies, and continuing to argue the technical merits will confirm to the person that they were right to hold on.
- Use it on yourself. A program that cannot say what would make it revise its own plan has the same problem in the other chair.
Common misconceptions
- “This is a way to catch people out.” It works only when it is asked in good faith, and the visible intent to catch someone produces the defensive answer that makes it useless. It is a question you ask because you want the answer.
- “An answer of ‘I don’t know’ means it is displaced.” It frequently means the person has not been asked to think about it before, which is common and fair. Give it time and revisit rather than scoring the first response.
- “Once classified, the person is classified.” Both can be true at once and in the same person. A senior practitioner often holds a real constraint and a genuine loss simultaneously, and the question separates the claims rather than sorting the people.
- “This replaces the technical review.” It sequences it. The question tells you which objections deserve a full review, which is what makes reviews affordable when 30 of them are in flight.
- “Senior people should not need to be asked this.” Senior people are precisely who it is for, because they are the ones whose objections are sophisticated enough to be indistinguishable by content.
Questions people ask
What if they name a condition that is impossible to satisfy? That is a real answer and a useful one, because an impossible condition usually points at a genuine constraint in the estate. Record it as a documented limit rather than as an objection, and plan the segment around it.
How many times can I ask before it looks like pressure? Once per objection. The information is in the answer and in what happens when the condition is met, so repeating the question adds nothing and reads as interrogation.
Who should ask it? Anyone with a working relationship with the person. It travels well from a peer, from the migration owner, and from an outside advisor, and people frequently answer an outsider more openly, since the outsider does not write their review.
Does this work upward? Yes, and it is uncomfortable and valuable. Asking a sponsor what would make them fund faster, or an executive what evidence would change their view on the timeline, produces the same read.
What if I get a condition that has already been satisfied? Say so, calmly, with the evidence, and see what happens next. That is the clearest instance of the second row available, and it is worth handling without any suggestion of a gotcha.
Is this a formal process? It is a question in a conversation. Building it into a workflow with a form attached converts an honest exchange into an audit and kills the answer you were trying to get.
Go deeper
- Change Management for Cryptographic Migration: what to do when the objection turns out to carry a loss.
- The Undocumented Estate: why the strongest objections tend to come from the people holding the most estate knowledge.
- Why Post-Quantum Migrations Stall: the wider anatomy of a stall.
- The Contradiction Audit: the check for when the organization’s own systems are the real objection.
Everything here is the map, given freely. When your team needs the objections in your program sorted, and the real constraints folded into the sequencing, that’s the work I do.
Last verified 2026-08-19 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.