The System You Are Afraid to Change Is Already Changing You
Waiting looks safe. It just moves the risk somewhere you cannot see it.
There is a decision every technology leader makes more than once. A dependency sits underneath something important. Nobody fully understands why it behaves the way it does. The safest looking choice is to leave it alone and build carefully around it instead.
That decision is never free. The budget for it is never approved by anyone. It shows up later, in an audit finding, a vendor invoice nobody expected, a customer complaint that takes three teams to trace back to a system nobody had touched in years. The cost does not disappear because the decision was never written down. It just waits for someone else to find it.
What Changes While You Wait
Three forces reshape a system while its owner hesitates, and none of them ask permission first.
The first is the workaround. Every quarter a system stays untouched, someone builds around it instead of through it. A spreadsheet becomes the reconciliation. A vendor tool becomes the record for a class of work the original system was meant to handle. Nobody calls it architecture at the time. However, when the next transformation gets scoped, the spreadsheet is in the critical path, and the vendor tool cannot be removed without a project of its own.
The second is memory. The people who understood why a system looks the way it looks are retiring, moving on, or simply forgetting. What one generation held as tacit knowledge becomes what the next generation cannot recover at any price.
The third is newer, and harder to see coming. AI is being embedded into systems whether their owners sanctioned it or not. Vendors ship it as a feature update. A workflow tool starts making decisions nobody in compliance was asked about. Most institutions, asked today which of their vendors use AI, on what data, and who is accountable for the outcome, cannot answer with confidence.
Immobility does not protect a system. It reshapes it, without you in the room.
What Deliberate Change Looks Like
Two of Amazon’s own 2025 decisions are worth examining closely, not simply admired.
The company rebuilt the inference engine behind Bedrock, a system it named Mantle, using a small team working to a bounded scope rather than a large one working to an open brief. Amazon says the original estimate was forty engineers over a year, and that six delivered it in seventy six days. I take a number like that with real caution, especially arriving in the same season as headlines about reduced corporate headcount. What holds up under closer reading is not the multiple. It is the design choice sitting underneath it. Mantle was built with zero operator access, meaning there is no technical path for an Amazon engineer to reach the customer data running through it. That is a governance decision built into the architecture itself, not a policy written down and hoped for.
That same year, Amazon rearchitected Alexa, a decade old system serving six hundred million devices, moving it from scripted commands to something able to plan and act across tens of thousands of services using large language models. The hard constraint was never the model. It was doing this without breaking a single existing partner integration, and without missing the two second response window a voice assistant needs to feel instant rather than sluggish. Bedrock and Alexa+ share the same shape. Decide what must not break. Bound the scope around that decision. Then move.
Banking has its own version of this story.
In 2014, Piyush Gupta watched Alibaba issue loans and move money for millions of customers with no branches at all. He chose not to build an innovation lab beside DBS and leave the rest of the bank untouched. He chose to change how the whole institution worked, starting with culture, not with a system.
The clearest evidence of that choice was not a piece of technology. It was a format DBS called Process Improvement Events. Two hundred and fifty of them were run over the following years. Each one pulled the people who actually did the work, across functions, into a room for three days. Day one was spent mapping the process as it actually ran, not as anyone assumed it ran. By day three, the redesigned process had the sign off of whoever could actually approve it, sitting at the same table, rather than waiting on a steering committee that met once a quarter. Outsourced development gave way to an in-house engineering organisation over the same period, growing from fifteen percent of technology staff to eighty five percent within a decade. Both changes point to the same underlying decision. The transformation ran through ownership and authority long before it ran through any platform.
By 2019, Harvard Business Review had named DBS one of the ten most transformative organisations of the decade. Euromoney named it World’s Best Bank more than once.
A separate finding about DBS deserves space of its own, not as a rebuttal to the story above. Between 2021 and 2023, DBS suffered a run of digital banking outages. Singapore’s regulator raised the bank’s additional capital requirement for operational risk to 1.8 times risk weighted assets, roughly one point six billion Singapore dollars by MAS’s own account, and paused non essential IT change for six months while DBS rebuilt its recovery capability. Further disruptions followed in 2025 and into 2026.
I am not claiming the transformation caused this. I have found no evidence that it did, and no one else appears to have found any either. The finding says something narrower. Operational resilience is its own discipline, built and renewed on its own timeline, never a by-product of cultural change or a well-earned award.
Reinventing an institution and keeping it resilient are two different disciplines. Progress in one does not finish the other.
That discipline holds whether an institution transforms or stays still. The real choice was never between risk and no risk. It is between the risk of standing still and the risk of moving, and resilience has to be built for either one.
The Pattern I Know From the Inside
I have made the safe looking choice myself, more than once, in different roles, on different systems. The shape is always the same. A dependency looks too fragile to open. The blast radius feels unclear enough to justify waiting. So I waited.
The system never waited with me. An unrelated event, a vendor decision outside my control, a platform consolidation nobody had scheduled around my caution, forced the change anyway. What I believed I had protected by waiting turned out to be a problem I had only postponed and made more expensive in the meantime. The risk I thought I was avoiding did not disappear. It went underground, and it grew there, quietly, until something else finally forced it into the open.
Therefore the honest question is not whether a system is too risky to touch. It is who gets to decide when it changes, and on what terms.
Someone always pays for the years you waited. It is rarely the person who chose to wait.
The system you are afraid to change is not standing still while you decide. It is already choosing, without you.
If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.