The physical vs. the philosophical approach

Can you relate to the situation: you're in a meeting. Internal. Someone shares that they have observed something worth improving in the organisation, an inefficient process, a piece of friction. After very little back and forth, just shortly before you are confident everyone is actually talking about the same thing, it happens: someone suggests the problem can be solved by implementing a tool. Within seconds, the discussion shifts: to alternative tools, to the challenges in rolling out the tool, to adoption, to who could own it … and never returns to fully understanding the problem or exploring the full solution space.

In a recent Zeit magazine podcast interview with Markus Gabriel, the discussion touched on an interesting point: the difference between the physical and the philosophical perspective. The physical looks at how things work, how they are connected, why they work. Philosophy does something very different. It asks, "what's the point of all this?".

There are a million tools out there. We can introduce a new software, we can buy an add-on workflow, we can have someone vibe code a solution. But more often than not, we end up with one more thing to click and to maintain. One more dead silo of data, knowledge, and wasted time.

What we should be asking is the philosophical question. What, really, is the point of all this? By doing so, we can try and put our need, as humans, as organisations, back into the center of the discussion.

Wendell Berry, in his 1987 essay "Why I won't buy a computer", sums up what he perceives as a tool use fallacy:

“[...] I do not wish to fool myself. I disbelieve, and therefore strongly resent, the assertion that I or anybody else could write better or more easily with a computer than with a pencil.”

You don't have to be as radical as Berry. There are a lot of things a good tool can fix. But more often than not, your problem lies elsewhere. Maybe your team has the wrong priorities. Maybe no one has quite agreed on what the organisation is actually trying to achieve - which means there's nothing to design your processes against in the first place. Maybe decisions don't stick, and the tool becomes just another arena for the same unresolved argument. Maybe the management team isn't paying enough attention. Or maybe it's more mundane: compliance tasks that never stop growing, legacy software no one touches, processes so bloated no tool is going to save them.

Once you've solved the why and come back to the how, maybe you can actually look to Berry for advice, in what he calls his "standards for technological innovation":

The new tool should be cheaper than the one it replaces.
It should be at least as small in scale as the one it replaces.
It should do work that is clearly and demonstrably better than the one it replaces.
It should use less energy than the one it replaces.
[...]
It should not replace or disrupt anything good that already exists, and this includes family and community relationships.

The language may sound a bit old fashioned, but I believe the criteria to be quite valid in a world where tools are ubiquitous and most things digital can be changed in a second. Our human speed, cognition and attention are not just the limiting factor in new tool adoption. Attention is also increasingly the most precious resource in the organization, and you should be careful what you ask your team to turn it to.

So next time you're in that meeting, inhale, exhale. Call for a pause, and channel your inner philosopher.