Neural Natter

How individual judgement becomes organisational capability

What does a senior leader actually need to hold in their head?

A few weeks ago, I found myself sitting in a meeting staring at a piece of work that represented weeks of meticulous effort.

There were architecture diagrams, capability maps, system relationships, supplier dependencies, data flows and operating-model implications. Every risk, constraint and option you would expect to see in a substantial transformation programme had been explored. The work was not finished, but it was solid. It captured something genuinely important about a complex part of the organisation.

The situation we were considering involved several major changes happening at once. An established supplier relationship was ending. New logistics arrangements were being explored. A major enterprise platform was being introduced elsewhere in the organisation. Existing engineering systems remained operationally important but did not necessarily provide all the capabilities the future organisation would need. Financial processes, inventory, purchasing, supplier management and operational control all intersected.

Each strand made sense when considered on its own. The difficulty was that the organisation would eventually have to operate them as one connected system.

The architecture tried to make that system visible. It showed where information moved, where it stopped, where responsibilities crossed boundaries and where decisions could become trapped between teams. It exposed manual workarounds, supplier dependencies and assumptions about how the future organisation might function. It raised questions about what the organisation needed to own, what it could safely delegate and what information it would need if it were to remain accountable for operational outcomes.

I had expected these questions to generate a detailed discussion of the architecture. I anticipated challenge around system boundaries, integration choices, process assumptions and target-state design. I expected people to test the evidence, question the interpretation and debate the recommendations.

The discussion that followed completely caught me off guard.

It was not that people disagreed with the analysis or considered the work poor. Quite the opposite. The architecture was broadly accepted. The people in the room recognised the complexity and appeared to value the work that had gone into understanding it.

The surprising thing was that nobody seemed particularly interested in the architecture itself.

Instead, the room gravitated towards a different set of questions. One senior leader asked:

“What do I actually need to hold in my head?”

Another wanted a version that could be explained to people outside the room. Someone else moved the conversation away from systems entirely and back towards outcomes, ownership and decision-making.

They were not asking for more detail. They were asking what the detail meant.

As I listened, I realised something uncomfortable. The work was not struggling because it lacked information. It was struggling because it contained too much of it.

That did not make the detail unnecessary. Without the detailed work, we would not have understood the situation well enough to say anything useful. The maps, models and analysis were the foundations of the argument. They allowed us to see relationships that were not obvious when each programme, function and supplier was considered separately.

But the leaders in the room did not need to remember every relationship. They needed to know which distinctions mattered when they next faced a decision.

The real request was not, “Can you simplify the architecture?” It was, “Can you make the judgement behind it usable?”

I left the meeting with the strange feeling that the most valuable part of the work had not yet happened.

From analysis to judgement

For most of my career, I have assumed that organisations make poor decisions because they lack information.

That belief is understandable. When something goes wrong, one of the first questions is often whether the people involved possessed the information they needed. When a project fails, we look for missing requirements, incomplete analysis or inadequate reporting. When leaders make inconsistent choices, we often respond by creating more governance, better dashboards or additional documentation.

I have spent much of my career contributing to that machinery. I have written reports, designed systems, built dashboards, created governance packs, developed strategies and produced architecture. I have worked as a software engineer, product leader, founder, Chief Technology Officer, Managing Director and architect. In each role, part of the job involved making more of the organisation visible to itself.

Over time, however, I have become less convinced that information scarcity is the central problem.

Most large organisations are drowning in information. They possess reports, dashboards, presentations, plans, strategies, roadmaps, business cases, governance papers, risk registers, project documentation, meeting notes, performance measures and architecture repositories. New information is produced every day, often faster than anybody can absorb it. Every issue can generate another analysis. Every programme can create another governance pack. Every governance forum can request another report.

Information accumulates, but certainty does not.

The same questions return. The same risks resurface. The same decisions are revisited in slightly different forms. Teams can agree that a problem exists without agreeing who owns it. Several functions can each make rational decisions while the combined organisational outcome remains incoherent.

If information alone created good decisions, the best-documented organisations would also be the best-run organisations. That is not consistently what I have observed.

The harder problem is not obtaining information. It is transforming information into understanding, understanding into judgement and judgement into action.

That distinction has become increasingly important to me because information and judgement perform different jobs:

• Information tells us that two systems exchange data. Judgement asks whether the organisation has become dangerously dependent on that exchange.
• Information tells us that a supplier performs an activity. Judgement asks whether the organisation has also delegated the decisions necessary to remain accountable for the outcome.
• Information tells us that an operational platform experiences recurring capacity problems. Judgement asks whether adding capacity resolves the cause or merely postpones the next occurrence.
• Information tells us that a transformation programme contains workstreams covering purchasing, logistics, finance and supplier management. Judgement asks whether those workstreams collectively form a coherent operating capability.

Information can describe reality. Judgement determines its significance.

That significance is rarely found in one diagram, one data point or one expert opinion. It emerges from relationships. It comes from understanding how a decision in one programme changes the options available to another, how a supplier arrangement changes the organisation’s ability to intervene, or how a rational local choice creates an unacceptable outcome when combined with several other rational local choices.

The architecture had helped us see those relationships. The next task was to decide which of them the organisation needed to remember.

The five things that needed to travel

In the days following the meeting, I kept returning to the senior leader’s question.

What did they need to hold in their head?

Not what did they need to know in theory. Not which document should they read. Not which diagram should they recall. What small number of ideas would help them recognise the important decision when it appeared in another form, in another room, perhaps several months later?

The detailed analysis eventually became five decision principles.

1. Own the decisions, outsource the execution. The organisation might reasonably ask suppliers to source materials, move inventory, operate platforms or perform logistics. But outsourcing an activity is not the same as outsourcing accountability. Somewhere within the organisation, somebody must still understand which decisions affect aircraft availability, operational resilience, cost, compliance and risk. If those decisions are not explicit, the organisation can remain formally accountable while becoming practically unable to intervene.

That principle compressed a complicated set of questions about supplier responsibilities, internal capability and operational control. It did not prescribe one universal answer. It gave leaders a test to apply. When considering a future supplier arrangement, they could ask not only what the supplier would do, but which decisions the organisation still needed to understand, exercise and own.

2. Transform now or pay twice. A major supplier transition occurring alongside a significant enterprise-platform implementation creates a temporary opportunity. Existing inefficiencies can either be addressed while processes, responsibilities and systems are already changing, or they can be reproduced in the new environment and transformed later at additional cost.

The principle was not an argument for pursuing perfection. Large transformations always involve compromise. Nor was it an attempt to expand the scope of every programme until nothing could be delivered. It was a reminder that choosing not to transform during a major change is still a choice, and that the cost of that choice may only become visible after the programme has declared success.

A manual process copied into a new platform can still be called a successful migration. An unresolved ownership gap distributed across several new teams can still sit beneath a completed programme plan. A clumsy hand-off can still pass every deployment milestone. The programme may finish while the organisation inherits the transformation it postponed.

“Transform now or pay twice” gave leaders a way to recognise that risk while there was still time to decide consciously.

3. If you cannot see it, you cannot control it. In a distributed supply chain, visibility is not merely a reporting feature. The organisation needs to know what is happening quickly enough to intervene while intervention can still change the outcome.

Information that arrives after the operational consequence may support analysis, assurance or retrospective learning. It does not necessarily support control. A weekly report might reveal a pattern. A monthly dashboard might expose poor supplier performance. But neither helps if an urgent operational decision requires current information about stock, repair status, material availability or a developing exception.

This reframed the discussion about interfaces and data. Real-time or near-real-time visibility was no longer simply a technical preference. It became part of the organisation’s ability to remain operationally accountable.

The question ceased to be, “What integration pattern do we prefer?” It became, “What must the organisation be able to see, and how quickly, if it is expected to act?”

That is a decision a senior leader can carry. They do not need to remember every interface or data flow. They need to recognise when delayed or fragmented information is eroding the organisation’s practical ability to control an outcome.

4. Preserve choice. A supplier solution may work extremely well while also creating dependency. A bespoke integration may deliver immediate value while making future change expensive. A platform may solve today’s problem while narrowing tomorrow’s options.

Preserving choice does not mean refusing commitment. Every meaningful decision closes some options. Nor does it mean avoiding all supplier or platform dependency. Almost every operating model depends upon organisations, technologies and capabilities outside its direct control.

The judgement lies in understanding which dependencies are deliberate, which are difficult to reverse and which are being accepted without anybody quite noticing.

Short-term pressure has a habit of deciding the future by default. A deadline approaches. A supplier proposes a convenient route. A platform offers an expedient extension. An integration is created because it is the fastest available option. Each decision may be reasonable in context. Years later, the organisation discovers that what appeared to be a delivery decision was also a strategic commitment.

“Preserve choice” was therefore not a demand for theoretical purity. It was a request for conscious commitment. Which future options matter? What are they worth protecting? What dependency are we accepting? Under what conditions would we want to change direction? What are we doing now that might make that future change unnecessarily difficult?

5. Organise around outcomes. Systems, suppliers, programmes and departments provide convenient administrative boundaries. Operational outcomes rarely respect them.

If the important outcome is aircraft availability, responsibility may cross engineering, logistics, purchasing, finance, supplier management, inventory and technology. Optimising each component separately does not guarantee the result. A purchasing process can be efficient while the required material remains unavailable. A logistics provider can meet its contractual measures while the wider operation struggles. A finance transformation can apply consistent controls while creating friction in an engineering process it does not fully understand.

The problem is not that individual teams are necessarily doing anything wrong. The problem is that the outcome exists between them. Someone must understand how the parts work together, how decisions travel across the boundaries, where exceptions move and who intervenes when the normal process fails.

“Organise around outcomes” reminded leaders that the real unit of performance was not the system, programme, supplier or department. It was the operational result produced by their interaction.

These five principles did not replace the architecture. They depended upon it. Each was a compressed expression of detailed analysis.

But unlike the detailed analysis, the principles could travel.

A leader could use them in a supplier discussion. A programme could turn them into evaluation criteria. A governance forum could apply them when considering an exception. A technology team could use them to explain why a seemingly convenient integration created a longer-term concern.

The work had moved from describing the system to equipping people to make decisions about it. That shift still feels important to me.

The intervention recorded in 20260811_intervention_supplychain_principles was deliberately cautious about claiming success. The five principles had been created in response to the leadership discussion, but the evidence did not yet show that they had been formally adopted, embedded into supplier evaluation, used in governance or translated into changed organisational behaviour.

That caution matters because compelling language is not the same as organisational change. A principle only becomes valuable when somebody uses it to ask a different question, request different evidence, challenge an unsafe assumption or make a better decision.

The lesson was not simply that executives prefer concise material. The deeper lesson was that judgement must be converted into a form the organisation can carry.

Compression without losing the judgement

There is a danger in compressing complex analysis into a small number of memorable ideas.

Complexity can be removed so aggressively that the resulting statement becomes meaningless. A principle may sound powerful while being too broad to guide any real choice. It can become something everyone agrees with precisely because nobody is required to do anything differently.

Who would argue against owning important decisions? Who would deliberately choose to pay twice? Who would say they did not want visibility? Who would reject preserving useful options? Who would claim not to care about outcomes?

The words themselves are easy to endorse. Their value lies in what they require when applied to a real decision.

• “Own the decisions” matters only if the organisation identifies those decisions and names the people authorised to make them.
• “Transform now or pay twice” matters only if consciously deferred transformation is visible, costed and owned rather than disappearing into an unspecified future.
• “If you cannot see it, you cannot control it” matters only if the necessary visibility becomes part of readiness criteria, supplier expectations and operational design.
• “Preserve choice” matters only if leaders can identify which future options are valuable and what present choices threaten them.
• “Organise around outcomes” matters only if accountability, measures and intervention routes operate across functional boundaries rather than stopping at them.

The principles therefore needed to do more than summarise the analysis. They needed to preserve its critical distinctions.

That is the challenge of making judgement travel. Compress too little and the judgement remains inaccessible. Compress too much and it becomes a slogan.

The aim is not to preserve every fact. It is to preserve enough of the reasoning that another person can recognise when the principle applies, understand why it matters and know when to return to the deeper evidence.

A travelling decision principle should not eliminate further thinking. It should trigger it.

• It should cause someone in another room to pause and ask, “Are we outsourcing an activity here, or are we also losing control of the decision?”
• It should cause a programme leader to ask, “Are we consciously accepting this manual process, or simply recreating it because the deadline makes challenge uncomfortable?”
• It should cause a supplier discussion to include, “What information will we receive, at what speed, and will it arrive while we can still change the outcome?”
• It should cause a technology team to ask, “Is this integration merely convenient, or does it close an option the organisation may later need?”
• It should cause an executive to ask, “Are these teams individually on track while the end-to-end outcome remains nobody’s responsibility?”

When that happens, the principle has retained the judgement rather than merely retaining the words.

A travelling decision is not a travelling answer

The more I considered the five principles, the more I realised that what needed to travel was not a fixed answer.

The original situation was too complex for that.

The correct balance between internal capability and supplier execution might vary from one activity to another. The appropriate speed of information might depend on the operational decision being supported. Preserving one future choice might not justify its cost, while preserving another might be essential. Some existing inefficiencies might need to be transformed immediately, while others might rationally be accepted to protect a critical delivery date.

The principles could not decide those questions in advance. What they could do was preserve the basis upon which the questions should be judged.

That may be the crucial distinction.

Organisations often try to scale good practice by standardising answers. Templates are created. Processes are mandated. Controls are introduced. Approved patterns are documented. This can be effective where the situation is sufficiently repeatable.

But complex organisational decisions are rarely identical. Context changes. Constraints move. New evidence emerges. The same answer applied mechanically may produce a worse outcome than a different answer reached through a consistent decision process.

If judgement is to travel, the organisation may need to transmit not only what was decided, but what mattered when reaching the decision.

In the supply-chain example, the five principles did not say which supplier to select, which platform to implement or which operating model to adopt. They preserved five dimensions of judgement:

1. Decision ownership
2. Timing and the cost of deferral
3. Visibility and operational control
4. Reversibility and future choice
5. End-to-end outcomes

Those dimensions could be applied repeatedly without pretending every future situation would have the same answer. That made the principles more durable than a single recommendation.

They were not conclusions to be copied. They were lenses through which future decisions could be examined.

Judgement begins to travel when the originator is absent

There is a simple test for whether judgement has become organisational rather than personal.

Can it still influence the decision when the person who formed it is not in the room?

While I was present, I could explain the diagrams. I could trace the dependencies. I could describe how a supplier choice interacted with an enterprise-platform programme. I could defend the interpretation, answer questions and add missing context.

That was useful, but it was not scalable.

If every future decision depended upon me reproducing the full argument, then the judgement had not travelled. It remained attached to the individual who did the analysis.

This is a familiar problem in organisations. Certain people become known as the ones who understand how things really work. They remember the history, know which apparent constraints are genuine, recognise why a previous decision was made and can anticipate where an exception is likely to surface.

Their value becomes obvious whenever they are present and painfully obvious whenever they are absent.

The organisation may believe it possesses that capability because it employs those people. In reality, it may possess a dependency upon them.

Making judgement travel is therefore partly an act of organisational resilience.

It does not require extracting everything an experienced person knows. That would be impossible. Much professional judgement is contextual and partly tacit. It develops through exposure, repetition, reflection and consequence.

But the organisation can capture the critical distinctions that repeatedly guide that person’s decisions. It can make assumptions visible. It can preserve the questions that reveal hidden risk. It can record why an apparently attractive option was rejected. It can identify the conditions under which a previous judgement would no longer apply.

The goal is not to replace experienced judgement with a checklist. It is to give the next person a better starting point.

A good principle carries enough accumulated experience to help somebody recognise the shape of a decision they may not have encountered before.

The database problem that was not only a database problem

Another situation helped me understand the same idea from a different angle.

A recurring production database-capacity issue required tactical movement of data between tablespaces. The immediate technical response was understood. Capacity pressure could be relieved and the operational platform could continue functioning. The intervention mattered because the platform was important and immediate stability could not wait for a perfect strategic answer.

But everybody involved also knew that the work would need to be repeated.

There was a broader question about retention and archiving. How much information needed to be kept? For how long? What business, operational or regulatory purpose did it serve? What could be archived? What consequence would that create? Who was authorised to accept the trade-off?

Those were not database questions.

The technical team could explain the available mechanisms. Architects could describe dependencies and consequences. Suppliers could advise on platform behaviour. But none of those groups necessarily owned the business judgement about information retention.

The interesting part was the distinction between recognising a problem, knowing how to relieve it and identifying who possessed the authority to decide the underlying trade-off.

The organisation already possessed considerable information. It knew that the capacity intervention was recurring. It knew that a more strategic archival approach was required. It knew that business acceptance would be necessary.

What had not travelled clearly enough was the ownership implication:

Technical teams can manage the consequence of information growth, but they cannot decide the business value, obligation or acceptable risk of retaining the information.

When I tried to move the discussion towards retention ownership and information-lifecycle accountability, the response gravitated towards governance mechanisms and architecture decision records. Those mechanisms might have helped, but they did not, by themselves, answer the ownership question.

That experience reinforced another important distinction:

A decision can travel into a forum without travelling to an owner.

A governance forum can discuss a problem. A decision record can document an outcome. A technical team can implement an action. None of those things necessarily establishes who is accountable for the underlying judgement.

The observation recorded in 20260813_observation_process_ownership remained deliberately cautious. It acknowledged that an accountable owner might already have existed outside the visible discussion, that governance might have been intended to establish ownership, and that immediate operational priorities might have justified postponing the wider decision. What was clear was that the tactical response could proceed while ownership of the retention and archival judgement remained less visible.

The lesson was not that tactical remediation was wrong. Stabilisation was necessary. The lesson was that the strategic judgement also needed a form in which it could travel beyond the technical conversation.

Not simply: “The database keeps filling up.”

But: “The organisation is repeatedly managing a technical consequence of an unresolved business decision about information retention.”

That sentence changes the destination of the conversation.

It no longer asks only what the database team should do next. It asks which accountable owner must determine what information the organisation requires, what it is obligated to retain and what trade-off it is prepared to accept.

The technical facts have not changed. The problem has become decision-shaped.

From personal insight to shared language

This may be one of the simplest ways individual judgement becomes organisational capability.

First, somebody notices something. They see that several apparently separate workstreams are creating one connected operating model. They recognise that outsourcing activity may also be moving decision capability. They notice that delayed information changes control, not merely reporting. They see that a recurring technical remedy depends upon an unmade business decision.

At this stage, the insight may exist only as discomfort. Something does not fit. The proposed answer seems to solve the visible problem but not the underlying one. The organisation appears busy, but the outcome remains vulnerable.

The next step is interpretation. The individual has to work out what they are noticing and why it matters. That requires evidence, challenge and a willingness to consider that the initial concern may be wrong.

In the supply-chain case, later cross-domain examination did not reveal one catastrophic missing capability. It revealed a more nuanced picture: substantial work was already happening, but assumptions across supplier onboarding, supplier evaluation, price books, financial treatment, stock visibility, asset tracking, reporting and analytics still required validation. The concern became more precise rather than more dramatic.

That recalibration is an important part of judgement. If an idea is to travel safely, it must carry its uncertainty as well as its conviction.

The third step is translation. The insight has to become intelligible to people who did not perform the analysis and may not share the same professional language. This does not mean removing complexity merely to make the situation comfortable. It means identifying the critical distinctions that another person must understand to make a responsible choice.

The fourth step is application. The principle must be attached to a real decision, not left as an attractive statement. Somebody must use it when assessing a supplier, designing a control, accepting a compromise, determining readiness or assigning ownership.

The final step is adoption. The principle begins to travel without the original author. Other people use it accurately. They adapt it to new circumstances. They challenge it with new evidence. They know when it applies and when it does not.

At that point, the organisation has gained more than a document. It has acquired a small piece of shared judgement.

The danger of confusing agreement with travel

One reason this is difficult to evaluate is that organisational agreement can look very much like adoption.

A senior audience may praise the clarity of a principle. A steering group may accept a set of recommendations. A supplier workshop may include the language in its materials. A governance pack may reproduce the five headings.

None of that proves the judgement has travelled. The words may travel while the reasoning remains behind.

• “Preserve choice” may appear in a presentation while the organisation approves a deeply constraining bespoke arrangement because nobody translates the principle into evaluation criteria.
• “Own the decisions” may be endorsed while decision rights remain implicit and suppliers continue making choices the organisation is formally accountable for but practically unable to influence.
• “Organise around outcomes” may be repeated while funding, measures and accountability remain aligned to individual departments and programmes.
• “If you cannot see it, you cannot control it” may be accepted while delayed reporting is treated as sufficient because the distinction between retrospective visibility and operational intervention has been lost.

This is why the moment after translation matters as much as the translation itself.

A principle becomes organisational only when it enters the machinery of decisions.

• It changes the question asked in a meeting.
• It changes the evidence requested from a supplier.
• It changes the acceptance criteria for operational readiness.
• It changes the allocation of decision rights.
• It changes the conditions attached to an approved exception.
• It changes which risks are accepted and by whom.
• It changes what the organisation chooses not to do.

Without this, the language has travelled but the judgement has not. The organisation may sound wiser while behaving exactly as before.

A decision principle needs an evidence trail

There is another balance to strike.

If a travelling principle is separated completely from the evidence that produced it, it can become dogma. People may repeat it because it sounds authoritative, even when the context has changed.

The principle therefore needs a route back to the deeper reasoning.

• A leader should be able to ask why a particular decision must remain internal and see the operational, regulatory or commercial consequence behind that judgement.
• A programme should be able to challenge whether near-real-time visibility is genuinely required for a particular decision, rather than adopting it as a universal technical demand.
• A team should be able to show that a dependency is acceptable because the value of the arrangement outweighs the cost of reduced optionality.
• A governance forum should…