Timothy Pomaville

I'm a multidisciplinary engineer with roots in Chemical Engineering and a career that's run through automotive, chemical, and aerospace manufacturing. That operational background isn't incidental. It shapes how I build data systems. I understand the processes the data describes, not just the pipelines that move it. I know what it means when a sensor goes offline, or a batch job fails, because I've been in the plant when it happens. This perspective drives me to build data platforms that aren't just technically robust, but operationally resilient and aligned with the realities of manufacturing environments.

Over the past six years I've moved deeper into platform and data engineering, designing and operating Kubernetes-native infrastructure for data-intensive workloads. My stack spans GitOps with ArgoCD, secrets management with Vault, SSO with Keycloak, and a full ML/data platform: Spark, Airflow, MLflow, Trino, JupyterHub, Metabase, deployed on self-hosted Kubernetes and secured end-to-end. I care about the layer that lets teams move fast without breaking things: reproducible deployments, automated security scanning, experiment tracking, and self-service tooling that doesn't require a platform ticket to use.

Most of my recent work sits at the intersection of manufacturing operations and modern data engineering: the space where OT historians, process data, and ML pipelines finally start talking to each other. I run Morning Star Engineering, a consultancy focused on that problem, and I'm always open to interesting work in the same vein.

My Take On AI

AI makes me faster. It doesn't make me smarter. That part is still on me. The real work in data/software engineering has never been writing code. It's understanding what the data represents, why a process behaves the way it does, and what the system actually needs. That requires domain knowledge and engineering judgment built over years, not tokens. I use AI as a tool, the same way I'd use any other. The thinking, the architecture decisions, the trade-offs: those are still mine. And in manufacturing and other domains, where bad assumptions don't just create bugs but can affect safety, quality, and yield, that distinction matters.