A career shaped by the life of a commerce product

Mandate

Lead consumer software engineering and the capabilities needed to turn commercial ideas into examinable digital products.

Outcomes

• Resolved eighteen commercial interpretation disagreements before approving a promotional implementation.
• Stopped a compromised experiment from becoming the basis for a feature decision.
• Separated fourteen basket interface releases while retaining four explicit backend dependencies.

Decisions in context

My CTO role brings together product engineering, architecture and the capability to evaluate a change. The present employee and contractor counts describe today's remit; the spending authority is explicitly for 2026. I report to the CEO and work with commercial owners on the intended meaning of a feature. Our CIO retains enterprise applications and infrastructure, so shared work requires agreed responsibilities rather than competing claims to the same decision. Recent programmes have concerned promotional examples, trustworthy experimentation, physical constraints in search and product-image accuracy. Each requires software specialists to understand a business condition without assuming they own the policy behind it. I also present investment and product questions to the company's directors, while holding no board seat. The role has reinforced my view that a credible technology account should explain both the freedom a design creates and the dependencies a later team must continue respecting.

Reason for the move

Current executive appointment after responsibility for the wider software-engineering portfolio.

Mandate

Balance customer-product work, shared platform renewal and the engineering capability needed to measure and support changes.

Outcomes

• Established portfolio discussions that included measurement work alongside visible product features.
• Clarified responsibilities for shared software interfaces across product teams.
• Made continuing platform obligations visible in annual engineering plans.

Decisions in context

As vice-president I had to compare investments whose benefits appeared at different times. A new customer feature could attract attention immediately, while better instrumentation or a clearer shared contract might prevent an expensive misunderstanding much later. I worked with product leads to explain those differences without pretending they were interchangeable units of output. The final 2021 remit comprised 156 employees, five direct reports and €38 million annual authority. Solmerive's ownership changed during this period, and the investment conversation increasingly required a clear account of what the engineering organisation could sustain. I reported to the CTO rather than serving as an independent decision maker for every technology question. This appointment prepared me for the next role by making resource choices, team boundaries and the quality of product evidence part of one discussion. It also taught me to retain the limitations of a result when shortening it for an executive audience.

Reason for the move

Promoted to CTO to connect the product-engineering portfolio with company strategy and executive decisions.

Mandate

Develop shared commerce capabilities while defining their responsibilities to the product teams using them.

Outcomes

• Introduced review of the dependencies created by shared platform proposals.
• Established clearer ownership of common calculation interfaces.
• Brought product teams into the discussion before shared changes entered delivery plans.

Decisions in context

Platform leadership changed how I understood reuse. A shared capability could remove duplicate work, but it could also concentrate decisions and make a local change dependent on several teams. I learned to examine both consequences before describing an architecture as simpler. By the end of 2015 I led sixty-eight employees through four direct reports, with €12 million annual authority. Those figures reflect the scope reached during the appointment, not its starting size. I reported to the technology director and worked with product owners to identify what belonged in a shared capability and what could remain specific to a customer journey. The most useful conversations were often about responsibility: who could change a rule, who needed to know and what evidence would show that the change preserved its intended meaning. That experience became the basis for my later emphasis on explicit contracts and honest accounts of product independence.

Reason for the move

Moved into vice-presidential leadership as the software portfolio and engineering organisation expanded.

Mandate

Build and sustain commerce software that translated campaign requirements into understandable customer behaviour.

Outcomes

• Used concrete basket examples to clarify requirements with commercial colleagues.
• Retained the reasoning behind campaign-specific software decisions for later teams.
• Developed a small engineering group into an accountable continuing product team.

Decisions in context

Joining a retailer allowed me to remain close to a product after its first delivery. A campaign did not end the software's life; its assumptions returned in later offers, new interfaces and questions from colleagues. I began using concrete examples to discuss those assumptions with the people who understood the commercial intention. By December 2009 I led twenty-four employees through three direct reports and held €3.8 million annual authority. I reported to the head of digital technology. The company context was thirty-four stores and 2,100 employees, much smaller than the organisation described in my present role. I learned to build a team that could explain its choices after the original author was no longer in the room. The subsequent platform appointment grew from that work, extending responsibility from individual commerce features to the common capabilities and coordination needed by several developing products.

Reason for the move

Promoted to lead commerce platforms as more products depended on common software capabilities.

Mandate

Implement and test commercial software requirements while learning to clarify their meaning through practical examples.

Outcomes

• Developed repeatable test examples for commercial calculations.
• Raised ambiguous requirements before implementation decisions became fixed.
• Built a grounding in software delivery and collaboration with nontechnical colleagues.

Decisions in context

I joined Corvanel Systems in July 1995 after completing my computer-engineering degree the previous month. I was an engineer in an eight-person team, with no direct reports or delegated budget. The employer's 420 employees and €52 million revenue describe its scale in 2002, not a business I managed. My work involved implementing requirements, testing calculations and asking colleagues to explain the situations the software needed to handle. Early confidence in a repeatable answer gradually became curiosity about whether it answered the right question. That change in perspective was important to my later career. I wanted to understand how software behaved after delivery and how the next commercial request exposed earlier assumptions. Moving to Solmerive gave me that continuing product context, while the habits of careful examples and explicit questions remained useful as my responsibility expanded beyond writing the code myself.

Reason for the move

Joined a retailer to take continuing responsibility for commerce products beyond a delivery assignment.