The Most Dangerous Phrase in Business: “It’s Common Sense.”

“It’s common sense.”

Every time I hear that phrase, I roll my eyes a little.

It usually arrives immediately after somebody has made a mistake that the organisation had ample opportunity to prevent. It sounds like an explanation, but it functions as blame.

After all, who decided that the relevant knowledge was common? Common to the founder? Common to a junior employee? Common to a contractor who joined three weeks ago? Common to somebody who has worked with a particular client for eight years?

Was the rule explicit? Was it available somewhere? Could the person see it at the point where they made the decision? Did the organisation’s tools and processes support the supposedly obvious behaviour?

When leaders say “it’s common sense”, they often mean: “I expected you to notice, remember, and correctly apply something we never actually turned into a rule.”

This matters because many businesses still run on the assumption that sensible people will somehow infer the right answer from context. That approach becomes increasingly fragile as organisations grow, people join and leave, work becomes more complex, and artificial intelligence begins acting within the same environment.

AI has no common sense. Humans, frankly, are patchy.

Designing for the Average Human 

So let’s talk about a place where no common sense seems to exist. The airport passenger terminal.

I have spent a great deal of time in airports throughout my career, from tiny regional airports to enormous international hubs. As the daughter of one Air Traffic Control Officer and the wife of another, I have spent my life resisting becoming an airport nerd. The resistance is becoming less successful.

Airports are extraordinary systems.

They can take somebody who has never been on an airplane before and get them, safely and more or less efficiently, to the correct destination on the other side of the world. That traveller has not completed an airport training course. They do not understand baggage logistics, aircraft tail numbers, air traffic control, gate allocation, or airside vehicle movements.

They recognise a flight number, follow some signs, and arrive at a gate.

This is particularly impressive when you consider how people actually behave in airports.

Passengers stop dead immediately after stepping off an escalator. They change direction without warning. They walk diagonally through a crowded terminal while staring at a boarding pass. They form an impatient queue as soon as the first boarding announcement is made, regardless of their group number or whether boarding has even started.  They have 7:00am pints of beer because they're in an airport.  

Airport security also appears to surprise people on every visit. Belts contain metal. So does the handful of change in your pocket. The litre bottle of water is still a liquid.

I often think humanity collectively loses around 20 IQ points every time it enters an airport.

Airports are designed with this in mind. They are designed for actual humans, rather than the attentive, well-rested, emotionally regulated and fully informed passengers that a designer might prefer.

Good systems are resilient to ordinary human stupidity.

That deserves to be unpacked fairly. Most of the time we are not being unusually stupid. We are distracted by duty free, tired because we spent half the night worrying that we would sleep through three alarms, stressed by travelling with family, unfamiliar with the language, or are simply following the herd because everybody else seems to know where they are going.

Most people are wonderfully average. Great systems do not rely on everybody delivering exceptional cognitive performance all day.

The strongest systems go further than resilience. They become antifragile. Mistakes, near misses and unexpected behaviour are used to improve the system. A warning changes. A procedure is altered. A permission is tightened. A route is redesigned. Organisational learning becomes part of the infrastructure.

Airports and aviation embody accumulated knowledge in signage, sequencing, announcements, markings, access boundaries, technology, procedures and physical design. Passengers, luggage, aircraft and airside vehicles move through a series of linked systems that carry much of the cognitive load.

The airport is built to remember so that passengers do not have to.

Many businesses are built the other way round. They leave knowledge in people’s heads, then blame individuals for failing to retrieve it, or failing to recognise that they needed to retrieve it, at exactly the right moment.

The Burden of Invisible Knowledge 

What leaders call common sense is usually something else. It may be experience, commercial judgement, learned organisational norms, professional scar tissue or knowledge of a particular client. It may be a preference that has gradually hardened into an unofficial rule and become reinforced by workplace culture.

None of this is common. It has all been acquired.

“Common sense” is what organisations call institutional knowledge when they haven’t bothered to write it down.

Even writing it down only gets us so far.

Institutional knowledge does not become operational control because somebody mentioned it in a meeting. Businesses routinely confuse communication with control. An email is communication. So is a passing comment during a meeting, or an updated policy sitting somewhere on SharePoint. None of these becomes a control unless it changes what somebody can see, know or do when the decision is being made.

Telling is an event. Control is a system.

I have seen versions of the same pattern throughout my working life.

An employee receives a perfectly plausible request from somebody they reasonably understand to be a client. The request might involve helping with a document, producing a piece of analysis or refactoring some code. Helping clients is culturally rewarded. The person asking appears entirely entitled to make the request, and there is no visible warning that the engagement has ended, the work falls outside the current sprint or agreed scope, or additional authorisation is required.

So the employee does the work.

Later, they are told that working for a client who is out of contract, accepting work that had not been agreed, or changing code outside an authorised sprint demonstrated a lack of common sense.

The supposed rules may have existed somewhere. Somebody may have mentioned the contract status during a meeting. The sprint boundaries may have been discussed elsewhere. The preferred method of collaborating with clients may be understood by experienced staff, despite never having been formally documented. Expectations about when to escalate may exist largely within the organisation’s culture.

Communication Is Not Control 

The employee was not expected to apply common sense. They were expected to reconstruct an undocumented operating model from fragments.

To be fair, they might have taken better notes. They could have asked more questions. That does not turn a collection of passing remarks and disconnected conversations into a reliable control environment. Nor does it mean the individual bears no responsibility. The more important question is why the organisation has designed commercially significant boundaries around memory, inference, and personal confidence.

Culture affects the outcome as well. Some organisations reward people for asking whether a request has been authorised. Others place a higher value on appearing capable, responsive and certain. In the latter, a junior employee may worry that asking a basic question will make them look incompetent or obstructive. The same invisible operating model produces very different behaviour depending on whether curiosity is encouraged or uncertainty is punished.

Organisations tend to respond to these failures in one of four ways: blame, rescue, document or design.

The Maturity of Organizational Response 

Blame individualises the failure. Somebody should have used more common sense. The incident is treated as a one-off and the organisation learns nothing.

Rescue usually follows. An experienced person swoops in, fixes the immediate issue and restores order. The hero feels useful. The organisation remains dependent on heroes.

Documentation is genuine progress. A policy, checklist or procedure creates organisational memory. It is necessary, although insufficient. Somebody still has to know that the document exists, find it, read it, recognise when it applies, interpret it correctly and remember it at the point of action.

Design puts the relevant information and control where the work actually happens. The correct path becomes easier. The dangerous path requires a deliberate override or approval.

Documentation tells people what the organisation expects. Design helps the system produce it.

Systems thinking is the discipline of moving knowledge from people’s heads into the environment around them.

Blame, rescue, document and design are not four neat categories of organisation. Most organisations use all four at different times. Organisational maturity shows in which response becomes the default. An organisation that routinely blames the individual and waits for an experienced hero to rescue the situation is more fragile than its leaders probably realise.

Solving the client example does not require a 40-page offboarding policy or an enterprise platform supported by twelve process managers.

It requires a small chain of linked controls.

Every client engagement needs a visible status, such as active, paused, closing or closed. It needs an owner, an end date and a clear statement of what work is currently authorised. That information must live somewhere people already work, such as the customer relationship management system, project register or delivery platform. A spreadsheet hidden in a leadership folder does not count.

When an engagement closes, something should happen. The project may close to new time entries. The delivery workspace may become read-only. Shared channels may be archived or clearly marked. The person responsible for approving any further work should be visible.

If a former client contacts a friendly employee for help, the employee then has an easy route:

“This engagement is currently closed, so I’ve sent the request to the account owner to confirm scope and authorisation.”

The same principle applies to code. Work that is outside an agreed sprint or change process should be visible as such before somebody begins refactoring it. The delivery system should surface the missing authorisation, route the request correctly or require an explicit approval.

The employee no longer needs to reconstruct the commercial position from memory. The system carries it.

The minimum viable version is simple: one status, one owner, one trigger, one route for exceptions and one control at the point of work.

Then the organisation needs to learn. When a near miss or breach occurs, the useful questions concern the system. Was the status wrong? Did the closure trigger fail? Was the information invisible? Was the escalation route unclear? Was the workaround easier than the approved route?

This is where resilience becomes antifragility. The mistake improves the system that allowed it.

AI and the Limits of Invisible Knowledge 

Back to AI.

AI has no common sense. It acts using the data it can access, the instructions it has been given, the tools and permissions available to it, the patterns it detects, and the feedback it receives.

It will not reliably know that a client is “sort of finished”, that a particular collaboration method is frowned upon but undocumented, or that an exception made by a senior employee should not become a precedent.

AI therefore exposes the places where organisations depend on invisible knowledge.

Making a policy available to an AI model may tell it what it ought to do. System design determines which data it can access, which clients are active, which actions it can execute, when approval is mandatory, how exceptions are routed, what is logged and how an action can be stopped or reversed.

A prompt is telling. A control is design.

Good systems must also be resilient to ordinary AI stupidity. AI will misunderstand instructions, apply the wrong pattern with confidence, and find new ways to be incorrect. The objective cannot be to eliminate every error. The objective is to make errors visible, contained, and survivable, then use them to improve the system.

If your controls cannot survive ordinary human behaviour, why would they survive ordinary AI behaviour?

When an AI makes a mistake, will your organisation contain it, detect it and learn from it? Or will somebody complain that the correct answer should have been obvious?

Knowledge can live in several places. Knowledge in people is fragile. Knowledge in documents is durable, provided that anybody can find it. Knowledge embedded in the working environment is usable. Knowledge embedded in active systems becomes adaptive, because it can guide behaviour, enforce boundaries, and change as the organisation learns.

Airports distribute knowledge and controls across all four. Their strength comes from people, procedures, technology, permissions, physical design and repeated operational routines working together.

Systems Thinking vs. Common Sense 

The opposite of common sense is not stupidity. It is systems thinking.

The next time somebody says that a mistake should have been prevented by common sense, resist the temptation to nod along. Ask where the relevant knowledge lived, whether it was visible at the point of action and what made the correct behaviour easier than the incorrect one.

If the answer is that somebody mentioned it in a meeting, you have not found an incompetent person.

You have found an unfinished system.