Ideas
The Logician-Engineer Method
My engineering background still shapes the way I work. When a transformation is struggling, my first instinct is to understand how the different pieces connect before recommending another tool, process or programme.
I look at the data, the processes, the technology, the organisation and the people who will have to make it work. Over time, I started referring to this way of working as the Logician-Engineer Method.
It is not a product and there is nothing proprietary about it. It comes from having done the job from three different positions: building HR systems in my first years, running an HR department that depended on systems built by other people, and now carrying commercial and delivery responsibility for transformation work.
Working principles
Evidence
I prefer evidence to opinion. Not every executive decision can be reduced to a number, but data helps make assumptions visible and gives a team something concrete to discuss.
Architecture
I tend to favour solutions that are understandable, maintainable and dependable over something impressive in a demonstration but difficult to operate.
People
A solution only creates value if people can actually use it in the reality of their work.
01. Diagnose
Before proposing a solution, I want to understand where the problem actually sits. It is rarely where the complaint is. A reporting issue often turns out to be a question of who owns the data. What looks like resistance to a new tool is often a process that was never simplified.
So I go through the same five areas each time, and try not to settle on the first explanation that sounds convincing.
Data
What the definitions are, who owns them and whether the quality is good enough to rely on.
Processes
What the process is supposed to be, what people actually do, and why the workaround exists.
Technology
The architecture, the integrations, and the constraints that are not going to move.
Organisation
Roles, skills and where responsibility really sits, which is not always where the org chart puts it.
Governance
Who decides, how quickly, and what happens when two sponsors want different things.
02. Architect
Once the problem is clear, I work through how the processes, systems, data and responsibilities need to fit together. This is the part that gets squeezed when a programme is behind schedule, and it is expensive to redo later.
What I am looking for is a design precise enough to be costed, argued with and turned down. "HR closer to the business" is an intention. A service model with named responsibilities and a data model behind it is something a committee can approve.
The HR model
What HR does centrally, what stays local, and what it stops doing altogether.
Systems
The core system and the tools around it, what gets configured and what is left standard.
Data
Where each piece of information comes from, and what happens when two systems disagree.
AI
Where it genuinely helps, what it needs from the data, and what a person still decides.
Running it
Who operates the result day to day, with which skills, at what cost.
03. Make it live
A good design is not enough. Someone still has to use it, manage it and make decisions with it. In my experience this part gets far less attention than the work of reaching go-live, and it is where the benefits are either realised or quietly lost.
What that means in practice is fairly ordinary: a group that keeps making decisions after the project team leaves, responsibilities written down before they are contested, skills built before they are needed, and a few measures agreed in advance, including the ones that would tell you it is not working.
Why three positions matter
An engineer asks whether the system holds together. An HR leader asks whether people will live with it. Whoever carries the budget asks whether the numbers work. I have sat in all three seats, and programmes get into trouble when only one of those questions is being asked seriously.
What this is, and is not
This is how I work, built up on real programmes and adjusted along the way. It is not a certified framework and it has not been validated by independent research. Judge it on whether it holds up against your own situation.
Applied to talent, skills and AI, the same way of working becomes the frameworks and, at book length, The Death of Skills.
Start a conversation
I am open to selected executive opportunities, strategic assignments, speaking and academic collaborations across EMEA. If any of that fits, write to me.
- Executive and leadership opportunities
- Strategic transformation and advisory
- Speaking and media
- Teaching and academic collaboration