Organisational Engineering: A Complex Name for a Simple Idea

The meeting starts exactly on time.

Twelve people sit around the table. Laptops open. Coffee cups within easy reach. Someone apologises for joining remotely. Someone else reminds everyone that another meeting starts in fifty minutes.

The chair opens with a familiar sentence.

“So… we’ve got a recurring problem.”

Everyone nods.

The problem itself isn’t new. In truth, that’s why everyone is here.

A customer has complained again.

Invoices are taking too long.

Projects keep slipping.

People are duplicating work.

Take your pick. The details don’t really matter because you’ve probably sat in this meeting yourself.

Almost immediately, the conversation turns to solutions.

“We need another checkpoint.”

“What if we changed the process?”

“Perhaps another team should own it.”

“IT might be able to automate that.”

Somebody suggests training.

Someone else thinks communication is the real issue.

The discussion is intelligent. Everyone contributes. Nobody is deliberately defending poor practice.

And yet something feels wrong.

You can’t quite explain it.

You leave with actions.

The meeting has produced decisions.

But as you walk back to your desk, a quiet thought lingers.

I don’t think we’ve actually discussed the problem.

We’ve discussed what happened.

We’ve discussed what people did.

We’ve discussed what we’ll do next.

But nobody asked why the organisation keeps producing this outcome in the first place.

That feeling stayed with me for years.

At first, I assumed I simply enjoyed solving problems.

Then I realised something uncomfortable.

I wasn’t especially interested in solving them.

I was becoming fascinated by where they came from.

Not the immediate cause.

The deeper one.

The organisational one.

Because organisations are extraordinary things.

No one ever intends to create unnecessary approvals.

Nobody consciously designs duplicate spreadsheets.

No executive stands in front of their leadership team and proudly announces, “Let’s build a process that takes three months longer than it should.”

Yet these things appear everywhere.

Almost as though organisations have a gravity of their own.

The more I observed, the more I noticed that organisations leave clues.

A spreadsheet maintained by one person because the official system can’t answer an important question.

A weekly report that everyone produces but nobody reads.

An approval stage whose original purpose has long since been forgotten.

A manual workaround passed from one colleague to the next like family folklore.

These aren’t random inefficiencies.

They’re evidence.

An archaeologist learns about an ancient civilisation by studying the objects it leaves behind.

Perhaps we can learn about organisations in the same way.

Every workaround.

Every unofficial process.

Every exception.

Every strange rule.

They’re artefacts.

They’re telling us something about how the organisation has evolved.

And once you start seeing them, you can’t stop.

The interesting thing is that other professions already think this way.

When an aircraft crashes, investigators don’t begin by asking, “Who made the mistake?”

They reconstruct the system.

Training.

Maintenance.

Cockpit design.

Weather.

Communication.

Fatigue.

Procedures.

Human factors.

The accident is rarely explained by a single error. It emerges from a system that quietly allowed that error to become consequential.

Medicine has travelled a similar road.

For decades, mistakes were often attributed to individual clinicians. Today, hospitals routinely examine handovers, checklists, equipment layout, communication and workload because experience has shown that competent people can produce poor outcomes inside poorly designed systems.

Engineering has always understood this.

Civil engineers don’t simply reinforce a cracked bridge.

They ask why the load reached that point.

They study the structure before they prescribe the repair.

Somehow, organisations often escape the same curiosity.

We redesign the process before we’ve understood the system.

We replace the people before we’ve questioned the incentives.

We introduce technology before we’ve examined the behaviour it is supposed to support.

What if we approached organisations differently?

What if, before proposing a solution, we became investigators?

What if we learned to read organisational artefacts in the same way a structural engineer reads stress fractures?

This is the idea I’ve started calling Organisational Engineering.

The name sounds technical.

The practice is remarkably simple.

Observe before you intervene.

If you want to try it yourself, don’t begin with the process map.

Begin with curiosity.

The next time you’re in one of those meetings, resist the temptation to suggest a solution.

Instead, ask questions like these.

What behaviour is the organisation rewarding?

If this problem keeps returning, what is the system designed to produce?

What unofficial work exists that never appears on a process map?

What assumptions have become invisible simply because “that’s how we’ve always done it”?

If we hired a new employee today, which parts of this process would we struggle to explain?

Who benefits from the system remaining exactly as it is?

These questions don’t produce immediate answers.

But they often produce something far more valuable.

A different conversation.

Perhaps organisational engineering isn’t really a new discipline at all.

Perhaps it’s simply the habit of looking beneath the surface.

Because once you begin to see organisations as systems rather than structures, something remarkable happens.

You stop asking why intelligent people keep making poor decisions.

You begin asking why intelligent people keep producing exactly the outcomes the organisation is quietly designed to create.

And that, I think, is a much more interesting question.