Skills

A live view of where the work has actually been done. Each word is a skill, sized by how often it appears across my roles and projects with a slight bias toward recent work. Similar skills cluster together.

Technical Skills

Levels here reflect honest depth of production delivery, not exposure. The "Evidence" column links to the project or role where the skill was used at that level.

Languages

Frameworks and libraries

Architecture and systems

Cloud, DevOps, and infrastructure

Practices

• TDD / BDD end-to-end, including Gherkin DSLs that double as ISO 13485 / IEC 62304 audit artefacts.
• Contract testing with Pact across 8 global teams (BrightInsight digital health) — 40% reduction in cross-service bugs at dunnhumby.
• DORA metrics, change-failure rate, MTTR as first-class outcomes.
• Compliance-driven CD: daily releases against ISO 13485, IEC 62304, HIPAA, GDPR, MDSAP — rules encoded in code, gated in CI.

Leadership Skills

I've led delivery for organisations of up to 200 engineers while staying 20–30% in production code at every seniority level, including principal. The "Evidence" column points to the role or project where each behaviour was concrete and accountable, not theoretical.

Leadership areas

My leadership style

I partner with specialists rather than around them. The best abstractions I've built came from sitting next to the people who lived in the domain — underwriters at BrightInsight, clinicians on the HL7 feedback loops at Philips, restaurant operators wiring EPOS printers at Just Eat. Their constraints shape the design, and the lead engineer's job is to translate those constraints into patterns the team can carry.

I stay hands-on. At principal level that's an unfashionable choice in some organisations, but I've found that the decisions I make as an architect erode quickly if I'm not the one paying for them in the editor. 20–30% production code at every level is the rule I hold myself to.

I treat delivery practices as part of the architecture. TDD, contract testing with Pact, observability-first design, GitOps reconciliation — these aren't process overhead, they're the things that let small teams own large surfaces without becoming a coordination problem. At BrightInsight that meant 8 global teams composable through Pact contracts; at dunnhumby it meant contract testing cutting 40% of cross-service bugs.

I'm comfortable with difficult conversations. Most of the regulated work I've led — Crown Prosecution Service integration at Blackthorn, ISO 13485 / IEC 62304 audit cycles at BrightInsight and Philips, FCA reporting at Alpari — requires saying "no" or "not yet" to delivery shortcuts, and then having the credibility to propose a better path. Credibility comes from being in the code, knowing the domain, and being honest about trade-offs.

I lead curiosity from the front. Most recently that's meant shaping AVEVA's organisational practice around agentic coding (GitHub Copilot CLI, Claude Code, ChatGPT Codex) via the Hypervelocity Engineering initiative — not because the tools are trending, but because they materially change what a small team can deliver in a sprint.

Domain Expertise

Across 25 years I've gone deep enough in a handful of domains to write code, defend designs, and pass audits in each. The breadth is part of the point — patterns translate across industries — but confidence calibration matters, so this table is honest about where the depth lives.

Where I would not claim depth

• Pure quant / market-making algorithmic trading. My FinTech work has been platform, reporting, and pricing infrastructure — not strategy R&D.
• Game engine / real-time rendering. Sports-app CMS work at Miomni is the closest I've been, and that was data and streaming, not engines.
• Embedded / firmware. Medical IoT at Medisanté was device-adjacent (Java-on-device, MQTT to AWS) — not bare-metal C.
• Foundation-model training. I integrate LLMs and run agentic workflows; I'm not training base models.

Skill Evidence Map

This table is for honest calibration: which file is the strongest evidence for a given skill, how confidently I can speak to it, and where I would not overclaim. It's also the reference the AI assistant on this site uses to ground answers in concrete projects rather than vague resume language.

Strongest evidence themes

• Regulated platforms shipped at daily-release cadence. Pair compliance with continuous delivery, not against it. BrightInsight, Philips, Medisanté, Blackthorn.
• Cross-domain pattern transfer. DDD, CQRS, event sourcing, reconciliation loops, declarative IaC, GitOps — same patterns shipped in C#, Go, Rust, TypeScript, Python, Java, and Swift across nine industries.
• Hands-on principal-level leadership. 20–30% production code at every level. Architecture decisions backed by being the person paying for them in the editor.
• Domain-expert partnership as a design technique. DSL work at BrightInsight and Thoughtworks; HL7 feedback loops at Philips; EPOS reverse-engineering with restaurateurs at Just Eat.

Weak or developing areas

• Foundation-model training and pure ML research. I integrate and operate models in regulated systems; I don't train base models. Stanford / DeepLearning.AI Supervised ML cert (2025) is the formal grounding; the practical depth is in pipelines, not theory.
• Rust as a primary language. One year on a real production system; growing, not yet deep.
• Pure quant / algorithmic trading R&D. My FinTech work is reporting, pricing infrastructure, and risk platforms — not strategy research.
• Embedded firmware / bare-metal. Medical IoT was device-adjacent (Java + MQTT), not C-on-microcontroller.
• Mobile native at current depth. Swift / Kotlin / Java / Xamarin work is real but era-bound — I'd lean on partners for a 2026-current native mobile delivery.
• Active security clearances. SC and CTC were held during specific engagements and are renewable; both currently lapsed.