I’ve been sitting with a question from my PhD research that I think every board and executive team should be asking out loud, not just in the risk committee: when we hand more strategic power to technical systems and the people who build them, are we choosing wisdom, or are we just choosing whoever is loudest and fastest?

Plato and Aristotle spent their careers arguing about exactly this, and 2,400 years later, boardrooms are still running the same experiment.

Start with Plato. In the Republic, he makes a case that still unsettles people today: the ones best qualified to lead are not the most technically skilled, the most popular, or the most confident. They’re the ones who have trained themselves to see past the “shadows on the cave wall” and grasp what is actually good, not just what is expedient. His philosopher-king is unpopular precisely because Plato didn’t trust expertise on its own to produce wise decisions. Technical mastery, he warned, can just as easily serve a bad end as a good one.

Sit with that for a second in a 2026 context.

We are increasingly letting the people with the deepest technical fluency in AI, data, and platforms make decisions that used to sit with boards: what gets automated, whose job that changes, what a model is allowed to infer about a customer, how much autonomy a system gets before a human has to sign off. That’s not necessarily wrong. But Plato’s challenge stands: technical skill and good judgement are not the same capability, and an organisation that quietly lets one substitute for the other is making a governance decision, whether it names it as one or not.

Aristotle pushes back on Plato in a way I find more useful for actual strategy work. He wasn’t interested in a single ruling class of the wise. In the Nicomachean Ethics, he argues that good judgement, phronesis, practical wisdom, isn’t something you’re born with or hand to one person at the top. It’s built through repeated, deliberate practice, and it shows up as the ability to find the right response in a specific, messy, particular situation. Not a rule. Not a checklist. A calibrated judgement call, made in context, by someone who has done the work of practising it.

That’s the piece I think most technology governance gets backwards. We reach for frameworks, checklists, and compliance sign-offs because they’re auditable and they feel like safety. Aristotle would call that a mimicry of virtue rather than the real thing. A checklist can tell you a box was ticked. It can’t tell you whether the people in the room had the practical wisdom to know when this particular case, this specific model, this specific rollout, was the exception the checklist didn’t anticipate. And in my experience advising on technology strategy, it’s almost always the exception that causes the damage, not the pattern the framework was built for.

So here’s where I land, and where I’d genuinely like to hear where you land too.

Plato says: don’t confuse technical fluency with fitness to govern. Someone needs to be answerable for the good, not just the capability.

Aristotle says: don’t confuse a policy document with wisdom. Judgement has to be practised, in the room, on real decisions, or it never actually develops.

Put together, they suggest something most boards aren’t doing yet: treating ethical and strategic judgement about technology as a skill to be deliberately built in your leadership team, not a document to be approved once and filed. A philosopher-king who never practises judgement is just as dangerous as a technologist with no one asking what the good outcome actually looks like.

Two questions for discussion, because I’d rather hear disagreement than agreement here:

  • Where in your organisation does “we followed the framework” quietly stand in for “we exercised judgement”?
  • And who, right now, actually has the standing to say no to a technically sound decision because it’s the wrong one?

I work with boards and leadership teams on exactly this kind of question, building the practical judgement Aristotle described into how technology decisions actually get made, not just how they get documented. If this is live for your organisation, I’d welcome the conversation.