Why Technology Teams Resist New Technology and What Actually Gets Them to Adopt It

Technologists hesitate due to unfair comparisons, status quo bias, and learning debt. Experience gaps cannot be closed through analysis. Adoption requires deliberate practice on the new platform, allowing teams to build competence and reduce uncertainty. Without allocating time for hands on exploration, the old system's accumulated expertise will always win in short term comparisons.

Every technologist eventually meets the same moment. The team agrees that an existing technology has reached the end of its useful life. Everyone agrees the replacement is the right direction. And then, month after month, the team keeps building on the old platform anyway.

This is not usually laziness, and it is not usually stubbornness either. It is a specific, predictable pattern of hesitation, and it has a mechanism behind it that is worth taking apart properly, because until you understand the mechanism, encouragement alone will never fix it.

1. The hesitation comes from an unfair comparison, not a lack of will

Ask a team how long a piece of work will take on a platform they have used for fifteen years and they will give you a number. It might be a number they dislike, but it is a real number, built from years of knowing exactly where the platform’s weaknesses are and how to work around them.

Ask the same team how long the same piece of work would take on the platform they are supposed to be moving to, and the answer changes shape entirely. It might take longer, because they have to learn as they go. It might take less time, because the new tooling removes categories of work the old platform forced on them. Nobody actually knows, and that uncertainty gets treated as a mark against the new platform, when it is really just a mark against how little the team has been allowed to practise on it.

That comparison is not a fair one. One side of it carries fifteen years of accumulated experience, while the other side carries almost none, and the team is being asked to bet on the side with the smaller number attached simply because a number exists at all.

What makes this stranger still is that the number attached to the old platform is often a bad one. I have seen teams whose current platform takes far too long to deliver anything and produces code that is buggy and does not scale, and who will still choose to build the next new feature on that same platform rather than the one everyone has already agreed is the strategic direction. They are not choosing a known good outcome over an unknown one. They are choosing a known bad outcome, delivered slowly, on a platform they already dislike working with, simply because it is the bad outcome they know how to produce. Familiarity, it turns out, does not require the familiar thing to actually be good. It only requires it to be familiar.

2. Known problems get mistaken for lower risk

William Samuelson and Richard Zeckhauser gave this behaviour a name, status quo bias, in research showing that people disproportionately favour an existing option over an alternative simply because it is the one already in place, even when a rational comparison would not favour it (Samuelson and Zeckhauser, 1988). Their experiments and their data on real decisions, including health plan and retirement choices, found the same pattern repeatedly, that the status quo carries a psychological advantage that has nothing to do with its actual merit.

Technology teams live inside this bias constantly. The old platform has known defects, known constraints and known costs, all of which sound like disadvantages until you set them against a new platform whose defects, constraints and costs have simply not been discovered yet. Known problems feel safer than unknown ones, so the team chooses the platform whose problems it has already catalogued, and calls that decision pragmatic.

None of this means the new technology is automatically better. Switching costs are real, immature platforms fail, vendor ecosystems disappear, and sometimes the incumbent genuinely remains the rational choice. The mistake is not choosing the old technology. The mistake is allowing familiarity itself to masquerade as evidence. Staying should be an explicit decision, supported by the economics and the engineering, rather than the residual outcome of nobody being willing to learn the alternative.

3. Exploitation always looks better than exploration in the short term

James March described the deeper version of this problem in his work on exploration and exploitation in organisational learning. Exploitation, refining what you already know, produces fast, predictable returns. Exploration, trying something genuinely new, is slower and carries a real chance of early failure. March warned that this asymmetry creates a feedback loop, where organisations become increasingly good at exploiting existing knowledge, which makes exploitation look even more attractive relative to exploration, and the resulting pattern can be effective in the short run while becoming self destructive over time (March, 1991).

This is exactly what happens inside a stalled technology transition. A team becomes very good at the old framework, which makes the old framework the fastest option for the next project, which gives the team even more expertise in it, which makes it the fastest option again the time after that. Eventually the organisation points at the team’s deep expertise in the old framework as evidence that moving away from it would be too costly, when that expertise is itself the product of every previous decision not to move.

4. The debt that matters most here accumulates in people, not systems

We talk constantly about technical debt, the cost sitting inside old code and old architecture. There is another form of debt that is useful to think about alongside it, which accumulates somewhere different, in the skills of the people who were supposed to be learning the replacement. TalentLMS ran a survey across the workforce in 2026 and found a substantial share of employees believed their roles were evolving faster than their organisations could train them for, a gap they described directly as learning debt. In a technology transition the same effect shows up at team level, and it is particularly damaging, because every month an engineer spends deepening their expertise in a platform that is being retired is a month they did not spend building competence in the platform that is meant to replace it.

That is learning debt, and unlike technical debt, it cannot be refactored away over a weekend, because it lives in people rather than in code, and people only pay it down by actually doing the new work, badly at first, until they are not bad at it any more.

Learning debt compounds the same way technical debt does. Six months into a stalled transition, leadership asks why the migration still looks so far away, and the honest answer is that the organisation spent the previous six months making sure nobody had the practice to do it any faster.

5. You cannot analyse your way across an experience gap

This is where a lot of otherwise sensible organisations go wrong. Faced with the uncertainty around a new platform, the instinctive response is another round of analysis. Large meetings get scheduled to discuss the impact of the move, dependencies get mapped, and someone asks for a detailed comparison of delivery velocity between the old approach and the new one, weeks before anyone has actually built anything on it.

The assumption hiding inside that instinct is that the impact will be negative, and it is worth asking why. What if the new platform makes development faster once the team understands it. What if testing improves, deployment gets safer, or the tenth implementation takes half the time the first one did. None of those questions can be answered in a meeting room, because they depend on experience the organisation does not yet have, and there is a point past which further analysis stops reducing uncertainty at all. Only doing the work reduces it further.

The cheapest way to answer most of these questions is not another workshop. It is a small, real piece of work, built on the new platform, with the specific intention of finding out what breaks.

6. The operating model has to change, not just the technology

John Hagel’s distinction between scalable efficiency and scalable learning explains why encouragement alone rarely moves a stalled transition. Scalable efficiency is the model most large organisations were built around, taking known activities, standardising them and performing them more cheaply at scale, and it works well when the underlying work is stable (Hagel, “Learning and Strategy”). Technology is not stable, and Hagel argues that organisations operating in a changing environment need scalable learning instead, which he defines specifically as creating new knowledge by confronting new problems through action, not as distributing existing knowledge more efficiently through training courses and internal presentations (Hagel, “Learning and Strategy”).

That distinction matters here because a team measured entirely on delivery predictability, the language of scalable efficiency, will always look irrational when it chooses the slower, less certain path of learning something new. It is not being irrational. It is being judged by the wrong operating model, one built to optimise the thing the organisation already knows rather than to reward the thing it is trying to learn.

7. Temporary incompetence has to be made safe

An engineer with fifteen years of experience is used to being the person with the answers. Moving them onto a genuinely new technology takes that away for a while, and turns them back into someone asking basic questions, making mistakes a junior colleague might not make, and occasionally being slower than people who have been on the new stack for less time than they have.

Amy Edmondson’s research on psychological safety found that teams were more likely to engage in the behaviours learning actually requires, asking questions, admitting uncertainty, exposing gaps in their own knowledge, when they believed it was safe to take that kind of interpersonal risk (Edmondson, 1999). A technology transition asks exactly this of experienced people, and if the organisation treats their temporary loss of fluency as underperformance rather than as evidence that learning is happening, it will get exactly the caution and retreat it is punishing people for showing.

The clearest version of this I see right now has nothing to do with a migration project at all. It is senior engineers, often the most capable people on the team, still hand writing every line of code and manually reviewing every pull request line by line, while quietly overwhelmed by the volume of work in front of them and surrounded by colleagues already using AI assisted coding tools to move faster. They know the tools exist. Many of them have even tried one, once, briefly. What they cannot do is give themselves permission to be visibly bad at using them, because being the engineer everyone turns to for the hard problems is the identity they have spent fifteen years building, and an AI assisted workflow, at least for the first few weeks, makes that same engineer look like a beginner again. So they keep doing the thing they are already excellent at, even as the backlog grows and the overwhelm gets worse, because staying excellent at the old way feels safer than being visibly mediocre at the new one, even for a fortnight.

There is real evidence behind the fear that the first weeks will look worse, which makes it easy to understand why so many engineers stop right there. METR ran a randomised controlled trial in early 2025 in which experienced open source developers, working in repositories they knew well, took nineteen percent longer to complete tasks when they used the AI tools available at the time, despite believing throughout the study that the tools were making them faster (METR, 2025). By early 2026, METR reported that this result was already looking dated, since newer tools appeared likely to produce a genuine speedup, though changes in participant behaviour were making the effect harder to measure cleanly (METR, 2026). Read together, the two results say something more useful than either one alone. An expert with fifteen years of optimisation around one workflow and a handful of hours around a new one should expect to be slower at first, and the organisation has to tolerate that inversion long enough for a new competence curve to actually form, rather than reading the early slowdown as proof the whole exercise was a mistake.

This is also where the problem becomes a loop rather than a one time hesitation. The senior engineers most overwhelmed by their current workload are usually the ones with the least apparent time to learn anything new, so they keep doing everything the manual way, which keeps the workload exactly where it was, which leaves them just as overwhelmed and just as unable to find the time next month either. Overload prevents exploration, the absence of exploration preserves the workload that caused the overload, and the cycle repeats until something outside the loop, usually a deliberate decision by a leader, interrupts it.

That is status quo bias and learning debt again, just wearing a different, more personal costume than a platform migration, and it will not resolve itself until the organisation makes it explicitly safe for its most senior people to be temporarily worse at their jobs while they learn something that will make them faster for years afterward.

8. What an actual transition requires, in practice

Knowing the mechanism behind the hesitation is only useful if it changes what leadership actually does. A few things have to hold together at the same time for a transition to move rather than stall.

The new platform has to become the default, so teams justify staying on the old one rather than justify leaving it, because left to a genuine choice, the pull of accumulated experience will win almost every time. Real production work, not a training exercise, has to be the vehicle for learning, because fluency comes from delivery, not from a course. The first team through has to be allowed to be slower, because their job is not only the feature they ship but the documentation, tooling and hard won judgement the next team inherits. Those lessons have to be deliberately fed forward, so the second team is faster than the first and the third faster again, otherwise every team is independently discovering the same problems and the organisation is repeating rather than learning. And at some point leadership has to actually close the old road, because an old platform that remains available indefinitely will absorb every deadline as an exception, and exceptions have a remarkable tendency to become the permanent architecture.

I have watched this play out enough times to trust the pattern completely. A team will agree entirely with the strategy, agree the old platform has to go, and then carry on building against it indefinitely, because agreeing with a direction costs nothing while actually moving costs a period of visible discomfort. Nothing changes that until I stop the old path outright, and the moment I do, the team does not calmly pivot. It gets genuinely chaotic for a while. Estimates fall apart, people are frustrated, the first few weeks look considerably worse than continuing on the old platform ever would have. Then, without exception so far, the team comes out the other side of that chaos and accepts the new world, usually faster than they expected to. The confrontation with reality, not the strategy document and not the meeting where everyone nodded along, is the thing that actually moves anyone. Until that confrontation happens, agreement is free and change is optional, and an organisation will always choose the free, optional path over the disruptive, mandatory one, no matter how sincerely everyone in the room believes in the strategy.

Organisational ambidexterity research backs the shape of this. O’Reilly and Tushman describe the need for organisations to exploit mature capabilities where control and efficiency genuinely matter while simultaneously exploring new ones where flexibility and experimentation are required, and doing only one of those well is not enough to keep an organisation viable (O’Reilly and Tushman, 2013). A transition needs both modes running deliberately, not the exploitation model quietly winning by default because it is the only one anyone is measuring.

9. Treating the transition as a project guarantees the next one stalls too

The deeper trap is believing that once this particular migration finishes, the organisation can go back to normal. Every technology a team adopts today will eventually become the legacy technology somebody is afraid to leave tomorrow, defended by people with fifteen years of expertise in exactly the framework the organisation once fought to adopt. That is closer to what James Carse called an infinite game than a finite one, a contest with no finish line, where the point is not to win once but to keep being able to play. Treat this transition as the last one you will ever need, and you have simply guaranteed that the next hesitation will look exactly like this one, with a different framework’s name attached to it.

10. When do you want to start being good at the next thing?

There will always be a reason to do one more piece of work on the platform everyone already knows. There is always a deadline that makes this quarter the wrong time to start, and next quarter will offer exactly the same excuse dressed slightly differently. If every individual argument for waiting gets accepted, the collective result is entirely predictable, which is that nothing changes, the migration gets larger every month, and the gap between the people who know the old platform and the people who know the new one keeps widening in exactly the wrong direction.

The way out is not a bigger meeting. It is smaller, real work on the new platform, permission to be slower while learning it, and lessons that genuinely travel from one team to the next. Everything else is a way of postponing the only question that actually matters, which is when you want to start being good at the thing you already know you need to do next.

References

1. William Samuelson and Richard Zeckhauser, Status Quo Bias in Decision Making, Journal of Risk and Uncertainty, 1988.
2. James G. March, Exploration and Exploitation in Organizational Learning, Organization Science, 1991.
3. John Hagel, Learning and Strategy, on creating new knowledge through action rather than distributing existing knowledge.
4. Amy C. Edmondson, Psychological Safety and Learning Behavior in Work Teams, Administrative Science Quarterly, 1999.
5. Charles A. O’Reilly III and Michael L. Tushman, Organizational Ambidexterity: Past, Present, and Future, Academy of Management Perspectives, 2013.
6. TalentLMS, Learning Debt Report 2026, on the gap between how fast roles are changing and how fast organisations can train for them.
7. James P. Carse, Finite and Infinite Games: A Vision of Life as Play and Possibility, 1986.