The Absence of Method Is Worse Than an Imperfect Method

In one of the organizations I worked in, every attempt to introduce more structure met the same response, spoken or not: "We're different." Formal processes? Doesn't fit our culture. Standardization? Might slow us down. Documentation? Whoever needs to know, already knows. Remote work? Here, things run differently. Org charts, accountability, an operating model? Interesting, but reality is more complex than that.

For a long time I found that certainty almost fascinating. Then I started seeing the problem in it.

There is no such thing as no method

No organization runs without a method. If you don't have an explicit one, you have one anyway — built from the habits of the most influential people, from organizational memory, from exceptions accumulated over time, and from a growing set of unwritten rules everyone gradually learns. And this can work. It can even work very well. The problem shows up when you need to scale.

When "the person who knows" becomes the architecture

I remember how hard it was, in that environment, to reconstruct something as basic as a complete, accessible org chart. Who's accountable for what? Where does one function's responsibility end and another's begin? Who actually makes a given decision? Often the answer wasn't in a system or a document. It was a person. "Ask him." "She knows how it works." "That's handled by so-and-so." "You'll need to call someone for that."

This can look remarkably agile. In reality, you've already built a process — it's just a process based on memory. And organizational memory has a very specific limit: it doesn't scale as fast as the organization does. When knowledge lives mostly in people, physical proximity becomes part of the infrastructure. Seen this way, some of the debate around remote work looks different. The need for people to be physically present doesn't always come from the nature of the work. Sometimes it comes from the fact that the organization's real operating model is made of hallway conversations, personal relationships, and knowing who to call. In that case, remote work doesn't just threaten a culture. It makes visible an organizational architecture that was never actually formalized.

Legacy doesn't mean obsolete

The same logic applies to technology. I've worked with core systems built on technology decades old — CICS, for instance, dates back to the late 1960s and still runs mission-critical workloads in a great many organizations today. Old doesn't automatically mean bad. The problem isn't the age of the technology. It starts when decades of customization, exceptions and implicit knowledge get layered on top of a long-lived platform. A component exists because someone needed it twenty years ago. An interface exists because a process once required a workaround. Another application solves one very specific need. Every individual decision may have been perfectly rational at the time it was made. But twenty years later, nobody can easily see the system anymore. They see the layers. Call it technological archaeology — and before you demolish it, you need to understand it. But you also need the courage to ask when the stability of the past has started becoming the cost of the future.

When IT becomes an order taker

This leads to another pattern I've seen more than once. IT can be extremely close to the business and, at the same time, not very strategic. It happens when a request comes in and the first question is "When do you need it by?" instead of "What problem are you actually trying to solve?"

The pattern is easy to recognize. The business asks for something. IT builds it. A customization is born. The customization needs integrating. The integration needs maintaining. Maintenance introduces dependencies. Dependencies produce incidents. Incidents require experts. The experts become indispensable. And the organization rightly celebrates those experts when they save the day. The problem is that, gradually, the heroics needed to manage the complexity become the apparent proof that the model works.

A technology function that is a genuine business partner also needs to be able to say: "We're not building this." "We already have that capability." "Let's change the process instead." "Let's standardize." "This exception costs little today, but in five years we'll be paying for it daily." That's demand management. Not simply collecting requests.

Demand management, or request management?

In that organization, demand management — and a meaningful part of what was called digital transformation — sat inside an HR function. I don't think a function's position on the org chart makes it right or wrong on its own. What matters is capability. Genuinely qualifying a piece of demand requires business understanding, technology, architecture, economics and the ability to weigh the operational consequences of a decision, all at once. Without that combination, demand management quietly turns into request management: a need arrives, gets formalized, becomes an initiative, and someone builds it. "Internal consulting," in that setup, risks becoming a strange kind of expression — consulting that organizes demand without necessarily having the depth to actually question it.

That's how digital transformation can produce a paradoxical result. A new need. A new report. Then a dashboard. Then Power BI. Then another Power BI dashboard, because another function wants to read the same data slightly differently. Each dashboard answers a question. Few of them change the system that keeps generating that question. Transformation becomes the digitization of exceptions.

When the leader becomes the method

When the system isn't explicit enough, something has to replace it — and very often, that something is leadership. Not always in the best sense of the word. If the process doesn't decide, the person decides. If accountability isn't clear, what counts is who has enough authority to force a direction. If the model doesn't create predictability, the executive's presence does.

This can give rise to a very muscular kind of leadership. Highly visible. Highly assertive. Centered on control, sometimes almost theatrical. The executive ends up performing the role of executive: has to know everything, has to intervene, has to have the last word, has to be present, has to project certainty even when a question might be more useful. This style can be remarkably effective in some circumstances — especially in organizations that are relatively small, stable, and tightly bound to a handful of people. But it has a ceiling, because leadership doesn't scale through personality. It scales through systems, standards, delegation and other leaders.

The real problem with generational change

This is where the issue widens. Any organization built heavily around people, relationships and implicit knowledge eventually has to face a question: what happens when those people change? Generational change isn't simply replacing a sixty-year-old executive with a forty-five-year-old one. It means transferring organizational capability. If a large part of that capability lives in people rather than in the system, the handover becomes far harder. New leaders first have to understand the folklore — who really matters, the unwritten rules, why certain things are "just done this way here." And there's a strong temptation at that point: instead of changing the system, they learn to play the same character. That's how organizational cultures can outlive the people who built them.

The limit of scalability

None of this means the organization doesn't work. Quite the opposite — an implicit model can work extremely well. It can produce growth, build a powerful identity, develop extraordinary capability, and generate strong financial results for decades. But success and scalability are not the same thing. A system can remain profitable even as its ability to produce new growth from the same model becomes progressively less evident.

A public benchmark from a large European retailer illustrates the point well. In a recent reporting period, total sales grew by roughly 1%. Look one level down, though: average prices had risen, volumes had fallen, and the store network had kept expanding. The company doesn't publish a true like-for-like figure, so it would be wrong to invent one — but the question is still worth asking: if total revenue grows slowly while prices rise, volumes fall, and new commercial capacity keeps getting added, how much is the existing base actually growing? We can't answer that precisely. That's exactly the point — headline growth doesn't necessarily equal organic growth of the existing model.

Over the same period, profitability improved significantly. Public disclosures pointed to cost containment, workforce optimization, a review of some commercial and loyalty levers, and headcount reduction. All of it perfectly legitimate — recovering margin is a real financial achievement. But it raises a different management question: how much of the improved performance came from making the system more capable, and how much from extracting more efficiency out of the existing one? Those are two different things. The second can be very effective. It isn't infinite. You can cut a cost. You can revise a loyalty program. You can raise a price. You can open a new store. You can streamline a structure. But sustainable growth requires the system itself to become progressively more capable — simpler, more delegable, more legible, more repeatable. This is usually where an implicit model starts showing its limit.

An operating model can remain profitable long after it has started to become difficult to scale.

The real advantage of an imperfect method

This might be the most important lesson I've carried from that experience. A method can be mediocre. It can be bureaucratic. It can be full of unnecessary meetings, too heavy, badly designed. But it has one fundamental advantage: you can see it. You can measure it. You can criticize it. You can change it. You can decide a part of it doesn't work and replace it.

The absence of method is far more insidious, because the method still exists — it has just become invisible. It's in the habits. It's in the power dynamics. It's in the memory. It's in the executive who "has always done it this way." It's in the application nobody dares touch. It's in the process nobody ever wrote down. It's in the answer: "We're different." And once a model becomes identity, questioning it gets read as questioning the organization itself — which makes change enormously harder.

Being different isn't enough on its own

I don't think every company should use the same frameworks. That would be absurd — every organization has a different history, market, culture and set of constraints. Method isn't there to make everyone the same. It's there to make how we choose to be different intentional.

So today, when I hear "it doesn't work that way here because we're different," a second question comes naturally: different from what — and is that difference still helping us? The absence of method can look like freedom. It can look like pragmatism. It can even look like speed. Until the day the organization gets too big for memory, heroics and personality to keep substituting for the system. And at that point, an imperfect method still has one enormous advantage over no method at all: it can be improved.

Different from what — and is that difference still helping us?