Delivery Track Record

Twenty years of building software and running the teams that ship it. This page covers the leadership and delivery side. For consultancy, audits and architecture work see Architecture & Audits. For the recent payments and blockchain contracts see Mastercard MDES and Starknet.

Role Progression

Developer → Lead Developer → CTO (Folk Digital, UK) → CTO (Shero Commerce, US) → Senior Solutions Architect → Delivery and architecture consulting

Each step widened the scope rather than replacing what came before. I still read the code. I just spend more of my time on the decisions that sit above it.

CTO · Folk Digital (UK) and Shero Commerce (US)

Two chief technology officer roles at digital agencies, one either side of the Atlantic. Both were owner-level positions: I sat in the room where the commercial and technical direction got decided, and I carried the consequences.

What I owned:

• Engineering headcount, hiring and mentoring across distributed teams of up to 20
• Platform architecture for client builds and internal products
• DevOps, CI/CD, environment strategy and release process
• Delivery standards, estimation, code review culture and definition of done
• Technical due diligence on new business, including which work to turn down

Distributed by default. The teams spanned multiple countries and time zones well before it was standard practice. That means async handover, written decisions, and process that survives people being offline for eight hours at a stretch.

Agency Delivery

Enterprise e-commerce delivery for brands with real revenue on the line and no tolerance for a bad release.

Client work included:

• Wedgwood · heritage retail, international catalogue
• Hackett London · premium menswear, multi-territory storefronts
• Turnbull & Asser · luxury retail, bespoke ordering journeys
• MADE.COM · high-volume furniture e-commerce
• Pernod Ricard · global drinks brand, brand and campaign platforms

What that delivery involved:

• Scoping and phasing programmes with fixed launch dates
• Integrating platforms with ERP, PIM, payment providers and fulfilment
• Performance work under peak trading load
• Migrations where the old system had to keep running until the new one was proven
• Stakeholder management across marketing, trading, IT and the board

The pattern that repeats: the technical problem is rarely the hard part. The hard part is a client with a launch date, three stakeholder groups who want different things, and a legacy integration nobody has documented. That is the job.

How I Run Delivery

Scope. Get the shape of the work agreed in writing before anyone estimates it. Most overruns I have seen were scope disputes wearing an engineering costume.

Decisions. Write them down, with the reasoning and the discarded options. A decision nobody can reconstruct in six months gets relitigated in six months.

Cadence. Short feedback loops, working software early, and a release process boring enough that nobody dreads Fridays.

Escalation. Bad news travels fast or it compounds. I would rather tell a client in week two that the date is at risk than in week nine that it has gone.

Handover. Every engagement ends. The measure of a good one is whether the team can carry it without me.

Team Leadership

• Hiring, onboarding and progression for engineers at all levels
• Mentoring leads into their first management roles
• Code review and quality standards that raise the floor without stalling delivery
• Performance conversations, including the difficult ones
• Keeping engineers close enough to the commercial context to make sensible trade-offs on their own

What I look for in a team: people who flag problems early, write things down, and can explain their work to somebody outside engineering. Those three habits are worth more than raw output.

Next

→ Architecture & Audits for consultancy and technical review work → Mastercard MDES and Starknet for the recent infrastructure contracts → Contact to discuss a role