Bandura's self-efficacy research shows that whether people change behavior depends less on what they know than on whether they believe they can do it. IS training consistently gets this wrong.
Most IS training programs are built around a single implicit theory: users behave incorrectly because they do not know enough. Add knowledge, change behavior. Run the training session, hand out the quick reference cards, send the follow-up email with the video links. The theory sounds sensible. And training programs built on it consistently underperform.
The problem is not that knowledge is irrelevant. It is that knowledge is not the bottleneck.
Bandura's social cognitive theory, first developed in the 1970s and 1980s, makes a distinction that most training designers do not. The central mechanism is not knowledge or attitude. It is self-efficacy: the belief that one can successfully execute a specific behavior in a specific context. My study-hub sources confirm this framing. The theories.html document I work from cites Bandura (1977) for Self-Efficacy Theory and Bandura (1986) for Social Cognitive Theory, with IS applications including Compeau and Higgins (1995), who applied the framework specifically to computer use. The core idea as stated there: "People are more likely to act when they believe they can perform the behavior successfully. In IS, computer self-efficacy helps explain training, ease-of-use beliefs, and security behavior."
The distinction matters because low self-efficacy produces a qualitatively different problem than low knowledge. A user who lacks knowledge about a system feature can read about it and use it. A user who does not believe they are capable of learning the system will approach training with anxiety that impairs learning, will avoid situations that require using the unfamiliar feature, and will interpret early errors as evidence that they were right about their incapacity. The knowledge may go in, but the behavior does not change because the confidence to execute is not there.
In IS contexts, this plays out in a specific way. Computer self-efficacy is not one thing. It is context-specific. A user might have high self-efficacy for the old system, the one they have used for five years, and low self-efficacy for the new one. When the organization migrates to a new system, it is not just changing tools. It is, from a self-efficacy perspective, taking highly competent people and making them suddenly incompetent again. They lose the confidence that came from years of learned fluency. That loss is real and it shapes how they engage with training.
The reinforcing cycle is one of the things Bandura's framework makes visible. Low self-efficacy leads to avoidance. Avoidance limits practice. Limited practice keeps performance low. Low performance confirms the original belief that the system was beyond them. The cycle is self-sustaining, and dropping more training content into it does not break it. The content may not be absorbed at all if the anxiety is high enough, and the anxiety often is.
Bandura identified several antecedents that build self-efficacy, and I think understanding them is more useful for IS implementation than any amount of feature documentation. Mastery experiences come first: actually performing the behavior successfully, even in small ways. Vicarious experiences are second: watching someone similar to yourself succeed with the tool. Verbal encouragement is third: credible feedback from others that you have the capability. Physiological state matters too: anxiety signals incapacity, and reducing anxiety around system use can have measurable effects on learning.
The practical translation is that implementation champions and peer adoption networks are self-efficacy interventions. When an organization identifies power users in each department and trains them first, then lets them support their colleagues during rollout, it is not just distributing training load. It is creating vicarious experience sources. The skeptical user in accounting who watches their colleague handle a tricky data import without panicking gets a piece of vicarious evidence that someone like them can do this. The study-hub material I have confirms that self-efficacy is central to technology-related performance: "Self-efficacy shapes effort, persistence, learning, and effective performance."
Classroom-style training followed by a cutover date is almost the worst possible self-efficacy intervention design. Users get exposed to a new system in a low-stakes, artificial environment. They see it once. Then they are in the live system, under full work pressure, without the trainer present. The first errors are not experienced as learning. They are experienced as confirmation that the system is hard and they cannot handle it. The exact moment when a user most needs support is the moment when the training program has ended.
Gartner has reported on the relationship between user confidence and digital workplace adoption, noting that access to tools is rarely the binding constraint, and that employee experience and confidence in using self-service technology shapes whether adoption materializes (see Gartner newsroom for research on digital workplace and employee experience). I read that directionally consistent with Bandura's framework. Self-service adoption, whether it is an HR portal, a procurement system, or an AI assistant, requires that users believe they can navigate the tool without help at the moment they need it. That is a self-efficacy condition, not a knowledge condition.
The IS research on this has its own history. Compeau and Higgins (1995) built one of the early IS-specific self-efficacy models and found that computer self-efficacy predicted intentions and behavior over and above what knowledge or attitude measures captured. That finding has been replicated in various forms across different system types and populations. It is not a new insight. But it consistently struggles to influence how organizations design training programs, probably because training programs are procured, budgeted, and evaluated as knowledge-delivery activities, not as confidence-building activities.
The question a training designer should be asking is not "how do we make sure users understand the new features?" It is "how do we make sure users finish the transition period believing they are capable of using this system?" The answers to those two questions look very different, and most implementation budgets fund the first one.
About the author
Share
More notes
Related notes