Engineers love their animal metaphors, and I am no exception. The quickest way to get me to read about a new technology is to claim it’s based on how some sort of obscure creature gathers stones. However I have always thought there is a distinct hierarchy to the animals of tech: actually useful things are based on bugs, slugs, and other such slimy organisms, while anything that references a large charismatic predator like a tiger or a shark is almost certainly a scam (these are also the favourite animals of venture capitalists, naturally)

Pictured: a role model. (Photo by Elize Bezuidenhout on Unsplash)

I am of course, joking. Mostly. But it’s worth taking a look at what differentiates these two (very broad) groups and how they relate to how we build our systems and organisations. Megafauna, a group that includes elephants, tigers, humans and most likely the animal you are thinking of right now, are the cruise liners of animals. We are small in number, vast in size, and require a mind-boggling quantity of resources to keep going. Large does not mean invincible though: struggling against gravity and thermodynamics as we do requires constant effort by many complex, specialised organs, and when we fall, we fall hard.

An insect, by contrast, cannot afford complexity. Each additional neuron takes up precious calories, precious space inside a shell that has none to spare. But while nobody would call a beetle a creature of intelligence, it is an incredible example of efficiency and robustness. Rather than devoting millions of neurons to the task of staying upright, a beetle simply has a body that won’t fall over (and if it does, will likely roll back over on to its feet). It is capable of scrambling over almost any obstacle not by understanding it, but by simply persisting until one of its legs finds purchase. The result may look mindless, but it works better than any robot humankind has ever built.

So how does this relate to us? A common problem I see in organisations, particularly tech-focused ones, is trying to solve complexity with more complexity. A new tool is acquired with dozens of options (more options = more value) that most employees don’t need or shouldn’t have, so to prevent incidents another system has to be built on top of it. This system of course requires management, documentation, a budget… before long a single overambitious adoption can become a major source of administrative bloat. It’s hard to reverse course once this has begun, but much easier to ask if a shiny new toy is solving problems that actually exist. Because if it’s not, it’s probably manufacturing new ones.

Don’t over-complicate things
Walk like a beetle