Ben Satchwell argues that pushback on capability frameworks is usually rational feedback, not irrational resistance. Drawing on established research, Ben shows common objections often signal solvable issues: weak co-design, unclear data use, ignored history, time burden, or a missing personal why. Instead, ask what would need to change for support.
When people push back on a new capability framework, the project team tends to file it under “resistance to change”, as though resistance were an irrational reflex to be managed, overcome or waited out. This framing is comfortable, because it locates the problem entirely in the other person. It is also wrong, and acting on it makes things worse. Resistance to a capability framework is almost always rational. Behind nearly every objection sits a legitimate concern that is solvable, if you will stop treating the objection itself as the problem.
Much of what we label resistance is a rational response to how change is usually done
The research here is clear and not new. Ford, Ford and D’Amelio’s influential work reframed resistance as feedback rather than an obstacle, and pointed out something inconvenient for change agents: much of what we label resistance is a rational response to how change is usually done. People who have watched previous initiatives launch loudly and deliver nothing aren’t being difficult when they are sceptical of the next one. They are pattern-matching, accurately.
Whether it is a capability framework, a competency framework or a skills taxonomy, the objections rhyme, because they are responses to a common experience of being on the receiving end of change.
What sits beneath the objection
It helps to look at the common objections and what actually sits beneath them.
- “This doesn’t reflect what I really do” usually isn’t obstinacy, it is a genuine signal that the framework’s language is too abstract or was built without enough contact with the actual work. The fix is co-design, not persuasion.
- “Is this going to be used against me?” is a rational question wherever capability data could feed into performance or redundancy decisions, and a vague reassurance won’t settle it, because the concern is about power, not information. The fix is absolute clarity, in writing, on what the data will and won’t be used for.
- “We tried this before and nothing happened” is accumulated experience talking, and it is often correct. The fix is acknowledging the history honestly, rather than asserting that this time is different.
- “I don’t have time for this” is frequently true rather than evasive, especially for managers already running hot. The fix is to make the framework genuinely lighter to engage with, not to insist it is important.
- “I don’t understand why we need it” is sometimes the most honest objection of all, and the fix is the one most rollouts skip: explain the why in terms that matter to that person. In every case the objection points at a real, addressable cause. None of them is solved by labelling the objector resistant and pressing on.
That label is the actual danger. When you treat a rational concern as irrational resistance, you communicate that you are not listening, which converts a solvable disagreement into a relationship problem. The person who raised a fair point and was dismissed doesn’t quietly comply. They disengage, or they organise, and now you have manufactured the very entrenched opposition you imagined you were facing. Resistance treated as irrational tends to become irrational, because you have removed the rational route to being heard.
The question to ask
There is a question I would put at the centre of any rollout, borrowed from the spirit of that research. For each person or group pushing back, ask: what would need to be true for this person to support this?
The question forces you off the assumption that they are wrong and onto the substance of their concern. Sometimes the answer is a piece of information they are missing. Sometimes it is a genuine design flaw you need to fix. Sometimes it is a guarantee about how data will be used. Occasionally the honest answer is “nothing, their interests are genuinely threatened by this”, and even that is useful, because it tells you that you are dealing with a conflict to be negotiated, not a misunderstanding to be cleared up.
This is a different posture from the usual change-management instinct to “build the case” and “overcome objections”. It treats the people resisting as a source of intelligence about your own framework and its rollout. The objections are a free audit. Some will reveal that your framework needs work. Some will reveal that your communication failed. Some will reveal a real conflict of interest you will have to manage. All of that is more useful than a smooth launch where nobody says anything and you discover the resistance later, in the usage data, when it is too late to ask why.
So the next time someone objects to your capability framework, resist the urge to classify them. Assume the concern is rational until proven otherwise, find out what sits beneath it, and ask what would have to change for them to come on board. Most of the time, they are telling you something you need to hear.
Ben Satchwell is Head of Capabilities at Acorn PLMS
