About Me¶
The person behind the systems
From operations to production ML¶
I'm Duque Ortega Mutis, based in Mexico City, and I am making my first formal career move into ML/MLOps.
My previous career was not technical by title, but it was technical in practice: I spent 14 years coordinating people, budgets, vendors, customer pressure, deadlines and process failures. That work taught me to value systems that are clear, measurable and usable by the next person responsible for them.
That is why this portfolio is built around production habits rather than only model scores. I am seeking my first formal ML/MLOps role, but I am not new to ownership, trade-offs, documentation or operating under pressure.
How to read my seniority
First formal ML/MLOps role — experienced in ownership, pressure, cost-awareness and making systems easier for other people to operate.
The Route¶
Fourteen years of context, two years of code.
-
2026
Template, governance, certification¶
TripleTen DS certificate. Open-source production template with governed AI-assisted development. Preparing GCP Associate Cloud Engineer and AWS ML Engineer Associate.
-
2025
Three services, three incidents¶
BankChurn, NLPInsight and ChicagoTaxi built, tested (395+) and deployed to GKE + EKS. The serving failure, the SHAP zeros and the impossible HPA scale-down — measured, root-caused, documented.
-
2024
The deliberate pivot¶
Full-time retraining into data science and machine learning — TripleTen Data Science program.
-
2010
Operations leadership¶
Fourteen years coordinating teams of 5–10 (peak 20), budgets up to $20K USD, vendors, customer pressure and process failures. The origin of the cost discipline and the documentation habit.
Operations Experience In Numbers¶
What Operations Taught Me About Engineering¶
Systems fail at the handoffs, not in the happy path. A budget is a design constraint, not an afterthought. Documentation is what makes a system usable by the next person responsible for it. And when something breaks, you measure before you guess — because under real pressure, guessing is the expensive option.
I like practical systems, clear ownership and honest measurement. If a model metric looks too good, I want to check for leakage. If an API fails under load, I want the root cause, not a workaround. If a cloud setup costs more than the value it provides, I want the trade-off written down.
Simple working principle
Build the smallest system that proves the operating idea, then make the evidence clear enough that another engineer can review it.
The Toolbox¶
Every tool below was used in at least one of the three production services — not listed from a tutorial, but from working code with tests, incidents and ADRs.
Model training, evaluation and explainability — including original-space SHAP and promotion gates.
Async inference, single-worker serving, metrics-driven scaling and CI/CD gates for promotion.
GKE and EKS paths built in the same monorepo, with delegated credentials only — Workload Identity and IRSA.
Data workflows built for honest evaluation: temporal validation, leakage gates and drift signals.
Education And Certifications¶
Formal ML training
Data Science Professional Program — TripleTen¶
Completed in 2026. The formal training layer behind the portfolio: applied machine learning, data workflows, evaluation and project delivery.
In progress
GCP ACE · AWS ML Engineer Associate¶
Preparing both cloud certifications — one per cloud, matching the multi-cloud evidence already in the portfolio (GKE + EKS, Terraform, Workload Identity / IRSA).
AI Transparency¶
This portfolio was written with AI-assisted tooling for drafting and documentation. Every architectural decision, trade-off, and debugging conclusion is my own — the reasoning trail is in the ADRs and incident writeups, not in the tool that helped type them.
Links¶