I’m Director of Data Products at Elfie, a Series A HealthTech startup (~110 people) in Vietnam. I built the data platform from scratch: multiple external and internal data sources consolidated into BigQuery through dbt, with data quality testing and documentation built in from day one. The platform serves pharma partner reporting for Servier and Sanofi, internal operational dashboards, and anonymized patient datasets (two full rounds of GDPR-compliant anonymization with an external specialist). I also built a cardiovascular economic impact dashboard used in presentations to pharma country heads and government health delegations. Not all of the work is a dashboard. When I found that three core tables had silently stopped rebuilding for weeks, I didn’t hotfix it: I forced the ownership question. The result was an explicit data-engineering ownership boundary across regions and a completed repo transition with a hard cutoff, executed within the week. Deciding who owns what, and making the decision stick, is the part of the job that scales a company past the point where one person can hold it in their head.

I’ve been building with AI since before it was called AI engineering. I trained LSTM models in 2018 (the write-up I published on tuning them has 192K views). I built a GPT-3 chatbot four months before ChatGPT launched. I co-founded an AI company in early 2023 and built agentic workflows before the term existed (chaining model calls, structured outputs, multi-step pipelines, all from scratch). Today I build my own engineering harnesses on top of tools like Claude Code, run custom MCP servers, and think about how AI changes company operations at a structural level, not just which tasks you can automate. The leverage I care about isn’t shipping faster alone: it’s that a harness lets a whole team, people and agents together, move at that speed with the evidence discipline to prove the output actually works.

The question I keep coming back to: most companies want AI, but very few have the data foundation to make it work. AI doesn’t fix broken operations. It makes the good ones faster and the bad ones more expensive. That’s where I start.

I’ve built a data team from 1 to 12 people across data management, analytics, and engineering. The training was a designed program, not ad-hoc: three to four workshops (Python for automation and analysis; a structured feedback protocol built on Schulz von Thun’s four-ears model and the Johari window; running effective meetings; public speaking) paired with stretch-project assignments and weekly or bi-weekly one-on-ones, modeled on my own learning pattern plus the pointers I’d lacked. What it produced: someone with no engineering background became a senior Python engineer at FPT Software inside 18 months; another went from a law firm (where she solved in two days an accounting-analysis task E&Y had quoted at three weeks for three people) into a special-operations unit of the Vietnamese Finance department; another is a senior data engineer at a Danish company. I’m honest about the mechanism: this is selection and acceleration, not creation. But the acceleration was real, and it was designed. I care about building organizations that produce results, not just tools that run queries.

I commit fully when there’s a real problem to solve. I spent four years building a data organization from scratch, and I’ve walked into a failing enterprise engagement and turned it around by fixing how the team worked under pressure. What I don’t do is coast. I target growth-stage companies for a reason: when a company is scaling, the problems keep evolving. You build the platform, then you need real-time capabilities. You hire the team, then you need to grow the team. The systems have to expand, the people in leadership have to grow with them, and there’s always a next thing to figure out. That’s the environment I’m built for.