Narrative Timeline
Professional Experience
How the scope evolved
Not a second CV. This page shows how the scope widened over time: from teaching and research, into consulting under constraints, and then into engineering management for applied ML systems, model evaluation, reliability, and live data products.
🧭 Professional Arc
From research and teaching to Engineering Management for applied ML systems
This page is intentionally not a second CV. It is the story of how the same pattern kept widening: make complex work understandable, turn ambiguity into structure, and build the teams, interfaces, evaluation loops, and operating models needed to make ML useful in production.
- 🎓 Research roots
- 🏗️ Production ML
- 📐 Model eval/replay
- ⚙️ Streaming architecture
- 👥 Engineering management
- 🏛️ Standards work
✨ What Changed Along The Way
- Early years: explaining and teaching I learned to break complex ideas down clearly and help others build confidence in technical subjects.
- Consulting years: delivery under ambiguity I learned how messy systems, unclear requirements, product pressure, and client constraints reshape "correct" engineering.
- Current years: management and leverage I now focus on people leadership, research-to-production ML delivery, evaluation loops, operational quality, stakeholder alignment, and repeatable delivery systems.
2010–2016
Foundations
teaching, research, communication
teaching, research, communication
🎓 Teaching, doctoral work, and the habit of clarity
KCL · UCL · GSM · David Game College
Associate Lecturer · Coding Teacher · TA
Before I was responsible for production systems, I spent years teaching and researching, which is where I developed the habit of explaining difficult ideas simply and structuring technical work carefully.
What I was doing
- Teaching Java, Python, MATLAB, HTML, CSS, SQL, AI, systems, and data structures.
- Completing doctoral research in persuasion dialogues, opponent modelling, and large knowledge graphs.
- Working close to formal methods, graph reasoning, and research-driven problem solving.
What stayed with me
- Technical communication is a force multiplier.
- Good systems thinking starts with clean abstractions.
- Explaining something clearly is often the best test of understanding it.
04/2016–12/2020
Consulting
shipping under constraints
shipping under constraints
🏗️ Consulting became the bridge from data science to technical leadership
Data Reply
London, UK
Data Scientist → ML Engineer → Senior Consultant
This was the period where model work became inseparable from delivery discipline. I joined the London spin-off as its first consultant, grew into a Senior Consultant, helped the team scale, and learned to turn enterprise constraints, client goals, and production expectations into deliverable ML/data systems.
Representative client work
- Client delivery: led client meetings, scoped goals, facilitated technical delivery, placed consultants, interviewed, mentored, and contributed to Data Reply's growth from a small founding team to 30+ consultants.
- 🏦 UBS: graph analytics, process mining, and real-time insight pipelines with Kafka, Elasticsearch, and Python; learned XP/pairing practices and later became the sole embedded Data Reply consultant.
- 🚜 CNHi: lead data scientist / Scrum Master for predictive maintenance on Azure/Databricks, translating stakeholder needs into a DS/DE backlog and guiding a PySpark team over live telemetry.
- 📱 Vodafone: led technical delivery across multiple workstreams, worked on Infinity, a GCP data-science platform based on Kubeflow, and built Red Agent, a mobile-network feature-engineering framework.
What this phase taught me
- Most ML failures are systems failures, not modelling failures.
- Ambiguous environments are where architecture and product discipline matter most.
- Bridging DS, engineering, and product is a delivery problem as much as a technical one.
- Good managers create feedback loops that make specialists faster, safer, and less dependent on individual memory.
12/2020–present
Management
teams, systems, reliability
teams, systems, reliability
🚢 Vortexa: managing teams and live ML/data systems at scale
Engineering Manager / ML Systems Lead
London, UK
Architecture · Delivery · People
At Vortexa, the centre of gravity shifted again: from delivering components to owning engineering strategy and delivery for a live ML/data estate, setting operating standards, managing 6 direct reports, and leading a 10-person cross-functional team around model quality, reliability, stakeholder alignment, and delivery maturity.
What I lead
- 6 direct reports across Product, SME analysis, Data Science, and Data Engineering, plus leadership of a 10-person cross-functional team.
- Performance and career development, hiring for 6 roles, delivery accountability, sprint reviews, retrospectives, mentoring, and code pairing.
- Workshops across Product, SMEs, analysts, and engineers to turn model-quality disputes into shared definitions, measurable objectives, interface/SLA proposals, and OKR-linked workstreams.
- Team practices that reduce single-person ownership: clearer ownership, pairing, docs close to code, tests-as-docs, and onboarding that makes new joiners productive in production code quickly.
What the estate requires
- A live ML/data estate processing roughly 6M vessel-position records/hour into production intelligence for 13.5K monitored vessels.
- 0-to-1 research-to-production delivery for destination and arrival-time sequence/transformer models in PyTorch.
- MLflow, model/data versioning, automated evaluation gates, replay, monitoring, and model-serving workflows.
- Batch/online model-evaluation and replay loops; failure-mode analysis with domain experts and Product to drive model, data, and interface improvements.
- Kafka Streams-to-Flink as a strategic platform move, with signal-quality controls, rollback/fallback paths, shared on-call, and MTTR under 30 minutes.
- Data contracts, repo archetypes, AWS CodeArtifact publishing, ADRs, dev containers, and local E2E tests to reduce ambiguity and improve delivery feedback loops.
🏛️ Beyond The Core Role
Standards and research
- Since 01/2021 · ISO/CEN-CENELEC JTC 21 WG3
Committee Expert Member contributing to AI standards aligned with EU policy and international norms, including auditability, model/data versioning, explainability, and safer adoption. - Since 10/2024 · UCL Department of Information Studies
Associate Researcher helping expose students to practical AI applications and lecturing on AI standardisation, the AI Act, auditability, versioning, explainability, and safe adoption.
🎙️ Public Work
Talks and interviews
- 2026 · Skeleton runtime evidence
Published a public article on Promet, Skeleton, runtime evidence, and the harness around applied GenAI systems. - 2026 · skeleton-replay
Published skeleton-replay and a JetBrains plugin for turning Python runs into traces, architecture snapshots, workflow evidence, and replayable reports. - 2023 · Agile in Action
Podcast interview on agile data science and the Vortexa journey. - 2022 · ODSC
Industry talk on dynamicio, a published PyPI library for abstracting I/O in ML systems. - 2020 · iunera & Big Data Warsaw
Interview and conference talk on agile data science and graph-driven analytics. - 2018 · Connected Data London & Minds Mastering Machines
Panel and talk appearances on graph AI and doing data science the agile way.
📐 Through-Line
What has remained constant
- Production is the only truth.
- Models need evaluation, replay, monitoring, and graceful failure paths.
- Responsible AI is partly engineering work: auditability, explainability, ownership, and human accountability.
- Standards set teams free when they remove avoidable ambiguity.
- System quality should scale through clear ownership, evidence, and repeatable practice.