Expertise · 03
HR technology, from the systems up
I came to HR technology through the systems themselves, not through slides. That still changes the questions I ask about architecture, data and AI.
I spent my first years at Royal Air Maroc on the build side: implementing HR Access for the group and around ten subsidiaries, working with roughly five developers and twenty HR specialists on modules, interfaces and data.
A few years later I was running an HR department, and I was the one depending on those systems to work. Today I look at HR technology from both sides, which is mostly what I am useful for.
From code to boardroom
I am not a full-time engineer today and I do not present myself as one. What that early period gave me is harder to pick up later: I can sit in an executive committee and know what a technical answer will cost in practice, and sit with an architect and know what the business answer implies for them.
The questions I keep coming back to
Most of my work on HR technology and AI comes down to a small number of practical questions. They sound simple. They are usually the ones that have not been answered.
- What problem are we actually solving, and for whom?
- Is the data good enough to support it, and who owns that data?
- How does this connect to the systems already in place?
- What changes for the person who has to use it on a Monday morning?
- Who owns the decision the system is helping to make?
- What happens when it gets something wrong?
Where I work
HRIS architecture
Core HR and the tools around it, and what belongs in the system of record. Settling this late is what makes integration expensive.
Data and integration
Data models, master data ownership, flows between systems, and the reconciliation rules nobody wants to write down.
AI and automation
Where automation removes work, where it simply moves the work somewhere less visible, and how to tell the difference before signing.
Generative AI and agents
What these approaches change in an HR process, what they need from the data, and which controls have to exist first.
People analytics
Measures an executive committee can act on, built on definitions that hold up when finance asks where the number came from.
AI governance
Who decides, what gets reviewed by a person, what is explainable, and where the line sits between helping a decision and making it.
Process design
Simplifying a process before automating it. Automating a bad process tends to make it permanent.
Adoption
Skills, roles and measurement. This is usually what decides whether any of the above produces value.
What it changes in practice
- I assess vendor demonstrations on the architecture behind them rather than the interface in front of them.
- I treat data work as a prerequisite, not as a parallel workstream that gets compressed at the end.
- I sequence AI ambitions against the actual state of the data, so a pilot that works can be scaled.
- I design governance alongside the architecture rather than after the first incident.
More on how I approach a programme in the method, and related writing in Insights.
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