About
The route from software engineer to chief information officer, and the way of working that came out of it.
From software engineer to CIO
I started as a software engineer, writing Java and administering Oracle databases for a consultancy in Lisbon. Getting from there to running information systems for a retail group was not a leap. It was a sequence of responsibilities that kept getting larger: from code to projects, from projects to operations, from operations to a budget, and from a budget to strategy.
Ten of those years went into building and leading the IT department at AKI. That is where I learned that retail technology is judged in a store on a Friday afternoon, not in a steering committee. When AKI and Leroy Merlin came together the scale changed: two information systems, two support models and two store networks to converge into a single architecture, measured against ADEO's international standard.
The period at Chemonics International was short and formative. Running global technology operations behind international procurement, logistics and health supply-chain programmes means working with stakeholders spread across time zones, and treating data security as an operating requirement rather than a project.
Since 2021 I have been CIO at Grupo Mosqueteiros in Portugal, accountable for information systems, data, AI, cybersecurity and digital transformation across 11 business areas and corporate functions, around 370 stores, 220 fuel stations, four logistics platforms and roughly 14,000 users.
How I lead
My job is not to run the best technology. It is to make sure every euro spent answers a priority the business can name out loud, and that the result is measured in real usage rather than by a go-live date.
That means saying no. A portfolio that accepts everything is not a portfolio, it is a waiting list. The hard part of governance is not approving things; it is declining them and explaining the reasoning to the person who asked.
It also means owning the operation. A CIO who only talks strategy loses the room on the day the store network goes down. The standing to argue about a three-year roadmap is earned by keeping the estate up every day.
Business, technology and people
Business, technology and people fail in the same place every time: translation. The business states a problem in the language of process, technology answers in the language of systems, and the distance between the two gets paid for in rework.
I work that translation in both directions. For an executive committee, architecture, risk and technical debt become investment decisions with dated consequences. For engineering and delivery teams, a corporate priority becomes the concrete criterion that lets them choose between two equally defensible designs.
People are the third side, and the side that decides the outcome. A system that is delivered and not adopted is a cost, not a capability. Change management therefore lives inside delivery — training, follow-through, usage measured — rather than in a session at the end of the project.
Boards and international stakeholders
I have reported to executive committees and worked with boards for as long as I have carried a technology budget. What a governing body needs is not technical depth. It is a decision presented with its alternatives, its cost, its risk, and a plain account of what happens if nothing is done.
International context has been a constant. At ADEO I represented Portugal in Digital and Data governance forums and workshops; at Grupo Mosqueteiros, working with the group's international structures is part of the role. I work in Portuguese, English and French, and in Spanish at the same level.
A group operating across countries requires a permanent balance between the shared standard and local reality. The standard buys scale, coherence and negotiating power; local reality is where the customer actually is. An architecture decision that ignores either side does not survive first contact with the operation.
Operating principles
Three rules applied consistently, and open to being argued with.
Technology serves a business decision
Every investment has to answer an explicit priority. Without that link, a project delivers software rather than an outcome.
Governance before scale
Scaling without governance multiplies the problem. Principles, architecture and decision rules first; volume afterwards.
Adoption is the result
A system nobody uses is not delivered. The measure is real usage and realised benefit, not a go-live date.
What I bring
In short, and without the padding:
- 23 years in enterprise technology, with leadership responsibility and a budget since 2008.
- A complete transformation arc: systems convergence, ERP and platform modernisation, data and artificial intelligence, cybersecurity and operational excellence.
- Genuine scale — 11 business areas and corporate functions, around 370 stores, 220 fuel stations, four logistics platforms and roughly 14,000 users.
- Habitual executive reporting and international governance, across four working languages.