The recommendation nobody acted on

The three arguments published alongside this one were written independently, about different domains, for different audiences. They arrive at recommendations that share a structure, and the shared structure is the subject of this document.

The operational technology argument asks an operator to accept that the inbound pathways accumulated over a decade were each approved by somebody, and that the total was never anybody’s document. The agentic systems argument asks an institution to adopt refusal by default when an approval path is unavailable, which means accepting that a system built for availability was built to the wrong preference. The cloud spend argument asks an organisation to attach an owner to every line on an invoice, which surfaces, item by item, how much of the estate nobody could account for.

None of those three is intellectually difficult. Each of them requires a named person to say, in front of colleagues, that something they approved or ran or signed for is not what they believed it was. That is the actual work, and it is the part no architecture diagram contains.

It would be convenient to treat this as a separate discipline, to be handed to a communications function once the technical position is settled. The argument here is that this is precisely the wrong sequence, and that the conditions under which a recommendation can be acted on are a design constraint on the recommendation itself.

The sociologist Ron Westrum published a typology of organisational cultures in a patient safety supplement of Quality and Safety in Health Care in 2004. His claim is narrow and useful: because information flow both influences performance and indicates other aspects of culture, it can be used to predict how an organisation will behave when signs of trouble arise. He sorted organisations into three kinds, distinguished by what happens to the person carrying the bad news. In a pathological organisation, messengers are punished. In a bureaucratic one, messengers are neglected. In a generative one, messengers are trained.

The row worth sitting with is the one about failure. Under a pathological culture, failure leads to scapegoating. Under a bureaucratic culture, failure leads to justice, which sounds acceptable until you notice that justice means establishing who was at fault. Only in the third case does failure lead to inquiry. An organisation can be scrupulously fair, follow every procedure, and still be one in which nobody volunteers a problem early, because the reliable consequence of raising one is an investigation into who caused it.

This matters here for a reason specific to the subject matter. Westrum was writing about safety, in aviation and healthcare, where the cost of an unreported anomaly is measured in lives. The finding was later carried into technology by the DORA research programme, which reports that a high-trust, generative culture of the kind Westrum describes predicts software delivery performance and organisational performance. So the claim is not that pleasant workplaces are more productive. It is that the handling of bad news is a property of a safety-critical system, established in the literature of safety-critical systems.

It is also measurable, which is what separates this from an appeal to values. The Westrum construct is operationalised as six statements, scored on agreement: that information is actively sought; that messengers are not punished when they deliver news of failures or other bad news; that responsibilities are shared; that cross-functional collaboration is encouraged and rewarded; that failures are treated primarily as opportunities to improve the system; and that new ideas are welcomed. Six questions, a numeric baseline, and a defensible way to say whether the condition improved. An institution that will not measure this is not declining a soft initiative, it is declining to instrument a variable its own incident history depends on.

A reader in a security function is entitled to be suspicious of an argument about behaviour, because a great deal of what arrives under that heading is unfalsifiable. So it is worth noting who else is making it.

In October 2024, the Cybersecurity and Infrastructure Security Agency, the Federal Bureau of Investigation and the Australian Signals Directorate’s Australian Cyber Security Centre published a joint guide on safe software deployment. Its conclusion names two approaches for keeping a deployment process inside its safety boundary. The first is to “foster a blameless retrospective (also called postmortem) culture, where teams analyze both positive and negative outcomes by focusing on the processes that contributed to the result, rather than assigning blame to any individual”. It then states the design principle underneath that, in one sentence: “Individual actions should not lead to an incident if the environment and processes are resilient.”

That sentence is doing more work than it appears to. It relocates the question. If an individual action was sufficient to cause an incident, the finding is about the environment that permitted it, and an investigation that terminates at the individual has stopped one step early. This is a technical claim about system design, issued by three national security agencies, and it is the same claim Westrum arrived at from accident research twenty years earlier.

The same guide asks for two further things that are behavioural rather than technical, and are easy to skim past. Organisations should “establish a culture of encouraging staff to report potential problems, even when the problems seem negligible”. And near misses should be treated as real incidents, because they “provide an opportunity to enhance the program without the software manufacturer or their customers experiencing the full negative impact of an actual incident”. A near miss is only available to an organisation whose staff report things that did not go wrong. That reporting is the control. Nothing else in the deployment pipeline can substitute for it.

The underlying construct has a longer empirical history. Amy Edmondson’s 1999 study in Administrative Science Quarterly introduced team psychological safety and tested it in a field study, finding it associated with learning behaviour, of which reporting error is the clearest instance. It is among the most heavily cited papers in organisational research. The relevant point for this argument is modest and specific: the willingness to say that something is wrong varies measurably between teams doing the same work in the same institution, and it is a property of the team’s conditions rather than of the character of its members.

There is one piece of evidence in this argument that is not drawn from published literature. In 2020 Mohd Atasha presented the findings of Malaysia’s Cloud Survey 2020 at the inaugural KL Cloud Maestro Series, on 2 October. The survey was led by Alphaus Cloud in collaboration with Hitachi Sunway and supported by the MDEC Cloud Department, MAJECA, MASSA, UUM, PIKOM and Integra. It was an online survey with 105 respondents in senior technology and executive roles, the average participating organisation being around 1,200 people. The survey was run because the industry data the organisers wanted did not exist.

Two findings have been on the public record since. Half of respondents named missing skill sets as the largest gap after adoption. Four in five named scalability as the principal benefit they were seeking.

Those two answers came from the same people about the same programmes, and read together they describe something other than a technology problem. The capability being bought was the ability to create infrastructure quickly. The constraint being reported, by the buyers themselves, was human capacity. Nobody in that sample said the technology did not work. They said their organisations could not absorb it at the rate they were adopting it.

The FinOps document on this site reads the same finding as a security argument, and it holds: thin operational capacity plus rapid creation is the condition under which unowned resources accumulate. Read for this document, it says something adjacent. When practitioners were asked what was hardest about a major technology change, the answer they gave was about people, and it was the largest single gap they identified. That was 2020, about cloud adoption. The recommendations in the other three documents here make heavier demands of an organisation than a migration does.

The limits of this evidence should be stated. The surviving recording is a short extract showing the summary slide, so it does not display the skills and scalability figures, which rest on his own record of the presentation. The slide records a three-week fielding period where the presenter says about two. The exact question wording is not published. Those are the same caveats carried in the FinOps document, and they are repeated rather than dropped, because a number reused in a second argument is not thereby better attested.

The literature offers stage models, most famously an eight-step sequence, and they are usually introduced with the claim that seventy per cent of change initiatives fail. That statistic should be treated with care. Mark Hughes examined its provenance in the Journal of Change Management in 2011 and found the figure repeatedly asserted and attributed without traceable empirical support. This document declines to use it, and declines the stage models with it, on the grounds that a site inviting readers to check its claims should not build on a number that cannot be checked.

What can be offered is narrower: a set of properties that make a recommendation acceptable to the organisation that has to act on it. Each follows from something already established above.

Establish the reporting condition before the assessment, not after. If the Westrum items score badly, the assessment will return a shorter list of problems than the estate contains, because the people who know about them have accurately judged the consequence of saying so. An assessment conducted in that condition is not a measurement of the estate, it is a measurement of what is currently sayable. Six questions, asked first, tell you which of the two you are about to buy.

Separate the finding from the person. The joint guidance already states the principle: individual actions should not lead to an incident if the environment and processes are resilient. Applied to an inbound pathway approved in 2014, the finding is that change control assessed whether access was justified and nothing assessed what remained listening afterwards. That is a structural gap with an owner who can fix it. The same fact expressed as a person’s error is unactionable, because the only available remedy is a reprimand and the pathway stays where it is.

Make the first admission at the top. The demand in each of these documents is that somebody concede an error. The cheapest way to establish that this is survivable is for the most senior person present to do it first, about their own decision. This is the least technical item on the list and it is the one that most reliably determines whether the rest proceeds. It cannot be delegated downward, because its entire content is who was willing to go first.

Ask for the near miss, and treat it as a finding. Near misses are the only cheap information an organisation gets, and they exist solely where people report things that did not go wrong. An institution that can produce a list of near misses has already demonstrated the reporting condition, and one that cannot has answered the question whether it is present.

State the limits of the recommendation in the recommendation. Every document on this site carries a section on what it does not solve. That is partly honesty and partly a practical device: an argument that names its own boundary invites disagreement about the boundary rather than about the author, and disagreement about the boundary is a conversation that can end in a decision.

This argument does not work where the information is unwanted. There are institutions in which the absence of reported problems is the desired state, because a reported problem creates an obligation to spend. Nothing in this document changes that, and an adviser who claims to be able to should not be believed. What can be done is to name the condition accurately and let the sponsor decide, rather than delivering an assessment whose optimism is an artefact of what nobody would say.

The evidence is associative and its direction is not fully established. Westrum was careful about this himself, writing that the relationship between culture and safety “requires more exploration before the connection can be considered definitive”. It remains plausible that organisations performing well can afford to handle bad news generously, rather than that handling bad news well causes the performance. The practical consequence is a limit on what may be promised: improving the reporting condition is not a lever that produces a predictable delivery outcome, and the six items are a diagnostic rather than a dial.

None of this substitutes for the technical work. A generative culture with no asset inventory still has no asset inventory. The claim here is only that the three technical arguments on this site have a common precondition for being acted on, and that the precondition is usually left unexamined while the technical content is debated. The precondition is not the work. It is what determines whether the work gets done.

Finally, this document is at an earlier stage than the other three. It is published at version 0.1 with its structure and its cited argument in place, and it awaits the first-hand account named in the section above. That is stated here rather than inferred from the version number, because the same standard applied to the other documents applies to this one.

Mohd Atasha, The recommendation nobody acted on, version 0.1, revised 2026-08-09. Available at mohdatasha.com/doctrine/the-adoption-problem/