About Mark
I help good companies get unstuck.
Software companies rarely lose momentum all at once. It happens gradually. Priorities multiply. Ownership blurs. Architecture gets harder to change. Teams spend more time coordinating and less time delivering.
That is the work I know best. I come into complex situations, find the constraints that actually matter and help the organisation move through them. Sometimes that means reshaping a product portfolio. Other times the job is rebuilding engineering delivery, separating a platform out of its parent company, or turning AI ambition into something customers and teams can genuinely use.
I started as a software builder and never lost the instinct to make things. Over more than 25 years I have led product and technology through startups, founder-led companies, listed businesses and large software organisations. I have been a CTO, CIO, divisional CEO and product executive. The titles matter less than the pattern underneath them: I go where the building has stalled, and I stay until it is moving again.
I do not hand over a strategy and disappear. I stay close to the decisions, the teams and the delivery until the change has traction.
What I bring
I have run the same kind of transformation enough times to recognise the pattern early, and I have enough technical depth to ask questions engineers take seriously. I am comfortable in the board conversation and in the architecture review. The gap between those two rooms is usually where the real problem is living.
Why leaders trust me
I say what I see, without creating drama around it. I make complexity legible, treat people with respect and remain accountable for what happens after the decision. The aim is not dependency. It is a stronger organisation that can keep moving after I step away.
Still close to the work
Through ByteJam, I build software products and experiment with AI. That hands-on practice keeps my thinking honest and connects executive decisions to the reality of shipping.
How I think
Execution over theatre.
Strategy matters. It only becomes valuable when it changes decisions, behaviour and what reaches the customer.
Start with the constraint, not the org chart.
Make fewer promises, then keep them.
Treat APIs as business capabilities, not plumbing.
Use AI to change the work, not decorate the roadmap.
Build capability that remains after I leave.
Let’s talk
Tell me what isn’t moving.
No pitch deck required. A little context about the business, the constraint and what you have already tried is a good place to start.