DA
All perspectives Read in danish

AI StrategyPublished

The psychology of AI transformation: five patterns from 14 years of change

How I apply my psychology study to AI transformation

For 14 years I have led and advised agile transformations. Delivery organizations, management teams, scale-ups and established companies. One pattern has held every time. Planning, sprints and dailies are easy to understand and easy to start. The human factor decides whether any of it lasts. In other words, transformation is mostly psychology.

I learned that the hard way. Years ago I watched six months of steady agile progress unravel when a client hired a new director from a very different school. I was millimeters from kicking his door in, or throwing in the towel and running away screaming. I did neither. Instead I started asking why the human side had been so fragile. And I have been asking that question ever since.

AI raises the pace. What used to unfold over a year now happens in a quarter. That doesn't make the human factor less important. It makes it more important, because there is less time to get it wrong.

I'm currently studying organizational psychology as part of my MBA at Edinburgh Business School. Very little of it has been new to me in practice. What it has given me is additional language and evidence for patterns I have seen in transformation after transformation.

It starts with the diagnosis. McCalman and Paton's TROPICS test places a change on a scale from hard to soft: timescales, resources, objectives, perception, interest, control and source.

AI lands on the soft side almost every time. Unclear timelines, shifting objectives, people seeing the problem very differently. Soft changes need direction and participation, not a detailed master plan. So what happens if we stop treating AI as a machine to be installed, and start treating it as a change in how people relate to their work?

The research on readiness for change gives a useful answer. It points to four drivers: belief that the organization can handle the change, trust in peers and leaders, participation, and relationships.

I have seen all four make or break agile programs. None of them is about technology. They shape the rest of this post, plus a fifth that holds them together: leadership.

1. Belief: line of sight before tools

The agile transformations that stalled rarely failed on the framework, perhaps with SAFe being the exception. They failed when teams could no longer see how their sprint connected to the strategy. Velocity without direction is just running fast in circles. People only believe an organization can handle a change when they can see where it is going.

AI makes this risk bigger. It is easy to launch twenty pilots. It is hard to explain which strategic outcome each one serves. A transformation leader's first job is to keep that line of sight: from strategy, to value stream, to the single task AI is meant to change.

2. Trust: people don't resist change, they resist a broken deal

I have watched teams push back hard on changes that looked harmless on paper. A new role, a new board, a new cadence. It was rarely about the change itself. It was about what the change said about their status, their autonomy and their future.

Psychology calls this the psychological contract: the unwritten deal between employee and organization. AI touches every line of it at once. When leaders say "efficiency," people do the math on their own role. Quietly. Usually on the commute home.

The literature on organizational justice gave me a useful split:

  • distributive: who gets the hours AI saves, and who carries the extra work
  • procedural: whether people can see how use cases are chosen and how stop or scale decisions are made
  • interactional: whether people are told the truth, early, with respect

Procedural justice turns out to predict commitment to change. That matches my experience. People accept a hard outcome from a fair process. They rarely accept a good outcome from a hidden one. So "augment before replace" must be more than a design principle. It has to be said out loud, as a promise leadership is willing to be held to. Trust is built on that promise, or lost on it.

3. Participation: start with the ending

In agile transformations I learned early that the project manager who lost the Gantt chart lost more than a tool. They lost a piece of who they were.

William Bridges gave me the better words. Change is the new situation. Transition is the inner process of getting there, and every transition starts with an ending. Skip the ending and people hold on to the old identity and call it skepticism.

AI ends things faster and for more people. The case handler who knew every rule by heart. The analyst whose value was the first draft. Bridges says people need four things to begin again: a purpose, a picture of how it will look and feel, a plan, and a part to play. Most AI programs deliver the plan beautifully. The picture and the part are often missing. That part to play is what participation really means. Not an invitation to a workshop, but a role in shaping what comes next.

The course also confirmed something I've seen in every team: people respond to change at different speeds. Those who believe they can make a difference, and that the outcome depends on them, will try anything. Others need safe practice before they believe. In a running group you don't win by shouting at the slowest runner. You set a pace the group can hold.

4. Relationships: beware the cool kids' table

Most agile transformations start with a pilot team. I have seen pilot teams become role models, and I have seen them become an island. The difference was rarely talent. It was how the rest of the organization related to them. Readiness lives in relationships, not in org charts.

Social identity theory explains why. Put a smart team in a room with new tools and a direct line to the executive team. Within weeks you have an in-group and an out-group. The pilot becomes "them." Everyone else becomes "the ones who don't get it." With AI, a small expert lab is the natural starting point, so the risk is built in.

Kotter saw the same trap. His early model drove change through a small, powerful core. His later work argued for a second operating system: a volunteer network from up, down and across the hierarchy. For AI, that means champions inside the value streams, joint demos and a business owner for every experiment.

And psychological safety moves from nice to have to precondition. If reporting a hallucination or a failed experiment hurts your career, you get polished demos and hidden problems. Small, enthusiastic teams also breed groupthink. Every AI team needs someone whose job is to ask if we are running the right race.

5. Leadership: learn twice, and celebrate the stop

Belief, trust, participation and relationships don't appear by themselves. Leaders create the conditions for them.

Agile organizations are good at improving how they work. Retrospectives fix the process. What I have seen far less often is teams questioning why the work exists in the first place.

Argyris calls this the difference between single-loop and double-loop learning. Single loop: the prompt failed, so fix the prompt. Double loop: should this process exist at all? Why do we approve this decision three times? That second loop is where AI creates strategic value, not just efficiency. It asks three things of people: self-awareness, honesty and taking responsibility.

Edgar Schein adds the leadership piece. People learn culture from what leaders pay attention to, measure, reward, and how they react when things go wrong. Not from values posters. In my master's thesis I called (agile) leadership a contact sport. Leaders can't stand on the sideline and install agility (or AI) in others. They have to be on the pitch.

One executive reaction to a failure can set the tone for years. If the executive team only applauds the AI pilot that scales, people learn to hide the ones that should stop. A well-argued stop decision deserves the same applause. That is how an experimentation culture becomes real.

The transformation leader's real job

Every AI transformation runs two loops at once. One is about the technology: experiment, measure, decide, scale. Most organizations are getting better at that one.

The other is about people and direction. Whether teams can see the strategy in their daily work. Whether they trust the process. Whether they still see themselves in the future being built. That loop decides whether the first one ever pays off.

That is the job I see for a transformation leader. Not only focusing on the AI tools, but owning the connection between strategy, organization and the people who make it real, at the pace AI now demands.

That is also why I'm putting it all together in an AI Transformation Playbook. It combines 14 years of transformation leadership, my MBA studies in organizational psychology and hands-on experience implementing AI. Two loops, one rhythm. More on that soon. If you'd like a preview before then, reach out.

After 14 years of leading transformations, the mechanisms are familiar, but the pace is new. And the more language I get for the human side, the more I respect the people at the center of it. Each one different, with their own starting point and moving at their own pace.

What have you carried over from earlier transformations into your AI work?

A few links if you want to dig deeper

The thinkers behind the ideas in this post: