Why Change is Hard
Change is hard when it asks us to rethink who we are
Last week in Seattle, I attended Malcolm Gladwell’s session at Slalom’s R4 2026 conference. Gladwell, the writer behind The Tipping Point and Outliers, spoke about a question that intrigued me. Why can an idea that appears to work take so long to become an ordinary part of life?
We tend to imagine a fairly direct journey. Someone discovers a better way to solve a problem, demonstrates the result and persuades others to follow. The stories he told about policing and heart surgery made me think about what happens after that persuasion. People may know about an approach, accept its promise and even try it, yet struggle to make it part of dependable everyday work.
I am currently exploring how AI can help us build software differently, so the question feels close to home. Seeing what a tool makes possible is exciting. The harder task is creating the skills, working relationships and support that let people use it well over time. Making a new approach work requires changes in an organisation, but also in how people understand their place within it. That feels especially important when I am one of the people asking them to change.
A promising idea can have a long journey
In Boston, criminologist David Kennedy helped develop the work that led to Operation Ceasefire. Conversations with officers and people in the community revealed that much of the violence centred on relatively small networks of people. Knowing who was involved, and how one shooting could lead to another, offered a more focused way to intervene.
Boston began implementing Operation Ceasefire in 1996. It targeted illicit firearms trafficking and violent gangs, with direct messages that further violence would bring enforcement. An evaluation published by the US National Institute of Justice associated the intervention with a 63 per cent reduction in the average monthly number of youth homicide victims. By the early 2000s, there was published evidence that this approach could make a substantial difference.
Now move forward to January 2022. Baltimore launched a Group Violence Reduction Strategy in its Western District, combining targeted enforcement with offers of support for people at high risk of involvement in shootings. A University of Pennsylvania evaluation estimated that homicides and shootings were about 25 per cent lower over the first eighteen months than they would otherwise have been.
About twenty-six years separate Boston’s initial implementation and the launch of that Baltimore programme. But Baltimore had not spent those years unaware of the idea. According to the Abell Foundation’s account, the city had already attempted the approach in the late 1990s and again in 2014. Other cities had used it too. The 2022 programme was a renewed effort to turn a known approach into something that could work and last.
That makes the difficulty more revealing. In a 2024 statement, Baltimore’s administration attributed the earlier failures to insufficient leadership commitment, implementation resources and services for people seeking to leave violence behind. This was the administration’s explanation of those failures, but it identifies needs that greater awareness alone could not meet.
Baltimore knew about the approach and had tried it. Another explanation of its benefits would not, by itself, supply the leadership, resources and working relationships that earlier attempts had lacked. Decades after the early evidence of promise, the work of making it dependable was still being done. Surgery offers a different view of what that work can ask of the people involved.
Thirty years, and still a small minority
Cardiac surgeon John Puskas faced a similar frustration with minimally invasive bypass surgery. Surgeons had been developing these approaches since the 1990s. Roughly thirty years later, he estimated that only two or three per cent of bypass operations at major US hospitals used minimally invasive techniques. He doubted he would live long enough to see the figure reach 50 per cent.
His frustration is easy to understand. He had spent decades pursuing a different way to operate, yet believed it remained a small part of everyday practice. His frustration concerned the distance between performing the operation successfully and helping other teams make it part of their practice.
The change reached into the relationships around the operating table. In conventional surgery, the surgeon had direct access to the heart, and an experienced team could anticipate much of the work through familiar routines and cues. With the smaller openings and instruments Puskas described, the surgeon could no longer obtain all the same information directly. Colleagues had to supply information and coordinate their movements much more closely.
Surgery was already a team activity. What changed was how visibly the surgeon depended on the rest of that team. A highly experienced person could no longer rely on seeing everything for themselves. They had to listen to what a colleague could see, adjust what they were doing and trust the information being passed to them in the middle of the operation.
The change worked in both directions. Other team members had to become more active in communicating what they noticed, rather than relying so heavily on the surgeon’s familiar cues. For the surgeon, listening became part of exercising control. For colleagues, speaking became part of taking responsibility. Each person’s ability to do the work depended on the others learning those habits too.
Puskas’s concern was therefore whether he could bring an entire team through the transition, train its members, retain them and keep them committed to a way of operating he described as harder for them and better for patients.
This is the part I find most revealing. Explaining the advantages could give the team a reason to begin. It could not give them the shared experience needed to work differently under pressure. Nor could it settle how an accomplished surgeon would feel about becoming more dependent on colleagues. The equipment, the working habits and the experience of being the expert were changing together.
The story also leaves a practical question. If changing the work requires changing a whole team’s habits, what support makes that possible? Singapore’s experience with container shipping offers a different setting in which that preparation was deliberately organised.
A port has to change around the container
The attraction of container shipping is easy to picture. Goods can stay inside a box while the box moves between different forms of transport. But a box alone does not provide a working transport system. Ships, cranes, storage areas and the movement of cargo through the port have to fit together.
In 1966, Singapore decided to build its first container terminal. According to PSA’s history, no shipping line had yet committed to building container ships for the Europe–Far East route. The first container berth opened at Tanjong Pagar in June 1972. Singapore was preparing for a change whose regional future was still uncertain.
Opening the berth made container handling possible. Expanding it meant changing the work of the port. In a 1980 speech on workers’ response to containerisation, PSA chairman Lim Kim San reported that containerised general cargo had reached 40 per cent of PSA’s general cargo in 1979. Seven years after the terminal opened, the transition was well under way, with further growth expected.
His account also described apprehension about job losses. He said no worker had been made redundant as a result of containerisation, and pointed to systematic training and union support in helping workers move into the new work. That is evidence of a transition being actively managed, with concerns about livelihoods addressed alongside the introduction of equipment.
Singapore committed early, and carrying out that commitment required years of coordinated work. Training helped workers learn the new tasks, while assurances about employment addressed their concerns about the future. Both gave people a place in the port that was emerging. More publicity about the advantages of containerisation could not have done either job.
Software can seem exempt from this problem because it does not require a new quay or a fleet of ships. A development tool can be installed quickly, and a team can learn the outline of a method in a workshop. But what happens when the method asks them to make decisions that their organisation is not yet ready to support? The experience of agile brings that difficulty closer to my own work.
What agile asked people to become
When the Agile Manifesto appeared in 2001, it expressed a straightforward approach to building software. Teams would build in small steps, work closely with the people using the software and change direction as they learnt. Instead of waiting until the end of a long project to discover whether they had built the right thing, they would find out along the way.
For a manager responsible for a budget and a delivery date, this changes what it means to do the job well. A conventional project rewards keeping work on an agreed course. Agile asks the team to act on what it learns, even when that means revising an earlier commitment. The manager may welcome the approach while still answering to colleagues who need firm dates and leaders who expect the original plan to hold.
Singapore’s experience shows how much had to change around the people doing this work. The Infocomm Development Authority announced plans for an agile development tender in 2013. By 2017, GovTech, Singapore’s Government Technology Agency, was describing the shift from managing technology contracts towards building the technical skills to develop services within government.
The ability to build was only part of what teams needed. They also needed ways to fund work whose direction could change as they learnt. In 2019, GovTech outlined changes to funding arrangements to support digital development and experimentation.
Let’s pause a bit on the shift from contract management to developing services. Imagine being accustomed to checking whether a supplier has delivered what was agreed. Now you are expected to question whether the agreed feature is worth building at all. You need to understand users, discuss alternatives with engineers and sometimes recommend abandoning work that already has approval.
That calls on a different kind of judgement. A clear specification once helped demonstrate that you had done your job. Now part of doing it well involves discovering where the specification is wrong. If budgets and performance reviews still reward adherence to the original plan, accepting the case for agile does little to resolve your daily predicament.
I joined GovTech in 2023 and now serve as its chief technology officer, so these developments predate my time. I read those dates as a record of building the conditions for a different way of working. Knowing the principles of agile was useful, but teams also needed technical capability, permission to reconsider decisions and funding that allowed them to learn as they went.
These examples make me cautious about treating a difficult implementation as a failure to understand the benefits. The missing piece might be resources, time to practise or authority to make a different decision. Finding out which one is missing matters more than repeating the case for change.
There can also be a more personal difficulty within that same process. A new working arrangement may be well supported and still unsettle someone because it changes how they earn respect or experience satisfaction. Professional identity can shape how people learn and work together, even when they agree that the change is worthwhile.
What we are being asked to give up
Imagine spending twenty years becoming good at something. You have worked through difficult cases, made mistakes, learnt from people you admire and eventually become someone others turn to. You know what you contribute, and other people know it too.
Then a new way of working changes the terms. Some decisions you once made are shared. A skill that used to distinguish you becomes easier for others to perform. You are still needed, but it is less obvious what people need you for. Understanding why the organisation wants to change does not immediately supply an answer.
There is a useful distinction between improving a familiar way of working and changing the work itself. These are not separate categories with a clean boundary. A new tool might save a few steps, or it might gradually change which decisions we make, whom we depend on and what others value in our contribution. As those relationships change, people need opportunities to practise the new role and discover how their experience still helps. A course can support that learning, but it cannot supply all of it.
Get Sau Sheong’s stories in your inbox
Join Medium for free to get updates from this writer.
The surgeon’s growing dependence on colleagues captures something I find uncomfortable. Experience often brings the satisfaction of needing less help. Being asked to rely more on others can feel like moving backwards, even when it allows us to do better work. I would like to think I welcome a colleague’s correction, but being recognised as the expert creates its own pressure to appear self-sufficient.
A profession gives us several things at once. There is the satisfaction of being good at something, and the recognition that comes when other people know we are good at it. There is also the feeling of belonging among people who share our habits, language and standards. Over time, these become bound up with our sense of why the work is worth doing.
A change can leave that larger purpose intact while disturbing much of what makes the job rewarding from day to day. An engineer still wants to build something useful, and a manager still wants a team to deliver good work. Those ambitions tell us little about how they will feel when their own contribution changes.
Imagine telling a pianist that they can remain in music, with the same income and job security, but will now spend most of their time selecting and evaluating performances generated by software. Some would enjoy that work. Others would feel they had lost the activity that brought them into the profession. Pointing out that the audience still gets music misses a large part of the experience.
For me, this is a blind spot in the way we talk about productivity. We count what comes out of the work and pay much less attention to what the person gets from doing it. I do not think every enjoyable task deserves protection from automation. But I am reluctant to call time spent making something wasted simply because there is now a faster route to the result. Work is also how we spend our attention, what we practise and the kinds of difficulty we find satisfying.
How our colleagues react matters as well. If the people we respect regard a new method as a shortcut, using it can make us feel less like one of them. Someone might privately admire what a tool can do while avoiding it at work because they do not want to be seen as less serious about their craft. Their own opinion of the technology is only one influence on the decision.
These changes happen at different speeds. A tool can be installed in an afternoon, and its basic operation learnt in a few days. Becoming confident in a changed role requires experience. People need to make decisions, see what follows from them and discover which parts of their earlier expertise still help. One successful attempt may be encouraging without being enough to trust themselves with the next difficult case.
Recognition takes time too. Colleagues may continue seeking the kind of help someone used to provide, while overlooking their newer contribution. A manager may praise careful review but still give the most interesting assignments to whoever produces work fastest. Until the new contribution earns respect repeatedly, it can feel like a temporary departure from the real job.
This can leave a person practising two roles at once. They are learning the new work while remaining the dependable expert in the old work. The more useful they have been, the harder it may be for the organisation to release them from those expectations. A training course cannot resolve that conflict.
This is why the passage of time tells only part of the story. Repeated attempts help when people can learn from them and change the conditions that made the work difficult. If they return to the same expectations and constraints each time, another year may leave them no better prepared.
The AI changes I am pursuing could affect precisely those sources of satisfaction. Some of the work we can delegate is work people chose this profession to do.
The changes I am asking for
Through an experimental lab in GovTech, I am exploring what these changes could mean in practice. We are looking at what happens when an individual, or a small team with different skills, uses AI agents, systems that can carry out tasks such as writing and checking code, to take on more of the work involved in building a product. That could extend from deciding what to build and writing the software to checking it and keeping it running.
The attraction is easy to understand. Someone with a useful idea might be able to take it further, with fewer handovers along the way. We are designing ways to test a role in which the person leading a product defines an acceptable result, gathers evidence that it works and takes responsibility for keeping it running. Specialist help and backup cover would be part of making that role workable.
A working product should be able to survive its creator taking a holiday. That is a useful test of what lies beyond a fast demonstration. Can a colleague understand the software and look after it? What happens when requirements change or something goes wrong? The person leading the work needs enough understanding to check it and seek help, while the team needs a way to share responsibility without leaving that person permanently available.
That could change where someone finds satisfaction in the job. Taking pride in the whole product might become more important than having personally made each part of it. The benefit to the organisation may be clear before we understand how demanding, or rewarding, that working day will be.
Some engineers may welcome that breadth. Others may prefer depth in a particular discipline. I do not yet know how much of that difference comes from unfamiliarity, and how much reflects a lasting preference for a different kind of work. The experiment needs to leave room to discover both.
A role can make sense on an organisational chart while being a poor fit for the person asked to do it.
AI reaches into the craft
I feel that tension most clearly when I consider my own attachment to programming. Would I still call myself a programmer if I wrote very little of the code? My first answer is yes. Understanding the problem, deciding how a system should behave and taking responsibility for it are substantial parts of programming. Yet that answer leaves something unresolved. Knowing that the contribution remains valuable does not guarantee that the daily work will feel equally satisfying.
I do not see much point in defending manual coding as a test of professional purity. I also do not want to pretend that producing a working system and enjoying the process of writing it are interchangeable pleasures. It is perfectly possible to appreciate the speed and miss the work.
That reaction is easy to mishandle. We tell the programmer they are being freed for higher-value activities. We may mean that their time can now produce more for the organisation, but that says little about which parts of the job they enjoy. The phrase offers little comfort if the supposedly lower-value activity was the part they loved.
Reviewing generated code brings its own difficulties. The solution may use an approach I would never have chosen, leaving me to work out whether its unfamiliarity hides a problem or simply reflects a different way of thinking.
There is substantial work in making that assessment. I need to understand what the software is supposed to do, what other systems it relies on and what could happen if it fails. Calling this a move towards judgement, creativity and strategy tells me little about what an ordinary Tuesday will feel like. It can sound suspiciously like a job description from which all the actual tasks have been removed.
Managers face their own adjustment. If someone junior can produce a persuasive analysis quickly, seniority becomes less reliable as a proxy for who has the best answer. Experience can still help distinguish a sound conclusion from an attractive mistake, but it has to demonstrate its value through that distinction.
The temptation is to restore familiar authority by controlling access, requiring unnecessary approvals or treating all machine-assisted work as suspect. The opposite temptation is to abandon judgement and celebrate output simply because it was produced quickly. Neither response helps people develop a respected, demanding practice around the tools.
For people entering the profession, there is a further difficulty. We are asking them to judge work that they may have had fewer opportunities to do for themselves. An experienced engineer can draw on years of trying things, finding mistakes and fixing them. If AI takes over much of that early work, a junior colleague needs another way to develop the understanding we expect them to use.
This is a question I do not think we can answer simply by telling people to review everything carefully. They need to learn what careful review involves. A team might ask a learner to explain how a proposed solution works, predict where it could go wrong and compare it with another approach before accepting it. An experienced colleague could then explore the reasoning with them. The exercise would reveal what the learner understands, even if generating the solution took only a few minutes.
That takes time from experienced engineers. If we count only the speed of today’s delivery, it will be easy to neglect the people expected to take responsibility for tomorrow’s systems.
Part of developing that judgement is learning when to challenge a proposed use of the technology. A person who identifies a privacy problem, a misleading result or an unacceptable failure rate is providing information. Calling every objection resistance to change makes the identity argument into a convenient way to stop listening.
This is where I put a limit on the identity explanation. The person slowing a rollout may be protecting an old role. They may also have found the failure everyone else has missed. The useful response is to examine the concern and establish what evidence would resolve it. If I want engineers to take responsibility for agent-generated work, I have to respect their willingness to question it, including when that questioning slows a result I want.
Making the new role worth having
If careful questioning is part of the work we want, people need to see that it counts in decisions about their careers. Otherwise the message to an engineer is confusing. Be thorough, but keep up with colleagues who appear to deliver much faster.
We need to recognise the engineer who spots that a requested feature would make the service harder to use, or catches a design mistake before the team builds more software around it. Making a product understandable enough for another team to take over matters too. These contributions are less visible than generating a large amount of code. If I celebrate speed at every opportunity and discuss quality only when something breaks, people will notice where my attention goes.
That recognition needs to reach decisions about promotion, assignments and how people spend their time. An engineer helping a colleague develop judgement should not have to explain it as a failure to produce enough of their own work. Someone who establishes that an experiment should stop has contributed, even if there is no launch to celebrate.
People also need opportunities to practise with help close at hand. For the roles we are exploring, we are considering a period of working alongside someone experienced before taking independent responsibility. That would let people talk through difficult decisions and gradually discover what they can handle themselves. For an experienced practitioner, being able to ask a basic question without putting their whole reputation on trial may be particularly valuable.
Practice needs clear boundaries when a live service is involved. Learning when to seek review or stop an agent is part of learning the role. I want the lab to help us understand what support a team needed, what remained difficult and whether someone else could repeat the work. Those lessons would give the next team more than a prototype to admire.
We also need to listen when the role is not working for someone. A broader job may turn out to be exhausting, or contain less of the activity they enjoy. Concern about employment or workload needs a concrete answer. It cannot be resolved by telling people to think differently about their identity.
I do not think leaders should require a performance of enthusiasm before offering help. Someone who misses doing the work themselves is giving us information about the job we are creating. We may be able to adjust the balance of tasks or find another application for their strengths. Where change is necessary, the disappointment still deserves to be heard.
Learning to be a beginner again
I keep thinking about the story of Gladwell’s father, a mathematician who approached problems with enjoyment and mischief. Before showing his son the expected way to solve a homework problem, he would explore an unusual way of doing it. He also tried things outside his expertise, including playing the piano and keeping bees, without needing to be especially accomplished at them.
What appeals to me about that story is its sense of enjoyment. Much of the discussion about change concerns what people might lose. His father’s example suggested something we might recover, the pleasure of trying without having to prove ourselves. Being good at one thing need not prevent us from enjoying being ordinary at another.
I would like there to remain some part of my working life where I can do that. There is a trap in becoming experienced. You grow accustomed to feeling competent and begin arranging your life around situations that preserve the feeling. Eventually, the desire to remain good at things can make you reluctant to begin anything new.
For my own work, curiosity means staying interested when an experiment gives an unwelcome answer. A role I favour may prove unworkable. Someone whose hesitation frustrates me may have recognised a difficulty I missed. I need to ask what support was missing and whether the work itself needs to change, without making the answer a verdict on my worth as a leader.
It is easy to admire adaptability while the change is happening to somebody else’s profession.
