Separating Genuine Concerns from Change Resistance in Strategy Implementation

Start by assuming both are true

The framing of "genuine concern versus resistance to change" is where most implementation efforts go wrong. In practice, the same stakeholder is usually doing both at once. A risk officer flagging model governance issues on a new lending strategy may be raising a legitimate control gap and protecting their team's workload and status. Treating it as one or the other leads to bad calls: you either steamroll a real problem or you capitulate to soft objections dressed up as technical ones.

Your job is not to sort people into camps. It is to isolate the substantive content of each concern from the political and personal context around it, then decide which parts require a change in plan.

Test the concern, not the person

Apply four tests to every significant piece of pushback you are hearing.

Specificity. Genuine concerns are concrete. "The capital treatment assumes IRB approval we haven't secured" is specific. "I'm worried about execution risk" is not. Vague concerns almost always mask something else: workload anxiety, loss of territory, or disagreement with a decision the person feels they were excluded from. Push for specifics. If a stakeholder cannot articulate the concern in a testable form after two conversations, it is not primarily a technical concern.

Falsifiability. Ask what evidence would resolve the concern. A genuine objection has an answer: a stress test result, a legal opinion, a pilot outcome, a regulator conversation. If no evidence would change the person's mind, you are dealing with values, politics, or exhaustion, not risk.

Consistency across audiences. Have someone your stakeholder trusts, but who is not you, ask the same question. If the concern shifts in shape depending on the audience, it is positional. If it stays the same when raised with peers, auditors, or external counsel, take it seriously.

Track record. Look at what this person has raised on previous strategies. Stakeholders who consistently flagged issues that later materialised deserve more weight than those whose pattern is late-stage objection to anything they did not originate.

Sequence matters more than analysis

The order in which you engage stakeholders will determine what signals you get. Three rules.

First, talk to the people with least political stake first. Second-line control functions, external advisers, and operational leads two levels down will tell you things the executive committee will not. They also give you a baseline against which to read more senior responses.

Second, separate the concern-gathering conversation from the decision conversation. If people believe they are being asked to endorse in the moment, they will either over-support or over-object. Neither is useful. Make it clear you are testing, not deciding.

Third, come back a second time. First responses are performance. Second responses, especially in writing after a week of reflection, are closer to what people actually think.

What good looks like

By the end of this exercise you should have a short list, no more than five to seven items, of concerns that pass the specificity and falsifiability tests. Each should have a named owner, a defined piece of evidence that would resolve it, and a deadline. Everything else goes onto a second list: real signals of resistance that need managing through communication, sequencing, or incentives, but not through changes to the strategy itself.

The mistake most leadership teams make is merging these two lists. They either treat all pushback as change management, which loses them the genuine risks, or they treat all pushback as substantive, which drags the strategy back into re-litigation and hands veto power to the least committed stakeholders.

Where this goes wrong

The most common failure is confusing seniority with signal quality. A board member's discomfort is not evidence of a flawed strategy, and a junior analyst's technical objection is not noise. Weight concerns by their content and track record, not the org chart.

The second failure is timing. Teams often run this validation once, at approval, and then treat silence as consent through implementation. Concerns evolve. Run the same test at ninety days and again at six months.

Your next decision

Before your next implementation checkpoint, write down the three concerns you are currently hearing most often. For each, answer: is it specific, is it falsifiable, and what evidence would resolve it? If you cannot answer those three questions today, you do not yet know whether your strategy has a problem or your stakeholders do.