The Code Beneath the Strategy

The Missing Domain, Part 5

On the 1st of January 2021, the United Kingdom’s border changed overnight.

What had been a relatively contained set of entry points — ports and airports handling arrivals from outside the European Union — became something significantly larger. The expansion of border check requirements following Brexit increased the number of operational entry points by approximately 300%. The services that had existed to process arrivals from the rest of the world now had to be redesigned, scaled, and redeployed across a far wider geography, in a compressed timeline, with no margin for a phased transition.

I was part of the architecture work that preceded that date.

The operating model we designed was, by any conventional standard, correct. The capability analysis was thorough. The process architecture was mapped. The critical services were identified and sequenced. We produced, in record time and under significant political pressure, a model that was internally coherent and technically sound.

We also produced a set of Standard Operating Principles to govern how it would be implemented and run.

What happened at rollout was not what the model anticipated.

When the gaps in the Standard Operating Principles surfaced — and in a design produced at that speed, gaps were inevitable — the staff on the ground did not wait for clarification from the centre. They did not escalate through the governance structure the model had specified. They did what organisations under pressure have always done: they reached for the code they already knew. The pre-existing patterns of judgment, the informal protocols, the ways of handling situations that the formal model had not addressed. The designed architecture held where the Standard Operating Principles reached. Where they ran out, the organisational code took over.

I have thought about that pattern many times since. Not as an implementation failure — though it was partly that — but as a precise demonstration of something the discipline has spent four articles in this series refusing to name.

When the cortex meets the code

Clotaire Rapaille, the cultural anthropologist and business adviser, made a distinction that is more useful to practitioners than most of the culture literature produced by management academics. He argued that human behaviour is governed by three layers: the cortex, which processes rational meaning; the limbic, which processes emotional meaning; and what he called the reptilian, which operates beneath both and is governed by deep cultural imprinting — the code.

The cortex explains. The reptilian decides.

When a designed operating model is presented to an organisation, it is almost always presented at the cortex level. Here is the capability architecture. Here is the process map. Here is the governance structure. Here is what we are trying to achieve and why it is logical. The leadership understands it. The steering committee approves it. The Standard Operating Principles are signed off.

And then the pressure comes. A gap appears. A situation arises that the formal model did not anticipate. And in that moment, the cortex model is not what the individual reaches for. They reach for the code: the deep, imprinted set of responses that tells them what to do when the designed answer is not available.

Rapaille was writing primarily about consumer behaviour and brand strategy, not operating model design. But his central observation holds with uncomfortable precision in transformation contexts: when rational design conflicts with deeply imprinted cultural code, the code wins. Not because people are irrational. Because the code is faster, more certain, and more trusted than any document produced by a team they have never met, working to a timeline the organisation never chose.

This is not a change management failure. It is an architectural blind spot.

Edgar Schein, whose three-layer model appeared in Article 3 of this series, would recognise the Brexit pattern immediately. What activated at the border, when the Standard Operating Principles ran out, was not the artefacts layer or the espoused values layer. It was the basic underlying assumptions layer: the deep, unexamined beliefs about how this work is actually done, who has authority in ambiguous situations, and what the right response is when the formal answer is not available. That layer was never mapped, never assessed, and never made part of the design.

Geert Hofstede would add a further dimension. His research on cultural dimensions — including power distance and uncertainty avoidance — suggests that organisations with high uncertainty avoidance respond to ambiguous situations by creating local rules rather than escalating upward. The instinct to reach for the familiar code, rather than wait for central guidance, is not a failure of compliance. It is a predictable response to a particular cultural profile, one that any architecture engaging with a distributed operational workforce should have assessed before a single process was mapped.

Three frameworks. Three independent research traditions. All pointing to the same blind spot in the same direction. And all three converging on the same practical implication: a capability that is technically defined but culturally incompatible will not perform — no matter how accurately it is mapped.

The invisible dimension of every capability

A capability can exist on paper and still not perform.

The process is defined. The technology is deployed. The people are trained. The governance is specified. And yet the behaviour does not shift. The organisation continues to operate in ways the model did not design. Not because the model is wrong, but because something it never measured is overriding it.

That something is cultural readiness: the degree to which the cultural code of the organisation is compatible with the behaviour the designed model requires.

Every capability assessment produced in BA practice today covers some combination of technology maturity, skill availability, and process quality. None of them, as far as I am aware, includes a cultural readiness dimension. None of them asks: is the code the organisation runs on compatible with the capability this model assumes? And if not, what is the translation cost?

In the Brexit context, the capability existed. The people were qualified. The process was documented. The cultural readiness dimension — the question of whether the code of a distributed operational workforce would accept, and operate within, a centrally designed compliance architecture — was not part of the assessment. The answer to that question surfaced at rollout, in the gaps, in the pattern of staff reaching for what they already knew.

An architecture that had mapped the cultural code before mapping the capability would have produced a different design. Not a different capability model, necessarily. But a different adoption strategy, a different training approach, a different governance structure — one that accounted for the translation work required to move the organisation from its current code to the behaviours the model assumed.

Mapping culture first: a practical proposal

This is where the series argument becomes a proposal rather than a critique.

The four preceding articles have established the following. The discipline is systematically silent on culture. The silence is not a technical limitation but a choice, enabled by the absence of professional norms that would make naming the cultural dimension part of the role. The empirical frameworks to do it exist and have been ignored. The cost of ignoring them is paid in capability maps that are technically correct and practically inert.

The proposal is simple in principle and demanding in practice: culture should be the first component assessed in any architecture engagement. Before the capability map. Before the value stream model. Before the operating model design. Before the process architecture.

Not instead of those things. Before them.

The question of cost will arise, and it deserves a direct answer. A structured cultural discovery phase adds time to the front of an engagement. In most cases, it removes significantly more time from the back — the time spent redesigning deliverables that did not land, reframing recommendations the organisation could not absorb, or explaining to a sponsor why a technically correct capability map is sitting unused in a presentation folder. The Brexit engagement produced an accurate model at speed. The cost of not assessing the cultural code was paid at rollout, not at design.

In practice, a cultural discovery phase means asking three questions before the first canvas is drawn.

The first: what is the organisation’s code? Not what it says its values are, but what the patterns of behaviour under pressure actually reveal. Schein’s artefacts layer is the starting point: how are decisions made, how is conflict handled, what gets rewarded and what gets quietly tolerated? This is observation. Architects already do this informally. The discipline needs to formalise it and include its outputs in the artefact set.

The second: where is the code in conflict with the designed model? Every proposed operating model makes assumptions about how people will behave. Those assumptions need to be tested against the observed code before the design is finalised. The conflicts that surface at rollout are almost always visible at design stage, if anyone has asked the question.

The third: what is the translation cost? Moving an organisation from its current code to the behaviour the model requires is not free. It takes time, deliberate intervention, and frequently requires the design to accommodate the code rather than assuming the code will accommodate the design. Naming that cost before the project starts is not pessimism. It is architectural accuracy.

None of this requires a separate workstream. It requires a different starting point and a different first question. Instead of: what capabilities does this organisation need? The first question becomes: what code is this organisation running, and what will it take to implement a model that either works with that code or explicitly plans to change it?

That question, asked before the first canvas is drawn, would change the character of every engagement in this discipline.

The close

This series began with the observation that business architecture maps almost everything an organisation contains — capability, process, information, technology, structure — and leaves out the one component that determines whether the map ever becomes reality.

It has spent five articles making the case that the omission is not innocent.

The discipline has the frameworks it needs. Schein has been in the management literature since 1985. Hofstede’s cultural dimensions have been applied in organisational contexts for four decades. Rapaille’s code framework contains a precise description of exactly what happens when a rationally designed model meets a culturally imprinted workforce and loses. None of these are obscure. The profession has simply chosen not to look.

The Brexit border engagement produced an operating model that was technically sound and built under conditions that would have tested any design. The gaps that surfaced at rollout were not in the capability model. They were in the assumptions the model made about the code the organisation was running. Those assumptions were never tested because the discipline has no standard phase for testing them.

That is the final argument of this series. It is also its call.

If you lead architecture practice in your organisation: build the cultural discovery phase into your methodology. Make it the first conversation, not the absent one. The three questions above are a starting point, not a complete answer — but they are sufficient to change what an engagement produces.

If you commission architecture work: require a cultural discovery phase as a condition of the engagement, not an optional addition to scope. Before a single canvas is drawn, the team should be able to describe the code the organisation is running and where it conflicts with the model they are about to design. If they cannot, the engagement is not ready to begin — and you now know what to ask for.

If you are the architect who has been in the rooms this series has described — who has seen the enacted culture and chosen not to name it, who has heard the intangibility defence and let it stand, who has presented the Espoused culture to a sponsor whose Enacted culture was doing something entirely different — this is not an accusation. It is an acknowledgement that the profession has made the honest path structurally difficult, and a proposal that it does not have to stay that way.

Culture is not the soil in which architecture grows. It is the architecture that was already there before you arrived.

Your job is to understand it before you try to replace it.