Background
In 2012 I founded Seven Technologies — an engineering services company. In 2016 a co-founder joined, and together we’ve since built it to a team of 25+ engineers. Over more than a decade, we’ve delivered full-stack development, cloud infrastructure, and digital transformation work for international clients across the UK, EU, India, and the Middle East.
Running a services company that long teaches you something that pure consulting doesn’t: you live with the consequences of your own decisions. A system you architected in 2015 is still your responsibility in 2020 when it needs to scale. An engineering culture you built in year one shows up in every hire you make in year five. That accountability shapes how I think.
What I actually specialise in
The honest answer has shifted over the last few years. I’ve always been strong on engineering organisation and architecture — but the work I find most valuable right now sits at the intersection of AI tooling and engineering culture.
I call the methodology Harness Engineering: the discipline of shifting engineers from writing code to designing the environments, scaffolding, and feedback loops that enable AI coding agents to produce reliable, production-grade output. This is not about replacing engineers. It’s about fundamentally changing what the engineer’s job is.
In practice, that looks like:
- Intent specification over implementation — clear prompts, AGENTS.md files, and structured in-repo documentation so AI agents can execute autonomously without constant hand-holding
- Repository as source of truth — moving knowledge out of Slack threads and people’s heads into versioned, machine-legible artefacts
- Feedback loop design — CI checks, automated tests, and verification gates that let AI agents self-correct before a human reviews
- Human-as-architect — the engineer designs the environment and asks “what capability is missing?” rather than writing every line
I’ve introduced this approach across my own engineering teams at Seven Technologies, and it’s the primary thing I help client teams adopt through 124Tech.
The first-principles habit
Most technology problems aren’t technology problems. They’re workflow problems that have accumulated technical debt around them.
Before reaching for a solution, I want to understand the actual constraint. What does this organisation need to be true? What would the system look like if we designed it knowing what we know now? That question is sometimes uncomfortable to ask — but it’s consistently the one that leads to solutions that don’t need replacing in two years.
Why 124Tech
Seven Technologies continues to run. 124Tech is the vehicle for a different type of engagement: fractional CTO work, AI strategy advisory, and hands-on team training with companies that want to move seriously on AI-first engineering — not just add AI tools to their existing workflow.
The companies I work with through 124Tech tend to need one or more of three things: senior technical judgment they don’t have in-house, a structured path to AI adoption, or someone to help their engineering team operate at a different level of leverage.
I work with a small number of clients at any time. If something here resonates, the best next step is a 30-minute conversation.