Meet the Four

The hidden behavioural patterns that decide every senior hire. Once you see them, you can't unsee them.

The board thought they had found the perfect CEO.

Two successful exits. 

A scaled multinational division. 

References that read like a character witness: decisive, commercially sharp, a natural leader. 

In the interview he was confident, fluent, convincing on growth and culture and transformation. The appointment was unanimous.

Twelve months later the same board was negotiating his exit.

Revenue targets had been missed. 

Two strong executives had resigned. 

Decisions were slowing down because information had stopped flowing upward, and the CEO had grown isolated, frustrated by resistance, doubling down on top-down control.

He had the competence. He had the experience. What undid him was how he behaved once the pressure was on.

As the market tightened and investor scrutiny rose, he reached for a familiar pattern: centralise the decisions, bypass the team, treat challenge as disloyalty. What everyone had read as decisiveness in the interview room hardened into rigidity in the role.

The numbers told the story late. The behaviour told it early.

The problem wasn't skill. It was schema.

So what is a schema?

It is the most useful idea I have come across in twenty years of placing senior technology-focused leaders.

Every leader I have ever placed has a default. Most have never been told what it is.

I am not talking about a personality type, a Myers-Briggs box, or one of those reports that gets handed over at the offer stage and quietly filed in HR. 

A schema is the set of assumptions a leader carries about how to lead. Who should be in charge. How decisions get made. What good looks like when the pressure is on. We rarely say these things out loud. Most of the time we don't even notice them. 

We just act on them.

And that matters because of what assumptions are. Personality is close to fixed: the person you are at eighteen is broadly the person you are at sixty. Assumptions are different. They can be surfaced, questioned and changed. So a schema is something you can actually work on, which is the whole reason it is worth talking about.

It describes, and it predicts

A schema does two jobs at once.

It describes how a leader operates when the room is calm. And it predicts what they reach for when the room gets rough.

Schemas tighten under pressure. The behaviour that is mild and manageable on a good day rises up and takes over on a bad one. The directive leader becomes more directive. The careful one slows right down. The visionary climbs higher, further from the ground.

That predictive part is what most assessments miss. Psychometrics tend to tell you who someone is. A schema tells you who they become when the stakes climb, and in senior appointments that second answer is usually the one that decides whether the hire works.

After enough placements, the same four patterns start to appear. Different industries, different titles, different ambitions, the same four shapes underneath.

Here they are.

The Commander

The Commander is who we picture when someone says the word leader.

They orchestrate. They make the call and move the team in one direction. When a business genuinely needs decisiveness, and plenty of moments do, the Commander is the schema you appoint.

Then the pressure climbs and the Commander stops listening. The directives sharpen. Dissent goes quiet. The room keeps moving but stops thinking. The Commander is not a worse leader for it. This is simply the schema, doing what it does when the stakes are high.

The Architect

The Architect builds systems.

They design the team, the process, the operating model, all of it interlocking. The work they leave behind tends to outlast them, because that is how it was built.

Under pressure, the Architect goes deeper into the design at the very moment the business needs a decision. Another week of analysis. Another workshop. The call never quite gets made, because good enough was never the bar they were built to clear. The most expensive senior failure I have watched up close was an Architect running an organisation that needed a Commander.

The Servant

The Servant holds the room together.

They develop the people around them and earn trust at every level. They are often the quiet engine of an organisation, the one whose work ends up credited to other people, and in the right context they turn a competent team into a high-performing one.

Under pressure, the Servant reaches for consensus when a hard call is needed. Everyone gets heard. Nobody gets a decision. The moment passes. The Servant is also the schema hiring committees most often overlook, because they mistake quietness for absence. That is a costly misread.

The Visionary

The Visionary sees the shape of the future before the rest of the room does.

They set direction and reframe the problem. They inspire the people who can already follow them, and that last part matters, because the Visionary's blind spot is assuming everyone is already following.

Under pressure, the Visionary climbs higher. The strategy gets bolder. The operational ground gets further away. The field they are pointing at stays empty until somebody else steps in to fill it.

No one is purely one of the Four

Every leader I have assessed has a dominant schema and a supporting one.

The dominant is the default, the behaviour that fires when the room is busy and the leader isn't consciously choosing. The supporting one comes in when the dominant has been running for a while, or when the leader is deliberately stretching.

The pairing matters as much as the dominant. A Commander who is also an Architect runs a tight ship and designs the process beneath it. A Visionary who is also a Servant sets the direction and holds the team together while everyone catches up. A Commander paired with a Visionary is the classic founder. An Architect paired with a Servant builds the kind of organisation that quietly endures.

No pairing is best. There is the pairing that fits the problem the business is solving, and then there is everything else.

Why this matters when you are hiring

For boards and CEOs, this raises an uncomfortable question.

The same job title, CPO, CTO, COO, MD, can demand a completely different schema depending on what the business actually needs. A CPO inheriting a mature product organisation that needs steady evolution is a different hire from a CPO inheriting a feature factory that has to be rebuilt from the inside out.

Most senior hiring failures I have watched up close began with the brief. The candidate was rarely the real problem. The brief never pinned down what the business was solving for, so it never surfaced the schema the role actually required. The shortlist got assessed on credentials. The safest-looking name in the board pack got the offer. Eighteen months later the postmortem reached its usual conclusion: we hired the right person for a different job.

So on every mandate my first question is the same. Not the job title. What problem are you solving by hiring this person? Once that is answered properly, the schema you need has a habit of writing itself.

Why this matters if you are the leader

If you are the one being hired, the value of knowing your schema comes down to one thing: regulation.

The Architect who knows they default to over-analysis can put a Commander in the room to force the decision. The Commander who knows they default to control can ask the question they would normally just answer. The Visionary who knows the field goes empty can hire the Architect who will fill it.

This is the part I find genuinely hopeful. A schema is developable. 

These are assumptions, picked up over a career, and assumptions can be examined and adjusted. The leaders I have placed who aged best as appointments were rarely the ones with the highest IQ or the most polished CV. They were the ones who knew their own default and built a team around them that could spot it before they did.

Where this framework comes from

I want to be straight about where this thinking comes from, because the structure behind it isn't mine.

For twenty years I have had what I think of as the best seat in commerce: a ringside view of how senior leaders succeed and fail under real pressure, with real money and real reputations on the line. I learned to work around these patterns long before I could name them. 

Defining the problem a hire is meant to solve, refusing to trust a track record without understanding the conditions it was won in, that was me navigating schemas on instinct, without the language for any of it.

The language has come from Ian Stewart, a social psychologist who has spent years studying how people actually behave under pressure rather than how they say they will, including a spell teaching at Sandhurst. Ian took the patterns that practitioners like me had only ever felt our way around and gave them rigour and a genuinely predictive edge. 

The Four are his.

Ian has a book on all of this coming out in October, The Hidden Patterns of Leadership, published by Routledge. He was generous enough to allow me to contribute a chapter from my “practitioner's” side of the table. Over the months ahead I am going to walk you through the whole framework, with Ian's work as the backbone and two decades of placements as the evidence.

What comes next

In the coming issues I will take each of the Four in turn: the behaviours, the way each one tightens under pressure, and the contexts where the schema thrives or quietly destroys value.

Then I will turn the lens around. 

How to interview for the schema rather than the CV. 

How to brief a search properly before anyone writes a job spec. 

And why some environments demand a completely different schema from the one that looks impressive on paper.

Before your next senior conversation

If you asked the people who work with you to name which of the Four they see in you when the pressure is on, which one would they pick?

And would you agree with them?

---

If this resonated, subscribe and stay with the series. And if you are scoping a senior appointment right now and can feel the brief drifting toward "what is the role" rather than "what is the problem we are solving," that is exactly the conversation I would welcome.