Coupled to the Way Things Were

I worked on an enterprise commerce project for a large multinational company. Big ERP, many internal processes, many people who had been there a long time. And a change to a discount rule that, from the code side, looked like a few conditions and a test.

Here’s how that change traveled.

We’d align with leadership. Finance would ask for adjustments. We’d revise, go back to leadership, get approval, go back to finance. Then someone would remember that another area had to see it, and that area would find a constraint, often in the ERP, that sent the proposal back to the start. More meetings, more rework, the same feeling every time: we’d been here before.

The funny part is that nobody in that loop was doing anything wrong. Each step made sense on its own. The loop was the problem, and the loop had two halves: one in the organization, one in the software.

A company’s ability to change is a capability

Markets change. Technology changes, and lately it changes faster than most planning cycles. A company that sold through distributors decides it needs a B2B e-commerce channel. A company that ran everything inside its ERP needs to expose prices, stock and orders to a new digital front. None of this is exotic anymore. It’s the normal pressure on any large business.

What decides whether that goes well isn’t only budget or talent. It’s whether the company can still change. I’ve come to think of that as a capability, like any other. You can have it, you can lose it, and you usually notice you’ve lost it only when you need it.

In my experience, large companies lose it in two places at once.

How a system gets set in plaster

The first place is the architecture.

Take digitalizing an ERP-centered operation to sell B2B online. In a healthy system, that’s a new channel: it talks to pricing, customers, stock and orders through contracts, and those capabilities talk to the ERP through an integration.

In a rigid system, those capabilities aren’t separate things. Over the years, functions that should have lived apart, in their own services or at least their own modules, got stacked on top of each other. The discount logic knows about the customer’s credit rules. The credit rules read straight from ERP tables. The checkout assumes a specific order flow, which assumes a specific stock routine. Each layer leans on the one below.

Nobody designs that on purpose. It accumulates, one reasonable shortcut at a time, until the layers can’t be pulled apart anymore. And then a change that should touch one thing touches six.

That’s the architectural cost of rigidity, and it’s why I keep insisting on low coupling. Not because a diagram with separate boxes looks tidier, but because coupling decides how much of the system a single business decision drags along. A discount rule should be a pricing decision. If changing it means negotiating with the order flow, the stock routine and the ERP’s internals, then the architecture has turned a commercial decision into an excavation.

Low coupling has a cost too, and I won’t pretend it doesn’t. Contracts have to be designed and maintained. Integrations need owners. Some things get duplicated on purpose. It’s slower on day one. It pays off the first time the market asks for something the original design never imagined, and in my experience that day always comes.

The other half of the loop

The second place a company loses its ability to change is in people.

In a large company, many people have spent years, sometimes decades, working with the same rules, the same systems and the same paths for getting things approved. That experience is real and valuable. It’s also heavy.

What I saw, again and again, was resistance to changing how things were done. Proposals that seemed settled came back for one more discussion. Sometimes it felt like the project was being quietly boycotted.

I don’t think most of it was deliberate. My honest reading is that it was often subconscious: people protecting the way of working they knew, the one that had always worked for them. Inertia, basically.

It’s easy to get frustrated with that. It’s more useful to understand it. A rigid system and a rigid organization feed each other. When the software can’t change without a big risk, people learn to say no to change, and they’re often right to. When people say no long enough, nobody invests in making the software easier to change. The plaster gets thicker on both sides.

Forcing it from the outside doesn’t work

The natural reaction, when you arrive as part of an external team, is to push. You have the mandate, the plan and leadership’s support. Sometimes leadership can simply decide something, and that does move things. But pushing from the outside has a predictable effect: people become averse to the project itself. The more you force, the more the organization treats the change as something being done to it. In my experience, that’s one of the most reliable ways for a project not to move forward.

It’s worth thinking about why. A change imposed from outside asks people to give up what they know, in exchange for something they had no part in shaping, proposed by people who don’t know how the company really works. Put that way, the resistance makes sense.

What actually worked: change from the inside out

What made the difference on that project was finding people inside the company who were willing to change, and bringing them close to the work.

And I want to be specific here, because it’s easy to get this wrong: these weren’t necessarily the newest people. Some of the most important ones had been there for many years. They knew the internal flows, who decided what, which precedents existed and why a proposal would or wouldn’t fly. The difference wasn’t age or tenure. It was disposition. They were open to doing things differently, and they knew the company well enough to make it possible.

So we looked for those people, earned their trust and gave them a real part in the work. They’d tell us why something wouldn’t pass the way we had written it, and what would. They’d tell us who needed to be in a conversation before it happened, not after. They’d remember that something similar had been approved before, a kind of internal case law, minus the lawyers. With their support, we were able to move forward with more significant changes, and to innovate inside a structure that had resisted it.

It wasn’t a clean victory. Some proposals were postponed or dropped. In some places we accepted solutions we knew might hit limits later, and tried to build them so they could evolve. A pragmatic choice still carries a real cost, and leaving room to change it later doesn’t make that change free. It just makes it possible.

I also had to learn something less comfortable: that I needed those people more than they needed me. I was responsible for the technical side, but I didn’t understand the company. They did.

What I take from it

Two things, and they’re the same lesson seen from two sides.

In the software: protect low coupling. Keep business capabilities apart, put contracts between them, and don’t let the ERP, or any single system, become the place where every rule lives. The goal isn’t elegance. It’s keeping the company able to answer the next market change, the next channel, the next technology, without an excavation.

In the organization: don’t try to impose change from outside. Find the people inside who know the flows and want things to move, foster them, and build the change with them. It’s slower at the start. It’s the only version I’ve seen actually stick.

A system that can’t change and a company that can’t change usually come together. You have to work on both, and the second one starts with people.