Most technology resistance is not about the technology. When a tool threatens who someone believes they are, rejection is identity-consistent, not irrational.
A senior radiologist I read about in a case study kept declining to use the hospital's AI diagnostic tool. Not because she thought it was inaccurate, she had seen the validation numbers. Not because she did not understand how to use it. She understood it well. She declined because she said, in so many words, that radiology was about seeing what others had missed, and a tool that flagged the obvious cases first left her with less to do, not more. What she was describing was not a usability problem. It was an identity problem.
Identity theory, in the tradition that goes back to Stryker (1980, 2001), holds that people occupy multiple social positions, and that each position is associated with an identity: a set of meanings people hold about themselves in that role. Identities are organized into a salience hierarchy. The more committed a person is to a relationship network that depends on a particular identity, the more salient that identity becomes in a given situation, and the more likely they are to behave in ways that verify it. When something disrupts identity verification, the response is emotional distress and often behavioral resistance to the disrupting agent.
Burke (1991) formalized the verification process. People carry an identity standard, a reference level for what their identity means. When behavior or events produce perceptions inconsistent with that standard, a mismatch signal is generated and people act to restore verification. This is not a cognitive process that can be overridden by showing someone a better ROI number. It is a self-regulatory process that operates independently of rational calculation, and sometimes in direct opposition to it.
The radiologist's standard for the identity "radiologist" included being the expert reader in the room. She had built her career on catching what others missed. The AI tool verified her identity not at all. It took the easy cases, automated the obvious, and left her with the residue. Her behavior in the role now produced perceptions that the role was less about expertise and more about supervising an algorithm. The mismatch between the identity standard and the new situation was real, and resistance was the identity-consistent response.
This is what I mean when I say most technology resistance is not about the technology. When the IS field talks about theorizing the relationship between people and technology, we keep circling back to whether the artifact actually matters in our models. Identity theory says it matters, but not in the way TAM measures. The TAM family of models asks whether someone perceives a technology as useful and easy to use. If the answer to both is yes, the model predicts adoption. But a senior analyst whose identity is "the person who knows the data" can simultaneously believe a self-service analytics tool is highly useful, easy to use, and deeply threatening, and respond by undermining its adoption. The tool is not the problem. The threat is. The threat is to what the person is in the organization, which is not captured by attitude-toward-use scales.
Strich et al. (2021) documented this exact dynamic in a financial services firm. Their study of the CleverLoan case showed that the same AI system produced different outcomes for different workers, mediated by professional identity and prior experience. Experienced workers, those with strong professional identities built on expertise and discretion, experienced the AI as a threat. It reduced the complexity of their work, the aspects that had defined their professional self-concept. Less experienced workers, those who had not yet built strong identities around specific expertise, could experience the same system as empowering. The technology was constant. The identity was the variable.
This finding undermines the assumption, still common in the IS field, that AI adoption produces uniform effects across a workforce. It does not. The effect is mediated by who people understand themselves to be in relation to the work the technology is changing. Design teams and implementation consultants who ignore this are not ignoring a soft psychological factor. They are ignoring the main mechanism that determines whether the tool gets used or gets worked around.
Albert and Whetten's work on organizational identity adds another layer. They characterized organizational identity through three properties: centrality (what is most essential about the organization), distinctiveness (what makes it different from others), and endurance (what has persisted over time). When a digital transformation threatens all three, the resistance is not just at the individual level. It becomes institutional. The organization fights for what it understands itself to be. A hospital that has defined its identity around physician autonomy will institutionally resist any technology that shifts clinical authority to algorithms, even when those algorithms perform well on measurable outcomes. This is organizational identity verification operating at the collective level.
The connection to why people use technology differently from how designers intended runs directly through identity. I wrote about the delegation shift elsewhere, noting that the question is not whether someone counts as a user but what they are actually delegating to the system. Identity theory gives that analysis a mechanism. People delegate tasks to technology in ways that preserve the parts of the work most central to their professional identity, and resist delegating the parts where their expertise is most salient to their self-concept. The radiologist will use AI for routine screening but resist using it for the complex cases where her expertise defines who she is.
The same dynamic explains why doctors resist AI diagnostic tools, why senior analysts resist self-service BI platforms, and why experienced writers resist AI writing assistants. Across every case, the resistance correlates with how central the threatened skill is to the person's professional identity. It is not incompetence. It is self-regulation.
My read on this is that identity theory should be a standard part of technology implementation planning, not a psychological curiosity for researchers. If you are implementing a technology that changes the nature of expert work, you need to ask: whose identity standard does this disrupt, how central is that identity to those people, and what is the gap between their current identity-verification experience and the experience the new technology creates? The gap predicts resistance more reliably than perceived usefulness.
Jussupow et al. (2024) showed something consistent with this in their work on algorithm aversion. People's aversion to algorithmic recommendations is not simply irrational rejection of superior performance. It responds to object properties, interface design, task context, and identity implications. The identity implications component is exactly the identity theory mechanism in different language. When an algorithm's presence threatens professional self-concept, aversion is the rational, identity-consistent response.
This is also why the relationship people have with systems is personal in a way that most IS models do not capture. I wrote about how trust differs from delegation, and the same point applies here. People's relationship with a system is not only instrumental. It is partly constitutive, partly about whether the system verifies or disrupts the kind of person they understand themselves to be. When we design systems that ignore this, we get adoption statistics that look fine and actual use patterns that tell a different story.
The radiologist eventually found a way to use the AI tool: she used it to identify cases she could review quickly, and spent her gained time on the genuinely ambiguous cases that required her expertise. She found a way to re-verify her identity through the new tool. That resolution was not designed. It was improvised. The better outcome is when that work of identity re-verification is part of the implementation process, not something left to individuals to figure out on their own.
About the author
Share
More notes
Related notes